Purpose

This document is the cross-cutting summary of SADAR observability: the four primitives that together provide cross-organizational, cross-trust-boundary visibility into governed agentic flows, and the way those primitives compose into a coherent observability architecture.

The normative basis lives across multiple sections. Scope §5.1.14 is the umbrella section on observability. The 6.Telemetry Record and Repatriation companion document covers the durable audit artifact and its cross-boundary return mechanism. The 7.searchAndInvoke companion document covers how the invocation orchestrator drives these primitives at runtime. The 8. Risk Score Specification defines the synthesized cumulative-risk scalar. This page treats them as a cohesive whole, with introductory depth on each and an emphasis on how they compose.

Audience: enterprise architects, security architects, audit and compliance teams, and operations teams using this page either to scope SADAR observability for their environment or to evaluate whether an existing implementation meets their cross-organizational accountability requirements.

Why Observability Is Different in SADAR

Traditional in-organization observability — APM, SIEM, log aggregation, distributed tracing — assumes the systems being observed are within a single trust boundary the observer controls. This assumption breaks for governed agentic flows, where work routinely crosses organizational and jurisdictional boundaries: an originating organization delegates to a third-party agent, which may itself invoke further downstream agents at still other organizations.

In that environment, the originating organization needs to answer cross-organizational questions: what actually happened to the work it delegated, who attested to what at each boundary, how risk evolved as the chain extended, and whether the artifacts those parties produced are mutually consistent. Traditional observability cannot answer those questions, because the observer does not have direct access to the audit stores at other organizations and cannot rely on a single shared trace pipeline.

SADAR's four observability primitives close this gap. They are not a replacement for in-organization observability — each entity continues to use whatever stack already serves it for in-org concerns. They are the layer above that, providing the controlled cross-organizational visibility that governed delegation requires.

The Four Observability Primitives

SADAR observability is composed of four primitives. Like the security primitives in Core Security, they are not independent — each does something the others cannot, and the composition story(below) is more important than any individual primitive in isolation.

1.    Telemetry Record — the per-invocation durable audit record. Issued at each trust boundary; persists in the issuing entity's local audit store.

2.    OTel Baggage — the in-flight propagation mechanism. Carries cryptographic-parity values along the call sequence as it executes; ephemeral.

3.    Repatriation — the cross-trust-boundary return mechanism. Brings selected Telemetry Record content from where it was issued back to authorized recipients.

4.    Risk Score — the synthesized cumulative-risk scalar. Computed at each boundary, attested in the SCT chain link, and recorded in the Telemetry Record.

Each is treated below at orientation depth. The companion documents (6, 7, 8) cover the full normative content.

Telemetry Record

The Telemetry Record is the durable, per-invocation audit artifact issued at each trust boundary crossing. It is the persistent record that survives long after in-flight propagation context has dissipated, and the artifact that Repatriation returns to authorized parties.

Each Telemetry Record captures, at minimum, the cryptographic-parity values for the invocation (business process identifier, transaction instance ID, SCT chain root jti), the trust model claim that governed the boundary, the Risk Score at the moment of issuance, the operation performed and its scope content, the reference to the corresponding SCT chain link, and the issuer attribution (which entity, at which boundary).

Telemetry Records are stored in the issuing entity's local audit store. They are private to that entity by default — not pushed to other organizations as a matter of course. The Repatriation mechanism (covered below) is the controlled path by which authorized parties — typically the originating organization for work it delegated, or an explicitly-authorized auditor — gain visibility into Telemetry Records issued elsewhere. Conformance: every entity participating in invocation flows MUSTissue a Telemetry Record at each trust boundary it crosses.

OTel Baggage

OpenTelemetry baggage is thein-flight context propagation mechanism SADAR uses to carry cryptographic-parity values along the call sequence as it executes. Where Telemetry Records persist what happened at each boundary, baggage carries the values that bind Telemetry Records, traces, and SCT chain links together as they propagate.

The values carried in baggage during a SADAR-conformant flow include:

•       Business process identifier — the canonical anchor for the entire flow. Serves a dual purpose as authorization context and, where applicable, as planner context for LLM-driven agents that need to know which business process they are operating within.

•       Business process manifest ID — the version-specific manifest reference for the business process definition.

