# Consequential Reachability

## Cover block

Series and number: SEM, ARC-SEM-001
Series mark: ΛRC
Title: Consequential Reachability
State: Adopted, first issue, October 21, 2026
Adoption act: Founder Ricky, October 21, 2026, 6:41 PM PDT, by the words "you have my approval for the CLI manual and then for all the documentation so that you can publish that into its corresponding places repo website app CLI"; this document is one of the seven tranche-one documents adopted by that ruling, and the adoption is recorded in the corpus registry
Evidence grade: E1 Evidenced at the level of the volume. The claims table inside carries E0 through E2 per invariant under the charter's first standard, and the lowest claim grade in the table is E0, printed here so no reader mistakes the volume grade for the weakest claim's grade
Digest: computed at filing and carried in the corpus registry; the digest of this draft as filed is recorded with its filing act
License line: the text of this document is licensed under CC BY 4.0, attribution the only condition; code samples in this document are under the Apache License 2.0; the ΛRC and VΛLIS names and marks are not licensed under either instrument. Decided by Founder Ricky on October 21, 2026, at 6:45 PM PDT
Next review date: October 21, 2027, and at the close of the drafting tranches, whichever comes first, on the formula the charter carries on its own cover
Stable address: the corpus registry entry for ARC-SEM-001, when the registry stands
Authority note: this document specifies a computational object and grades the record behind it. It confers no authority, admits nothing, and settles nothing. Under the charter's fourth standard, a document describes; governance disposes.

## How to read this volume

This volume follows the charter's instruction for its drafting: the claims table comes before the prose. Consequential reachability is the first computational object of the standard, and the honest way to present it is to show, invariant by invariant, what the record proves today and what it does not, before any narrative smooths the difference. The table below carries all ninety-eight invariants of the consequence security invariant mapping of October 20, 2026, each with the grade this volume assigns under the charter's first standard and a pointer to the evidence as the mapping states it.

The grading convention is derived from the mapping's own three standing classes and is stated here so it can be checked. Where the mapping records an invariant as Evidenced, meaning an independently checkable record stands today that proves the invariant at the scope the entry states, this volume grades the claim E2, verified at that stated scope and at no wider scope. Where the mapping records Suite only, meaning a named suite or check exercises the invariant or its scoped form while no independently verified evidence stands at full scope, this volume grades the claim E1. Where the mapping records Neither, meaning no suite and no evidence stand, this volume grades the claim E0, declared, and the invariant stands as a build item on the programme's work list. The scope words in each row's pointer are the mapping's own, carried without widening.

## The claims table

