Purpose
This document is the on-ramp to the SADAR registry — the discovery infrastructure at the center of the SADAR architecture. It defines what the registry is, the three foundational principles that govern its behavior, and the operational shape readers can expect a SADAR-conformant registry to exhibit. It stays at the overview level by design; deeper material lives in the Entity Model, Registry Entries, Registry Manifests, Discovery, Federation, and Directory of Registries pages, and in the normative §5.1.6 (Registry Protocol) and §5.1.12 (Registry Isolation) sections of the Scope specification.
Audience: enterprise architects, security architects, technical leads, and standards practitioners evaluating the SADAR registry as discovery infrastructure or planning a conformant implementation.
What the SADAR Registry Is
A SADAR registry is a discovery-time component that holds publisher-signed, immutable manifests describing the agents, tools, business functions, business processes, and registries an organization makes discoverable. It runs the bilateral match algorithm against incoming queries and returns a classified candidate set. After discovery is complete, the registry plays no further role — consumers and servers communicate directly.
The registry is not a runtime broker, a gateway, an API mediator, an identity provider, a token issuer, or a payment processor. It does not duplicate any of those roles. It is the discovery layer, and only the discovery layer. This narrow scope is what makes SADAR registries safe to operate as multi-tenant infrastructure — including in federated topologies that span organizational and jurisdictional boundaries.
Three Foundational Principles
Three load-bearing principle govern the registry's behavior. Every other property of the SADAR registry —federation semantics, security posture, conformance criteria — follows from these.
1. Registry Isolation
The registry holds only what manifest owners submit. It does not hold credentials, API keys, usage tokens,or any other sensitive operational data. It does not issue authentication tokens for invocations — tokens are issued by the target service's authentication endpoint, declared in the target's manifest. Once discovery completes, runtime interactions do not depend on registry availability.
Registry Isolation is the property that lets a single SADAR registry serve many organizations safely. A compromised registry cannot impersonate a target, mint tokens, or replay invocations, because it never holds the material that would let it do so. This same property survives federation: a registry that forwards a query to a peer cannot extract usable credentials from the response, because credentials are never in the response.
2. Manifests as the Unit of Registration
Every entry in the registry is described by a publisher-signed manifest — a JSON Web Signature carrying the entry's identity, capabilities, requirements, and operational characteristics. Manifests are 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.
Treating the manifest as the unit of registration has two consequences. First, the registry's responsibilities are bounded: validate the signature, validate the schema, runcross-field checks, accept or reject. Second, downstream consumers can rely on the manifest as the source of truth for everything about the entry — there is no out-of-band configuration that the manifest doesn't capture.
3. Discovery-Time and Invocation-Time AreSeparate
The registry's role ends when discovery completes. The providing entity verifies the requester's manifest independently at invocation time, regardless of whatever pre-screen the registry performed. This double-check exists for a reason: the registry pre-screen is a discovery-time convenience, not a substitute for invocation-time verification. A SADAR-conformant provider rejects mismatches fail-closed at invocation, even where the registry had previously returned the candidate.
This separation also means a SADAR registry's availability is a discovery-time concern, not a runtime concern. Outages affect the ability to discover new candidates and to refresh expired discovery results; they do not affect invocations against already-discovered services within their declared TTL.
Registry Behavior — What It Does and Doesn't Do
The two columns below map the operational scope of a SADAR-conformant registry. The left column is what conformant implementations are required to do; the right column is what they are required not to do or are not asked to do.
| What the registry does |
What the registry doesn't do |
| Validates signed manifests on ingestion — signature, schema, and cross-field checks. |
Issue authentication tokens for invocations. Tokens are issued by the target's authentication endpoint. |
| Performs bilateral matching at query time across the four NFR categories, business process, and data fields. |
Hold credentials, API keys, usage tokens, or sensitive operational data. |
| Returns a classified candidate set (FULL_MATCH or PARTIAL_MATCH) to a consumer-supplied resolver. |
Perform final selection. The resolver does that, with business logic only the consumer can have. |
| Maintains the entity hierarchy and enforces discoverability levels on every query. |
Enforce cross-standard data interchangeability. The registry matches IRIs exactly; transformation is the consumer's concern. |
| Handles federation operations — query forwarding, content replication, content subscriptions — within declared terms of service. |
Sit in the payment path. Payment settlement happens directly between consumer and server. |
Emits structured error responses in the urn:sadar:error:v1 namespace. |
Need to be available for ongoing invocations once discovery is complete, except at TTL expiry. | Registry Roles and Operational Modes
SADAR specifies six registrytypes. The types are not mutually exclusive — a single physical registry may serve more than one type — but they help organizations think about positioning.
| Type |
Description |
| Provider |
A registry operated by a service provider advertising its own capabilities. |
| Marketplace |
An aggregator registry advertising capabilities from many providers in a neutral venue. |
| Industry |
A vertical-specific registry serving a particular industry, often hosted by a trade or standards body. |
| Community |
A community-curated registry, typically around an open ecosystem or technical domain. |
| Internal |
An organization-internal registry for non-federated use, conformant to the specification but not authorized for public federation. |
| Registry of Registries |
A registry that holds registry descriptors only — not agent entries — used to resolve cross-registry discovery. |
Independent of type, every registry operates in one of three modes governing federation participation:
| Mode |
Description |
| Internal-only (non-federated) |
Conformant to the specification but not certified and not in the Directory of Authorized Registries. Suitable for organizations with no need for cross-organizational discovery. |
| Authorized federated |
Certified, listed in the Directory of Authorized Registries, and participating in cross-registry forwarding and replication within declared terms of service. |
| Authorized non-federated |
Certified for internal-use SADAR conformance but not listed in the Directory. Permits the certification benefit without the public-federation commitment. |
Federation participation is governed by the Directory of Authorized Registries, maintained by OpenSemantics.org. Conformant registries reject forwarding and replication requests from registries not listed in the Directory. Between authorized registries, requests may be declined only if they violate the receiving registry's declared NFRs.
What's in the Registry
Entries are what consumers discover. Every entry is owned by an entity and is described by a signed manifest. The entry types most commonly found in a SADAR registry:
| Entry type |
Description |
| Entities |
The organizational units accountable for entries. Entities form a hierarchy with a single legally accountable root, with each entity declaring a discoverability level governing visibility. |
| Agents |
Requesting and providing agents — the actors that initiate or respond to invocations. Many agents declare both requester and server roles in a single manifest. |
| Tools |
General-purpose technical tools not tied to specific business functionality. |
| Business Functions |
Calls, APIs, modules, or capabilities that perform business-specific operations. Examples: getCustomer, finalizeOrder. |
| Business Processes |
Multi-step processes described against industry-standard process frameworks, providing scaffolding for planner agents and sequencing for dependency guardrails. |
| Registry Descriptors |
Used in a Registry of Registries — point to other registries in a federated topology, but do not contain agent entries themselves. |
The registry treats every entry uniformly: same signing requirements, same lifecycle states, same bilateral matching at discovery, same right-of-refusal at invocation. The diversity above is in what the entries describe; the registry's protocol does not branch on entry type.
Where to Learn More
• Why We Need Another Registry — theregistry-specific gap argument: what existing discovery patterns leave undone.
• Entity Model — the organizational accountability model and the six discoverability levels.
• Registry Entries — manifest top-level fields,lifecycle states, and the one-capability-per-manifest model.
• Registry Manifests — symmetric requester/server structure, the four NFR categories, three-tier strictness.
• Discovery — multi-level matching, TTL semantics,the resolver, and match classification.
• Federation — independent vs federated, federation security, private registries, and registry isolation in federated topologies.
• Directory of Registries — how registries appearin the Directory, replication semantics, refresh.
• 2. Scope §5.1.6 — Registry Protocol: registration, validation, immutability, error responses.
• 2. Scope §5.1.12 — Registry Isolation: the normative constraints establishing the registry as a discovery-time component only.
• 2. Scope §5.1.11 — Registry Topology, Federation, and Directory.