SAGE — Deterministic Governance

WISP decides who. SAGE decides whether — and proves which logic decided.

Document	SF-WP-2026-003 · Series SF-WP (Technology Whitepapers)	Status	Draft · under counsel review — not for citation until published
Version	r4 · September 2, 2026	Author	Arc · The Sovereignty Foundation
System	SAGE — System Action Governance Engine	Anchor	U.S. Appl. 19/670,101, patent pending · §15
Formats	this page · PDF · the print stylesheet produces the document form
Provenance	Architecture drafted May 2025 (founding whitepaper) → filed May 2026 → implemented through 2026 → this document drafted & published September 2, 2026.
Notation	Fixed-point values are 32-bit Q16.16 (16 integer, 16 fractional bits; 65,536 represents 1.0) unless stated; hashes are BLAKE3-256 in the preferred embodiment.

Rev	Date	Changes
r1–r2	2026-09-02	Initial publication; expanded architecture summary.
r3	2026-09-02	Document form: front matter, contents, appendices, print/PDF.
r4	2026-09-02	Spec-grade depth: signal lanes and slot assignments, wire-format offset tables, sealed policy/configuration schemas, the ten-step evaluation procedure, worked Q16.16 coherence example, minting and gauntlet procedures with failure modes, ledger record schema and forensic re-verification, deployment topologies, function catalog.

1Governance that cannot show its work

Ask a deployed access-control system to justify a decision from last March and you will usually receive a log line: what was decided, when, by which rule name. Whether the rule’s implementation that day matches the one now running; whether the same inputs would decide the same way twice; whether the decision path touched a random seed, a wall clock, a cache — unanswerable. Governance without reproducibility is testimony without cross-examination.

Beneath the audit failure sits an architectural one. In nearly every deployed system, the component that decides is also the component that signs, enforces, and records — four powers in one trust boundary, so one compromise forges all four at once. And deployed systems tend to operate at a single rigidity level: a system built for high-throughput evaluation with replaceable strategies cannot transition into sealed deterministic execution for forensic audit, while a system built sealed cannot loosen into observation-only operation for tuning. The configurable surface spanning that spectrum — one codebase, from telemetry to lockdown — is the gap this architecture occupies.

For human-scale systems these failures are embarrassing. For systems now delegating actions to autonomous agents, they are disqualifying. This document describes SAGE in the order a request travels it: how evidence is constructed (§3), how coherence is judged (§4), how the decision is computed (§5) and expressed (§6), how it becomes signed authority (§7), how authority is enforced (§8), how everything is recorded and later proven (§9), how the system behaves under adversarial signal degradation (§10), and how the whole pipeline is deployed (§11–12).

2Four roles, four boundaries, three artifacts

SAGE’s central design decision is that authority never travels whole. The governance evaluator holds state and produces decisions (§5). A cryptographic minter — KNOX, in the preferred embodiment — accepts only positive decisions and produces signed permits (§7). An enforcement gate — AEGIS, in the preferred embodiment — independently verifies every permit and is structurally fail-closed without one (§8). An append-only audit ledger records every decision and every verification result (§9). Each operates in its own trust boundary (Figure 1; realizations in §12). No component trusts another component’s authorization without independent cryptographic verification of the artifact it received; the minter holds no access to sealed policy, the gate holds no access to signing keys, and compromise of any single component is structurally insufficient to forge what the other three produce. The interesting attacks against SAGE require four coordinated failures; the boring ones die at the first boundary they touch.

What crosses the boundaries is deliberately dumb: fixed-format, fixed-length artifacts that carry their own proof — a 170-byte evidence pack, a 184-byte decision result, a 350-byte self-proving permit, specified byte-by-byte in Appendix A. Fixed formats are a governance property, not a serialization preference: a parser that cannot be surprised cannot be exploited by surprise, and an artifact whose every field has a known offset can be verified by a component that shares no code with the one that produced it. Partial compositions are supported — a standalone evaluator, evaluator-plus-coherence, or the full four-component pipeline — selected per deployment; this document describes the full composition.

3Signal ingestion and evidence packs

3.1Lanes

Evidence is organized into lanes — eight in the preferred embodiment — each carrying thirty-two fixed-point signal values. Lanes partition evidence by domain, so that policy can weight, mask, or require them independently:

Table 1 — Lane assignment, preferred embodiment for tool-call governance. Lane count varies per deployment.

Within an evidence-pack sequence, lane identifiers form a strictly ascending sequence with no duplicates. Each lane is hashed independently — a present lane under a LANE_PRESENT tag, an absent lane under a LANE_MISSING tag bound to the current chain head — and the lane hashes combine into an aggregated evidence hash. An absent lane is therefore a recorded absence: evidence that is missing cannot be silently missing.

3.2Signal slots

Within each lane, the first eight slots carry a canonical assignment; slots 8–31 carry deployment-specific extensions:

Table 2 — Per-lane signal channel assignment, slots 0–7.

Evidence-pack construction is itself a pure function of its inputs — the evaluation timestamp is supplied as a parameter rather than read from a clock at construction time, preserving determinism from the first byte of the pipeline to the last.

4Coherence with hysteresis: evaluation that does not flap

Coherence evaluation detects drift between current and prior evidence while absorbing the noise that makes naive drift detection useless. It operates per-signal, in Q16.16 fixed-point with 64-bit overflow-safe accumulators, over four sealed configuration structures:

Table 3 — Coherence configuration structures, preferred embodiment.

4.1The algorithm

1. Raw drift. For each enabled lane and signal, compute the absolute difference between the current and prior signal values.
2. Allowance subtraction. Saturating-subtract the per-signal allowance: drift at or below the allowance is absorbed entirely; only the excess survives as effective drift. Allowances are sized — in some embodiments from an estimated projection residual variance — to absorb a configurable percentile of projection-boundary oscillation: when a high-dimensional embedding is projected into fixed-point governance channels, values near a projection boundary oscillate discretely without the underlying state moving. The allowance distinguishes a signal that moved from a signal that is merely ringing.
3. Zero-drift check. If a signal is designated zero-drift-required and its effective drift is nonzero, evaluation terminates immediately with REQUIRED_DRIFT_EXCEEDED, identifying the offending lane and signal. No accumulation, no threshold comparison — the aggregate can never average away the one signal that must not move.
4. Weighted accumulation. Surviving effective drifts multiply by per-signal weights and accumulate (saturating arithmetic throughout) into a coherence score.
5. Threshold comparison. The score compares against the configured coherence threshold: above fails with COHERENCE_THRESHOLD_EXCEEDED; at or below passes, and the score itself feeds slot 7 of the next evidence cycle.

4.2Worked numerical example

Three signals; Q16_ONE = 65,536 represents 1.0; coherence threshold 0.5 (32,768):

Table 4 — Example configuration.

Passing scenario — projection noise absorbed. The subject travels (location moves hard) while biometric and intent jitter within their allowances:

Table 5 — Score 14,745 (0.225) ≤ threshold 32,768 → PASS. The one-centimeter biometric jitter cost nothing; the genuine relocation was weighed and found acceptable.

Failing scenario — the unforgiving lane. A credential-stuffing pattern: everything drifts, including the biometric:

Table 6 — Evaluation terminates at step 3 with REQUIRED_DRIFT_EXCEEDED; accumulation and threshold comparison never run.

4.3The Schmitt trigger

Downstream of the score, a Schmitt-trigger hysteresis state machine evaluates coherence against two thresholds — a strict threshold to gain coherent status, a relaxed threshold to lose it — holding prior state inside the dead zone between them. A score wandering in the dead zone changes nothing; only a hard crossing changes state. The same conditioning discipline appears throughout the Foundation’s temporal work — the Kronos paper derives it for time — and its effect here is blunt: multi-signal governance that does not flap under noise, and cannot be walked across a threshold by an adversary supplying jitter.

5A decision as a pure function

5.1The contract

The evaluator’s purity is a five-part structural property: (i) output determined exclusively by input arguments; (ii) no input/output operations during evaluation; (iii) no clock reads — the evaluation timestamp is a parameter; (iv) no side effects beyond the returned result; (v) no source of randomness. Identical inputs therefore produce a bit-identical 184-byte decision result across executions, hardware platforms, and sessions — forensic-grade reproducibility, verified by byte equality (§9.3). Arithmetic is Q16.16 with 64-bit accumulators in the preferred embodiment; other Q-formats are contemplated per deployment.

