A specification document package, distributed free of charge. It defines the normative boundary and decision logic for controlled rehydration of persistent context, permitting restoration only after complete verification.
Restoring saved state without verifying it first is indistinguishable from restoring a compromise.
This package is a self-contained, normative, execution-neutral single agent specification, delivered as-is, sufficient for an engineering team to build the agent without further design decisions about agent logic, evidence shape, validator behavior, or failure semantics.
This package is not software, SaaS, a managed service, consulting, support, managed operations, or implementation delivery. It does not approve source semantic content, activate tool-state without a separate gate, relax policy, or perform persistent writes during startup verification. It is not a live runtime — nothing in the package executes; everything in the package describes how a conforming executable agent must behave.
7 structural properties, defined in spec §2 Agent Overview / Core invariants and elaborated through the failure semantics, workflow, gate logic, and evidence contract sections:
No restoration is permitted before the full verification sequence completes successfully.
Any failure in framing, checksum, canonical parse, hash-chain continuity, signature validation, freshness, policy validation, or IRR validity triggers fail-safe handling and suppresses persistent-context injection.
Restored persistent state may originate only from the verified and eligible head.
Tool-state remains untrusted and inactive unless a separate activation gate and required approval both succeed.
Startup remains read-only until the restoration decision is reached.
Recovery is idempotent and must not produce duplicate effects or duplicate acceptance.
Replay must begin from a deterministic baseline defined by the verified snapshot and applicable local policy.
These are properties of the specification. They are not warranties about a delivered running system.
| Verified_Rehydration_Agent_Specification.md | Normative specification. The authoritative document. |
| Verified_Rehydration_Agent_Semantic_Index.md | Semantic Index — Human Edition (D1). Canonical glossary of all 96 normative terms. |
| Verified_Rehydration_Agent_Semantic_Index.yaml / Verified_Rehydration_Agent_Semantic_Index.json | Semantic Index — Structured Edition (D2). The same glossary as data, 1:1 with D1. For tooling. |
| Verified_Rehydration_Agent_Coverage_Matrix.md | Semantic Coverage Matrix (D3). Links term categories to the specification's sections. |
| Verified_Rehydration_Agent_Ambiguity_Register.md | Ambiguity Register (D4). 11 lexical-overload resolutions. Read before normalization questions arise. |
| Verified_Rehydration_Agent_Conformance_Tests.md | Conformance tests you run against your implementation, with fixtures, oracles, and minimal run note. |
| Verified_Rehydration_Agent_Whitepaper.html | Public-facing positioning. Non-normative. |
| NNT_Companion/ | Non-Normative Tests — demonstration-only evidence that the specification is derivable. Not a reference implementation, and not part of the specification. Do not read it before implementing: read it only after your implementation passes the Conformance Tests. |
| Verified_Rehydration_Agent_README.md | Orientation and reading order. |
| Verified_Rehydration_Agent_License.md | The license. |
| Verified_Rehydration_Agent_Manifest.sha256 | SHA-256 integrity manifest. |
| verify.md | Self-audit runbook you run against the package you hold. |
Per spec §19 Reuse Note and §16 Conformance Requirements and Deployment Obligations, 5 deployment artifacts are built by your engineering team from this specification:
A stable snapshot lock or deterministic equivalent, with observable snapshot binding evidence.
A non-regressing counter or equivalent anchor sufficient to prove rollback blocking.
A local, versioned policy bundle binding policy_id, V_POLICY, and V_COMPAT compatibility checks.
Serialized persistent-state mutation paths with emitted writer-lock and contention evidence.
An approver_set, recovery workflow, readmission-token evidence, and release procedure for controlled fail-safe exit.
The specification is complete enough that none of these requires interpretation of ambiguous prose. Spec §16 sets the implementation acceptance criteria your implementation must meet through the conformance requirements and deployment obligations.
This pack declares its own numbers — how many artefacts it ships, how many canonical terms it indexes, how many conformance records it carries, what those records return. This runbook has you reproduce those declared values on your own machine, before you build anything against the specification.
Each check has the same shape: find the value the pack declares, observe the value your machine produces, record whether they match. A mismatch is a fact you report, not a judgment you make: either the bytes you received are not the bytes that were published, or your environment differs. Both are worth knowing before you build. Neither requires you to decide what it means.
Integrity check, run inside the unzipped package folder.
sha256sum -c Verified_Rehydration_Agent_Manifest.sha256
shasum -a 256 -c Verified_Rehydration_Agent_Manifest.sha256
Get-Content Verified_Rehydration_Agent_Manifest.sha256 | ? { $_ -notmatch '^\s*#' -and $_.Trim() } | % { $h,$f = $_ -split '\s+',2; if ((Get-FileHash $f.Trim() -Algorithm SHA256).Hash -ieq $h) { "OK $f" } else { "FAIL $f" } }Recompute the Manifest's own hash and compare it to the manifest_ref bound in the License.
The Conformance Tests document contains 29 test records anchored 1:1 to the specification: 26 directly runnable on the agent's projection surface, 1 parameterized against operator-declared inputs, and 2 declarative checks verified at integration level. Each record cites the specification authority that grounds it, the input fixture that drives it, and the oracle that defines pass and fail. The Minimal Run Note declares the projection surface, input types, assertion result types, and the conformance condition for the suite as a whole.
Run the suite against your implementation. A fully conformant implementation passes the 26 runnable tests, satisfies the 1 parameterized test under your declared parameter envelopes, and attests the 2 declarative checks at your release-acceptance gate.
Your implementation's conformance is established by the Conformance Tests, not by verify.md.
Five paradigm-isolated reconstruction contexts of the same model independently built the Verified Rehydration Agent from the specification pack alone — in Python, Rust, Prolog, C, and Bash — and ran the agent's 29 Conformance Tests records against each reconstruction, under live toolchains with hash-attested binary provenance.
All 29 of 29 conformance records converged across all five paradigms, with zero divergent records. The convergence comprises 27 convergent PASS (records PT-001 through PT-027) and 2 convergent SKIP (records PT-028 and PT-029). The two SKIPs are the declarative bounded-external checks — policy-compatibility (V_COMPAT) and single-writer enforcement (V_WRITER_LOCK) — which are not locally runnable and require deployment-architecture evidence at release acceptance, beyond the local workflow transition surface; their convergent SKIP status is itself an agreement across the five contexts that the same two records are the same two non-local checks. Per paradigm, each of the five reconstructions' own run reported the identical profile: 27 pass, 0 fail, 2 skip, 0 error.
Within NNT, the five contexts were isolated from one another but shared their reconstruction model, prompt authorship, and training data, as the companion discloses.
This is evidence of derivability and self-sufficiency of the specification, not a certification, not a quality score, and not a set of implementations to follow.
The baselines/ are study artifacts produced under restricted conditions; they are not reference implementations and must not be used as implementation patterns.
Every figure here is bounded to this single NNT run on agent pack AGT-VRA-001. The NNT companion is not part of the specification. Do not read it before implementing: read it only after your implementation passes the Conformance Tests.
This supplement records five additional target paradigms for the Verified Rehydration Agent (AGT-VRA-001): Common Lisp, Brainfuck, spreadsheet formulas, an Analytical Engine-style program, and AWK. It is separate from the VRA package and its Non-Normative Tests (NNT) companion. The VRA package Manifest does not list the files in this supplement; the supplement has its own Manifest that names and hashes the VRA package Manifest as its parent artifact. The renderings use the same published Specification and Conformance Tests; their captured outputs are evidence for this artifact and these reported surfaces, not independent-party verification.
Specification §12, using the conformance suite's Boolean guard projection. The sweep covers nine states, nine triggers, and two guard outcomes: 162 input triples. Fifty produce explicitly specified transition results under the projection rules; 112 unmapped triples produce the fail-closed token E. This is a component-level sweep, not a full-agent or deployment evaluation.
The AWK runner and spreadsheet workbook report 27 PASS, 0 FAIL, 2 SKIP, and 0 ERROR across the 29 published records. PT-028 and PT-029 are declarative checks requiring deployment evidence.
The historical framing spans the Analytical Engine design described in 1843 and Rust's public announcement in 2010: 167 years between designs represented by contemporary renderings. Lisp (1958), rendered here in its Common Lisp dialect (standardized by ANSI in 1994), and Brainfuck (1993) supply additional points in that comparison. It does not imply that the Analytical Engine itself was built or executed in the nineteenth century.
All renderings are study artifacts. None is a normative source or a reference implementation for VRA. The VRA Specification and Conformance Tests define the required behaviour and acceptance criteria.
All rights reserved. You may download, inspect and run these files to reproduce the reported results. They are provided as is, without warranty, and are run at your own risk. No other right is granted.
This package is distributed free of charge. No payment is required, now or ever, for anything this license permits.
Subject to the Restriction section, you are granted, free of charge and perpetually:
You shall not:
The line. Using an implementation as internal machinery inside your own product or service is permitted, including commercially and at any scale: the third party consumes your product, and neither selects nor obtains the agent as such. Offering the capability itself is not permitted. Permitted: your application uses the agent internally to validate state, and your customers buy your application. Not permitted: you expose the agent as an API, ship it as a library, or offer it as a service, so that a third party can obtain or invoke its capability as a thing in itself.
The implementations you build are yours. SEMANTICHOR claims no ownership over the source code, builds, or deployments you produce from this specification.
The license sets out what is free; the reserved uses are not licensed for this package.
Inquiries about reserved uses: contact@semantichor.com
Where you obtained the package otherwise than at the point of distribution, you accept this license by accepting it at semantichor.com, in the same two confirmations, before any use of the package.
This is a summary. Where this summary and the license appear to differ, the license controls. Read the full license →