Manifests

The self-description every participant carries

A SADAR manifest is a signed, standards-grounded description of what something is, what it does, and what it requires — published by the entity itself and verifiable by anyone. Every participant in a SADAR registry has one.

Manifests are the substrate that makes discovery and authorization possible. When an agent asks the registry "which capability fulfills this intent, for this originator, in this business process step?", the registry is matching manifests against the request. There is no parallel mechanism. If something doesn't have a manifest, it isn't discoverable and it can't be invoked.

What carries a manifest

In a SADAR registry, every entry has a manifest:

• Entities — organizations that publish or operate capabilities.
• Federated registries — peer registries that participate in the global substrate.
• Agents — both the requesting side and the serving side. An agent is often both,     in different interactions.
• Tools — callable capabilities narrower than a full agent.
• Resources — databases, files, data products, and other non-executable assets.

This uniformity matters. A caller and a callee are describing themselves in the same language. A federated registry describes itself the same way an agent does. Bilateral matching works because both sides of any relationship are speaking a common, signed, standards-grounded dialect.

Standards context: anchoring meaning to widely-usedframes

A manifest does not invent its own vocabulary. It locates itself inside established industry and transaction standards so that the same term means the same thing to every participant.

The standards context declares:

• Industry — the domain in which the entity operates (healthcare, financial services, manufacturing, and so on), typically referenced by a widely-adopted taxonomy such as NAICS.
• Process — the business process the manifest participates in, grounded in a cross-industry framework such as APQC's Process Classification Framework (PCF) for business activities, or O*NET for tool-level skills and     knowledge.
• Industry-specific drill-down — optional, used where the industry has its own process or capability taxonomy that refines the general classification (for example, HL7 FHIR resource types refining a general "clinical data     exchange" process step).
• Operation or transaction — the specific transaction type the capability fulfills, grounded in the standard that governs it: HL7 in healthcare, X12 in US healthcare and supply chain, SWIFT and ISO 20022 in financial     messaging, and similar.

These anchors are what turn "our agent handles invoices" into a precise, matchable claim. Two manifests that both cite X12 837P are both describing professional healthcare claim submission — not generic billing, not commercial invoicing, not a UB-04. The registry does not have to guess.

Business process role: fulfillment and predecessors

A manifest declares what part of a business process its subject fulfills. For agents and entities, this is typically expressed against APQC PCF or an equivalent cross-industry framework. For tools — which describe narrower, skill-shaped capabilities — O*NET is the conventional anchor.

A manifest also declares its predecessors in the same frame: the business-process steps that must have happened upstream for this capability to be validly invoked. This is how the registry knows that an agent claiming to fulfill "adjudicate claim" is only appropriately invoked after a capability fulfilling "receive and validate claim" has run.

A single manifest can participate in a larger business process by composition. Claims submission is one step; claims adjudication is another; payment issuance is a third. Each has its own manifest. Each declares its predecessors. The larger business process emerges from composition rather than being hard-coded anywhere.

IRIs: how business semantics become runtime semantics

Every standards reference in a manifest is expressed as an Internationalized Resource Identifier (IRI). An IRI is not a pointer to a website — it is a globally unique, resolvable name for a concept. This is how a manifest's intent becomes a machine-checkable claim.

Consider a manifest for a healthcare claim-submission agent.Its operation field does not say "submits claims." It says something like:

industry: https://opensemantics.org/std/naics/2022/621

process:  https://opensemantics.org/std/apqc/pcf/v7/8.2.1

operation: https://opensemantics.org/std/x12/v5010/837P

Each IRI resolves to a formal definition. The NAICS IRI grounds the industry to a specific sector classification. The APQC IRI grounds the process step to a defined activity in the standard hierarchy. The X12 IRI grounds the operation to a specific transaction version with a defined segment structure, required loops, and field semantics.

The data payload of the operation is then defined in the context of the operation's IRI. An API definition — OpenAPI, AsyncAPI, Smithy, or any equivalent — can be bound to the operation IRI, giving the payload a concrete syntactic shape. But the shape is interpreted in the operation's semantic context. The same JSON field named invoice_id means one thing under an X12 837P IRI and something entirely different under a SWIFT MT103 IRI. The IRI is what disambiguates.

This is what "clear business semantics and syntax"means in practice: syntax comes from the API definition, semantics come fromthe operation IRI, and both are bound together in the manifest. A callercan check not only that a payload is structurally valid but that it isstructurally valid for the right thing.

Non-functional requirements

Beyond what a capability does, a manifest declares howit must operate. NFRs include, among others:

• Performance and latency envelopes
• Availability and reliability commitments
• Data residency and sovereignty constraints
• Regulatory scope (HIPAA, PCI-DSS, GDPR, sector-specific regimes)
• Security posture (authentication methods accepted, channel requirements, conformance level)
• Operational constraints (rate limits, concurrency, cost tier)

NFRs participate in bilateral matching the same way functional declarations do. A caller whose manifest requires EU data residency will not be matched to a capability whose manifest does not assert it, regardless of how well their functional claims align.

Signing: manifests as verifiable claims

A manifest is digitally signed by the entity that publishes it. The signature covers the manifest's high-level identifying and authorization-relevant details — enough that any participant can verify what was published, by whom, and that it has not been altered.

Signing is what makes manifests ground truth rather than metadata. A registry can be compromised, a DNS answer can be wrong, a catalog entry can be stale — but a valid signature over a manifest, anchored toa publisher whose identity is itself verifiable, gives the caller a claim they can rely on. Cryptographic provenance is how a federation of registries operated by different parties can still produce a trustworthy discovery answer.

How manifests are used

Manifests are the input to every significant operation in aSADAR registry:

• Publication. An entity publishes a manifest to a registry; the registry validates it against the specification and makes it discoverable.
• Discovery  A caller submits an intent and context; the registry matches requesting manifests against serving manifests, returning candidates that are both semantically appropriate and bilaterally compatible.
• Authorization. Policy evaluation consumes manifest claims — functional role, business process step, NFRs, conformance level — alongside the originator identity chain.
• Invocation. searchAndInvoke commits to a matched capability atomically; the signed manifest becomes part of the audit record for what was chosen and why.
• Federation. Registries exchange manifests across trust domains; signatures and standards anchoring are what allow cross-registry matching to remain meaningful.

Why this design

A manifest is deliberately constructed from publicly-adopted standards rather than from a SADAR-specific vocabulary. There are two reasons.

The first is interoperability. If the industry already has a standard for the thing being described — HL7 for clinical messages, X12 for claims, ISO 20022 for payments, APQC for process, O*NET for skills — SADAR uses it rather than inventing a parallel one. Participants do not have to learn a new language to publish; they have to write down the language they are already speaking.

The second is neutrality. A manifest grounded in NAICS, APQC, X12, and HL7 is not bound to any cloud provider, model provider, or agent framework. It describes the same thing the same way regardless of where the capability runs. That neutrality is what lets a SADAR manifest federate across clouds, across providers, and across sovereign boundaries without losing its meaning.

‍