Preview draft. Copy and visuals are pending review and may change before launch.

Architecture

Named components. Labeled status.

Vallum is specified as a set of components with explicit responsibilities. Every component below carries a status label that describes the state of the design. It says nothing about implementation.

Status labels used on this page:
  • CANONICAL TARGET
  • PROVISIONAL
  • BLOCKED
  • UNKNOWN
  • IMPLEMENTED — EVIDENCE REQUIRED
Definitions
Not implemented

CANONICAL TARGET means the component is part of the intended Vallum architecture. It does not mean the component is implemented. Implementation maturity is reported separately: the overall software candidate is BLOCKED and production qualification is NOT ACHIEVED. Development status

  1. 01

    Identity and admission

    CANONICAL TARGET

    Establishes who a principal is and whether it may be admitted to make requests at all.

    • Every principal, human, agent, or service, is bound to a verifiable identity before a request is considered.
    • Admission is scoped: an identity is admitted to a defined set of request types, not to the system as a whole.
    • Identities that cannot be verified are not admitted. There is no anonymous or implicit path.
  2. 02

    Authorization Handshake

    CANONICAL TARGET

    The exchange in which a principal presents an intent and Vallum establishes that legitimate, scoped authority exists for it.

    • Authority traces to a human grant. A principal cannot assert or expand its own authority within the handshake.
    • Scope is explicit: the target, the operation, and the conditions are named, not inferred.
    • The handshake produces an authorization record that later stages reference by identity rather than by trust.
  3. 03

    Policy decision

    CANONICAL TARGET

    Evaluates the authorized intent against written policy and required evidence, and returns ALLOW or BLOCK.

    • Decisions are deterministic. Identical inputs yield identical outputs, which is what makes them reviewable.
    • Policy is versioned. The version in force is part of the decision record.
    • No AI, probabilistic scoring, or natural-language judgment participates in the decision.

    BoundaryFail-closed behavior on missing, stale, ambiguous, inconsistent, unavailable, or unverifiable state is part of the canonical target and is qualified per deployment profile.

  4. 04

    Policy-enforcement point

    CANONICAL TARGET

    The named component that sits in front of a consequential effect and stops it on BLOCK.

    • Enforcement happens before the effect, not as a report after it.
    • Each protected effect has a named enforcement point so that its coverage can be stated and tested.
    • On ALLOW, the effect proceeds within the authorized scope and no further.

    BoundaryKernel-level and network-level enforcement are not implemented. Where an enforcement point can be placed is determined and qualified per deployment profile.

  5. 05

    Evidence verification and provenance

    CANONICAL TARGET

    Verifies the evidence a policy requires and records every decision with cryptographic provenance.

    • Evidence is checked for presence, freshness, consistency, and verifiability before it counts.
    • Decision records bind the request, identity, authorization, policy version, and outcome.
    • Records are designed to be verified by a reviewer who does not trust the operator.
  6. 06

    Revocation, quarantine, containment, and recovery

    CANONICAL TARGET

    Removes authority, isolates affected principals or artifacts, limits blast radius, and restores a known-good state under human control.

    • Revocation is immediate in intent: once authority is withdrawn, subsequent decisions on it resolve to BLOCK.
    • Quarantine isolates a principal or artifact pending governed human review.
    • Recovery restores state from preserved evidence rather than from operator memory.

    BoundaryAutomatic circuit breakers are not completed. In the current design, containment actions are human-initiated. This component is part of the intended architecture; its implementation maturity is reported separately on the development status page.

  7. 07

    Trust-root and key lifecycle

    CANONICAL TARGET

    Defines how the trust root is established, how keys are issued, rotated, and retired, and who may change any of it.

    • Trust-root changes require governed human approval. No administrator, agent, backup, or successor holds automatic root authority.
    • Key issuance and rotation are recorded as decisions with the same evidence requirements as any other consequential action.
    • Loss or compromise of a key is treated as a containment event, not a configuration change.

    BoundaryCeremony and custody details are not published. This component is part of the intended architecture; its implementation maturity is reported separately on the development status page.

Read the status definitions

The documentation index defines every label used on this page and lists the architecture documents behind each component.

Open the docs