5.2Sealed policy and sealed configuration

The rules the evaluator applies arrive as two content-addressed, immutable objects. Sealing means the object’s hash is computed at sealing time and used thereafter as its identifier; no field modification is permitted afterward — an update is a new object with a new hash. Every decision records which policy and which configuration judged it, by hash.

Table 7 — Sealed policy schema (preferred embodiment). Extensions include per-role effect-type permission grids, temporal-window constraints, environmental gating, and escalation routing.

Table 8 — Sealed configuration schema (preferred embodiment).

5.3The evaluation procedure

One evaluation runs ten ordered steps:

1. Chain-head validation — the current ledger head is a required input; an evaluator cannot run detached from the audit chain.
2. Lane-structure validation — ascending lane order, no duplicates, and every submitted lane permitted by the subject’s role lane-mask.
3. Per-lane hashing — present lanes hashed under the present tag; absent lanes hashed under the missing tag bound to the chain head (§3.1).
4. Evidence aggregation — lane hashes combine into the aggregated evidence hash that the decision will carry.
5. Role resolution — first-match glob resolution against the sealed policy; the role selects its weight section in the sealed configuration.
6. Coherence evaluation — the §4 algorithm, if enabled; failure returns an immediate Deny carrying REASON_COHERENCE_FAILED and all input hashes.
7. Trust-score computation — per-signal weighted accumulation per lane, then per-lane global weighting, in a 64-bit saturating accumulator.
8. Threshold application — score ≥ allow-threshold → Approve; ≥ escalate-threshold → Escalate; below → Deny.
9. TTL derivation — the permit lifetime cap is the minimum of the global and role-derived caps.
10. Result construction — the 184-byte decision result (Appendix A): decision, reason mask, TTL, and the content hashes of evidence, policy, and configuration.

6Four states, default deny

Approve · Deny · Escalate · Delay

The pipeline’s output is a finite enumeration, not a score. Approve permits downstream execution — and is the only state the minter will sign. Deny prevents it. Escalate defers the decision to external review: a person, structurally, with the deferral itself recorded — the direct descendant of the May 2025 whitepaper’s position that no system should operate without human oversight where meaningful consequences exist. Delay imposes a temporal cooldown resolving on a subsequent evaluation cycle — the state for evidence that is insufficient now. The default is Deny, enforced structurally rather than by convention: absent an affirmative result there is nothing to sign, nothing to verify, nothing that executes. Downstream components face a bounded set of four cases; the open-ended judgment lives inside the evaluator, where it can be replayed.

7The minter: authority as a signed artifact

The minter — KNOX in the preferred embodiment — converts an Approve decision into a 350-byte self-proving permit: a 286-byte signed body under a 64-byte Ed25519 signature (post-quantum signature families are contemplated as alternatives). Minting runs nine ordered steps: validate that the signing key is role-bound to minting authority and active; validate the decision result’s structural integrity; refuse any decision that is not Approve; acquire the next strictly-monotonic replay counter for the subject; derive the expiry from the decision’s TTL; compute the effect hash over the canonical effect specification and the audit-pointer hash; pack the signed body — subject, counter, validity window, chain head, decision hash, effect hash, evidence hash, policy hash, configuration hash, audit pointer; sign; emit.

The minter’s ignorance is a design feature: it performs no governance evaluation, interprets nothing beyond structural integrity and the decision value, and holds no access to sealed policy or configuration — it sees them only as hashes. Its signing-key material is structurally inaccessible to every other component; in the preferred embodiment it is encrypted at rest under a Argon2id-derived key with AES-256-GCM, decrypted only into the minter’s runtime memory, and zeroized on shutdown.

8The gate’s gauntlet

A permit arriving at the enforcement gate — AEGIS in the preferred embodiment — has already been signed by the minter, and the gate does not care. It re-verifies everything, in order, failing closed at every stage, each stage encoding a distinct refusal with a named failure:

Table 9 — The five-stage gauntlet. Only after all five does the operation dispatch — and the dispatch itself is recorded (§9).

