Deterministic Verification — A Canonical Property

This page is an explainer for deterministic-by-spec terminal-state behavior. It is not operational verification output.

Boundary contract: We bind all causal variables influencing terminal state into declared inputs and enforce that closure at build and runtime boundaries through dependency isolation, canonicalization of representations, and reproducible execution.

Authoritative provenance is a trust-weighting attribute, not an availability guarantee. When required authoritative inputs are unavailable, Sovrient records INPUT_UNAVAILABLE, preserves acquisition evidence, and prevents release of artifacts whose required inputs are not verifiably bound.

VERSION: RC2 EXPLAINER · LAST UPDATED: 2026-02-27 UTC · PATH: /docs/deterministic-verification

Operational artifacts—sealed catalogs, integrity sidecars, and timing ladders—are published at their public operational endpoints and are not hosted on this explainer page.

Implementation confluence closeout (2026-03-01): PASS · /data/implementation_confluence_closeout_latest.json

Given identical packet bytes, spec bytes, and verifier mode, all conformant verifiers must produce the same terminal state—PASS, HOLD, or FAIL—with identical mandatory-check outcomes.

terminal_state = F(packet_bytes, spec_bytes, verifier_mode)

This verifies integrity and internal consistency; it does not itself constitute settlement, regulatory, or legal adjudication authority.

terminal_state is admissible
iff
    terminal_state == F(packet_bytes, spec_bytes, verifier_mode)
    and F is total over syntactically valid inputs and deterministic
    and no undeclared dependency is reachable

Totality domain: syntactically valid packet_bytes × spec_bytes × verifier_mode. Malformed input → deterministic FAIL, not undefined.

Determinism scope: deterministic ordering, deterministic encoding, and deterministic numeric semantics as specified in spec_bytes.

Three conjuncts, each necessary, jointly sufficient. If any one fails, the terminal state is inadmissible.

If any conjunct fails, terminal_state MUST be FAIL or INPUT_UNAVAILABLE; it MUST NOT be PASS.

THREE-STATE SEMANTICS

PASS — Consensus threshold met; all conjuncts satisfied. Terminal.

HOLD — Consensus threshold not yet met; inputs are valid but corroboration is incomplete. Terminal for the current evaluated evidence set and always non-release. HOLD is a deterministic evaluation result over the declared evidence set and consensus window as encoded in spec_bytes; it does not imply temporal polling or implicit future state. Re-evaluation requires new packet_bytes or a new verifier_mode explicitly encoding a different consensus window.

FAIL — A conjunct is provably violated. Terminal.

Settlement trigger: PASS only. Transition from HOLD → PASS or FAIL is governed by the settlement specification and the applicable consensus window.

This explainer addresses the deterministic property of conformant verifiers. Settlement trigger semantics are specified in the settlement contract and are outside this document’s scope.

The Confluence Property

“All paths from the same origin converge to the same terminus.”

III

The Verification Pipeline

“Each stage reads, transforms, and passes forward. The terminal state is their composition.”

▼

PKT

HDR

SPC

CHK

VRF

HSH

CMP

RES

HALT

◀ INGEST · VALIDATE · VERIFY · COMMIT ▶

Verifier Convergence

“Three implementations, one terminal state.”

Illustrative simulation of the confluence property—that independent implementations converge to the same terminal state given identical inputs. The simulation resolves to PASS for visual clarity; a live event may terminate at HOLD or FAIL depending on consensus status and conjunct outcomes. This is not operational verification output.

Lineage of the Idea

“What the pioneers imagined, we now execute at scale.”

1936 — The Foundation

Computable Numbers

A function, once defined, produces one and only one output for any given input. The machine does not waver. The tape does not lie. If two machines compute the same function, they halt in the same state.

A. M. TURING — On Computable Numbers

2026 — The Realization

Canonical Verification

Given identical packet bytes, spec bytes, and verifier mode, conformant verifiers must produce the same terminal state. The bytes do not waver. The spec does not lie. If two verifiers are conformant, they halt with the same verdict.

VIA PLATFORM — Deterministic Attestation

1936 — The Calculus

Lambda Abstraction

A function is a rule of correspondence. Two expressions are equivalent if, for all arguments, they reduce to the same normal form. There is no room for interpretation; there is only reduction.

A. CHURCH — Lambda Calculus

2026 — The Application

Functionally Closed Verification

F(packet_bytes, spec_bytes, verifier_mode) is functionally closed over its declared inputs—no side effects, no hidden state, no oracle consultation. The same bytes yield the same terminal state. This is not a design choice; it is a mathematical necessity.

VIA PLATFORM — Functional Integrity

Mandatory Check Outcomes (illustrative subset)

“Each check is a gate; the terminal state is their conjunction.”

Check	Fα	Fβ	Fγ	Confluence
SHA-256 Integrity	PASS	PASS	PASS	✓ EQUAL
Spec Conformance	PASS	PASS	PASS	✓ EQUAL
Manifest Chain	PASS	PASS	PASS	✓ EQUAL
Field Schema Valid	PASS	PASS	PASS	✓ EQUAL
Network Consensus	HOLD	HOLD	HOLD	✓ EQUAL
Terminal State = AND(check₁, check₂, …, checkₙ) — HOLD if any check pending, FAIL if any check violated — illustrative subset shown
Terminal State	HOLD	HOLD	HOLD	■ CONFLUENT (terminal for current evidence set; non-release)

“The terminal state is not a matter of opinion. It is a matter of computation.”
A property first imagined on paper tape, now enforced in cryptographic attestation.