| Invariant | Claim | Grade | Evidence pointer |
|---|---|---|---|
| INV-01 | Authority laundering never settles | E2 | The invariant mapping of October 20, 2026, entry INV-01, whose standing stands there as: Evidenced, at reference implementation scope. |
| INV-02 | Fabricated evidence never validates | E2 | The invariant mapping of October 20, 2026, entry INV-02, whose standing stands there as: Evidenced, at reference implementation scope, with a named open counterexample at the deployed backend layer. |
| INV-03 | No consequential effect occurs except through a settled release | E1 | The invariant mapping of October 20, 2026, entry INV-03, whose standing stands there as: Suite only, with the deployed estate form unevidenced. |
| INV-04 | Execution binds the exact proposal | E2 | The invariant mapping of October 20, 2026, entry INV-04, whose standing stands there as: Evidenced, at research prototype scope. |
| INV-05 | No single key satisfies any authorization shape | E0 | The invariant mapping of October 20, 2026, entry INV-05, whose standing stands there as: Neither. |
| INV-06 | The settlement grammar holds no unilateral path | E0 | The invariant mapping of October 20, 2026, entry INV-06, whose standing stands there as: Neither. |
| INV-07 | Coercion of any one person yields zero capability | E0 | The invariant mapping of October 20, 2026, entry INV-07, whose standing stands there as: Neither. |
| INV-08 | A duress marked act never settles and its mark stays invisible | E0 | The invariant mapping of October 20, 2026, entry INV-08, whose standing stands there as: Neither. |
| INV-09 | A release is consumed once and replay is a non object | E2 | The invariant mapping of October 20, 2026, entry INV-09, whose standing stands there as: Evidenced, at the wrapper and reference implementation scopes named. |
| INV-10 | Settled value never exceeds authorized value | E1 | The invariant mapping of October 20, 2026, entry INV-10, whose standing stands there as: Suite only. |
| INV-11 | One active claim per asset wins atomically at commit | E2 | The invariant mapping of October 20, 2026, entry INV-11, whose standing stands there as: Evidenced, within the reference implementation. |
| INV-12 | Admission refuses while an exposure stands unresolved and budgets bind across actions | E2 | The invariant mapping of October 20, 2026, entry INV-12, whose standing stands there as: Evidenced, as lived operational record. |
| INV-13 | Engine state writes are atomic under lock | E2 | The invariant mapping of October 20, 2026, entry INV-13, whose standing stands there as: Evidenced, for the engine writer only. |
| INV-14 | Discharge stands only on evidence that resolves and recomputes | E0 | The invariant mapping of October 20, 2026, entry INV-14, whose standing stands there as: Neither. |
| INV-15 | Stale prerequisites invalidate the actions that depend on them | E0 | The invariant mapping of October 20, 2026, entry INV-15, whose standing stands there as: Neither. |
| INV-16 | Authority is scoped, expiring, and revocable at exercise time | E2 | The invariant mapping of October 20, 2026, entry INV-16, whose standing stands there as: Evidenced, within the reference implementation, with the delegation register form unbuilt and named. |
| INV-17 | No principal inherits another principal authority | E0 | The invariant mapping of October 20, 2026, entry INV-17, whose standing stands there as: Neither. |
| INV-18 | A denial can never be consumed as an admission | E2 | The invariant mapping of October 20, 2026, entry INV-18, whose standing stands there as: Evidenced, at the sanctioned call sites, with the wider script population unverified. |
| INV-19 | The record is one recomputable hash linked chain | E2 | The invariant mapping of October 20, 2026, entry INV-19, whose standing stands there as: Evidenced, at the registry and release tree scopes named. |
| INV-20 | Checkpoints anchor the head outside the replica set | E2 | The invariant mapping of October 20, 2026, entry INV-20, whose standing stands there as: Evidenced. |
| INV-21 | Statement validity is an exact verification result | E2 | The invariant mapping of October 20, 2026, entry INV-21, whose standing stands there as: Evidenced, with the format own limits named. |
| INV-22 | The release tree stands under a signed manifest | E2 | The invariant mapping of October 20, 2026, entry INV-22, whose standing stands there as: Evidenced, for the release own tree, with the runtime vetting boundary named. |
| INV-23 | The field serves only relations carrying a retain disposition | E0 | The invariant mapping of October 20, 2026, entry INV-23, whose standing stands there as: Neither. |
| INV-24 | No failure is silent in the record | E0 | The invariant mapping of October 20, 2026, entry INV-24, whose standing stands there as: Neither. |
| INV-25 | A registration proposal verifies or stands refused as an entry | E2 | The invariant mapping of October 20, 2026, entry INV-25, whose standing stands there as: Evidenced. |
| INV-26 | Admitted addresses stay unique and duplicate admission refuses | E2 | The invariant mapping of October 20, 2026, entry INV-26, whose standing stands there as: Evidenced, for uniqueness enforcement, with the no expiry fence named. |
| INV-27 | Registry admission allocates atomically under lock | E0 | The invariant mapping of October 20, 2026, entry INV-27, whose standing stands there as: Neither. |
| INV-28 | The genesis entry is anchored and compared field by field | E0 | The invariant mapping of October 20, 2026, entry INV-28, whose standing stands there as: Neither. |
| INV-29 | Checkpoints are pinned, chained, and fresh or refused | E0 | The invariant mapping of October 20, 2026, entry INV-29, whose standing stands there as: Neither. |
| INV-30 | Carried identity records are authentic or refused | E0 | The invariant mapping of October 20, 2026, entry INV-30, whose standing stands there as: Neither. |
| INV-31 | Presence counts only from verified beats | E2 | The invariant mapping of October 20, 2026, entry INV-31, whose standing stands there as: Evidenced, with the replay bound named. |
| INV-32 | Presence freshness binds to publisher observed time | E0 | The invariant mapping of October 20, 2026, entry INV-32, whose standing stands there as: Neither. |
| INV-33 | The served presence record is signed or checkpoint bound | E0 | The invariant mapping of October 20, 2026, entry INV-33, whose standing stands there as: Neither. |
| INV-34 | A surface never renders presence stronger than its source | E2 | The invariant mapping of October 20, 2026, entry INV-34, whose standing stands there as: Evidenced, at code and format level, for our own surfaces only. |
| INV-35 | Mailbox content is sealed to the recipient key | E2 | The invariant mapping of October 20, 2026, entry INV-35, whose standing stands there as: Evidenced, at the shipped kit layer only, and open at the deployed layer. |
| INV-36 | Envelopes are authenticated and trust gated before they are held as trusted | E2 | The invariant mapping of October 20, 2026, entry INV-36, whose standing stands there as: Evidenced, at the shipped kit layer only, and open at the deployed layer. |
| INV-37 | The relay stays blind and its carriage stays bounded | E2 | The invariant mapping of October 20, 2026, entry INV-37, whose standing stands there as: Evidenced, at the shipped kit layer, at the fair grade the family assigned. |
| INV-38 | Collection requires both keys and a fresh nonce | E2 | The invariant mapping of October 20, 2026, entry INV-38, whose standing stands there as: Evidenced, at the shipped relay layer. |
| INV-39 | Channel challenges die on first use and sessions bind to the registry key | E2 | The invariant mapping of October 20, 2026, entry INV-39, whose standing stands there as: Evidenced, in staged code only, and not deployed. |
| INV-40 | Registry sync can never substitute a key for an address | E2 | The invariant mapping of October 20, 2026, entry INV-40, whose standing stands there as: Evidenced, in staged code only, and not deployed. |
| INV-41 | Channel traffic rests only as sealed envelopes | E0 | The invariant mapping of October 20, 2026, entry INV-41, whose standing stands there as: Neither. |
| INV-42 | Relay metadata is released only to its recipient | E0 | The invariant mapping of October 20, 2026, entry INV-42, whose standing stands there as: Neither. |
| INV-43 | The record travels more than one path and disagreement enters as divergence | E0 | The invariant mapping of October 20, 2026, entry INV-43, whose standing stands there as: Neither. |
| INV-44 | Healing never silently patches | E0 | The invariant mapping of October 20, 2026, entry INV-44, whose standing stands there as: Neither. |
| INV-45 | Restoration follows anchors and never majority | E0 | The invariant mapping of October 20, 2026, entry INV-45, whose standing stands there as: Neither. |
| INV-46 | A disputed checkpoint halts healing | E0 | The invariant mapping of October 20, 2026, entry INV-46, whose standing stands there as: Neither. |
| INV-47 | A copy diverging twice at one sequence stays quarantined until a seat act | E0 | The invariant mapping of October 20, 2026, entry INV-47, whose standing stands there as: Neither. |
| INV-48 | A compromised key heals by suspension, replacement, and review, with history intact | E0 | The invariant mapping of October 20, 2026, entry INV-48, whose standing stands there as: Neither. |
| INV-49 | A bulletin exists only as a signed ledger entry | E0 | The invariant mapping of October 20, 2026, entry INV-49, whose standing stands there as: Neither. |
| INV-50 | A bulletin can never change a binding parameter | E0 | The invariant mapping of October 20, 2026, entry INV-50, whose standing stands there as: Neither. |
| INV-51 | Consumption is an entry and every pattern refusal names its bulletin | E0 | The invariant mapping of October 20, 2026, entry INV-51, whose standing stands there as: Neither. |
| INV-52 | Every signed object carries a suite identifier inside the signed bytes | E0 | The invariant mapping of October 20, 2026, entry INV-52, whose standing stands there as: Neither. |
| INV-53 | The suite registry is a governed text and migration moves in published stages | E0 | The invariant mapping of October 20, 2026, entry INV-53, whose standing stands there as: Neither. |
| INV-54 | Key lifecycle events are entries in the record the keys serve | E0 | The invariant mapping of October 20, 2026, entry INV-54, whose standing stands there as: Neither. |
| INV-55 | Keys stay separated by custody class and private material never rests group readable | E2 | The invariant mapping of October 20, 2026, entry INV-55, whose standing stands there as: Evidenced, with the one named staging exception standing open. |
| INV-56 | Update manifests are signed end to end and the anchor carries its exit | E1 | The invariant mapping of October 20, 2026, entry INV-56, whose standing stands there as: Suite only. |
| INV-57 | Update publication refuses an absent signature and verifies every asset digest | E0 | The invariant mapping of October 20, 2026, entry INV-57, whose standing stands there as: Neither. |
| INV-58 | Wrapper requests are signed over a canonical payload | E1 | The invariant mapping of October 20, 2026, entry INV-58, whose standing stands there as: Suite only, with the deployed tier unverified. |
| INV-59 | The KORE decision record is hash linked and its identifiers reveal nothing | E0 | The invariant mapping of October 20, 2026, entry INV-59, whose standing stands there as: Neither. |
| INV-60 | A generated cryptographic inventory stands with its triggers instrumented | E0 | The invariant mapping of October 20, 2026, entry INV-60, whose standing stands there as: Neither. |
| INV-61 | Confidential channels adopt hybrid key establishment on the Mosca arithmetic | E0 | The invariant mapping of October 20, 2026, entry INV-61, whose standing stands there as: Neither. |
| INV-62 | Membership never converts into power | E2 | The invariant mapping of October 20, 2026, entry INV-62, whose standing stands there as: Evidenced, in its formal shape only, with the residual pipeline shapes open. |
| INV-63 | A seat recipient never authorizes their own release | E0 | The invariant mapping of October 20, 2026, entry INV-63, whose standing stands there as: Neither. |
| INV-64 | An opposed standard release escalates to the full seat shape | E0 | The invariant mapping of October 20, 2026, entry INV-64, whose standing stands there as: Neither. |
| INV-65 | One person aggregate holdings meet a ceiling at settlement | E0 | The invariant mapping of October 20, 2026, entry INV-65, whose standing stands there as: Neither. |
| INV-66 | Suspension is bounded, externally reviewed at three seats, and priced in bad faith | E0 | The invariant mapping of October 20, 2026, entry INV-66, whose standing stands there as: Neither. |
| INV-67 | Succession stands instrumented before it is needed | E0 | The invariant mapping of October 20, 2026, entry INV-67, whose standing stands there as: Neither. |
| INV-68 | Signing is read back through an independent channel | E0 | The invariant mapping of October 20, 2026, entry INV-68, whose standing stands there as: Neither. |
| INV-69 | Delegations stay bounded for life across every renewal | E0 | The invariant mapping of October 20, 2026, entry INV-69, whose standing stands there as: Neither. |
| INV-70 | Recovery never rewrites history and never moves balances by assertion | E0 | The invariant mapping of October 20, 2026, entry INV-70, whose standing stands there as: Neither. |
| INV-71 | Recovery meets floors no declaration may go below | E0 | The invariant mapping of October 20, 2026, entry INV-71, whose standing stands there as: Neither. |
| INV-72 | Enforcement never precedes proven notice | E0 | The invariant mapping of October 20, 2026, entry INV-72, whose standing stands there as: Neither. |
| INV-73 | The uncuratable pin carries a budget | E0 | The invariant mapping of October 20, 2026, entry INV-73, whose standing stands there as: Neither. |
| INV-74 | Standing stays visible, change aware, and periodically reattested | E0 | The invariant mapping of October 20, 2026, entry INV-74, whose standing stands there as: Neither. |
| INV-75 | Every binding text ships as a digest bound pair with a comprehension gate | E0 | The invariant mapping of October 20, 2026, entry INV-75, whose standing stands there as: Neither. |
| INV-76 | Setup never asks for a secret in chat and never encrypts silently | E1 | The invariant mapping of October 20, 2026, entry INV-76, whose standing stands there as: Suite only, at instruction strength. |
| INV-77 | Custody is confirmed where the key lives before standing counts on it | E1 | The invariant mapping of October 20, 2026, entry INV-77, whose standing stands there as: Suite only, with the current readings unmet. |
| INV-78 | Setup completes only with a performed backup and restore | E0 | The invariant mapping of October 20, 2026, entry INV-78, whose standing stands there as: Neither. |
| INV-79 | Device loss runs a published order of operations with a freeze act | E0 | The invariant mapping of October 20, 2026, entry INV-79, whose standing stands there as: Neither. |
| INV-80 | Every state writer routes through the one atomic writer | E0 | The invariant mapping of October 20, 2026, entry INV-80, whose standing stands there as: Neither. |
| INV-81 | Claims are swept only on lease, liveness evidence, and a cap | E2 | The invariant mapping of October 20, 2026, entry INV-81, whose standing stands there as: Evidenced, as operated practice under the lifecycle standard. |
| INV-82 | A reserved claim blocks only its resource subclass | E0 | The invariant mapping of October 20, 2026, entry INV-82, whose standing stands there as: Neither. |
| INV-83 | Load bearing seats are watched and silence pauses the work that targets them | E1 | The invariant mapping of October 20, 2026, entry INV-83, whose standing stands there as: Suite only, at one watched seat. |
| INV-84 | Nothing counts as published until the real client parser has accepted it | E1 | The invariant mapping of October 20, 2026, entry INV-84, whose standing stands there as: Suite only, with the pattern instance evidenced. |
| INV-85 | Releases carry signed provenance bound to the lockfile | E0 | The invariant mapping of October 20, 2026, entry INV-85, whose standing stands there as: Neither. |
| INV-86 | Deciding routes check a role and the decider comes from the session | E0 | The invariant mapping of October 20, 2026, entry INV-86, whose standing stands there as: Neither. |
| INV-87 | A decided approval can never be redecided | E2 | The invariant mapping of October 20, 2026, entry INV-87, whose standing stands there as: Evidenced, at code level. |
| INV-88 | Secret comparisons fail closed and in constant time | E0 | The invariant mapping of October 20, 2026, entry INV-88, whose standing stands there as: Neither. |
| INV-89 | Dispatch consumes before it executes and only success ever receipts | E0 | The invariant mapping of October 20, 2026, entry INV-89, whose standing stands there as: Neither. |
| INV-90 | Endpoint safety is rechecked at dispatch | E0 | The invariant mapping of October 20, 2026, entry INV-90, whose standing stands there as: Neither. |
| INV-91 | Credentials resist attack at the gate and at rest | E0 | The invariant mapping of October 20, 2026, entry INV-91, whose standing stands there as: Neither. |
| INV-92 | The economy publisher refuses on any disagreement | E2 | The invariant mapping of October 20, 2026, entry INV-92, whose standing stands there as: Evidenced, at publisher strength, with the residual trust named. |
| INV-93 | Served economy documents verify against their activation entry, never their shape | E0 | The invariant mapping of October 20, 2026, entry INV-93, whose standing stands there as: Neither. |
| INV-94 | The meter rides inside the receipt | E0 | The invariant mapping of October 20, 2026, entry INV-94, whose standing stands there as: Neither. |
| INV-95 | Declared class is checked against observed use | E0 | The invariant mapping of October 20, 2026, entry INV-95, whose standing stands there as: Neither. |
| INV-96 | Aggregation is evaluated across controllers and thresholds bind only after publication | E0 | The invariant mapping of October 20, 2026, entry INV-96, whose standing stands there as: Neither. |
| INV-97 | Standing decays unless witnessed and inherited standing re earns | E0 | The invariant mapping of October 20, 2026, entry INV-97, whose standing stands there as: Neither. |
| INV-98 | Agents hold no economic identity of their own | E0 | The invariant mapping of October 20, 2026, entry INV-98, whose standing stands there as: Neither. |

