AIR
Proof Lab
StartEcosystem
Explore (579)Live Systems (52)Pricing
Log InGet API Key✓ Verify It Yourself
H33 Standards · Verification Model

Two Precision Levels of Verification

Every H33 replay artifact carries a verdict. Two verdict classes are normative: STRUCTURALLY_VALID and FULLY_REPLAYABLE. Each answers a different question, requires a different artifact set, and serves a different audience. Pay for the verification depth your audit actually needs.

Definition. The H33 Verification Model defines the two normative precision levels at which an independent verifier renders a verdict on an H33-74–anchored replay artifact it did not produce. Unlike a score or a rating, a verdict is a deterministic yes/no on a specific set of checks; unlike a marketing claim, its ceiling is fixed by the artifacts presented, not by the requester. It defines how the verdict is rendered — it does not produce the artifact (H33-74 produces it) and it does not rate posture (that is a score).

Level 1 · Bundle Integrity

Did this replay bundle hold its structural invariants?

VERDICT: STRUCTURALLY_VALID

The verdict ceiling for a replay bundle alone. Proves the governance graph holds its structural invariants: transcript-version consistency, no orphan parent references, no cycles, no cross-tenant contamination within a lineage, required lineage for state-transition nodes, deterministic graph root, deterministic Merkle root over stored canonical_hash values.

CostCheap; no external lookups
Inputh33-replay-bundle-v0.2 (single file)
Verifierh33-replay-verify CLI · WASM playground
Level 2 · Receipt Authenticity

Were the receipts that produced this graph cryptographically authentic?

VERDICT: FULLY_REPLAYABLE

The verdict ceiling for a replay bundle paired with its receipts archive. Adds two foundational cryptographic checks on top of Level 1: every receipt's canonical_hash recomputes from its canonical fields, and every receipt's three-family post-quantum signature verifies against the public key resolved from its signer_key_id.

CostHigher; one PQ signature verification per receipt
InputBundle + h33-receipts-archive-v0.1
Verifierh33-verify CLI (with archive attached)

When to use which level

Use caseRequired level
Continuous CI of replay stateSTRUCTURALLY_VALID
Internal compliance dashboardsSTRUCTURALLY_VALID
Regulator first-look or quarterly reviewSTRUCTURALLY_VALID
Public verifier playground (default)STRUCTURALLY_VALID
Regulator full auditFULLY_REPLAYABLE
Post-incident forensicsFULLY_REPLAYABLE
Legal discoveryFULLY_REPLAYABLE
Public verifier playground (archive attached)FULLY_REPLAYABLE
Verifier honesty · the load-bearing principle
Verifiers report which checks they performed, not just the verdict.

The NOT_PERFORMED contract

A v0.2 bundle without a receipts archive cannot reach FULLY_REPLAYABLE. The verifier surfaces the checks it could not perform with stable reason codes — never silently treats them as passed. Operators read the JSON output and never mistake "absent from violations" for "passed."

NOT_PERFORMED
The check has no implementation path in the running verifier today. Distinct from "skipped due to missing input."
REQUIRES_RECEIPT_PAYLOAD
The check needs receipt-level fields or signature bytes that the bundle format does not carry. Resolved by attaching a paired receipts archive.
NOT_AVAILABLE
The check could be performed but a required external resource (public-key registry, anchor RPC) was unreachable at verification time.

What this looks like in the CLI

The verifier's JSON output groups checks into three explicit arrays. checks_passed, checks_failed, checks_not_performed. An auditor reading the JSON never confuses "absent from violations" for "passed."

$ h33-replay-verify case-bundle.json | jq '.verdict, .checks_not_performed[]'

"VALID"
{
"code": "HATS-V-CHECK-001",
"reason": "REQUIRES_RECEIPT_PAYLOAD",
"detail": "Bundle format v0.2 stores canonical_hash but not the receipt-level canonical fields required to recompute it. Awaiting paired receipts archive."
}
{
"code": "HATS-V-CHECK-007",
"reason": "REQUIRES_RECEIPT_PAYLOAD",
"detail": "Bundle format v0.2 stores signer_key_id but not the signature bytes; verify_signature() cannot be called. Awaiting paired receipts archive."
}

The same bundle paired with its receipts archive elevates the verdict ceiling and clears those two skipped checks.

$ h33-verify case-bundle.json --receipts archive.json | jq '.verdict_class, .replay_integrity_level'

"FULLY_REPLAYABLE"
"FULLY_REPLAYABLE"

Backward compatibility

Existing h33-replay-bundle-v0.2 bundles remain fully usable for Level 1 verification. No producer needs to upgrade. Customers that want Level 2 verdicts attach a paired h33-receipts-archive-v0.1 file alongside the existing bundle. The bundle format itself does not change.

Verifiers MUST refuse to elevate a v0.2 bundle to FULLY_REPLAYABLE in the absence of a paired archive, regardless of caller intent. The verdict ceiling is governed by the artifacts presented, not by the requester.

What a passing verdict does NOT mean

A verdict is scoped precisely to the checks it names, and no wider. Reading more into it is the failure mode this model exists to prevent.

  • STRUCTURALLY_VALID does not mean the receipts were cryptographically authentic. It proves the bundle held its structural invariants only; receipt signatures were NOT_PERFORMED without a paired archive.
  • FULLY_REPLAYABLE does not mean the governed decision was correct, wise, or compliant. It proves the receipts recompute and their three-family post-quantum signatures verify — that the recorded history is authentic and reproducible, not that it was the right history.
  • A passing verdict is not a score or a rating of posture, and not a warranty of security. It is a deterministic result on a fixed check set.
  • A passing verdict says nothing about artifacts, checks, or time windows outside the ones presented. Absence from the violations list is never a claim that an unperformed check passed.

Frequently asked

What is the H33 Verification Model?

The definition of the two normative precision levels — STRUCTURALLY_VALID (bundle integrity) and FULLY_REPLAYABLE (receipt authenticity) — at which an independent verifier renders a deterministic verdict on an H33-74–anchored replay artifact.

How does it work?

Level 1 checks a replay bundle’s structural invariants (versions, no orphans, no cycles, deterministic roots). Level 2 adds two cryptographic checks per receipt — canonical-hash recomputation and three-family post-quantum signature verification — when a paired receipts archive is attached. Verifiers report which checks they performed, surfacing anything unperformed with stable reason codes.

When should I use which level?

Use STRUCTURALLY_VALID for continuous CI, internal dashboards, and first-look reviews. Use FULLY_REPLAYABLE for full regulator audits, post-incident forensics, and legal discovery — where receipt authenticity, not just structure, must be proven.

What doesn’t a passing verdict mean?

It does not mean the decision was correct, wise, or compliant, and it is not a score or a security warranty. STRUCTURALLY_VALID does not imply receipt authenticity; FULLY_REPLAYABLE proves the history is authentic and reproducible, not that it was the right history. A verdict covers only the checks it names.

How is verification different from a score?

A score (a rating of posture) is produced by measuring against a rubric. Verification renders an independent, deterministic yes/no on an artifact it did not produce — its ceiling fixed by the artifacts presented, not by the requester’s intent.

Closing

Two verdict classes. One open-source verifier. The precision matches the audit.