Registry Entities
Within the SADAR Semantic Registry, Entity and Service Specifications define the precise attributes, schema, versioning, and hierarchical behavior for participating organizations and the capabilities they offer. These specifications replace unstructured descriptions with a rigorous, machine-readable model that enables autonomous agents to interact with definitive accountability, exact semantic matching, and enforceable governance.
Entity Specifications and Self-Sovereignty The core design principle of the entity specification is that entity content is self-sovereign—the registry validates the overall schema and enforces mandatory fields, but participating entities populate and manage their own data. Entities represent the organizational units that publish or consume capabilities and are classified by a controlled vocabulary, such as LEGAL_ENTITY, SUBSIDIARY, DIVISION, DEPARTMENT, or JOINT_VENTURE.
- Flexible Sub-Entity Hierarchy: The entity's Internationalized Resource Identifier (IRI) is permanent, registry-minted, and deliberately encodes no hierarchy within its path. Instead, organizational hierarchy is established via a parent_entity_iri pointer, making sub-entities structurally relocatable. Severing or reassigning this pointer represents a major structural change that forces a new entity version.
- Versioning and TTL Invalidation: Entity records are strictly immutable; any modification produces a new version. When an entity's status changes, the registry emits Time-To-Live (TTL) invalidation signals to consumers holding cached discovery records. These signals are either SOFT (advisory, meaning the consumer should re-resolve at the next natural boundary) or HARD (mandatory, meaning consumers must treat cached discoveries as immediately stale, typically triggered by structural, payment, or jurisdictional changes).
- Comprehensive Metadata: Entity records mandate the inclusion of registered addresses, contacts, authoritative industry classifications (such as NAICS), and supported payment methodologies. Entities can also declare an optional "Published Profile," acting as a business intelligence card that lists certifications (e.g., SOC 2, FedRAMP), employee ranges, and operating regions.
Service Specifications and Direct Ownership Services—which include functional agents, utility tools, APIs, and data resources—are registered under an entity and carry their own unique identity, versioning, and contact surface.
- Strict Direct Ownership: A service is linked to its owner via an owning_entity_iri. Crucially, legal jurisdiction, data sovereignty, and payment method linkages are derived exclusively from this directly owning entity. The registry deliberately does not traverse up the entity hierarchy to parent entities to infer these attributes.
- Payment Method Validation: While a service can define its own specific payment terms (such as minimum_amount or net_days), the payment methods it advertises must be a strict subset of the active payment methods declared by its directly owning entity.
- Endpoint Hints and TTL Constraints: The service specification includes lightweight discovery pointers (like base_url or openapi_uri) and a discovery_ttl_seconds field, which dictates exactly how long a consuming agent is permitted to cache the discovery result before re-evaluating the service.
The Larger Context: Establishing the Trust Baseline In the broader context of SADAR, these specifications enforce the separation between the accountable organization (the Entity) and the functional capability (the Service). Because actual payment instruments, credentials, and sensitive tokens are exchanged directly between the consumer and the producer outside of the registry, the Entity and Service specifications act purely as the discovery and governance filter. By formally linking services to accountable entities and issuing precise TTL signals when terms change, these specifications guarantee that autonomous agents are operating under valid, mutually verified, and legally traceable terms at all times.