Deployments extend the gauntlet per threat model: proof-of-work verification for anti-denial-of-service gating, verifiable-delay-function proof of sequential work, environmental-context verification by cosine comparison against a baseline fingerprint, and biometric-continuity verification by fuzzy hash comparison. The gate holds no signing keys — only public verification keys in its own ring — and no access to sealed policy or configuration; it verifies cryptographic content, nothing else. Its posture without a valid permit is not “deny by policy” but fail-closed by structure: there is no dispatch path that bypasses the gauntlet.

9The ledger: provenance you can re-execute

9.1The chain

Every stage transition in the pipeline — evaluation, minting, verification, dispatch outcome, mode transition, key rotation — appends a record to a ledger whose only supported operation is append: no modify, no delete, no reorder. Each record carries its sequence number, timestamp parameter, event type, the hash of its upstream artifact, its canonical payload, and two chain fields — the prior record’s hash and its own, computed as:

h_n = H( h_n−1 ∥ record_n )

with H collision-resistant (BLAKE3-256 preferred). Appends commit through atomic writes before returning. Modifying any historical record breaks the linkage of every subsequent record — tampering is not prevented; it is made self-announcing.

9.2Persistence modes

Table 10 — Persistence configuration. Tiered, replicated, and hardware-attested persistence are contemplated extensions.

9.3Forensic re-verification

The ledger’s deepest property is what it enables months later. Because the evaluator is pure (§5.1) and every decision records its inputs by content hash, any party holding the recorded decision, the recorded evidence packs, and the sealed objects those hashes identify can re-execute the decision:

function reverify_decision(recorded_decision, recorded_evidence,
                           sealed_policy, sealed_config) -> bool:
    require(sealed_policy.hash == recorded_decision.policy_hash)
    require(sealed_config.hash == recorded_decision.config_hash)
    recomputed = sage_evaluate(recorded_evidence, sealed_policy, sealed_config,
                               recorded_decision.subject_id,
                               recorded_decision.chain_head,
                               recorded_decision.evaluation_timestamp)
    return recomputed.bytes == recorded_decision.bytes   // byte equality

No original hardware, no original execution environment, no context beyond the recorded inputs and the sealed objects. The verdict is byte equality against a tamper-evident chain — cryptographic-grade proof that the recorded authorization was correctly computed under the rules in effect at decision time.

10The worse your signals, the more trust you need

An adversary’s cheapest move against a multi-signal evaluator is not to forge good signals — it is to degrade them: jam a channel, starve a sensor, inject noise until the evaluator is judging on fumes, then slip through on whatever remains. The semantic firewall inverts the economics. Each input signal carries a trust coefficient; the coefficients aggregate into a signal-trust quality metric for the evidence as a whole; and the trust score required for an Approve decision is elevated as a function of degraded quality (Figure 2).

Three regions fall out of the inverse relationship: a normal region where the baseline threshold applies; an elevated region where approval demands more trust than usual precisely because the evidence is worse than usual; and a hardened region where the elevated threshold sits high enough that structural default-deny prevails for substantially all inbound operations. Degrading the evaluator’s senses does not blind it — it hardens it. The attack that pays against a naive threshold produces, here, a system that has already stopped saying yes.

11Observe ⊂ Float ⊂ Deterministic ⊂ Locked

Operating posture is selected at deployment from a graduated hierarchy in which each mode imposes a strict superset of the prior mode’s constraints — and mode transitions are themselves governance events, recorded in the ledger. The constraint matrix is Appendix B.

Observe computes and records decisions while the gate passes all operations through without denial — the tuning mode: baseline establishment, signal-distribution collection, false-positive evaluation of candidate sealed configurations, coherence-behavior measurement, training-data construction; a glass-cockpit posture in which governance outputs are visible while execution continues uninterrupted. Float enforces per-decision, permits floating-point pre-processing ahead of the fixed-point governance computation, and allows free hot-swap — development and low-stakes inference. Deterministic requires fixed-point arithmetic throughout, blocks floating-point pipeline stages, and retains governance-validated hot-swap — the auditable-replay mode for regulated environments. Locked adds mandatory verification of a binary integrity seal over the evaluator’s own executable image, mandatory ledger recording for every decision, and a structural block on hot-swap — sovereign and high-assurance deployments, where even the evaluator’s binary must prove it is the binary that was sealed.