•       Transaction instance ID — the unique chain-root identifier for this specific invocation.

•       SCT chain root jti — the JWT identifier of the originating SCT chain link.

•       Risk Score inputs — the values needed to recompute the Risk Score at each boundary.

Baggage is ephemeral. It exists only during in-flight execution; once the call sequence completes, baggage propagation ends. The values it carried persist via Telemetry Records and SCT chain link claims at each boundary it crossed — those are the durable artifacts. Cryptographic Parity (§5.1.17) requires that the values agree at every point of observation, so an auditor can cross-reference a Telemetry Record against the trace from which it was emitted and against the SCT chain link it corresponds to.

Repatriation

Repatriation is the SADAR mechanism for returning Telemetry Record content across trust boundaries —specifically, getting selected fields (or the full record, depending on policy and entitlement) from where they were issued back to the parties entitled tosee them.

The problem Repatriation solves is structural. An originating organization delegates work to a third-party agent. The third party performs the work, possibly across multiple downstream invocations, each generating its own Telemetry Records at its own trust boundaries. Without Repatriation, the originating organization sees only the boundaries it directly controls — its own. The rest of the audit trail lives in other organizations' private audit stores. The originator has no visibility into what actually happened across the chain it set in motion.

Repatriation provides the controlled return path: per-record or batched, pull or push, with field-level entitlement policy that lets each party return what it is contractually obliged to expose without exposing what it is not. Entitlement to specific Telemetry Record content is asserted via the same authentication baseline that governs invocation — scoped tokens, target-as-issuer, with the receiving party validating its own scope on every request. The protocol details, including the Repatriation request envelope and the field-level filter expressions, live in the 6. Telemetry Record and Repatriation companion document.

Repatriation is what makes cross-organizational accountability tractable for delegated agentic flows. Without it, the only options would be radical centralization (every entity sending all telemetry to a single shared audit pool — infeasible across competing organizations) or radical opacity (no cross-org observability at all —infeasible for governance). Repatriation is the negotiated middle path the spec defines.

Risk Score

The Risk Score is the synthesized cumulative-risk scalar computed at each trust boundary from the baggage-carried inputs and the trust-model claim of the inbound SCT chain link. It is recorded in two places at every boundary: as a claim in the new SCT chain link the boundary issues, and as a field in the Telemetry Record the boundary persists.

The Risk Score serves two roles. As an observability primitive, it is a single value that auditors and dashboards can use to characterize a flow's risk posture — and, by walking the SCT chain, to characterize how risk accumulated over the chain's length. As a control primitive, downstream consumers can refuse calls whose Risk Score has crossed a threshold, or apply additional gating (re-authorization, human review, hold-and-audit) without needing to recompute the underlying inputs themselves. The same scalar serves both roles, which is the point — observation and action are not separate concerns when the goal is governed delegation.

The canonical inputs to the Risk Score, the computation, the threshold semantics, and the contribution of each trust model are normatively defined in 8. Risk Score Specification. For the composition story below, the Risk Score is treated as a scalar that is computed at each link, attested in the SCT chain claim, recorded in the Telemetry Record, and reconstructible at audit time from the SCT chain alone (assuming the auditor can decrypt the relevant chain links).

How They Compose

The four primitives are not redundant. Each does something the others cannot, and their composition is what produces the full observability picture.

OTel baggage carries the parity values across calls in flight; without baggage, the values that bind Telemetry Records and SCT chain links together would not flow with the call. Telemetry Records persist what happened at each boundary; without Telemetry Records, baggage would propagate and then disappear, leaving no durable artifact for audit. Repatriation crosses organizational trust boundaries; without Repatriation, Telemetry Records would be siloed in the organizations that issued them. Risk Score synthesizes the boundary-by-boundary state into a single scalar; without Risk Score, downstream consumers and auditors would haveto reconstruct cumulative-risk reasoning from raw inputs at each step.

Cryptographic Parity (§5.1.17) is the discipline that binds them. Any value that appears in multiple layers —business process ID, transaction instance ID, SCT chain root jti, Risk Score —SHALL be consistent at every point of observation. Parity is what lets an auditor walk the SCT chain, retrieve corresponding Telemetry Records via Repatriation, cross-reference an OTel trace, and treat the artifacts as agreeing on the same set of facts about the same flow. Inconsistencies become structural error conditions, not unresolvable ambiguities.

