Provenance attribution is the discipline of recording, on every span SADAR-conformant entities emit into the OpenTelemetry trace fabric, an explicit identifier of which entity, agent, and environment produced it. The mechanism is a single attribute — telemetry.origin.environment — carried on every span. The architectural consequences are large: traces become self-attributing, two-sided emission at every interaction makes unilateral tampering detectable, and cross-organizational trace reconstruction becomes tractable without requiring centralized control of the trace pipeline.
This document covers what provenance attribution is, the structure of the telemetry.origin.environment attribute, the two-sided emission pattern at every trust boundary, how cross-organizational trace correlation works, and the tamper-evident audit reconstruction that follows. The full span schema beyond the provenance attribute lives in the 6. Telemetry Record and Repatriation companion document, span structure section.
Audience: implementers building agents, tools, or orchestrators that emit spans into the SADAR observability fabric; architects evaluating audit-trail trustworthiness; and audit/compliance teams scoping cross-organizational forensics.
In a single-organization observability context, provenance attribution is implicit. There is one observer and one set of emitters, all under the same operational control. Spans flow into one trace pipeline, and the question "who emitted this span" has only one possible answer.
In cross-organizational agent flows, that assumption breaks. When work crosses from Org A's agent to Org B's agent, the resulting trace contains spans from emitters at two distinct organizations — neither of which has a privileged claim to the trace's interpretation. If those spans don't carry explicit attribution, an auditor reconstructing the trace cannot tell which entity emitted which span; any reconstruction is open to dispute; and no cross-organizational accountability is possible.
Provenance attribution is the mechanism that closes that gap. Every span emitted by a SADAR-conformant entity carries the telemetry.origin.environment attribute, identifying the emitter explicitly. The trace becomes self-attributing: each span carries its own evidence of origin. Cross-organizational reconstruction is no longer a matter of trusting an authority; it is a matter of joining attributed artifacts.
Note: spans are distinct fromOTel baggage. Spans are recorded events in the trace pipeline — durable, attributed, structured. Baggage is in-flight context propagation that travels with calls — ephemeral, carrying parity values to be persisted into spans, SCT chain links, and Telemetry Records at each boundary. Provenance attribution is a property of spans, not baggage. See Observability Overview for how the two compose.
The attribute name is telemetry.origin.environment. The valueis structured as the concatenation of three identifiers, in this order:
• entity_urn — the URN of the legal entity that owns and operates the agent. This is the same URN that identifies the entity in its manifest, in SCT chain link issuer claims, and in Telemetry Record issuer attribution. Cryptographic parity (§5.1.17) requires these uses to agree.
• agent_urn — the URN of the specific agent within the entity that emitted the span. Drawn from the agent's manifest.
• environment_id — an identifier for the specific dseployed instance of the agent. Examples: prod-us-east-1, staging, canary-12345. This handles cases where one agent URN runs in multiple deployed environments — multi-region, multi-tenant, blue/green, or geographic-isolation deployments — by giving each one a distinguishable provenance.
Conceptually, the value is a triple: <entity_urn>:<agent_urn>:<environment_id>. The exact wire form — separator character, escaping rules, optionality of environment_id for entities that operate from a single environment — is normatively specified in 6. Telemetry Record and Repatriation. This page treats the value as a structured triple at orientation depth.
The attribute is set on every span SADAR-conformant entities emit. Spans without it are non-conformant and cannot participate in cross-organizational reconstruction; consumers of the trace fabric are entitled to treat such spans as untrusted.
OpenTelemetry's emission convention is that every cross-process call produces two spans: a client-side span emitted by the caller, and a server-side span emitted by the callee. Both spans share the same trace ID; the server span has the client span as its parent in the trace tree. In a SADAR-conformant flow, both spans carry provenance attribution — each attributed to its respective emitter.
This is two-sided attribution. It is the property that makes unilateral tampering detectable: every interaction has two independently-attested records, one held by each side, and the two records corroborate each other on every observable claim about the interaction.
The example below shows what gets emitted when Agent X at Org A invokes Agent Y at Org B over an attributed call:
Both spans are correlated by trace ID and by the parent-child linkage. Both are attributed via provenance attribution to distinct entities. Each lives in its emitting organization's observability infrastructure. Neither organization holds the other's spans as a matter of course — cross-organizational visibility is achieved through Repatriation or analogous audit-access patterns, not through shared infrastructure.
This pattern repeats at every trust-boundary crossing in the chain. A three-organization chain (Org A → Org B→ Org C) produces three pairs of attributed spans, six in total, all sharing the same trace ID and forming a coherent trace tree across organizations.
Cross-organizational trace correlation is the property that lets an authorized auditor reconstruct an end-to-end attributed trace from spans that live in multiple organizations' observability infrastructures. Three independent mechanisms compose to produce it:
• Trace ID propagation — handled by W3C Trace Context unmodified. The trace ID propagates across HTTP and gRPC calls (and any other transport supporting OTel context propagation), so spans emitted at any step in the chain share the same trace ID.
• Provenance attribution — the telemetry.origin.environment attribute on each span identifies its emitter, so the auditor knows which entity attests to each step.
• Audit access across organizations — Repatriation (for Telemetry Records) and analogous span-access mechanisms move authorized views of the artifacts across trust boundaries to the auditor.
With all three in place, the audit reconstruction is mechanical: collect the spans by trace ID across organizations, validate the trace tree structure, and produce an end-to-end view in which each step is attributed to the entity that performed it. No central trace pool is required, and no organization needs to grant any other organization full access to its observability infrastructure.
This is a distinct capability from anything traditional in-organization observability provides. APM and SIEM systems assume the observer has direct access to the emitters' telemetry streams. SADAR's pattern is the inverse: each organization owns its own telemetry, exposes selected views through controlled mechanisms, and the trace becomes federated by composition rather than centralized by capture.
Two-sided attribution combined with cross-organizational trace correlation makes the audit fabric tamper-evident: unilateral or limited tampering produces detectable inconsistencies. The fabric is not tamper-proof — a sufficiently determined attacker with cross-organizationally coordinated access could, in principle, corrupt enough artifacts to produce a consistent false picture — but the bar is dramatically higher than for single-organization audit, and several common tampering scenarios produce immediate inconsistencies.
The scenarios below summarize the kinds of tampering that two-sided attribution detects and how:
In each case, detection comes from cross-checking artifacts that independent organizations hold separately. The attacker who wants to produce a falsified-but-internally-consistent reconstruction must successfully tamper with the artifacts of every organization that holds a corroborating record — including organizations that have no stake in the falsification and no reason to cooperate. This is the property that makes the audit fabric foundational for cross-organizational accountability: the trustworthiness of any individual artifact is reinforced by the trustworthiness of corroborating artifacts at organizations the attacker does not control.
Provenance attribution is one of the values cryptographic parity (§5.1.17) covers. The entity attribution recorded on a span MUST agree with the issuer attribution recorded on the corresponding SCT chain link, with the issuer attribution recorded on the corresponding Telemetry Record, and with any other layer in which it appears. Parity violations are reported as structured error and are themselves audit-significant events. The combination of two-sided emission, provenance attribution, and cross-layer parity is what produces the tamper-evident substrate that the rest of the SADAR audit story rests on.
This page covers provenance attribution as an observable property of the span fabric. Several adjacent topics are intentionally out of scope here and live in dedicated documents:
• Observability Overview — the cross-cutting summary of SADAR observability; how spans, baggage, Telemetry Records, Repatriation, and Risk Score compose into the full observability picture.
• Telemetry Record — the per-invocation durable audit artifact whose issuer attribution must agree with span provenance attribution under cryptographic parity.
• Repatriation — the cross-trust-boundary return mechanism; analogous patterns govern cross-organizational access to span content.
• SADAR Context Token — the SCT chain link whose issuer attribution must agree with span provenance attribution at the same boundary.
• 2. Scope §5.1.14 — Observability umbrella; the normative source for span emission requirements.
• 2. Scope §5.1.17 — Cryptographic Parity; the requirement that provenance attribution agree across layers.
• 4. SCT Operations — full SCT cryptographic semantics including issuer attribution semantics.
• 6. Telemetry Record and Repatriation — the full normative content for the span structure including the wire form of telemetry.origin.environment and other span attributes.
• 7. searchAndInvoke — the orchestrator that emits spans during invocations and propagates trace context across boundaries.