Conformance

A deployment claims conformance per class, not as one blanket claim. This page defines the classes, how a claim declares what applies to it, and how the specification itself is validated and released.

Conformance classes

• Client: browser-side behavior. Identity resolution, session allocation, attribution capture, consent-gated storage, payload assembly and delivery.
• Server Integration: same-origin participation. Cookie issuance and refresh, the relay, handoff endpoints, server-injected request context.
• Endpoint: the receiving side. Schema validation, event_id deduplication, (session_id, session_seq) ordering, rejection behavior.

Every test scenario names the class or classes it applies to. A deployment without same-origin server or serverless participation may run in the explicitly nonpersistent ephemeral mode. It must not claim the persistent-identity profile (see Introduction).

Applicability manifest

A conformance claim is never a bare class name. It names the edition and, per class, the identity mode and the set of enabled capability modules. The requirement blocks in the specifications and the machine registries remain the sole authorities on behavior. This manifest only standardizes how a deployment declares which of those requirements apply to it.

Base capabilities, always required for a claimed class:

• Client: identity resolution under the declared identity mode, session allocation, attribution capture, consent-gated storage, payload assembly, and delivery discipline (dirty projection, one-shot triggers, retry queue).
• Server Integration: cookie issuance under the create/recover route contract, cookie refresh middleware, the same-origin relay, and server-injected request context. This class exists only under the persistent-identity profile. Ephemeral-mode deployments claim Client only.
• Endpoint: payload validation against the exact edition snapshot, event_id deduplication, (session_id, session_seq) ordering, and the declared rejection behavior. The endpoint accepts both the standard and the compact wire shapes.

Identity mode (Client; exactly one): the persistent-identity profile or the explicitly nonpersistent ephemeral mode. The profile requires same-origin server or serverless participation per the Introduction. Ephemeral mode keeps no persistent user identifier (UID) and must not claim the profile. It is an alternative mode, not an optional module.

Named optional modules:

Module	Classes	Dependency / exclusion	Configuration evidence
recovery	Client, Server Integration	Persistent-identity profile only	The explicit continuity recovery policy is configured; under the default privacy policy the module is off and no recovery call is ever made
handoff	Server Integration	Persistent-identity profile; structurally not applicable to single-domain deployments	Cross-domain mint/redeem routes deployed per the section-04 handoff contract
server_emission	Server Integration	Requires an authenticated server-to-server channel	emitter: "server" is asserted only on that channel; the Endpoint hard-rejects unauthenticated assertions regardless of any claim
restricted_measurement	All	Never implied by a core claim; default-off	The separately named profile’s own documented legal basis, minimization, schema, and retention policy exist [CONTROLLER][COUNSEL]

Compact-body production is a Client pre-freeze selection (MAY), not a module. Compact reception is part of the Endpoint base capabilities, not an option.

Scenario selection and N/A marking. The applicable scenario set for a claim is every scenario naming a claimed class, minus those whose exercised capabilities all belong to modules the claim leaves off. Mark a scenario N/A only in that case, or where the capability is structurally unreachable in the deployment (for example handoff scenarios in a single-domain deployment). Declare every N/A individually in the traceability report with scenario ID, class, module, and reason. N/A is never a convenience marker. Enabling a module makes all of its scenarios applicable, including its negative and security scenarios. N/A must never be used to set aside a capability the deployment in fact supports or exercises. A deployment that exercises a module’s behavior without claiming the module is non-conforming, not “N/A”.

A claim is expressible as data, for example:

{
  "edition": "3.1.1",
  "classes": {
    "client": { "identity_mode": "persistent_identity", "modules": ["recovery"] },
    "server_integration": { "modules": ["recovery"] },
    "endpoint": { "modules": [] }
  }
}

Edition authority

The schema version const in uiaf-payload.schema.json is the sole edition authority. The status strip on every page, the examples, the package metadata, and this page derive from it or are mechanically compared to it.

How drafts are handled

Draft handling is a timeless process rule, never a claim about current file contents: in-progress work carries a draft edition label and draft artifact URLs, drafts are never recorded in the release ledger, and the release gate replaces the draft label with the final edition string atomically at publication.

Machine contracts live at:

• /schema/v3/uiaf-payload.schema.json: wire schema (working latest-compatible alias).
• /schema/v3/uiaf-events.json: event registry (exactly session, conversion, identify).
• /schema/v3/uiaf-enums.json: closed enums and the pending-context allowlist.
• /schema/v3/uiaf-storage-keys.json: storage-key registry with purge rules.
• /schema/release-ledger.json: append-only release manifest.

Released editions publish an exact immutable snapshot under /schema/<edition>/. Reproducible consumers pin the exact release URL; the /schema/v3/ alias is convenience. Versioning and compatibility rules are defined in the repository’s VERSIONING.md; the payload-diff history is on the Changelog page.

Coverage policy

The scenario catalog is a prose conformance catalog: fixtures validate payload shapes in CI, and browser and storage behavior remains manually verified until a real automated harness exists. No raw scenario count is accepted as coverage evidence. The gate is coverage:

• every testable MUST / MUST NOT maps to at least one scenario in Test Scenarios.
• every security or rejection requirement has at least one negative scenario proving its declared failure reason.
• anything non-automatable carries a reviewed waiver with rationale, owner, and review date, tracked in the generated traceability report, never silently uncovered.

Requirement IDs (UIAF-NN-TOPIC-NNN) are unique, stable after publication, and never reused; retired scenarios become tombstones.

Validation gates

Continuous integration runs a fail-closed gate stack from a clean install under the pinned Node version. The stack covers schema and fixture validation, annotated-example validation, requirement/coverage integrity, and source integrity. It then runs a production build plus rendered link, navigation, and text-equivalent checks against the built output. A missing prerequisite is a failure, never a skip.

Release state

The published site is served at https://uiaf.dtv.dev with canonical URLs and sitemap metadata. External-link verification runs at the release gate.