## Introduction and goals

Consequential reachability is, in the vocabulary of record [ARC-STD-1], the exact set of effects an actor can actually reach from where it stands, computed before it acts. It is the object settlement is evaluated against. A proposal does not ask whether an actor is trusted in general; it asks whether this specified consequence is legitimately reachable by this actor, from this position, under explicit authority and constraints, and the answer is computed before any effect takes place.

The founding specification of the consequence security programme states the doctrine the object serves, and the sentence is quoted here in its exact words, as the mapping of October 20, 2026 carries it: "A compromised agent should not automatically inherit the ability to cause every consequence accessible to its tools or credentials." The boundary sentence travels with it, also exact: "We cannot promise it for paths outside the enforcement boundary." Every claim in this volume stands inside that boundary or is marked as standing outside the record. Entries whose threat lives outside the boundary were not entered as invariants in the mapping, and this volume does not invent them.

## Constraints

The sealed specification of the founding release bounds the object on its face, and this volume inherits the bound without widening it. The computed set covers only registered, modeled, and enforced pathways. Undisclosed out-of-band capabilities, unknown dependencies, compromised clocks, and unobserved effects cannot be represented as complete knowledge. The specification's open questions stand open in this volume as well: canonical relation grammar, trust anchors, typed exposure dimensions, the time oracle, independent observer requirements, totality and determinism conditions, and equivalence under representational transformations, each to be resolved from verified source rather than from invented compatibility claims.

## Context and scope

The system context, drawn as text under the charter's diagram programme, stands as follows. The diagram is a drafting figure, authored as text and versioned with this prose; it depicts the enforced pathway only, and anything outside the settlement gate is outside the diagram for the same reason it is outside the claims.

```mermaid
flowchart LR
    A[Actor, holding an admissible identity] -->|signed proposal| S[Settler]
    S -->|computes consequential reachability against authority, constraints, budgets, dependencies| R{Reachable and admissible}
    R -->|yes| REL[Single-use release]
    R -->|no| REF[Refusal, entered in the record]
    REL -->|consumed once| X[Execution]
    X -->|observed effect| E[Evidence]
    E --> ST[Statement, verifiable by anyone]
    ST --> L[(Governed record, hash-linked)]
    REF --> L
```

The two named attacks the programme defends against stand at the head of the claims table because they name the object's characteristic failures. Authority laundering is presenting caller-supplied claims of authority as if they were verified authority, and its defense is independent authority verification at settlement, with authority never taken from the proposer's own assertions [INV-01]. Evidence laundering is presenting well-formed evidence as if formatting were provenance, and its defense is independently verifiable provenance, cryptographically protected [INV-02]. Both stand evidenced at reference implementation scope, and INV-02 carries a named open counterexample at the deployed backend layer, graded inside its own entry and answered under INV-89, which stands at E0. This volume prints both facts at the same size.

## Solution strategy

Settlement computes reachability as a conjunction, never as a reputation. The sealed formal semantics sketch states the judgments the computation must make: the proposal is well formed; authority is valid, invalid, or unknown, with unknown never treated as valid; dependencies are satisfied, unsatisfied, or unknown; exposure is reserved atomically under a shared budget identity before execution; a release is consumed exactly once; and an unknown effect is never treated as zero exposure and never silently upgraded into a confirmed effect at attestation. The operating form of the same strategy is specified in [ARC-GOV-002], and the invariants of the claims table are its checkable decomposition: mediation and binding in INV-03 through INV-18, the record and its Statements in INV-19 through INV-24, registry, identity, presence, and transport in INV-25 through INV-43, self-healing in INV-44 through INV-48, attacks as immunity in INV-49 through INV-51, cryptographic agility and the key lifecycle in INV-52 through INV-61, governance and the human layer in INV-62 through INV-79, operations and the supply chain in INV-80 through INV-93, and metering and the machine economy in INV-94 through INV-98.

## Building block view

The building blocks are the settler, which verifies identity, authority, consistency, and admissibility and clears or refuses the release; the gate, which stands in front of execution so that no consequential effect occurs except through a settled release; the record, one recomputable hash-linked chain in which every act and every refusal stands entered; the field, which serves only relations carrying a retain disposition and never serves as the operational ledger; and the verifier, by which any reader checks a Statement from the public record alone. The blocks are specified at the level this record supports. Their implementations stand at the scopes the claims table grades, and no block is described here at a strength its invariants do not carry.

## Runtime view

At runtime the pipeline is the lifecycle of the vocabulary of record: proposal, settlement, release, execution, evidence, receipt. The settlement step is where reachability is computed, and it is the only step that can clear a proposal into a release. Execution binds the exact proposal that settled [INV-04]. The release is consumed once and replay is a non-object [INV-09]. Discharge of a reservation stands only on evidence that resolves and recomputes [INV-14], which stands at E0 in the table, and this volume flags the consequence plainly: the operating record shows discharge on evidence as daily practice under the KORE engine [ARC-GOV-002], while the general invariant as the mapping states it carries no suite and no evidence at its full scope. Both statements are true at their own scopes, and the table's grade follows the mapping.

## Deployment view

What stands deployed today is stated in [ARC-GOV-002] with designed, staged, and live labels per mechanism. For this volume the deployment fact that matters is the partition the mapping's tally records: the evidenced invariants cluster in the registry and checkpoint machinery, the shipped kit constructions, the release tree, the reference implementation suites, and the lived engine record, while the unbuilt set clusters in the doctrine machinery designed on October 19, 2026 and never built, in the deployed backend hardening set, and in the human layer, where every defense is an instruction or a design awaiting a founder word and a build.

## Quality requirements and the tally

The mapping's tally is the quality statement of this volume, and it is reproduced without rounding. Ninety-eight invariants stand mapped. Twenty-eight stand evidenced at the scope their entries state. Eight stand at suite only. Sixty-two stand at neither, with no suite and no evidence, and those sixty-two are the programme's real work list in mapped form. The mapping also records its own trace test, in which an outside reader must reach the evidence from an entry alone: the strong sample, INV-20, passes in full; the partial sample, INV-10, passes as a partial; the empty sample, INV-52, passes as an empty entry because its absence is findable and owned. This volume inherits that test as its standard for every row of its table.

