Repatriation is the SADAR mechanism that bridges Telemetry Records across trust boundaries — returning selected, field-filtered content from where it was issued to parties entitled to receive it. This document covers the mechanics: how parties declare their participation through four Protocol NFRs, how bilateral matching at discovery determines compatibility through the empty-intersection applicability rule, when Repatriation flows trigger relative to span lifecycle, and which fields are structural and therefore non-redactable.
The full wire protocol —submission envelope, field-path syntax, batching, acknowledgment, retry — lives i n the 6. Telemetry Record and Repatriation companion document, repatriation mechanics section. This page is the architectural framing and the negotiation-pattern explanation.
Audience: implementers building agents, tools, or orchestrators that emit or receive Repatriation submissions; architects scoping cross-organizational audit infrastructure; and audit/compliance teams evaluating whether a deployment's Repatriation declarations meet their policy requirements.
The simple case of cross-organizational observability is the single boundary: Org A invokes Org B's agent. A wants to know what happened on its delegated work; A and B are the only entities with relevant artifacts; bilateral mutual access — A returning relevant artifacts to B, B returning relevant artifacts to A — is sufficient. This is the case any pair of integrating organizations can solve with a contract.
The non-trivial case is the multi-boundary chain: A delegates to B, which in turn delegates to C, possibly through further onward calls. The shape of the problem changes:
• A is not a party to the B→C boundary. That boundary is between B and C, governed by their bilateral arrangement, not by A's relationship with either.
• A nonetheless has a legitimate accountability interest: A originated the work; A's audit trail must include what happened to it across the chain — not only at boundaries A directly participated in.
• A cannot unilaterally compel B or C to expose anything to it. Cross-organizational coercion is not how agreements work between sovereign parties.
• Centralized observability — one trace pipeline that all organizations submit to — is infeasible across competing or jurisdictionally separated entities.
This is the A→B→C problem. The solution must be bilateral and composable: each pair of entities establishes its own Repatriation arrangement; the chain's overall observability emerges from the composition of those bilateral arrangements rather than from anycentral coordinator.
Repatriation provides exactly that. Each pair of entities declares its Repatriation participation through Protocol NFRs in their manifests. Bilateral matching at discovery determineswhether the pair is compatible. If matched, span-close events trigger Repatriation submissions per the bilateral arrangement. The architectural pattern —bilateral declaration, discovery-time matching, event-driven flow — produces cross-organizational observability without centralization and without coercion.
Repatriation participation is declared in entity manifests through four Protocol NFRs. Like all Protocol NFRs, they are matched bilaterally at discovery — both sides declare what they support or require, and the matching algorithm determines compatibility. An entity's Repatriation behavior is fully captured by the values it declares for these four NFRs; no behavior is implicit, and no behavior is unilaterally negotiable at runtime.
All four NFRs participate in bilateral matching. An entity's manifest declarations describe its behavior on both sides of any future Repatriation flow it engages in: as sender, the redaction policy it will apply; as receiver, the unredacted-content policy it will enforce. Discovery matches a pair of manifests against each other to determine whether the bilateral arrangement is consistent.
The applicability rule for Repatriation is a single set-theoretic check applied bilaterally at discovery:
repatriation_redacted_fields∩ repatriation_required_unredacted_fields = ∅
The intersection of the sender's redacted-fields set and the receiver's required-unredacted-fields set must be empty. Any field that the sender intends to redact and the receiver requires unredacted is a contradiction — the two parties are saying incompatible things about field-level visibility, and Repatriation between them is not applicable.
The check applies in each direction independently. For Repatriation from B to A, the rule checks A's required-unredacted set against B's redacted set. For the reverse direction, the rule checks B's required-unredacted set against A's redacted set. Both must hold for bidirectional Repatriation; either may pass alone for one-way Repatriation.
Incompatibility is a discovery-time non-match, not a runtime failure. If the rule fails for a pair of entities, discovery does not return them as compatible counterparties; the parties either find compatible alternatives, relax their declarations, or accept that they cannot engage on the offered Repatriation terms. The runtime never produces a Repatriation incompatibility surprise — incompatibility is detected and signalled before any runtime engagement.
Consider two entities, Org A and Org B, both declaring Repatriation participation. The relevant NFR values from their manifests:
Both checks pass. Bidirectional Repatriation between Org A and Org B is applicable. At runtime, span-close events at either organization will trigger Repatriation submissions to the other, with the sender applying its declared redactions and the receiver accepting submissions that satisfy its declared unredacted requirements.
Repatriation flows are event-driven from span-close events. When a span representing a trust-boundary crossing reaches its close event in the OpenTelemetry span lifecycle, the entity holding the span identifies entitled receivers per its bilateral declarations and emits a Repatriation submission to each receiver's declared endpoint. The submission carries the relevant span data and the relevant Telemetry Record content, with field-level redaction applied per the bilateral matching.
Span close is the natural OpenTelemetry lifecycle event at which the span's content is finalized: the operation has completed (success or failure), the span's attributes and events are settled, and the span is ready for export to the trace pipeline. Repatriation co-locates with span close rather than running on a separate cadence. This produces several useful properties:
• Event-driven, not polled or batched. Receivers do not request submissions on a schedule; senders push them as the data becomes available.
• Fresh by construction. Repatriated content reaches receivers as quickly as the trace fabric reaches its own consumers —there is no separate audit lag.
• Backpressure via the trace pipeline. If Repatriation submissions are failing (network outage, receiver down, authorization expired), the failures show up immediately in the trace fabric's own emission metrics. Operational issues with Repatriation are not silently invisible.
• Per-span granularity. Each span produces its own Repatriation event. Long-running invocations do not defer Repatriation visibility to a final record-finalization point; receivers see each boundary as it closes.
The Repatriation submission's content is drawn from the Telemetry Record sections sealed by the time of the span close, augmented with the span data itself. Phase-immutability (see Telemetry Record) ensures the sealed sections will not be rewritten after the Repatriation submission is constructed; submissions are stable artifacts that do not need amendment as the invocation continues. Subsequent span closes within the same invocation produce additional Repatriation submissions covering the additional sealed content.
Some fields are structural: without them, the Repatriated artifact is uninterpretable, fails integrity checks, or loses the cross-organizational accountability properties that motivated Repatriation in the first place. These fields cannot be redacted, regardless of what an entity declares in repatriation_redacted_fields. An entity that declares a structural field as redacted is non-conformant; the registry's manifest validation MAY reject such declarations at ingestion.
Structural fields fall into the categories below. Specific field-path enumerations are normatively maintained in 6. Telemetry Record and Repatriation; this page describes the categories and the principle.
The principle: a Repatriated artifact must remain a coherent, attributable, parity-checkable record. Redaction is for content fields — payloads, internal identifiers, business-confidential data — not for the structural elements that make the artifact useful as audit. An entity wishing to limit cross-organizational visibility into specific content uses repatriation_redacted_fields to declare it; an entity wishing to refuse Repatriation altogether uses repatriation_participation to declare non-participation. There is no coherent middle ground in which structural fields are removed — that would not be a more-restricted Repatriation but a fundamentally broken one.
This page covers Repatriation as a mechanism: declaration, matching, timing, and the structural-field constraint. Several adjacent topics are intentionally out of scope here and live in dedicated documents: