This document is the orientation page for SADAR's Non-Functional Requirements (NFRs): the structured manifest declarations that organize properties and constraints into four canonical categories, and the three-tier strictness model that lets manifest authors choose how rigid each declaration should be in bilateral matching.
The normative basis lives across multiple sources. The 3. NFR Schema companion document is the canonical source for the four categories, every NFR field within each, and the matching semantics. The Website Narrative §Manifests and Matching provides the orientation framing this page builds on. SADAR Features §Three-Tier Matching Strictness introduces the strictness model. NFRs participate in bilateral matching as covered in the Core Functional Model sibling page; this page goes deeper into category structure and strictness semantics.
Audience: enterprise architects building or evaluating SADAR-conformant deployments; implementers writing manifests for their own entities; integration teams reasoning about how requesters and servers compose.
Non-Functional Requirements in SADAR are the structured declarations in a manifest that capture properties and constraints other than what the entity does. The substantive what — operations, processes, data fields handled — lives in the first-class manifest elements covered in their own pages (Business Process, Data Semantic Meaning).NFRs cover everything else: how the entity is priced, where it is deployed, what governance frameworks it operates within, and what protocol-level capabilities it provides or requires.
NFRs are bilateral. Each entity declares NFRs from two perspectives:
• As requirements — what the entity needs from a counterparty for the engagement to be valid (“My requester must satisfy these regulatory frameworks”).
• As provisions — what the entity offers (“I satisfy these regulatory frameworks; I host in these regions; I support these protocols”).
At discovery, the bilateral matching algorithm evaluates compatibility between requester requirements and server provisions, and between server requirements (of the requester) and requester provisions. Symmetry of treatment is a structural property of SADAR's discovery layer — there is no privileged side, and both sides' NFRs participate in the same matching machinery (see Core Functional Model).
Each NFR carries two pieces of metadata that determine its matching behavior: a category (which is structural, organizing the NFR namespace into the four canonical groups below) and a strictness level (which is policy, telling the matching algorithm how rigid this particular declaration should be). The category is fixed by the spec; the strictness is chosen by the manifest author.
NFRs are organized into four canonical categories. Each NFR belongs to exactly one category. The category determines which set of fields the NFR contains and which type-specific matching rules apply at discovery.
The four categories cover distinct concern domains. Financial NFRs answer “What does engagement cost?” Operational NFRs answer “Where and how is the entity deployed?” Governance NFRs answer “What institutional frameworks govern the entity?” Protocol NFRs answer “What protocol-level capabilities does the entity bring?” Each category has its own set of fields, validation rules, and type-specific matching semantics. The exact field-level content lives in 3. NFR Schema.
Financial NFRs declare the commercial terms of engaging an entity. The category covers cost structure (per-invocation, per-data-unit, time-windowed), currency, billing cadence and timing, prepayment or credit-line requirements, and tier structure (free vs paid, volume discounts). A requester reviewing candidate servers uses Financial NFRs to filter to those within its budget; a server declaring its provisions communicates the commercial terms requesters will need to satisfy.
Financial NFRs make pricing a first-class matching concern rather than an out-of-band negotiation. An entity that prices per invocation can declare the cost; one that requires prepayment declares the threshold; one offering tiered access declares the tiers and what each unlocks. The matching algorithm can then refuse pairings that fail commercial compatibility before invocation, surfacing budget-vs-cost mismatches at discovery rather than at billing time.
Operational NFRs declare deployment-level and runtime properties — the where and how of the entity's execution context. Geographic region (for data residency or latency optimization), hosting model (multi-tenant SaaS, dedicated tenant, customer-deployed), TLS minimum version and channel-binding requirements, environment identifier distinguishing production from staging or canary deployments, and availability windows for entities with scheduled service hours all live here.
Operational NFRs are matched as constraints. A requester declaring a region requirement (“EU only”) checks against the server's declared deployment regions; a server declaring a TLS-1.3minimum checks against the requester's supported TLS versions. The matching istype-specific (region matching is set membership; version matching is numeric comparison), but the categorical principle is the same: the matching algorithm verifies operational compatibility.
Governance NFRs declare the institutional frame within which the entity operates: regulatory framework conformance (HIPAA for healthcare, GDPR for European data, PCI DSS for cardholder data, SOX for financial reporting, FedRAMP for U.S. federal cloud),certifications and attestations (ISO 27001, SOC 2, ISO 42001 for AI management), audit retention discipline, oversight model (whether the entity operates autonomously or under human supervision), and human-in-the-loop requirements for specific operation classes.
Governance NFRs are central to regulated workloads. A healthcare requester sending PHI cannot be matched to a server that does not declare HIPAA conformance, regardless of any other capability match. A financial-services requester subject to SOX cannot use a server whose audit retention falls below the spec-mandated period. By making governance properties first-class declarations rather than implicit assumptions, the matching algorithm enforces compliance constraints at discovery rather than relying on out-of-band review.
Protocol NFRs declare protocol-level capabilities and requirements that go beyond the baseline every SADAR-conformant entity meets. The baseline (mTLS channel security, OIDC Client Credentials authentication, JWKS-published signing keys, per-spec authentication scopes) is universal. Protocol NFRs let entities declare capabilities or requirements above this baseline: Repatriation participation and field-level policy (see Repatriation), Impact Score for static potential-severity declaration (see Risk Score), supported SCT chain operations beyond the required minimum, custom authentication mechanisms (e.g., FIDO2 step-up, mTLS-with-client-attestation), or protocol extensions specific to particular industries.
Protocol NFRs are the extension point through which the spec evolves. New protocol capabilities are introduced as new Protocol NFRs; existing capabilities are extended through new fields within existing Protocol NFRs. Implementations that declare advanced Protocol NFRs interoperate richly with counterparties that share those declarations; implementations limited to the baseline still interoperate, just with a smaller surface.
Every NFR declaration carries a strictness level from a three-value set. The strictness level tells the bilateral matching algorithm how rigid this particular declaration should be when evaluating compatibility. The three levels — OPTIONAL, MANDATORY, MANDATORY_STRICT— give manifest authors a meaningful choice between soft preference, flexible requirement, and hard constraint.
An OPTIONAL declaration is purely advisory. It does not affect whether a candidate counterparty matches or not — pairs that would otherwise match still match if the OPTIONAL declaration is unsatisfied; pairs that would otherwise fail to match still fail. OPTIONAL declarations may inform scoring (a selector ranking candidates may prefer those that satisfy more OPTIONAL declarations) but never inform the binary match-or-no-match decision.
OPTIONAL is appropriate for preferences, hints, or documentation. A requester preferring EU-hosted servers but willing to accept others can declare its region preference as OPTIONAL —non-EU servers still appear as candidates, but the requester's selector can prefer EU candidates among them. A server declaring an OPTIONAL governance certification advertises the certification without making it a hard prerequisite for engagement.
Misuse of OPTIONAL is the most common manifest-authoring failure mode in practice. Authors who want to signal a strong preference but flinch at hard constraints sometimes default everything to OPTIONAL, producing manifests where nothing actually constrains matching. The matching algorithm cannot then enforce anything; the discipline of declaring requirements as MANDATORY when they are mandatory is what gives discovery its filtering power.
A MANDATORY declaration must be satisfied for a match. The bilateral matching algorithm applies the type-specific compatibility rule for the NFR — which often allows compatible-or-stronger satisfaction. A server's MANDATORY declaration of TLS1.2 minimum is satisfied by a requester supporting TLS 1.3 (1.3 is stronger, hence compatible). A server's MANDATORY HIPAA conformance requirement is satisfied by a requester declaring HIPAA + HITECH conformance (HITECH is a superset that includes HIPAA).
MANDATORY is the right level for most operational and governance requirements. A regulatory framework that admits stronger versions; a TLS minimum where exceeding the floor is acceptable; a certification where additional certifications still satisfy the requirement; a hosting region where multi-region deployment satisfies a single-region requirement — all are appropriately MANDATORY.
What MANDATORY does not allow is fundamental incompatibility. A requester needing PCI DSS conformance is nots atisfied by a server's HIPAA conformance, even though both are governance certifications, because they cover different concerns. The type-specific matching rule for governance frameworks knows that PCI DSS and HIPAA are not compatibility-equivalent. The matching algorithm enforces compatibility within the rule's defined notion of “compatible,” which is sometimes a strict superset relation, sometimes a typed comparison, sometimes a domain-specific equivalence— but always less permissive than “any value matches.”
A MANDATORY_STRICT declaration must be satisfied with exact equality. No substitution. No superset. No compatible-or-stronger flexibility. The declared value must appear, unmodified, in the counterparty's manifest, or the pair does not match.
MANDATORY_STRICT is rare and reserved for cases where the identity of the value, not just its compatibility, is the requirement. Examples include regulatory pinning where an organization is contractually bound to a specific framework version (“SOC 2 Type II specifically — Type I is not equivalent for our auditors”); vendor-relationship requirements where a specific certifying body's attestation is what the relationship requires; or version pinning where forward compatibility is not assumed (a procurement system might require ISO 20022 pacs.008 version 09,refusing version 10 even though 10 is a strict extension).
MANDATORY_STRICT exists because the gradient between flexible matching and exact matching is real and operationally meaningful. Without it, manifest authors needing exact matches would have to either accept MANDATORY's flexibility (and risk false matches) or work around the spec with out-of-band negotiation. The strictness flag preserves the integrity of bilateral matching as the discovery-time mechanism for compatibility verification.
The strictness flag is independent of the category. Any NFR in any of the four categories can be declared at any of the three strictness levels. A Financial NFR can be OPTIONAL(soft preference for cost ranges), MANDATORY (must fall within budget), or MANDATORY_STRICT (must match an exact pricing tier). A Governance NFR can be OPTIONAL (advertises a certification), MANDATORY (requires conformance with possible upgrades), or MANDATORY_STRICT (requires the exact certification). The same combinatorial freedom applies to Operational and Protocol NFRs.
This independence is deliberate. The category is structural — it organizes NFRs into matching-rule families and groups field definitions. The strictness is policy — it tells the matching algorithm how rigid this particular author wants this particular declaration to be. Conflating the two would tie strictness choices to category, which would force authors into category-determined rigidity rather than declaration-specific rigidity. By keeping them orthogonal, the spec gives authors the full 4 × 3 grid of meaningful declaration choices for every NFR they emit.
In practice, manifest authors learn to use the grid intentionally. Requirements that admit flexibility default to MANDATORY in the appropriate category. Soft preferences default to OPTIONAL. Hard constraints — regulatory pinning, version-exact requirements, contractually-fixed terms — default to MANDATORY_STRICT. The matching algorithm's behavior then directly reflects the manifest author's intent, with no out-of-band layer needed to translate between expressed declarations and actual matching outcomes.
This page covers NFR categories and the strictness model 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 this page extends.
• Business Process — first-class manifest element (not an NFR) covering business process declarations.
• Data Semantic Meaning — first-class manifest element (not an NFR) covering data field declarations.
• Repatriation — example of a Protocol NFR set: four NFRs (participation, endpoint, redacted_fields,required_unredacted_fields) governing one capability area.
• Risk Score — covers the Impact Score Protocol NFR alongside the runtime Risk Score concept.
• Authentication Scopes — the urn:sadar:scope:v1:* namespace; many Protocol NFRs reference scopes from this namespace.