Purpose

This document is the architecture-level on-ramp to SADAR for technical readers — enterprise architects, security architects, and technical leads. It introduces thefoundational design decisions, describes the components and how they compose,and walks an end-to-end invocation. It stays at the overview level by design; deeper material lives in the Layered Model, Integration with Existing Standards, Reference Architecture, and Implementation Guidance pages, and in the normative companion documents. Readers are assumed familiar with OAuth andOIDC, JSON Web Signatures and Encryption, mutual TLS, and OpenTelemetry; no prior exposure to SADAR is required.

Architectural Premises

Three design decisions shape every SADAR component. They are not arbitrary; each addresses a specific failure mode in current agent infrastructure.

Premise 1 — The registry is not in the runtime path

The registry holds manifests only, as submitted by their owners. It does not hold credentials, usage tokens, sensitive operational data, or authentication state. After discovery completes, the requesting agent communicates directly with the selected target; the registry plays no further role until rediscovery is required.

This isolation principle is what makes SADAR registries safe to operate as multi-tenant infrastructure —including in federated topologies that span organizational and jurisdictional boundaries. A compromised registry cannot impersonate a target, mint tokens, or replay invocations, because it never holds the material that would let it doso.

Premise 2 — The manifest is the unit of capability declaration

Every discoverable resource in SADAR — agents, tools, business processes, registries themselves — is described by a manifest. Manifests are publisher-signed using JSON Web Signature withES256 by default and immutable; any change produces a new versioned manifest with a new signature. One capability per manifest, with multi-capability endpoints publishing multiple manifests under a shared endpoint URN, lets organizations refine individual capabilities without disrupting unrelated ones.

The manifest carries the symmetric requester and server role sections; the same vocabulary applies in both. Many entities act in both roles simultaneously — calling upstream and being called by downstream — and declare both sections in a single manifest,reflecting the operational reality of agentic systems.

Premise 3 — Discovery is bilateral

Most discovery patterns are one-directional: only the requester's criteria determine what is returned. SADAR matching is bilateral: both the requester's wants and the server's requirements of the requester must be satisfied for a candidate to be returned.A non-qualifying requester never sees an entry it would not be authorized toinvoke.

Bilateral matching combined with three-tier strictness — OPTIONAL, MANDATORY, MANDATORY_STRICT — lets manifests express both soft preferences and hard requirements without forcingall-or-nothing decisions on the registry. Partial matches surface to a consumer-suppliedresolver, which applies business logic the registry cannot have. The resolver is the consumer's place to reason about historical performance, recent failures, cost optimization, and other context known only to the consumer.

Component Map

The following components compose the SADAR architecture. Each is summarized here and treated in depth in the dedicated companion documents and CMS pages referenced at the end of this overview.

End-to-End Invocation Flow

A typical SADAR-mediated invocation proceeds through the following steps. The flow is illustrative; specific sequences vary with trust model, federation topology, and whether the invocation extends an existing SCT chain or opens a new one.

1.  Discovery query. The requesting agent calls AI with target criteria. SAI issues a discovery query to the registry — possibly its local registry, possibly a federated peer reached through query forwarding. The query carries the requester's manifest reference; the registry has both sides for the bilateral match.
2. ‍Bilateral match. The registry runs the bilateral match algorithm across the four NFR categories — Financial, Operational, Governance, Protocol — plus business process and data field declarations. It returns a classified candidate set: FULL_MATCH and PARTIAL_MATCH candidates. NO_MATCH candidates are excluded entirely.
3. ‍Resolver selection. SAI passes the candidate set to the consumer-supplied resolver, which returns exactly one selection or a defined error. The resolver may not modify, augment, or substitute candidates outside the set returned by bilateral matching, and may not perform independent registry queries.
4. ‍Trust model negotiation. Discovery has already established which trust models are mutually supported via the supported_trust_models Protocol NFR. The negotiation algorithm selects the model of closest combined preference rank, with deputy preferred in ties. Thes elected model determines how the originator's identity propagates downstream.
5. ‍Authentication to target. SAI authenticates to the selected target's authentication endpoint — declared in the target's manifest — using OIDC Client Credentials over mTLS. The token issuer is the target, not the registry. The scope claim values come from the urn:sadar:scope:v1 namespace.
6. ‍Usage key delivery. The target returns a usage key as a JWE encrypted to the requester's public key. Because the key is issued during authenticated OIDC exchange, it is cryptographically bound to the requester's identity, enabling the target to attribute every subsequent invocation to a specific entity for billing, rate limiting, and audit.
7. ‍Invocation with SCT. SAI dispatches the invocation, attaching an SCT carrying authorization claims appropriate to thetrust model and the position in the chain — Open for first-link issuance, Continue for mid-chain re-issuance, Authoritative Carry for elevated-authority continuation, or Hold for asynchronous suspension.
8. ‍Provenance-attributed spans. Both ends emit OTel spans carrying telemetry.origin.environment attributes. The dispatch span andthe receipt span can be cross-checked for tamper-evident audit reconstruction. OTel Baggage carries the normative SADAR baggage fields, including the live Risk Score Adjustment list.
9. ‍Risk Score propagation. Components participating in the flow may emit Risk Score Adjustments — net step contributions after each step's own internal mitigation. Adjustments are appended to the Baggage list .An accumulated scalar, computed by the implementer-chosen algorithm, is embedded in the SCT chain at each trust boundary crossing.
10. ‍Repatriation (when applicable). If both sides have declared participation and the bilateral redacted-vs-required field-list intersection is empty, repatriation triggers on span close. The responder asynchronously returns redacted trace fragments to its immediate caller, preserving each side's control over disclosure while enabling end-to-end observability up the chain.‍
11. Telemetry Record finalization. SAI finalizes and persists the Telemetry Record at the Outcome phase. The record covers search metadata, resolver metadata, selection metadata, invocation metadata, outcome metadata, and risk score state. It isthe canonical per-invocation persistent audit artifact, written via the HelperAPI to enforce structural guarantees.

