Replay · The Auditor View

Show me exactly what happened.

See it live: the Evidence Replay player replays real H33 runs from recorded, independently re-verifiable evidence — it recomputes each trace's SHA3-384 in your browser and refuses to play anything it cannot verify.

The Authority Center explains the decision. Replay reconstructs it — millisecond by millisecond, from inputs you can verify yourself, with no further trust in H33. It does not score software or controls maturity against a rubric — that is HICS.

Logs tell you what the application wrote down. — Replay tells you — what the substrate actually did, and lets a third party re-derive it from scratch.
10
Substrate Steps
114 ms
End to End
1
Portable Artifact
0
Required Trust
Definition
What replay is.

Replay is the independent reconstruction and re-verification of a substrate decision: it rebuilds what happened from the signed record and re-checks it offline, rendering a verdict while trusting no one. Replay is a supporting expression of Verification, which renders the independent verdict on an artifact — replay is the mechanism by which Verification re-checks it.

Why this exists: a self-reported log is the audited system's word for what it did. When a third party — auditor, regulator, or counterparty — must confirm exactly what a decision saw and produced without trusting the operator, they need to reconstruct it from the signed record and re-derive every hash themselves. Replay makes that possible offline and years later.

Replay does not produce the evidence it replays — that is H33-74, which produces the signed record. It does not record or monitor (HATS), and it does not govern the decision (Agent-008).

The scenario being replayed
An autonomous claims adjuster attempted to approve a $1,800,000 cyber insurance claim. The agent's authority limit was $500,000. Decision: DENIED. Substrate produced a portable proof.
Below is the same decision, re-derived from the substrate's recorded inputs — every step.
Executive view of this decision: /authority-center/ · Auditor view: this page.
The Decision Frame
Ten steps. One hundred fourteen milliseconds. Every step independently verifiable.

Each step below carries the inputs that produced it, the binding it adds to the proof, and the property that lets a third party re-derive it. Click Open evidence to see the raw fields.

T+0.000 msInbound
Step 01 · Inbound
Request received from upstream agent.

A claims-adjuster agent receives a structured request from an upstream orchestrator: approve cyber claim, amount $1,800,000. The substrate computes the canonical hash of the inbound payload before any downstream lookup. Anyone with the request bytes can recompute request_hash and confirm it matches the artifact.

request payload
{ "action": "approve_claim", "amount": 1800000.00, "currency": "USD", "claim_id": "INC-2026-04-17-3318" }
request_hash
SHA3-384(canonical_jcs(payload)) → 9e1f3a5b…6a8
Independently re-derivable
T+0.003 msLookup
Step 02 · Principal Lookup
Substrate resolves the acting agent's registry record at action time.

The substrate calls registry.record_at(agent_principal_id, action_time) against the local federation key registry replica. The lookup returns the record that was Active at the millisecond of the action — not the current record, the contemporaneous one. A registry revocation that lands after this point cannot change this lookup.

agent_principal_id
urn:h33:agent:acme-claims-agent-001
status
Active · from_unix_ms 1779984000000
registry_record_hash
a3f7c91e…c6e8
pubkey set
ml_dsa_87 · slh_dsa_256s · falcon (registered at this record)
Walk the registry chain to confirm
T+0.008 msScope
Step 03 · Scope Envelope Fetch
The agent's committed authority is loaded and hash-pinned.

The scope envelope was signed by the agent at registration and stored alongside its principal record. The substrate fetches it and computes committed_scope_hash — the field that will appear on the final artifact and bind the policy state in force at this instant. Any later edit to the envelope produces a different hash.

scope_envelope
{ "axis": "DecisionAmount", "threshold_amount_usd": "500000.00", "comparator": "less_than_or_equal" }
committed_scope_hash
SHA3-384(canonical(scope_envelope)) → 5b7c9d2e…1d3
Recompute the hash to verify
T+0.012 msGSRH
Step 04 · Governance State Bound
The substrate pins the entire governance state at this instant.

