H33 protocols are built for long-term cryptographic reproducibility. Verifier outputs, replay integrity classifications, rejection semantics, domain separators, and compatibility rules are frozen and regression-tested against canonical conformance vectors.
Protocol Stability is the property that an H33-74 evidence artifact stays re-verifiable across protocol versions — replay integrity. The verifier semantics, encodings, and rejection rules that a receipt was produced under remain reproducible, so the same evidence yields the same result years later, in any language, against any conformant implementation.
Why this exists: long-term evidence is worthless if the rules for reading it drift. Insurers, regulators, courts, and forensic reviewers reach for a receipt years after it was created. Protocol Stability is what lets H33-74 promise that the receipt it produces and anchors can still be replayed and re-checked when the original system is gone.
Stability does not mean the protocol never changes. It means change is additive and versioned: new fields, profiles, and vectors may be added within a version; anything that would alter how an existing receipt replays requires a new major version with a migration guide and an overlap window. Prior receipts stay valid under the version they were produced with — the evidence remains re-verifiable across versions. Rely on protocol stability when you need a receipt produced today to remain re-verifiable years from now; it is not a promise that the format is frozen, only that change is additive and old receipts keep verifying.
Protocol freeze is a binding commitment. Frozen surfaces cannot change without a major version increment, a migration guide, and a minimum 12-month overlap window.
| Frozen Surface | Description |
|---|---|
| Verifier Schemas | Input/output shapes, field names, types, and ordering for all verifier endpoints |
| Proof Profiles | The 7 canonical proof profile definitions and their parameter envelopes |
| Replay Integrity Semantics | Classification logic, grading thresholds, and replay integrity labels |
| Error Namespaces | All 26 HATS_ERR codes, their severity levels, and requirement references |
| Deterministic Ordering | Field serialization order in transcripts and canonical encodings |
| Domain Separators | All context strings used in hash derivation and transcript binding |
| Canonical Encodings | Byte-level encoding rules for proofs, signatures, and attestation bundles |
| Transcript Semantics | Transcript derivation logic, append ordering, and finalization rules |
Protocol drift immediately breaks CI through canonical freeze vectors and regression corpora.
The same proof always produces identical transcript derivation, identical replay classification, identical rejection semantics, identical verifier outputs. Across implementations. Across languages. Forever.
Malformed governance does not merely fail. It fails deterministically with stable error codes, severity classification, requirement references, and replay integrity grading.
{
"error": "HATS_ERR_POLICY_EXPIRED",
"severity": "critical",
"requirement": "REQ-1.3",
"replay_integrity": "deterministic",
"message": "Governing policy version 4 expired at 2026-05-01T00:00:00Z",
"resolution": "Activate policy version 5 or later",
"verifier_output": {
"transcript_hash": "a3f8c1...",
"rejection_class": "policy_violation",
"deterministic": true
}
}
Protocol evolution follows strict compatibility rules. Some changes are safe within a minor version. Others require a breaking version increment.
| Surface | v1.x Status |
|---|---|
| Field additions | Allowed |
| Field removals | Breaking (v2 required) |
| Error code rename | Forbidden |
| Severity reclassification | Forbidden |
| Requirement ID reuse | Forbidden |
| Domain separator mutation | Forbidden |
| Proof profile additions | Allowed |
| Replay integrity reordering | Breaking (v2 required) |
| New test vectors | Allowed |
| Existing vector modification | Breaking (v2 required) |
Third-party implementations can validate protocol equivalence without trusting H33 infrastructure.
| Implementation | Language | Vectors Passing | Status |
|---|---|---|---|
| H33 Reference | Rust | 26/26 | Conformant |
| Your implementation | — | — | Register below |
Contact standard@h33.ai to register your implementation.
HATS compatibility is not a claim. It is a test result. 26 canonical vectors. Byte-identical expected outputs. Any language.
$ hats-verify conformance path/to/vectors/
H33's STARK engine runs in pure Rust. The cryptographic hot path does not depend on JavaScript or browser runtimes. No scripting layer participates in proving, verification, transcript construction, field arithmetic, challenge derivation, or security-critical execution.
Portable JSON test vectors allow independent verifiers in Go, TypeScript, Python, Java, or Rust to reproduce identical outputs. The proving and verification path is fully deterministic and backed by 524+ passing tests plus 26 canonical conformance vectors for third-party reimplementation.
Protocol Stability is an expression of H33-74, which produces and anchors the portable, durable evidence. It has clear neighbors, each with a distinct verb.
| System | Verb | Boundary |
|---|---|---|
| H33-74 | Produces / anchors | Creates the durable receipt whose replay stays stable across versions |
| Verification | Renders the verdict | Reaches the independent judgment over the evidence — not H33-74's job |
| HATS | Records / monitors | Observes live systems and controls over time |
| Agent-008 | Governs | Constrains an AI agent's authority in the moment |
When not to use this concept: Protocol Stability answers "will a receipt produced today still replay years from now." Do not use it when your question is "is this specific receipt valid" — that verdict is rendered by Verification instead; when your question is "are my live systems and controls still in a good state over time," use HATS; and when it is "what is this AI agent permitted to do right now," use Agent-008. This page is only about the versioned, additive stability that keeps H33-74 receipts replayable across versions.
No. Change is additive and versioned. New fields, proof profiles, and test vectors can be added within a version; anything that would change how an existing receipt replays requires a new major version with a migration guide and an overlap window. The guarantee is replay integrity — a receipt stays re-verifiable across versions under the version it was produced with.
No. H33-74 produces and anchors the evidence and keeps it replayable; the independent verdict over that evidence is rendered by Verification. Protocol Stability does not monitor systems (HATS) or govern agents (Agent-008) either.
By replaying it offline against the frozen semantics and canonical conformance vectors of the version it was produced under — trusting no operator and no live service. Any conformant implementation, in any language, reproduces byte-identical outputs. Deterministic ordering, domain separators, and canonical encodings are all frozen within a version so the result cannot drift.
No. Hash functions (SHA3), signature families (ML-DSA, SLH-DSA), and content-addressing conventions are external NIST/IETF standards H33 uses and verifies against — never invented or owned. What H33-74 owns is the portable receipt and the discipline that keeps it replayable over time.
Download the canonical test vectors. Run the reference verifier. Or build your own. The protocol is the proof.