The matrix below summarizes each primitive's role, persistence, and cross-boundary mechanism:

A Worked Example

Consider an invocation that crosses one trust boundary. Org A initiates a business process; Agent X at Org A invokes Agent Y at Org B; Agent Y completes the work and responds. The composition of the four primitives across this flow plays out as follows.

1.    Origin (Org A). The business process begins. OTel baggage is initialized with the business process identifier, business process manifest ID, transaction instance ID (this becomes the chain root), the SCT chain root jti, and the Risk Score inputs. Initial Telemetry Record T1 is issued at Org A's originating boundary, recording the initial values and a reference to the originating SCT chain link L0.

2.    Boundary Org A → Org B. Agent X issues a new SCT chain link L1 (parent_jti = L0.jti, signed by X, encrypted to Y). The Risk Score is computed at this boundary from the baggage inputs and the trust-model claim, then attested in L1's claim. Telemetry Record T2 is issued at Org A reflecting the outbound boundary; T2carries the same parity values as L1's claims. Cryptographic Parity applies —T2 and L1 must agree.

3.    Receipt (Org B). Agent Y validates the inbound SCT, decrypts L1, recomputes the Risk Score from baggage inputs, and verifies parity against L1's claim. Telemetry Record T3 is issued at Org B reflecting receipt and the work performed. T3 lives in Org B's local audit store.

4.    Completion (Org B). Agent Y completes the work and returns its response. Telemetry Record T4 is issued at Org B reflecting completion and the final Risk Score for this boundary.

5.    Repatriation. Org A's audit pipeline retrieves (or Org B pushes) the entitled fields of T3 and T4 across the trust boundary. Org A now holds repatriated views of both records, joinable to T1 and T2 by the parity-bearing values.

6.    Audit reconstruction. An authorized auditor at Org A walks the SCT chain (L0 → L1 → ...), retrieves the corresponding Telemetry Records (T1, T2, repatriated T3 and T4), and cross-references an OTel trace if one is available. Cryptographic Parity holds: business process ID, transaction instance ID, SCT chain root jti, and Risk Score are consistent across all four artifacts. The auditor can answer, with cryptographic backing, what happened at each boundary, who attested to what, and how the Risk Score evolved across the chain.

The same pattern composes recursively as the chain extends. A two-boundary chain (Org A → Org B → Org C) produces additional SCT chain links, additional Telemetry Records at each new boundary, and additional Repatriation flows from C back to B and from B back to A — each governed by its own entitlement policy. The auditor at A can walk an arbitrarily long chain, with parity binding the artifacts at each step.

Boundaries — What's Not Here

Observability Overview is the cross-cutting summary. Several adjacent topics are intentionally out of scope here and live in dedicated documents:

Where to Learn More

•       Core Security — the cross-cutting security overview. Observability primitives ride on the security primitives — same JWKS, same mTLS, same authentication scopes governing Repatriation entitlements.

•       Registry Security — registry isolation and therole of the registry as a discovery-only component, important context for why Repatriation is needed (the registry is not in the runtime data path).

•       SADAR Context Token — the SCT structure and chain semantics; the substrate Risk Score claims attach to.

•       Trust Models — direct_auth, asserted, impersonation, deputy. Trust model claim is one of the inputs to the Risk Score computation at each boundary.

•       2. Scope §5.1.14 — Observability umbrella; the normative source for what this page summarizes.

•       2. Scope §5.1.17 — Cryptographic Parity; the requirement that binds the four observability primitives together at the level of cross-artifact agreement.

•       4. SCT Operations — full SCT cryptographic semantics, including the inner-payload encryption patterns Repatriation relies on for confidential-content fields.

•       6. Telemetry Record and Repatriation — full normative content for the Telemetry Record schema, the Repatriation protocol, entitlement policy, and field-level filter expressions.

•       7. searchAndInvoke — how the invocation orchestrator drives the four observability primitives during each invocation.

•       8. Risk Score Specification — the canonical Risk Score inputs, computation, threshold semantics, and trust-model contribution.

‍