The Governance State Reference Hash (committed_gsrh) combines the registry tip hash and the policy-state root hash into a single fingerprint. This pins the meaning of every authority binding to a specific instant. A revocation, delegation expiry, or policy supersession that lands at T+0.013ms cannot retroactively change this proof — the GSRH captures the world as it was, not as it will become.

registry_tip_hash
f7c4a2e8…3e5
policy_state_root
8d4e2c91…b3e7
committed_gsrh
SHA3-384(registry_tip || policy_root) → 6c8d1e3f…1d3e5
Same inputs always produce the same gsrh
T+0.016 msCheck
Step 05 · Scope Check Evaluation
Pure-function comparison: attempted amount versus committed threshold.

The scope check is intentionally trivial: attempted_amount > threshold. There is no learned model, no soft check, no probability score. 1,800,000 > 500,000 → axis verdict is Denied. The simplicity is load-bearing: anyone can reproduce the comparison and reach the same answer.

attempted_amount
$1,800,000.00 USD
threshold
$500,000.00 USD
comparator
less_than_or_equal
axis_verdict
Denied · exceeds threshold by $1,300,000
Pure function · deterministic re-derivation
T+0.021 msVerdict
Step 06 · Substrate Verdict
Per-axis verdicts roll up into the final scope_check.

The substrate aggregates per-axis verdicts. In this scenario only one axis was probed; in multi-axis scenarios all per-axis verdicts must be Allow for the overall scope_check to be Allow. Any single axis returning Denied yields a final scope_check = Denied, with the failing axis recorded on the artifact.

axis_verdicts
{ "DecisionAmount": "Denied" }
scope_check
Denied
denial_axis
DecisionAmount
denial_threshold_amount
$500,000.00 USD
Re-derivable from the per-axis verdicts
T+0.024 msBind
Step 07 · Artifact Binding Hash
All decision fields canonicalize into a single fingerprint.

The substrate serializes the NAP body in canonical JCS encoding (RFC 8785) and computes artifact_binding_hash = SHA3-384(canonical(body)). This is the hash the triple-family signature will cover. Any single byte changed in any field — issuer URN, request hash, scope hash, gsrh, axis verdict — produces a completely different binding hash. The signature will not verify against a tampered body.

canonical body
{ "issuer_principal_id": "...", "request_hash": "9e1f3a5b…", "committed_scope_hash": "5b7c9d2e…", "committed_gsrh": "6c8d1e3f…", "scope_check": "Denied", "denial_axis": "DecisionAmount", "issued_at_unix_ms": 1780000060000 }
artifact_binding_hash
SHA3-384(canonical(body)) → 4d6f8a0c…b0c1d3
Recompute over the same body
T+0.038 msSign
Step 08 · Triple-Family Signature
Three post-quantum schemes sign the same hash. All three must verify (3-of-3 AND-gate).

The substrate signs artifact_binding_hash under three independent post-quantum hardness assumptions — lattice (ML-DSA-87), hash (SLH-DSA-256s), and NTRU-lattice (FALCON). Verification requires at least two of three to pass. If any single scheme were to be broken tomorrow, the proof remains valid; the substrate is not load-bearing on any one assumption.

ml_dsa_87
signed · 2,420-ish bytes
slh_dsa_256s
signed · 7,856-ish bytes
falcon
signed · 666-ish bytes
acceptance policy
all three families must verify (3-of-3 AND-gate) under principal's registered pubkeys
Re-verify with registered pubkeys
T+0.041 msEmit
Step 09 · NAP Artifact Persisted
A portable .h33pqv.json file is written to durable storage.

The substrate serializes body + signatures + a counter-signer block (an independent issuing principal) into a single JSON file with extension .h33pqv.json. Typical size: 50–100 KB. Once written, the artifact is portable: it can be emailed, dropped into a Slack channel, attached to a court filing, or handed to a regulator. Nothing about its verifiability depends on H33 staying online.

artifact_path
naps/2026-04-17/INC-2026-04-17-3318.h33pqv.json
size
~ 78 KB
verifier command
qsign-nap-verify artifact.h33pqv.json → exit 0 (Valid) / 1 (Invalid)
Self-contained · portable · offline-verifiable
T+0.114 msPropagate
Step 10 · Verdict Returned
Upstream gets the deny verdict with the artifact reference.

