This document is the orientation page for SADAR's taxonomic substrate: the set of established external standards SADAR's manifests reference for grounding capability declarations, the SADAR-managed IRI namespace pattern that complements those external standards with spec-defined identifiers, the ecosystem-extension pattern that lets implementers add their own namespaces, and the criteria the spec applies when evaluating new grounding standards for adoption.
Sources: SADAR Features TLDR §The SADAR Registry solves these by introduces the grounding-standards framing; 3.NFR Schema defines the IRI conventions normatively. This page is the orientation that ties the two together and surfaces the architectural reason for grounding.
Audience: enterprise architects evaluating SADAR for adoption against their existing taxonomy investments; implementers building manifests that reference grounding standards correctly; standards-engagement teams considering proposing a new grounding standard for SADAR adoption.
Without grounding, capability declarations across organizations would be incomparable. “Patient registration” at one health system might be “patient onboarding” at another and “new-patient intake flow” at a third — three different strings naming the same business process, with no mechanical way to detect the equivalence. Bilateral NFR matching, which is the foundation of SADAR's discovery layer (see Core Functional Model), depends on identifier-level comparability: the algorithm matches values, not natural-language descriptions.
Grounding solves this by anchoring declarations in established external taxonomies that already have the disambiguation work done. NAICS code 622110 means “General Medical and Surgical Hospitals” regardless of which entity is referencing it. APQC PCF process5.1.1.1 (Conduct credit risk analysis) means the same activity in any banking context. HL7 FHIR's Patient resource is structurally identical wherever it is used. By referencing these external identifiers in manifests, SADAR inherits their disambiguation work — and the cross-organizational interoperability that depends on it.
The properties grounding produces are concrete: declarations are globally meaningful (the identifier means the same thing everywhere), unambiguous (the issuing taxonomy resolves ambiguity by definition), stable (taxonomies evolve under governance), and cross-organizationally comparable (the same identifier matches across organizational boundaries by virtue of structural identity, not negotiation). These are exactly the properties bilateral matching needs to operate at scale.
SADAR builds on a curated set ofexternal taxonomies, organized by what they classify. Industry classifications anchor entity context (“this is a hospital,” “this is a bank”). Function and process taxonomies anchor activity classification (“this agent supports the credit-decision process”). Operations-level standards anchor concrete protocol-and-message specifics (“this tool emits ISO 20022 payment messages”). Public APIs serve as a pragmatic complement when formal taxonomies do not cover a domain.
These taxonomies classify what economic activity an entity is engaged in — the broad context within which its capabilities operate.
Why support multiple? Different jurisdictions and use cases prefer different classifications. A US healthcare provider serving cross-border patients needs to interoperate with both NAICS-grounded and ISIC-grounded counter parties. A financial services entity may need GICS for market-data alignment alongside NAICS for regulatory filings. Manifests can reference more than one industry classification, with each declaration appropriate to a particular relationship.
These taxonomies classify what work is performed — the business processes and occupational skill domains that organize activity within an industry. SADAR uses these to ground declarations of which processes an agent supports and which capabilities it brings.
APQC PCF and O*NET-SOC together provide the substrate for three-tier semantic grounding of agent capabilities: industry context (via NAICS or peer classifications), process context (via APQC PCF), and skill or knowledge context (via O*NET-SOC). The combination disambiguates capabilities that single-tier grounding leaves ambiguous — for example, “claims processing” is unambiguous when grounded as “NAICS 524 Insurance + APQC PCF Insurance variant 5.x.x” in a way that the bare phrase is not.
These standards specify the concrete operations, messages, or resources that agents and tools actually exchange. Where industry and process taxonomies anchor what an entity is and what work it does, operations-level standards anchor the specific protocols and data structures of execution.
Operations-level grounding is what enables a tool declaring “FHIR R4 Patient resource read” to be matched mechanically against a requester needing exactly that operation. The structural compatibility is verified by reference to the standard, not by inspection of free-text descriptions.
Beyond formal standards, SADAR recognizes widely-adopted public APIs as a category of grounding source. A capability declaration that grounds in “Stripe payment intents v2024-08-01” is comparable across deployments that all reference the same Stripe specification, even though Stripe is a single vendor's API rather than a multi-stakeholder standard.
The pragmatic angle: in many domains there is no formal cross-industry taxonomy at the operations level, but there is a de facto standard that the ecosystem has converged on. Treating these as legitimate grounding sources — with clear-eyed acknowledgment of the trade-off — extends SADAR's coverage to domains where formal standards have not yet emerged.
The trade-off is governance. Public APIs evolve at the discretion of their owners; they may break backward compatibility, change pricing models, or be discontinued. Implementers grounding in public APIs accept these risks, and the SADAR-recognized list of public-API grounding sources is curated with the same versioning discipline applied to formal standards. The version reference in the manifest pins the specific API version the declaration is making, isolating the manifest from subsequent provider-side changes.
Where the external taxonomies above provide grounding for what entities are and do, SADAR maintain sits own IRI namespace for spec-defined identifiers — concepts that are SADAR-specific and have no natural home in an external taxonomy. Examples include authentication scopes, OTel baggage keys carrying parity-bearing values, structured error codes, and the categorical reasons that drive Risk Score adjustments.
The namespace pattern is urn:sadar:<category>:v<version>:<specific>, drawing on the URN structure (RFC 8141) to provide a hierarchically scoped identifier space. Each path component is purposeful:
• urn —Uniform Resource Name scheme.
• sadar —the SADAR-registered namespace identifier.
• <category>— the kind of identifier (scope, baggage, error, risk-reason, etc.). Categories are themselves spec-defined; new categories are added through spec evolution.
• v<version>— the version of the category. Versioning at the category level rather than the namespace level lets categories evolve independently. v1 identifiers remain valid forever even as v2 introduces new content.
• <specific>— the specific identifier within the category (e.g., the specific scope name, the specific risk reason, the specific error code).
Categories currently in use across the spec include:
Specific identifiers within each pattern are normatively defined in the relevant companion document (Authentication Scopes for the scope set, 8. Risk Score Specification for the twelve starter reasons, the spec error model for the error catalog, and so on).This page documents the namespace structure; the canonical content lives in those normative sources.
The SADAR-managed namespace covers what the spec defines. Implementers — individual organizations, vertical-specific consortia, partner ecosystems — can introduce their own IRI namespaces to identify concepts the spec does not standardize. Examples:
• urn:cognita-ai:capability:v1:domain-specific-skill— an organization-private namespace for capabilities specific to thatorganization.
• urn:health-consortium-x:processes:v2:claim-resubmission— a vertical-consortium namespace for processes the participating organizationshave collectively defined.
• HTTP-URI namespaces for organizations that prefer themover URNs, such as https://standards.example.com/sadar/v1/capabilities/x— also valid IRIs.
The namespace registration discipline is the same one that applies to URNs and IRIs in general (RFC 8141for URN namespace registration; reverse-DNS or HTTP-URI ownership for non-URN cases). SADAR does not maintain a registry of implementer namespaces — that is operational policy at the implementer or consortium level — but the spec requires that implementer-namespace IRIs are well-formed, documented at their authority, and used consistently across the implementer's manifests. See 3. NFR Schema for the validation rules applied at registry ingestion.
The pattern of ecosystem extension is what gives SADAR the same scaling property as the broader IRI ecosystem: the spec defines a small standard set; the ecosystem extends it with as much specificity as it needs; matching across the standard plus extension space works uniformly via IRI structural comparison. Organizations do not haveto wait for spec evolution to introduce identifiers for their own concepts; they extend in their own namespace and proceed.
The SADAR-recognized list of grounding standards is curated rather than open. Proposals to add a new grounding standard — whether a formal taxonomy or a de facto public API — are evaluated against criteria that balance ecosystem coverage against governance integrity. The criteria below are the orientation summary; the formal evaluation process lives with spec governance.
• Authoritative governance. The candidate is maintained by a recognized standards body, government agency, industry consortium, or — in the public-API case — an organization with sufficient ecosystem standing to make its specification a de facto standard. Sole-source taxonomies without governance accountability are rejected.
• Public documentation. Schemas, codes, semantics, and version histories are publicly documented and accessible without proprietary licensing barriers that would prevent SADAR participants from referencing the standard.
• Stable versioning. The candidate has explicit, declared versioning; older versions remain available; version transitions are documented. Without this, manifests cannot meaningfully reference the standard at a fixed point in time.
• Cross-organizational adoption. The candidate is used by multiple independent parties in production, not just within a single organization or its immediate partner network. The breadth-of-adoption requirement filters out aspirational standards in favor of demonstrably-deployed ones.
• Appropriate scope and granularity. The candidatecovers a domain area SADAR needs at the right level of detail for matching.Taxonomies that are too coarse (everything is one of two categories) or toofine (every individual instance gets its own identifier) make matching eithertrivially-true or impossibly-specific.
• IRI representability. The candidate's identifiers can be expressed as well-formed IRIs (typically straightforward —URN namespaces, reverse-DNS-rooted URIs, or HTTP-URIs all work).
• Vendor independence (with public-API caveat). Formal taxonomies are vendor-independent by definition. Public APIs are accepted with explicit acknowledgment that vendor-side changes are an accepted risk and version pinning is the manifest's protection.
Proposals meeting these criteria can be evaluated for inclusion through the spec-governance process. The criteria are necessary, not sufficient — adoption decisions also weigh ecosystem fit, redundancy with existing supported standards, and the burden of long-term maintenance on the SADAR community.
This page covers the taxonomic substrate at orientation depth. Several adjacent topics are intentionally out of scope here and live in dedicated documents:
• Core Functional Model — the architectural framing for manifests, NFRs, and bilateral matching that the taxonomic substrate supports.
• Authentication Scopes — full specification of the urn:sadar:scope:v1:*identifiers.
• Observability Overview — describes the OTel baggage keys (urn:sadar:baggage:v1:*) that propagate parity-bearing values.
• Risk Score — the cumulative risk scalar; reasons are identified by IRIs in the urn:sadar:risk-reason:v1:* namespace.
• Registry Security — registry-side validation of manifests including IRI well-formedness and reference correctness.
• 2. Scope §5.1.10 — Manifests and the entitymodel; the structural surface that taxonomic grounding populates.
• 2. Scope §5.1.11 — Discovery and bilateral matching; consumes the IRI-grounded NFR values that Taxonomy describes.
• 3. NFR Schema — full normative content for theIRI conventions and the per-NFR field definitions that reference grounding standards.
• 8. Risk Score Specification — the canonical reason IRI enumeration; an example of fully-elaborated SADAR-namespace content.
• RFC 8141 — Uniform Resource Names (URNs); the underlying spec for the urn:sadar:* namespace structure.
• RFC 3987 — Internationalized Resource Identifiers (IRIs); generalization of URIs to non-ASCII characters.