## Risks and technical debt

The closing register of the mapping names four classes of material read and deliberately not entered, and this volume carries the register so the omissions are decisions on the record. The out-of-scope classes of the founding specification, among them stolen credentials, a compromised server in the general case, and prompt injection at the model layer, carry no invariant because no source states an enforceable one inside the boundary. The forty public claims graded by the sweep's eighth family are claims, not invariants, and were not entered. The deterrence arithmetic is a computation, verified by redoing it, and not an invariant. Two sweep classes state no invariant in any source: presence location assurance, answered by a claims closure rather than an invariant, and cascading failure as a distinct class, against which only the entered bounds at INV-10 and INV-11 stand.

## What this document does not establish

This document does not establish consequential reachability at network scale. The evidenced claims stand at reference implementation scope, at shipped kit scope, at the scopes the registry and checkpoint machinery have earned, and in the lived engine record of one institution's operations. No claim in the table reaches past its stated scope, and the volume grade of E1 is a statement about the volume's evidence, not a promotion of its weakest rows.

It does not establish the sixty-two invariants graded E0. They are specified, mapped, and owned by named programme items, and they are unbuilt. A reader who treats this volume as assurance over those invariants has misread it in exactly the way its closing section exists to prevent.

It does not establish the doctrine machinery of October 19, 2026 as machinery. Where the table grades a doctrine invariant at E0, the design text exists and the construction does not, and the designed-versus-live discipline of the charter applies to every sentence of this volume that touches it.

It does not publish the conformance matrix against the OWASP Agentic Top 10 and MITRE ATLAS. That matrix is proposed in the founding specification, is not entered as invariants in the mapping because crosswalks state no invariant of their own, and belongs to [ARC-VER-001], which waits on it.

It confers nothing. This specification describes the object settlement computes; the computing itself is a governed act performed by the machinery, never by the document.

Drafted October 21, 2026, by Noetica, Keeper of the Record, under WO-56. Sources of record: the consequence security invariant mapping of October 20, 2026, at goals/valis-consequence-security-specification/files; the founding specification valis-app/docs/CONSEQUENCE-SECURITY-SPEC-v0.1.md as carried in the mapping; the sealed SPECIFICATION.md and FORMAL_SEMANTICS.md of the founding release; the vocabulary of record [ARC-STD-1].