A specification document package, distributed free of charge. It defines an offline audit/replay/verification agent for deterministic reconstruction of ledger-backed sessions, hash-chain continuity validation, checkpoint and rollback replay, and evidence-sufficient audit reporting.
If you cannot reconstruct how a decision was made, you cannot prove it was made correctly.
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.
5 structural properties, defined in spec §19 and elaborated through the failure semantics, workflow, gate logic, and evidence contract sections:
Identity and boundary are explicit. The agent is delimited by identity, role, authority, boundary, and output contracts.
Replay is offline-auditable. The specified artifacts permit reconstruction of state and history without live access to the underlying system.
Integrity is constitutive. Verdict REPLAYABLE may not be issued without proof of frame-parse validity, signature validity where required, and hash-chain continuity.
Critical failure is observable and bounded. Every critical failure produces FAIL_CLOSED, NONCOMPLIANT_HOLD, or an explicit negative verdict. Silent failure is not permitted.
Deployment limits remain external. Deployment controls and external verification remain the responsibility of the deployment owner or external assurance component; their absence must be reported as an explicit gap, not masked.
These are properties of the specification. They are not warranties about a delivered running system.
| Audit_Replay_Agent_Specification.md | Normative specification. The authoritative document. |
| Audit_Replay_Agent_Semantic_Index.md | Semantic Index — Human Edition (D1). Canonical glossary of all 86 normative terms. |
| Audit_Replay_Agent_Semantic_Index.yaml / Audit_Replay_Agent_Semantic_Index.json | Semantic Index — Structured Edition (D2). The same glossary as data, 1:1 with D1. For tooling. |
| Audit_Replay_Agent_Coverage_Matrix.md | Semantic Coverage Matrix (D3). Links term categories to the specification's sections. |
| Audit_Replay_Agent_Ambiguity_Register.md | Ambiguity Register (D4). 14 lexical-overload resolutions. Read before normalization questions arise. |
| Audit_Replay_Agent_Conformance_Tests.md | Conformance tests you run against your implementation, with fixtures, oracles, and minimal run note. |
| Audit_Replay_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. |
| Audit_Replay_Agent_README.md | Orientation and reading order. |
| Audit_Replay_Agent_License.md | The license. |
| Audit_Replay_Agent_Manifest.sha256 | SHA-256 integrity manifest. |
| verify.md | Self-audit runbook you run against the package you hold. |
Per spec §21 Reuse and Dependency Notes, §18 Observability Requirements, and §20 Minimum Verification Scenarios, at least 7 deployment artifacts are produced by your engineering and operations teams from this public package:
A conforming executable implementation of the Audit Replay Agent.
An active policy profile with resolvable policy_profile_id / policy_hash bindings.
A compatible trust store or verification policy for signature and provenance checks.
Session-bundle ingestion and export handling for records admitted by the public specification and your declared deployment policy.
Validator implementations for V-01 through V-10, with validator outcomes linked to evidence references.
Output generation for OC-01 Audit Report, OC-02 Machine Evidence, and OC-03 Incident Notice, including report signature or export-manifest linkage.
Release-gate use of the public test suite, fixtures, oracles, and minimal run note.
The public specification does not expose a separately named "Implementation Acceptance Criteria" section. For implementation acceptance, use spec §20 and the public conformance suite ARA-T001 through ARA-T027. The acceptance surface is closed by the specification rules, the public tests, and your declared operator parameters.
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 Audit_Replay_Agent_Manifest.sha256
shasum -a 256 -c Audit_Replay_Agent_Manifest.sha256
Get-Content Audit_Replay_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 27 test records anchored to the specification: 22 directly runnable on the agent's projection surface, 1 parameterized against operator-declared inputs, and 4 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 22 runnable tests, satisfies the 1 parameterized test under your declared parameter envelope, and attests the 4 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 Audit Replay Agent from the specification pack alone — in Python, Rust, Prolog, C, and Bash — and ran the agent's 27 Conformance Tests records against each reconstruction, under live toolchains with hash-attested binary provenance.
All 27 of 27 conformance records converged across all five paradigms, with zero divergent records. The convergence comprises 26 convergent PASS and 1 convergent SKIP (record ARA-T019). ARA-T019 is the declarative check that V-10 tool-state exclusion yields QUARANTINE; the Conformance Tests declare it untestable through the local next_state surface, because enforcement sits in the gate layer. Per paradigm, each of the five reconstructions' own run reported the identical profile: 26 pass, 0 fail, 1 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 ARA-AUDIT-REPLAY-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 Audit Replay Agent (ARA-AUDIT-REPLAY-001): Common Lisp, Brainfuck, spreadsheet formulas, an Analytical Engine-style program, and AWK. It is separate from the canonical ARA package and its Non-Normative Tests (NNT) companion. The supplement Manifest names and hashes the canonical ARA package Manifest as its parent artifact. The ARA Specification, Conformance Tests, and Semantic Index define the rules and acceptance criteria.
Nine workflow states, fourteen named or derived measurement inputs, two guard values, and the bounded T023 branches: 271 rows. The output token E means the projection does not assert an output for that input; it is not an ARA state, event, verdict, or gate status. This is a bounded component projection, not a full-agent or deployment evaluation.
The AWK implementation and runner, and the workbook's formula assertions after a full recalculation in native Excel, each report 26 PASS, 0 FAIL, 1 SKIP, and 0 ERROR across the 27 records. ARA-T019 is SKIP because the Conformance Tests declare V-10 / QUARANTINE untestable through local next_state; this does not establish gate enforcement in a deployment.
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.
Projection choices are declared in SOURCE_RULES.md; the canonical ARA package remains authoritative.
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 →