The core architecture of the SADAR Semantic Registry is designed to solve the critical infrastructure gaps of the Agentic AI ecosystem—namely the lack of deterministic discovery, verifiable trust, and enforceable governance. To achieve this, the architecture is built upon several foundational pillars:
1. Registry Isolation (Discovery-Time Only) A defining architectural principle is Registry Isolation. The Semantic Registry operates strictly as a discovery-time infrastructure component; it never sits in the runtime execution or payment path. Once a requesting agent discovers a capability, the registry facilitates an automated credential handshake (exchanging OpenID Connect endpoints), allowing the consumer and the provider service to communicate directly. This isolation ensures the registry does not become a runtime performance bottleneck or a single point of compromise.
2. Immutable Signed Manifests Every entry in the registry—whether a functional capability, a tool, a data resource, or a multi-step business process—is backed by a publisher-signed manifest. These manifests are the authoritative, tamper-evident records signed using JSON Web Signatures (JWS). Manifests carry machine-readable declarations across seven dimensions: Business process, Data, Compliance, Licensing, Costs, Operational limits, and Provider details. Any modification to a capability requires publishing a new, versioned manifest.
3. Semantic Grounding via IRI Ontology To eliminate the brittle, probabilistic guesswork of LLMs matching free-text descriptions, SADAR’s architecture uses Internationalized Resource Identifiers (IRIs) as semantic anchors. The architecture maps capabilities to a structured taxonomy (Industry → Function → Transaction) using recognized, authoritative industry standards such as NAICS, APQC PCF, HL7, and X12. This ensures that when an agent requests a capability, the semantic intent and data syntax are perfectly understood and deterministic.
4. Bilateral Match Agreement Discovery within the architecture operates on a Bilateral Match Agreement. Both the requesting agent and the providing service declare their functional and Non-Functional Requirements (NFRs) in their manifests, and both sides must satisfy each other's constraints for a match to occur. This means operational limits (rate caps, SLAs), financial costs, data sovereignty rules, and compliance postures (e.g., HIPAA, SOC2) are evaluated programmatically before an invocation is permitted. Providers maintain a built-in right-of-refusal, allowing them to reject discovery by requestors that lack compatible assertions.
5. Verifiable Trust and Attribution SADAR relies entirely on established cryptographic standards rather than proprietary trust mechanisms. During the initial connection, the requester authenticates directly to the service using standard OIDC flows, and the service issues a time-of-use token directly to the requester, cryptographically bound to the requester's key-pair with replay protection. Furthermore, the architecture dictates a three-part identity structure for every invocation: it must carry the agent's identity, the originating human or system identity, and the transactional context (business process ID), ensuring an unbroken, end-to-end chain of authority and auditability.
6. Federation and the Registry of Registries (RoR) To support a global agentic ecosystem without fragmentation, the architecture employs a Directory of Registries federation model. A central Registry of Registries (RoR), operated by a neutral standards body, acts as the trust anchor for the ecosystem. The RoR holds signed registry manifests and issues tokens that allow authorized registries to authenticate with one another for controlled query forwarding and content replication. Crucially, organizations retain full control over their boundaries; they can run private, internal proprietary registries that govern local agents without participating in the ublic federation.
7. The searchAndInvoke Interface To make this architecture accessible to agents, SADAR defines a standard interface tool called searchAndInvoke, designed to be exposed via the Model Context Protocol (MCP) or Agent-to-Agent (A2A) frameworks. This tool takes the agent's search request, queries the registry, handles the automated authentication handshakes, performs the bilateral matching, and uses a Strategy pattern to make the final selection and invoke the service—all as a single, governed operation.