What Replay Means
Governance replay is the ability to reconstruct the exact governance state of a system at any point in its history using only the cryptographic evidence chain. It is not log aggregation. It is not event sourcing with a mutable store. It is deterministic reconstruction from immutable, signed evidence that any independent party can verify.
The replay guarantee is: given the same evidence chain, every replay engine — regardless of implementation language, hardware platform, or operator — produces byte-identical output. This is what "deterministic" means in practice. It is not "roughly the same." It is identical to the bit.
This property makes governance evidence suitable for legal proceedings, regulatory investigations, insurance claims, and any other context where the question is not "what does the operator say happened?" but "what does the evidence prove happened?"
The Replay Engine
H33's replay engine operates on the evidence structures described in the other explainers: attestation chains (from continuous attestation) and Agent Execution DAGs (from agent governance). The engine performs three operations:
1. DAG Traversal
The engine walks the evidence structure from a specified starting point to a target timestamp. For linear attestation chains, this is a simple forward walk. For Agent Execution DAGs, this is a topological traversal that respects causal ordering — parent nodes are always processed before child nodes.
At each node, the engine verifies the PQ signatures (all three families), recomputes the node hash from the node's content, and checks that the recomputed hash matches the hash referenced by successor nodes. Any mismatch halts the traversal and reports the exact location of the integrity failure.
2. State Reconstruction
As the engine traverses each node, it applies the state transition described by that node to an in-memory state accumulator. The accumulator tracks all governance-relevant state: active policies, agent scope objects, signing key validity, attestation chain status, and any application-specific state captured in the evidence.
At the target timestamp, the accumulator contains the exact governance state that existed at that moment. This includes which policies were active, which agents had which scope permissions, which signing keys were valid, and what the attestation chain head was.
3. Frame Hashing
The reconstructed state is serialized in canonical form (deterministic field ordering, no representation ambiguity) and hashed with SHA3-256. This produces the replay frame hash: a fixed-size fingerprint of the entire governance state at the target timestamp.
The frame hash is the core determinism guarantee. If two independent replay runs produce the same frame hash, the reconstructed states are identical. If they produce different frame hashes, something has changed — either the evidence was modified, or the replay engine has a bug.
// Replay to timestamp T
replay_result = engine.replay(
evidence_chain: chain,
target_timestamp: T,
verify_signatures: true
);
// Result contains:
// - frame_hash: SHA3-256 of reconstructed state
// - active_policies: [policy_v3, policy_v4]
// - agent_scopes: {agent_a: scope_12, agent_b: scope_7}
// - signing_keys: {key_1: valid, key_2: expired}
// - chain_head: attestation_4829
// - integrity: VERIFIED | TAMPERED(node_id)
Tamper Detection
Tamper detection is not a separate feature. It is a structural property of the replay process. Because each node in the evidence chain includes hashes of its predecessors, and because each node is signed with three PQ signature families, any modification to any node is detected during replay.
The detection is precise. The replay engine does not just report "the chain is invalid." It reports exactly which node was modified, what the expected hash was, what the computed hash is, and which downstream nodes are invalidated by the tampering.
There are three tamper scenarios the engine handles:
- Node modification — Content of a node has been changed. The recomputed hash does not match the hash stored in successor nodes. The engine identifies the exact modified node.
- Node deletion — A node has been removed from the chain. The predecessor reference in a successor node points to a non-existent node. The engine reports the gap.
- Node insertion — A new node has been inserted into the chain. The chain hash sequence is inconsistent because the inserted node's predecessors do not reference it. The engine detects the orphan.
Tamper detection is exhaustive. Unlike log-based integrity checks that detect tampering only in monitored fields, the replay engine verifies the entire content of every node. There is no field that can be modified without detection because the hash covers the entire serialized node content.
Replay Determinism Score
The Replay Determinism Score is a meta-metric: it measures whether the replay engine itself is functioning correctly. H33 computes this score by running the same replay across multiple independent implementations and comparing frame hashes.
A score of 100.0% means every implementation produced byte-identical frame hashes for every replay target in the test corpus. Any deviation from 100.0% indicates either a bug in one of the implementations or an ambiguity in the replay specification (which would itself be a specification bug).
H33's production Replay Determinism Score is 100.0%. This has been validated across the Rust reference implementation and independent test implementations, against the full canonical conformance vector set.
Fork Replay: Exploring Counterfactuals
Fork replay extends deterministic replay with counterfactual analysis. Instead of asking "what happened?", fork replay asks "what would have happened if a different decision had been made?"
The process works by:
- Replaying to a specific decision point in the evidence chain
- Creating a branch where the decision is replaced with an alternative
- Continuing the replay forward from the branch point with the modified decision
- Comparing the forked state with the actual historical state
Fork replay is valuable for:
- Incident analysis — "If the agent's scope had been more restrictive at time T, would the harmful action have been prevented?"
- Policy evaluation — "If we had enforced policy v5 instead of v4 during the period in question, how would outcomes have differed?"
- Risk modeling — "What is the blast radius if this specific control fails?"
Fork replay does not modify the historical evidence chain. The original chain remains immutable. The fork exists only in the replay engine's state and can be discarded after analysis.
Frequently Asked Questions
What is governance replay?
Deterministic reconstruction of system governance state at any point in time using only cryptographic evidence. Any independent verifier running the same replay on the same evidence produces byte-identical output.
How fast is governance replay?
10,000-action sessions replay in 2.5 milliseconds. Full DAG traversal, signature verification at each node, state reconstruction, and frame hash computation. Speed scales linearly with session size.
What is the Replay Determinism Score?
A meta-metric measuring whether independent replay runs produce identical output. H33's score is 100.0%: every replay of the same evidence chain by any implementation on any hardware produces byte-identical state reconstruction.
How does replay detect tampering?
Each node includes hashes of predecessors. Modification changes the hash, invalidating all downstream references. The engine reports the exact tampered node, the expected hash, the computed hash, and all affected downstream nodes.
What is fork replay?
Counterfactual analysis: branch from historical evidence, apply a modified decision, reconstruct the resulting state. Used for incident analysis, policy evaluation, and risk modeling. The original evidence chain is never modified.