5.6 Endpoint Capability and Representation Selection

A Direct address used as an identity-bound identifier identifies a party within the applicable trust context. A Direct address used as an Endpoint supplies a means of communication. The same address MAY serve both purposes, but using it for one does not establish its use for the other. The Routing Target is the address selected for the current Direct message and may differ from the Information Recipient’s own address.

The Information Recipient remains the party for whom the Shared Activity is intended when the Routing Target belongs to an Intermediary or a shared organizational workflow endpoint. Endpoint selection SHALL reflect the intended recipient and required transaction capabilities; an address alone establishes neither a participation role nor authority to accept or reject the structured payload.

Endpoint Semantics and Capability

A discovery process can locate the Information Recipient’s organizational affiliation and an endpoint designated for the use case. For example, Dr. Smith may have an individual Direct address while the organization provides a preferred endpoint for the required notifications. Applicable routing rules select that organizational endpoint as the Routing Target. If no suitable organizational endpoint is available, the individual address may be used when its capabilities and the applicable rules support the exchange. Retain the Information Recipient’s identity separately from the Routing Target. The DirectTrust Directory is the authoritative source for discovering an endpoint’s CapabilityStatement; the discovered CapabilityStatement is authoritative for declared transaction and Technical Actor Role capabilities. SERV_DESC is human-readable information and does not establish capability. Apply Chapter 4’s discovery requirements.

Resolve the Information Recipient and an authorized Routing Target before constructing representation-specific metadata. The Endpoint Capability Statement declares supported transactions, Technical Actor Roles, metadata representations, information-object options, and workflow status responsibilities. Select a mutually supported metadata representation using Chapter 4’s preference rules, and confirm JSON or XML support where applicable. TX8 normally uses the originating transaction’s metadata representation unless an explicitly established agreement specifies otherwise.

Capability declarations are testable assertions. A declared transaction, Technical Actor Role, and exchange-option combination asserts support for the corresponding functional requirements. Sender Actor and Receiver Actor capabilities, including those for TX8, are declared independently. Supporting an originating transaction does not universally require TX8 Sender Actor or Receiver Actor support; additional obligations may arise under the applicable Transaction Definition or exchange agreement. A separately labeled development-target CapabilityStatement may plan comprehensive testing-tool coverage, but it is not evidence of deployed capability and SHALL NOT be used for operational Directory discovery. Routing or relay capability alone does not authorize an intermediary to accept or reject a structured payload for the Information Recipient Organization.

Workflow Status Update Endpoints

A Workflow Status Update Endpoint is a Direct address eligible to receive a correlated TX8 report when reporting is required for an originating Transaction Instance. It differs from the Routing Target for the outgoing Direct message and from transport reporting addresses. When an originating Workflow Activity Task is present, its applicable workflow-status routing instructions govern endpoint selection. When Task is absent and TX8 reporting is required, the sole eligible fallback is the Direct address established for Message Delivery Notifications, and only if its Directory-discoverable CapabilityStatement declares TX8 Receiver Actor support. Chapter 3 defines the routing requirements; Chapter 4 governs capability discovery.

For a Task-bearing originating payload, Intermediaries preserve applicable Task-carried Workflow Status Update Endpoints and may add authorized endpoints under Chapter 3; deduplicate identical Direct addresses. Before dispatching TX8, verify that each proposed destination’s Directory-discoverable CapabilityStatement declares TX8 Receiver Actor support. If no eligible endpoint can be resolved for a required report, record the reporting obligation as unsuccessful and SHALL NOT attempt TX8 dispatch; this failure SHALL NOT by itself change the originating transaction’s processing outcome. An Intermediary may make the terminal acceptance or rejection decision only when authorized for the applicable workflow; taking delivery or forwarding alone does not establish that authority.

Workflow Status Monitoring Across Organizational Boundaries

The expected workflow status reporting interval starts when the last Intermediary or Sender Actor working on behalf of the Information Source Organization sends to a Routing Target associated with the Information Recipient Organization. Preparation and source-side hops before that organizational handoff are outside the interval. Recipient-side routing, receipt, evaluation, and return of the workflow status report are within it; additional recipient-side hops do not restart the clock.

Where TX8 reporting is required for an originating Transaction Instance, the expected interval is 60 minutes unless an explicit use-case or Information Recipient-specific agreement establishes another interval. Transport MDNs support monitoring of message delivery along the route. A dispatched final-destination MDN establishes delivery of the Direct message, not receipt or acceptance of the structured payload into its intended workflow. Subsequent processing after acceptance is outside the workflow status reporting interval.

When a correlated TX8 report is required but not received within the expected interval, the originating system SHOULD flag the Transaction Instance for follow-up. No report is expected merely because an endpoint supports an originating transaction. Absence of a report SHALL NOT be interpreted as evidence of structured payload acceptance, rejection, or non-receipt. Insufficient information to recover the originating SubmissionSet identifier or an eligible report destination may prevent a correlated report. Chapter 3 and TX8 specify the reporting boundary and requirements.