This document is the orientation page for SADAR's functional model: how the spec represents capabilities, requirements, and the bilateral matching that brings them together. It covers what 'functional model' means in SADAR's particular sense, the central role of the manifest as the unit of capability declaration, the symmetric treatment of requester and server roles, the four NFR categories that structure declarations, and the first-class manifest elements (business process, data fields) that complete the model.
The normative basis lives across multiple sources. The 3. NFR Schema companion document is the canonical source for the four NFR categories and the field definitions within each. The Website Narrative §Registry Entry Manifests provides the orientation framing this page builds on. Manifest signing, lifecycle, and registry-side handling live in their respective sibling pages and are referenced rather than re-covered here.
Audience: enterprise architects evaluating SADAR for adoption; implementers structuring agent and tool deployments; and developers writing manifests for their own entities.
In most enterprise architecture practice, a functional model describes what a system does. The decomposition is hierarchical: top-level functions split into sub-functions, sub-functions into operations. The model is implementation-centric — it describes the system as an island of capability, frequently in UML or a similar notation, and is consumed primarily during system design.
SADAR's functional model is structurally different in three ways:
• Manifest-centric,not implementation-centric. Capabilities are declared in signed manifests, not in code, configuration files, or runtime APIs. The manifest is the single source of truth for what an entity is and what it can do; entities exist in the SADAR ecosystem to the extent they are declared in manifests.
• Bilateral, not server-only. Every interaction has two sides — requester and server — and both sides declare manifests. Capabilities and requirements are evaluated symmetrically: the requesterdeclares what it needs, the server declares what it provides, and bilateral matching determines compatibility before any invocation occurs.
• Schema-driven via NFRs, not ad-hoc. Capabilities and requirements are expressed through structured Non-Functional Requirements (NFRs) drawn from four canonical categories. Matching is a function of NFR compatibility computed at discovery, not a runtime handshake or contract negotiation.
The functional model is therefore the union of: the manifest as a structural unit, the symmetric requester and server roles, the four NFR categories that organize declarations, and the first-class elements (business process and data fields) that complete the manifest. The remainder of this page covers each.
The manifest is the central artifact of SADAR's functional model. It is a signed, versioned document that declares everything about an entity's participation: who the entity is, what it does, what it requires from counterparties, where it can be reached, and how counterparties should authenticate to it. Nothing about an entity's role in the SADAR ecosystem exists outside its manifest.
A typical manifest contains:
• Identity. The entity URN, the agent URN within the entity, the manifest version, and the cryptographic signing key reference (typically a JWKS endpoint).
• Functional declarations. What the entity does or requires — operations, business processes, data fields. Covered later as first-class elements.
• NFR declarations. Structured non-functional requirements organized into the four categories (Functional, Operational, Protocol, Quality), each declaring requirements (as requester) and capabilities (as server). Covered next.
• Operational metadata. Endpoints, authentication endpoint URLs, JWKS URI, supported protocols and versions, lifecycle state.
• Cryptographic signature. A JWS signature overthe manifest content using the publisher's private signing key. Recipients verify the signature against the publisher's JWKS-published public key before trusting any field.
Manifests are immutable per version. A change to any field requires producing a new versioned manifest with a new signature and propagating the new version through the registry layer. The immutability is what lets a manifest be cached, replicated, and signed-once-trusted-everywhere— properties registry isolation depends on (see Registry Security).
In typical service registry models, registration is asymmetric: services register themselves with the registry, and clients query the registry to find services. The registry is service-centric; clients are not first-class participants and do not generally have registry presence.
SADAR inverts this. Both sides of every interaction have manifests. Both sides participate in bilateral matching at discovery. Both sides authenticate via mTLS, JWKS-published keys, and OIDC. Both sides declare trust models, NFRs, and capability characteristics. Neither side has privileged status.
The symmetry is illustrated by what each side declares in its manifest. A requester and a server publish substantively similar manifest content; the difference is in the directionality of specific declarations:
Symmetry is not a stylistic preference; it is what enables cross-organizational federation. In a multi-organizational chain (Org A's requester invoking Org B's server, which in turn invokes Org C's tool), the same matching machinery applies at every boundary. Org B is a server to Org A and a requester to Org C; its manifest declares both roles, and the bilateral matching at each boundary uses the same rules.
Symmetry also produces uniformity in the rest of the architecture. Authentication baselines are the same on both sides. SCT chain links are issued by every entity at every boundary it participates in. Repatriation is bilateral. Trust models are negotiated bilaterally. The functional model's symmetry propagates through every layer that builds on it.
NFRs in SADAR are organized into four canonical categories. Each category captures a distinct aspect of entity declaration, and each contains a defined set of NFR fields with structured matching semantics. The category boundaries are normative — an NFR belongs to exactly one category — and the bilateral matching algorithm processes each category according to the rules appropriate to its semantics. The exact category names below reflect this orientation page's framing; the canonical names and full content are normatively defined in 3. NFR Schema.
Why four categories? The categorization aligns NFR processing with the kind of matching the category requires. Functional NFRs are matched semantically (does the requester's required operation match the server's provided operations?). Operational NFRs are matched as constraints (is the requester's region requirement satisfied by the server's deployment regions?). Protocol NFRs are matched per the spec foreach NFR (Repatriation has the empty-intersection rule covered in its own page; Impact Score has its own matching semantics). Quality NFRs are matched by range comparison (does the server's latency profile satisfy the requester's threshold?). One matching algorithm per category, applied uniformly within the category.
This separation also lets implementations evolve different categories at different paces. New Quality NFRs (a new latency percentile) can be added without affecting Operational NFR processing. New Protocol NFRs (a new Repatriation field, a new authentication mechanism) can be added without changing Functional NFR semantics. The category boundary is the unit of evolution.
Beyond NFRs, the manifest includes a set of first-class elements that are not NFRs — they are too central to the functional model to be expressed as simple declarations against a category-scoped schema. These elements are referenced by NFRs, by the bilateral matching algorithm, and by the runtime layers (SCT chain, OTel baggage, Telemetry Record). Two stand out as foundational: business process and data fields.
A business process declaration in the manifest identifies the higher-level workflows or process definitions the entity participates in. The declaration is not a description of how the process works internally; it is a structural identifier (typically referenced through a taxonomy such as APQC's Process Classification Framework, with industry context drawn from NAICS) that lets matching identify entities operating within the same process.
At runtime, the business process identifier propagates as cryptographic-parity content through OTel baggage, SCT chain link claims, and Telemetry Record fields. It is the canonical anchor for the entire flow — every artifact for an invocation references the business process identifier of the originating process. See Observability Overview for the runtime propagation pattern and Telemetry Record for the per-record content.
Why first-class? Business process declarations bind invocations to organizational accountability frames. An invocation occurring within a known business process can be evaluated against that process's policy; an invocation outside any declared process raises questions about its authorization basis. Business process is the link between SADAR's mechanical matching and the organizational governance the matching serves.
Data field declarations identify the kinds of data the entity processes — patient records, transaction details, customer correspondence, sensor readings. Declarations are typed (referencing established taxonomies where possible) and include classification metadata indicating sensitivity, regulatory scope, or access requirements.
Bilateral matching uses data field declarations to verify that a requester sending data of type X can route to a server declaring it processes data of type X. Confidentiality and regulatory constraints surface here: a requester needing to send PHI (Protected Health Information) under HIPAA cannot match a server that does not declare HIPAA-compliant data handling, regardless of any other capability match.
Data fields are first-class forthe same reason as business process: they bind invocation matching to the substantive constraints (regulatory, organizational, ethical) that make matching meaningful in real deployments. Operations are processes acting on data; without typed data declarations, operation matching alone cannot enforce data-level constraints.
The four parts of the functional model — manifest as unit, bilateral roles, four NFR categories, first-class elements — compose into a single architectural pattern that the rest of SADAR builds on:
• At publication. An entity publishes a signed manifest declaring its identity, functional content, NFRs across the four categories, and operational metadata. The manifest is registered in one or more registries (or self-published, depending on deployment).
• At discovery. A requester searches registries with its own NFR requirements. The matching algorithm evaluates candidate server manifests against the requester's manifest, applying category-appropriate matching to each NFR category and verifying first-class element compatibility. Compatible candidates are returned.
• At invocation. The requester invokes the selected server through the protocol declared in the matched NFRs. Authentication uses both sides' JWKS-published keys. The business process identifier and other parity-bearing values propagate via OTel baggage. Each boundary issues an SCT chain link and emits a Telemetry Record.
• At audit. Authorized auditors reconstruct the flow from the artifacts each entity produced, joining by trace ID and parity-bearing values. The functional model's declarations are the ground truth against which runtime behavior is evaluated.
The functional model is therefore not a static description of the architecture — it is the operational substrate through which every interaction in SADAR is mediated. Manifests, NFRs, and first-class elements are not metadata about the system; they are the system, in the structural sense that the rest of SADAR depends on them.
This page covers the functional model as an architectural framing. Several adjacent topics are intentionally out of scope here and live in dedicated documents:
• Core Security — the cross-cutting security overview; how manifest signing, JWKS, and the authentication baseline support the functional model.
• Registry Security — registry isolation, manifest validation on ingestion, and federation of manifests across registries.
• Observability Overview — how the functional model's declarations (especially business process) propagate through observability primitives at runtime.
• Telemetry Record — the runtime audit artifact whose sections reference the manifest's functional content.
• Repatriation — example of a Protocol NFR set: four NFRs (participation, endpoint, redacted_fields, required_unredacted_fields) governing one capability area.
• Risk Score — Risk Score and the Impact Score Protocol NFR are both NFR-level concerns governed by the functional model framing.
• 2. Scope §5.1.10 — Manifests and the entity model.
• 2. Scope §5.1.11 — Discovery and bilateral matching.
• 3. NFR Schema — full normative content for the four NFR categories, the canonical category names, every NFR field within each category, and the bilateral matching semantics.
• Website Narrative §Registry Entry Manifests —orientation framing this page builds on.