8. Cross-cutting concepts

8.1 The consistency contract

Default reads are bounded-staleness and edge-local; read-your-writes-sensitive decisions present an opaque consistency token (the Zanzibar "zookie") and are served only by a sufficiently-fresh replica (ADR-0004). In production there are two strongly-consistent domains — the Wyrd identity core and the Forseti relation store — so a decision spanning both (a just-changed credential and a just-granted permission) presents a composite token that fences each, served only when both are caught up (ADR-0026). Each domain holds only its irreducible facts — issuance/uniqueness/revocation in the core, relation tuples in the Forseti store (rule 2, read per-domain); everything else is eventually-consistent.

8.2 Revocation and freshness

Short-TTL-dominant tokens, a signed Token Status List cached at the edge for "kill now," and NATS for urgent propagation, all as CQRS projections of a core-resident authoritative set (ADR-0005). Revocation lag is a first-class, instrumented signal.

8.3 Observability — three planes

Instrumented with OpenTelemetry (traces / metrics / logs, backend-agnostic; the full spec is proposal 0012). A request plane (RED metrics per plane); a security / freshness plane — the differentiator's telemetry: revocation lag, key-rotation lag, edge-cache staleness, and failed-verification / login-failure rates (the "are we silently serving stale auth, or under attack right now?" signals); and a capacity plane — per-tenant metadata-op-rate (Wyrd ADR-0018 §4), the binding scaling dimension. All derive from the identity event stream (ADR-0022).

Telemetry obeys the constitution: edge (Vör) instrumentation is async, best-effort, and never a hot-path core read — a verification never blocks on or fails because of telemetry (entailed by rule 1 and the no-core-handle Vör contract, ADR-0010). SLOs (verification latency, revocation lag, issuance latency, key-rotation lag) are first-class quality attributes (§10). Operational telemetry is distinct from the audit record: the event stream (ADR-0022) is the durable, replayable audit / compliance / billing substrate (streamed out via proposal 0009); the OTel metrics / traces are the ephemeral ops view.

8.4 Security and trust

Vord is the security system. The load-bearing concept is the Modgud↔Vör split (ADR-0015): authentication is stateful and core-touching; verification is stateless and core-independent; assurance (amr/acr) travels in the signed token, never a core query. Signing keys are custody-trait-held (ADR-0003, ADR-0023). The central security cost is named, not hidden: edge verification means a stolen access token is valid until expiry or the status-list refresh — Vord trades the instant, always-hit-the-core session-kill of a centralized IdP for core-independence. Short TTLs bound the window, the status list closes it within the freshness budget (ADR-0005), and DPoP (reserved, ADR-0014) sender-constrains tokens so a stolen bearer is not enough — the deliberate counter-position to an instant-kill model, owned on purpose. The full adversarial view — assets, trust boundaries, the attack catalog, and the abuse-case tests — is the threat model (§12, ADR-0027).

8.5 Multi-tenancy and realm isolation

The tenant is the shard, isolation, and residency boundary (rule 3); the four boundaries (namespace, cryptographic, capacity, performance) are enforced at the admission tier (ADR-0012). Workforce tenant and CIAM realm are policy over one mechanism, at 500K+ principals/tenant and millions/realm — directory size never reaches the verification path (ADR-0011).

8.6 The thick SDK and conformance

The SDK propagates the consistency token across services (ADR-0004); the token/credential conformance vectors (ADR-0003) let a non-Vord verifier read a token correctly long after issuance — "data outlives software" applied to tokens, demonstrated by certification (ADR-0025).

8.7 Compatibility and version skew

Every token carries its format version and is rejected if unknown (ADR-0003); keys are kid-versioned with publish-before-sign rotation (ADR-0023); directory records are schema-versioned (ADR-0011).

8.8 The front-channel / hot-path boundary

The restatement that every feature is filed against: issuance (Modgud) is stateful and may read the core; verification (Vör) is stateless and may not. SAML, SCIM, MFA, and federation all sit on the issuance side and emit only edge-verifiable artifacts (ADR-0009, ADR-0017).

8.9 The issuance / write path

The verification story can distract from where the real ceiling is. Verification scales off the core (§8.8, ADR-0010); issuance, registration, and permission grants do not — they are strongly-consistent writes (issuance to the Wyrd core, grants to the Forseti store, ADR-0026). At customer-identity scale the binding constraint is the login/registration write rate, and the honest claim is exactly this: Vord beats a single-store identity system to the extent that the per-tenant-sharded Wyrd metadata tier (Wyrd ADR-0018 §4) and a sharded Forseti store out-write one database — proved under a login-storm at M4 and M8 (§10, V3–V4), not assumed.