Vord

Architecture

1. Introduction and goals

Status: living document. Reflects decisions through the initial design phase. Open questions are marked [OPEN] inline. The binding decisions are recorded in the ADRs; this overview describes the system they compose.

1.1 What this is

Vord is an open-source foundation for a globally scalable identity system — the substrate on which a provider can run authentication and authorization for both workforce identity (employees signing into applications; the Microsoft Entra ID / Okta shape) and customer identity (end-users of consumer applications; the Auth0 / CIAM shape), from one platform. It is the sibling of Wyrd, the distributed-storage foundation, and consumes Wyrd as its strongly-consistent core without altering it (ADR-0001).

The name is Old Norse vörðr — the guardian spirit bound to a person. An identity is precisely that: a warden attached to a principal, vouching for them across the system.

1.2 The headline guarantee

Authentication and authorization decisions are served by stateless cryptographic verification at the edge, independent of any read of the strongly-consistent core. A relying party verifies a Vord token against public key material and a clock — never a shared store — so the common path scales with edge nodes rather than with a central database. This is the constitution's rule 1 (ADR-0001) stated as the product promise, and it is what separates Vord from identity systems whose single strongly-consistent store is their scaling ceiling.

1.3 Quality goals

The forces the architecture is optimized for, in priority order; when two pull against each other, the lower-numbered one wins.

  1. Verification correctness and security. Bugs here are silent security failures, not crashes; this is gate-zero and outranks everything. Pursued structurally — a narrow verification contract that makes a core read a type error (ADR-0010), spec-first versioned token formats (ADR-0003), and deterministic simulation (ADR-0002).
  2. Edge scalability and a distributed write path. The differentiator moves verification off the core — it scales with edge nodes, not any shared store (rule 1), reading only public material, a clock, and cached projections. Equally first-class and easy to under-weight: the issuance / grant write path stays strongly-consistent, so it must scale by per-tenant sharding of the metadata tier and the authorization store — at customer-identity scale the binding constraint is login/registration write rate, not verification (ADR-0012, ADR-0026).
  3. Revocation freshness and operability. "Kill now" within a stated budget (ADR-0005); revocation lag, key-rotation lag, and edge-cache staleness are first-class telemetry.
  4. Scale range. The same codebase runs as a single binary for development and spans a global edge fleet in production (ADR-0024).
  5. Standards interoperability. OIDC-conformant by construction so relying parties use stock libraries (ADR-0003, ADR-0025).

Scale targets. The architecture is designed to serve a workforce tenant of 500K+ principals and a CIAM realm of millions of users from the same system, because directory size never reaches the verification path (ADR-0011, ADR-0012).

1.4 Stakeholders and target users

  • Primary: providers running Vord as a workforce-IdP (Entra/Okta replacement) or a customer-identity platform (Auth0 replacement).
  • Secondary: application teams integrating Vord as a standard OIDC/SAML provider; relying parties verifying Vord tokens with stock libraries.
  • Tertiary: developers and evaluators running the single-binary profile to learn or assess the system.

1.5 Scope boundaries

  • Vord issues and verifies identity; it is not the resource it protects. Relying applications and their resource servers are out of scope; Vord provides them tokens and authorization decisions.
  • The single-binary profile is dev/eval only, not a production durability or security tier (ADR-0024).
  • The constitution is the binding frame (ADR-0001): features that would require a strong core read on the hot path are served from projections, refused, or routed through an explicit slow path — by design.