This document is the orientation page for data field declarations in SADAR manifests: how entities identify the specific data they handle through IRI references grounded in operations-level standards, how multiple standards compose in a single declaration array, the architectural choice that makes the registry's matching algorithm simple by deferring transformation to the selector, the strictness flags that govern matching rigidity, and the forward reference to the forthcoming Data Classification Annex for sensitivity and regulatory classification.
The normative basis lives in NFR Schema §10, which defines the field-level structure of the data_fields NFR. The Website Narrative § Data Semantic Meaning and Syntax provides the orientation framing this page builds on. The taxonomies that ground data field IRIs — X12, HL7, ISO 20022, OAGIS, and others — are covered in the Taxonomy sibling page.
Audience: enterprise architects building or evaluating data-aware deployments; implementers writing manifests for entities that handle structured data from established standards; and integration teams planning cross-standard data flows.
A data field declaration in a SADAR manifest identifies a specific field of a specific message in a specific standard the entity handles. The granularity is field-level, not message-level — an entity does not just declare “I process X12 850 documents,” it declares the specific fields within those documents it produces or consumes.
Each declaration is anchored by an IRI that uniquely identifies the field in its grounding standard. Multiple data field declarations are common — an entity that processes a single transaction type may declare dozens of individual field IRIs covering each piece of data it handles. The collection of declarations forms the entity's data field surface: the precise set of structured data the entity is qualified to send, receive, or process.
Why field-level granularity? Bilateral matching at this resolution lets the registry verify exact data-level compatibility between requester and server. “The requester sends X12 850documents” is not enough information to know whether the requester's documents will work with this server's expectations — the server may handle only a subset of fields, or require fields the requester doesn't include. Field-level declarations give matching the resolution it needs to detect these mismatches before invocation. See Core Functional Model for the broader argument about why declaration-time precision matters for runtime correctness.
Data field IRIs follow the pattern urn:<authority>:<standard-and-deeper-path>. The authority component identifies the standards body issuing the identifier (using a reverse-DNS-style convention); the remainder is the standard's own internal path to the specific field. The structure is hierarchical and deterministic — given an IRI, there is exactly one field it identifies, and given a field in a published standard, there is exactly one canonical IRI.
As an illustration, consider theIRI urn:ansi.org:x12:850:SEG:01:DATE.Decomposed:
Different standards bodies use different internal path conventions appropriate to their structure — HL7 FHIR uses dotted resource-and-element notation, ISO 20022 uses dotted message-and-element notation reflecting its XML schemas, OAGIS uses Business Object Document path notation. The URN-authority-and-standard prefix is consistent; the internal path follows the standard's own conventions. Examples across the operations-level standards covered in Taxonomy:
These IRIs are illustrative; the canonical conventions for each standard's IRI form, including the exact authority strings and path syntax, are coordinated through the spec governance process and documented in 3. NFR Schema §10.
A data_fields declaration is an array. Crucially, the array can contain entries from multiple grounding standards. An entity that handles cross-standard data — for example, a healthcare claims processor that ingests both X12 837 and FHIR Claim resources — declares fields from both standards in the same array.
Consider a healthcare-finance integration agent. Its declaration might include:
data_fields:
- urn:ansi.org:x12:837:SEG:CLP:01
- urn:hl7.org:fhir:R4:Claim.patient
- urn:hl7.org:fhir:R4:Claim.diagnosis
-urn:iso.org:20022:pain.001:CdtTrfTxInf.Amt
Four field declarations from three standards in one array. The agent receives invocations from requesters operating in any of these standards; the agent's manifest tells the registry exactly which fields the agent handles regardless of source standard. The manifest may define one of allowing multiple field definitions to be used
Cross-standard composition is what makes SADAR practical for real-world heterogeneous data flows. Most production systems do not operate in a single grounding standard; they receive data in one form, transform internally, emit in another. Declaring fields from multiple standards in one array lets the manifest reflect this reality without forcing the entity to fragment its capability declaration across multiple manifests.
An important architectural choice underlies how the registry handles cross-standard equivalences. The registry performs exact IRI matching. It does not know that urn:ansi.org:x12:850:SEG:01:DATE might carry the same semantic content as urn:hl7.org:fhir:R4:Order.created,or that ISO 20022 amount fields and X12 amount fields could be interconverted with appropriate rounding rules. From the registry's perspective, every IRI isa distinct token; matching is structural, not semantic.
Cross-standard equivalence and transformation are selector-side concerns. The selector — the requester (or an orchestrator acting on its behalf) choosing among candidate servers — is where transformation knowledge lives. If the requester needs an HL7 field but a candidate server provides only the X12 equivalent, the selector decides whether to (a) reject the candidate as a non-match for this requirement, (b) accept it and apply transformation in the request path, or (c) route through an intermediate transformer.
This split has clean architectural consequences:
• Registry simplicity. The registry's matching algorithm is exact-IRI lookup. It has no equivalence database, no transformation rules, no semantic-similarity heuristics. The matching is fast, deterministic, and verifiable.
• Equivalence knowledge lives where it's used. Different selectors have different transformation knowledge — a healthcare-specific selector knows X12-FHIR equivalences; a payment-specific selector knows ISO-X12equivalences. Centralizing this knowledge in the registry would force every selector to inherit transformation logic it doesn't need.
• Selector autonomy. Different selectors can make different choices about what is interchangeable for their purposes. An audit-strict selector may refuse all transformations; a pragmatic-selector may accept lossless transformations but refuse lossy ones; a permissive selector may accept any transformation that preserves required semantics. The same registry serves all three.
• Honest matching semantics. “This server provides field X” in the manifest is exactly what the registry surfaces — no transformations applied, no equivalences silently substituted. Auditors and operators can rely on what the registry says without needing to model the registry's transformation behavior.
The implementation pattern is therefore: the manifest declares precisely what the entity natively handles; the selector applies transformation knowledge appropriate to its operating context; the registry stays simple and serves both.
Each data field declaration carries a strictness flag governing how rigid bilateral matching should be for that field. The flag distinguishes between fields that are essential to the entity's correct operation and fields that are useful but not strictly required.
• Strict declarations are essential. A requester whose manifest declares a strict requirement for a particular data field will be matched only against servers that declare exact provision of that field. A server's strict declaration that it requires a particular field from its requesters will reject any requester whose manifest does not declare the field. Strict declarations are how regulatory and operational must-haves surface in matching.
• Non-strict declarations are advisory. They communicate that the field is preferred or expected but not required. Anon-strict requirement still factors into match scoring (servers providing thefield are preferred over servers that don't), but does not produce a hard non-match in its absence. Non-strict declarations let manifests express preferences, defaults, and graceful-degradation patterns without inflating the strict-requirement bar.
As with the strictness flag on Process exclusions (see Process), the existence of the gradation reflects a real continuum in operational practice: not all field requirements are absolute, and treating them as if they were forces manifest authors into overly-restrictive declarations that fail to match in plausible deployments. The strictness flag preserves matching honesty by letting the manifest say what it actually means.
The exact bilateral matching semantics — how strict and non-strict declarations interact across requester and server, how scoring weights non-strict matches, how the matching algorithm handles edge cases — live in 3. NFR Schema §10.
Data field declarations identify what data the entity handles. They do not, in their current form, identify the classification of that data — its sensitivity level (PHI, PII, PCI, financial), regulatory scope (HIPAA, GDPR, PCI DSS), or organizational handling requirements. Classification is essential for matching that respects regulatory boundaries (“I cannot send PHI to an entity that does not declare HIPAA-compliant handling”), but it is not yet specified in the spec.
The Data Classification Annex is the planned spec extension that will introduce classification taxonomies and the manifest fields that reference them. When published, it will define:
• Sensitivity-level taxonomies (referenced through IRIs in the same manner as data field IRIs and process IRIs).
• Regulatory-scope declarations (HIPAA, GDPR, CCPA, PCIDSS, SOX, and others) that entities can declare for inbound and outbound flows.
• Bilateral matching semantics for classification declarations — when a regulatory mismatch is a hard non-match versus an advisory warning, how strictness applies in this domain.
• Cryptographic-parity requirements connecting classification declarations to runtime artifacts (Telemetry Records, SCT chain link claims) so that classification compliance is verifiable post-hoc.
Until the Annex publishes, organizations adopting SADAR for regulated workloads should plan for classification matching as an out-of-band concern, with the expectation that the Annex will formalize what is currently handled by deployment-side policy. Forward references in the current spec to the Annex are placeholders signaling that the integration point exists but the content is forthcoming.
This page covers data field declarations and the bilateral pattern they participate in at orientation depth. Several adjacent topics are intentionally out of scope here and live in dedicated documents: