How Vallum works
Six steps between a request and a consequence
This page describes the canonical target architecture for a single Vallum decision. It is a design target under active development, not a description of a completed production system.
Decision path
From request to record
Part of the intended Vallum architecture; the agreed design that implementation must satisfy. Does not mean implemented. Implementation maturity is reported separately on the development status page.
- 01 · REQUEST
Authenticated request
A human, agent, or service submits an intent to perform a consequential action. The request is bound to an authenticated identity before anything else is evaluated.
- 02 · IDENTITY
Identity and authority verification
Vallum verifies who is asking and whether that identity currently holds legitimate, scoped authority for the requested action. Authority traces back to a human grant; it is never self-asserted.
- 03 · POLICY
Policy and evidence evaluation
The request is evaluated against explicit policy. Required evidence, such as provenance of the artifact or the state of the target, must be present, fresh, consistent, and verifiable.
- 04 · DECISION
Deterministic ALLOW or BLOCK
The outcome is one of two values. The same inputs always produce the same decision. Missing, stale, ambiguous, inconsistent, unavailable, or unverifiable state resolves to BLOCK.
- ALLOW
Action proceeds within authorized scope.
BLOCKEnforcement point stops the effect. Nothing consequential occurs.
- 05 · ENFORCE
Policy-enforcement point stops the effect on BLOCK
A named policy-enforcement point sits in front of the consequential effect. On BLOCK, the effect does not occur. On ALLOW, the action proceeds within the authorized scope.
- 06 · EVIDENCE
Evidence and audit record
The decision, its inputs, the policy version, and the outcome are recorded with cryptographic provenance so that a reviewer who does not trust the operator can verify what happened.
What is not in the path
No AI in the trusted path
Vallum does not use AI, probabilistic scoring, natural-language judgment, or conversational approval inside its trusted PASS/FAIL path. Those tools may help people write policy or investigate incidents, but they do not decide, approve, or enforce.
This is a deliberate constraint. A decision that cannot be reproduced from its inputs cannot be verified later.
Truth boundary
What this page does not claim
- It does not claim that any step is implemented in production. See the development status page for the current position.
- It does not claim kernel-level or network-level enforcement. Where the enforcement point sits depends on the deployment profile and is qualified per profile.
- It does not claim guaranteed prevention. A fail-closed design reduces the ways an unauthorized action can proceed; it is not a promise that none ever will.
Walk through the architecture
Each step above corresponds to a named component. The architecture page lists them with their current status label.