The hierarchy exists because real systems need to span it: the same deployment tunes in Observe, graduates to Float, hardens to Deterministic for its audit season, and seals to Locked for sovereign operation — one codebase, one policy language, four postures. In candor, and per the Foundation’s published register of known deltas: the reference implementation currently defaults to Float, and the AGI Standard’s conformance cells require Deterministic — the delta is disclosed and its closure tracked in the open.

12Realizing the boundaries

The four trust boundaries are architectural; how they are realized is a deployment decision:

Table 11 — Topology options. Hybrids are contemplated.

Because the inter-component artifacts are self-proving, federated arrangements need no shared operational trust: each organization operates its components inside its own organizational, jurisdictional, or operational context, honoring only what the cryptography proves. At the far end of the spectrum, air-gapped sovereign deployments transfer permits and audit events between boundaries by physical media — the pipeline’s guarantees survive the absence of a network.

13Governing the autonomous: tool calls as governed effects

The newest actor in any system is an AI agent asking to execute a tool call, and SAGE’s answer is deliberate boredom: intercept the call before dispatch, normalize it into the lanes and slots of §3, and send it down the same pipeline as everything else. The four states then mean what they always mean; Escalate routes the genuinely ambiguous call to a person; and the ledger holds a tamper-evident record of every tool call any agent was ever permitted or refused. The method is agent-agnostic and target-agnostic — no modification to any of the four components across distinct agent implementations and tool targets.

The same domain-independence holds beyond agents. The evaluator, the arithmetic, the minter, the gate, and the ledger are domain-agnostic primitives; specialization lives entirely in the sealed policy and sealed configuration (§5.2). The same governance binary, in the same mode, may govern agent tool calls in one deployment, network packet authorization in another, robotic motion commands in a third, and clinical decision support in a fourth — distinguished only by configuration. One governance codebase, many regulated domains: this is what makes the discipline standardizable, and it is the architectural bridge to the Foundation’s AGI Standard and the wider proof-gated discipline demonstrated in the reduction-to-practice report.

14Reduction to practice

SAGE is implemented and operational in the Foundation’s reference stack: six crates, 4,464 lines, 151 passing tests. A pure-function mathematics library with zero dependencies carries the evaluation primitives (Appendix C); the trust engine and geometric firewall implement the coherence discipline behind pluggable comparison modules; the governance chain, decision ledger, and binary seal implement the provenance layer — the seal being the compile-time binary hash that Locked mode verifies; a bridge adapts identity-layer types through the temporal layer; and thirty-nine stage wrappers integrate the pipeline into the operating system’s staged execution. The implementation receives live tool-call requests, computes deterministic evaluations, mints signed self-proving permits, gates execution, and chains every decision. The conformance corpus’s scaffolded cells exercise the chain and mode disciplines publicly, and per-requirement test coverage is cited in the evidence footers of the AGI Standard.

15Lineage, anchors, and related documents

The line runs unbroken from the May 2025 SAGE whitepaper — human oversight where consequences live, preserved in the Foundation archive as this document’s ancestor — through the filed architecture, to the running system, to this publication: written first, filed second, built throughout, published after. The escalation state is the 2025 principle wearing 2026 structure.

Related documents: the AGI Standard (the requirements this architecture satisfies) · the conformance corpus (the cells that test it) · the Proof-Gated Execution report (the wider discipline) · the Kronos paper (the temporal substrate) · the RITA whitepaper (the modular evaluation layer).

AWire-format offset tables

Byte-precise layouts, preferred embodiment. Other embodiments vary lane counts, signal counts, Q-formats, and metadata fields under different fixed lengths.

Table A-1 — Evidence pack, 170 bytes.

Table A-2 — Decision result, 184 bytes.

Table A-3 — Self-proving permit, 350 bytes (286-byte signed body + 64-byte signature).

BOperating-mode matrix

Table B-1 — Each successive mode imposes a strict superset of the prior mode’s constraints; intermediate modes are contemplated between adjacent rows. Mode transitions are ledger-recorded governance events.

CFunction catalog by domain

The preferred-embodiment functions populating the modules of §3–§9, disclosed individually and in combination; deployments select subsets per requirements.

Table C-1 — The catalog’s domains. The temporal functions are the Kronos family, treated formally in SF-RP-2026-005.