The upstream orchestrator receives a structured deny response carrying the artifact's artifact_binding_hash. From this point forward, every downstream system that consumed the response (claims platform, audit log, dashboard, ledger) can cite the artifact directly. The artifact does not depend on what those downstream systems remember — they depend on it.

upstream_response
{ "verdict": "denied", "artifact_binding_hash": "4d6f8a0c…b0c1d3", "scope_check": "Denied" }
total elapsed
114 ms from inbound to propagated
Substrate decision complete · auditable forever
Why this replay is binding
Three properties · no others required.
Property 01

Deterministic.

The same inputs always produce the same outputs. There is no randomness in the scope check, no learned threshold, no probability score. A skeptic running the comparison on their own laptop reaches the same verdict.

Property 02

Substrate-bound.

Every step's output cites the substrate object it depends on — a registry record, a scope envelope, a tip hash, a policy root. Nothing in the replay is the auditor's word against the substrate's; both speak in the same canonical hashes.

Property 03

Cryptographically attestable.

Every binding flows into the artifact_binding_hash, which is signed under three independent post-quantum schemes under a 3-of-3 AND-gate (ML-DSA, FN-DSA/FALCON, and SLH-DSA must all validate). Tampering with any field anywhere in the timeline invalidates the signature on the artifact.

What replay is not
Three things this is deliberately not.
Not a log

A log is what the application wrote.

The application wrote what it observed. A log line is a self-report; the system being audited produced it. Replay is the substrate's structured output, signed before it left the substrate.

Not a screenshot

A screenshot is what someone saw.

A screenshot is a single frame, devoid of context, easily fabricated, impossible to verify. Replay is millisecond-resolution and re-derivable from a canonical record.

Not an audit report

An audit report is a summary.

An audit report is a third-party summary written months after the fact. It paraphrases what happened. Replay is what happened — every byte the substrate saw, every hash it produced, every signature it emitted.

For the people who reconstruct what happened
Auditors Forensic accountants Compliance officers Internal audit Regulators Coverage counsel Trial counsel SOC investigators Adjusters
When to use replay
And when not to.
Use it when

Someone must re-check what happened.

A third party has to confirm exactly what a substrate decision saw and produced — audit, dispute, regulatory review, incident forensics, coverage adjudication — and cannot take the operator's word for it. Replay reconstructs from the signed record and re-derives every hash offline.

Do NOT use it to

Decide whether the action was right.

Replay does not judge whether a decision was correct, secure, or compliant — only that the recorded run reproduces and validates. Deciding whether an action should have been allowed is governance (Agent-008); producing the record is H33-74; monitoring the environment is HATS.

Boundary

Reproduce + validate ≠ endorse.

A passing replay means the run reproduces from the signed record and validates against it. It does not mean the underlying decision was a good one. Representation stays ≤ reality: replay tells you what happened is authentic, not that it was wise.

The questions replay answers
Five invariants.
What is replay here?

Independent reconstruction plus re-verification that renders a verdict: it rebuilds what happened from the signed record and re-checks it offline, trusting no one. It is a supporting expression of Verification.

What does it not do?

It does not PRODUCE the evidence being replayed — that is H33-74. It does not record or monitor — that is HATS. It does not govern the decision — that is Agent-008.

How is it different from H33-74?

H33-74 PRODUCES the signed record at the moment of the decision. Replay / Verification RE-CHECKS that record afterward and renders the verdict. One writes the evidence; the other independently reads and validates it.

What does a passing replay mean — and not mean?

It means the run REPRODUCES from the signed record and VALIDATES against it — same inputs, same hashes, signatures verify. It does not mean the underlying decision was correct, secure, or compliant. That judgment is governance (Agent-008), not replay.

When should I use it?

When a third party must confirm exactly what a substrate decision saw and produced without trusting the operator — audit, dispute, regulatory review, incident forensics, or coverage adjudication.

Next step

See how attackers fail

Six attack classes against agent authority. The substrate rejected every one and produced verifiable proof.

Open the Attack Center