Cross-Cutting Architectural Principles

Several principles cut acrossall SADAR components.

Service-sovereign token issuance

Each target service issues its own usage tokens through its own authentication endpoint. There is no central token issuer, no separate federation token system, and no SADAR-definedidentity provider. SADAR composes with whatever IdP infrastructure an organization already operates.

Identity-bound usage keys

The usage key is delivered as aJWE encrypted to the requester's public key during the authenticated OIDCexchange, binding the key cryptographically to the requester's identity.Subsequent invocations are attributable to a specific entity without the target needing to re-authenticate the requester per call.

Cryptographic parity

Values appearing in multiplepropagation layers — OTel Baggage, span attributes, SCT claims, Telemetry Record fields — are required to be consistent at any point of observation.Parity instances include the business process identifier, the SCT chain root jti, the trust model claim, the Risk Score scalar, and the Transaction Instance ID. Parity violations are reported with structured errors. Cryptographic parity is the foundation for tamper-evident audit reconstruction across trust boundaries.

Fail-closed semantics

Manifest verification, SCT validation, malformed Risk Score Adjustments, and parity failures all fail closed by default. SADAR does not silently relax constraints when verification cannot be completed; the operational expectation is that verifiable correctness is more valuable than best-effort completion.

Forward compatibility

Implementations preserve unknown reason IRIs in Risk Score Adjustments, propagate Adjustments without dropping or reordering them, and maintain the structural fields that downstream consumers rely on. New reason vocabularies, new accumulation algorithms, and new domain-specific extensions can be introduced without breaking conformance for existing implementations.

Where to Learn More

This overview is intentionally summary-level. Each topic is treated in depth in the dedicated CMS pages andnormative companion documents.

Companion documents (normative)

•       2. Scope — the umbrella specification; defines what is in and out of normative scope.

•       NFR Schema — manifest structure, NFR vocabulary, three-tier strictness, business process and data field declarations, the bilateral match algorithm.

•       SCT Operations — SCT structure, claims, the five chain operations.

•       Trust Models — direct_auth, asserted, mpersonation, deputy; bilateral negotiation; provider-side validation.

•       Telemetry Record and Repatriation — Telemetry Record schema, OTel span structure with provenance attribution, repatriation mechanics.

•       searchAndInvoke Telemetry and Authentication— Helper API surface, repatriation trigger specification, OIDC scope namespace and initial scope set.

•       Risk Score Specification — Adjustment data model, propagation rules, implementer obligations, Impact Score Protocol NFR.

Related architecture pages

•       Layered Model — Discovery, Identity & Trust, Invocation, Observability, and Risk as discrete architectural layers.

•       Integration with Existing Standards — sequence diagrams and interface mapping for MCP, A2A, OIDC, OAuth, JWS/JWE, andOpenTelemetry.

•       Reference Architecture — non-normative implementation patterns including the searchAndInvoke handler architecture andselection strategy patterns.

•       Implementation Guidance — non-normative operational guidance covering availability, high availability, geographic distribution, sovereign deployment, and federation deployment patterns.

‍