The HATS protocol is composed of twelve interdependent components. Each component has a defined responsibility, a frozen interface surface, and explicit dependencies on other components. The diagram below shows the layered relationship between all components.
┌───────────────────────────────────────────────────────────────────────────────┐
│ HATS PROTOCOL │
├───────────────┬─────────────┬─────────────┬─────────────┬─────────────┤
│ Governance │ Replay │ Proof │ Verifier │ Evidence │
│ Graph │ Engine │ Bundles │ Model │ Chains │
├───────────────┼─────────────┼─────────────┼─────────────┼─────────────┤
│ Nodes │ Frames │ H33-74 │ Public │ Hash-linked │
│ Edges │ Snapshots │ Receipts │ CLI │ PQ-signed │
│ DAG │ Timeline │ Anchors │ Offline │ Immutable │
├───────────────┴─────────────┴─────────────┴─────────────┴─────────────┤
│ Enforcement │ Transcript │ Conformance │ Capability │ Compatibility │
│ Semantics │ Semantics │ Suite │ Profiles │ Guarantees │
├───────────────┴─────────────┴─────────────┴─────────────┴─────────────┤
│ Federation (Cross-Domain Governance) │
├─────────────────────────────────────────────────────────────────────┤
│ Cryptographic Foundation │
│ SHA3-256 · ML-DSA-65 · FALCON-512 · SLH-DSA-128f │
│ Canonical Serialization · Domain Separators │
└─────────────────────────────────────────────────────────────────────┘
Each upper-layer component depends on the Cryptographic Foundation. The Governance Graph is the primary data structure; all other components consume, attest, verify, or replay its contents. No component redefines the semantics of another.
The Governance Graph is the core data structure of the HATS protocol. It is a directed acyclic graph (DAG) in which every operational decision is a node and every dependency between decisions is an edge. The graph is the single source of truth for governance state: all attestations, replays, and verifications derive from it.
The graph defines eight node types. Each node type carries a fixed schema, a deterministic hash computation, and a set of valid outbound edge types. Implementations MUST reject nodes with unknown type identifiers.
| Type ID | Name | Description |
|---|---|---|
0x01 | Route | A routing decision that directs data or control flow to a specific processing pipeline. Routes define which policies apply to which operations. |
0x02 | Policy | A governance policy definition. Policies express constraints (access rules, retention periods, exposure boundaries) as deterministic predicates. |
0x03 | Event | An operational event (data access, API call, model inference, key usage). Events are the atomic units of governance-observable activity. |
0x04 | Result | The outcome of evaluating an event against one or more policies. Results carry a pass/fail determination and the evidence that produced it. |
0x05 | StateTransition | A change in governance state (policy activation, deactivation, parameter change). State transitions are the mechanism by which the graph evolves over time. |
0x06 | Checkpoint | A snapshot of the graph's Merkle root at a given point. Checkpoints enable efficient partial replay and serve as synchronization points for federated verifiers. |
0x07 | Federation | A cross-domain governance link. Federation nodes reference governance decisions from an external trust domain, establishing inter-organizational evidence chains. |
0x08 | Anchor | A chain-binding node that records the publication of a commitment to a public ledger (Bitcoin, Solana, Ethereum). Anchors provide externally verifiable timestamps. |
Edges in the governance graph are typed and directional. Each edge type defines a specific relationship between two nodes. Edges are immutable after creation; the graph is append-only.
| Edge Type | Source | Target | Semantics |
|---|---|---|---|
DependsOn | Any | Any | The source node's validity depends on the target node's existence and validity. |
EvaluatedBy | Event | Policy | The event was evaluated against this policy. |
ProducedResult | Event | Result | The event evaluation produced this result. |
Supersedes | StateTransition | Policy | The state transition replaces or modifies this policy. |
CheckpointOf | Checkpoint | Any | The checkpoint captures the Merkle root that includes the target and all of its predecessors. |
AnchoredBy | Any | Anchor | The node's commitment was published to a public chain via this anchor. |
FederatedFrom | Federation | External | The federation node references governance data from an external trust domain. |
Every node in the governance graph has a deterministic hash. The hash is computed as:
node_hash = SHA3-256(
domain_separator // "HATS:v1:node:" (14 bytes, UTF-8, no null)
|| node_type_id // 1 byte
|| canonical_payload // Variable length, BTreeMap-ordered fields
|| sorted_parent_hashes // 32 bytes each, lexicographic order
)
The use of BTreeMap ordering ensures that field order is deterministic across implementations and programming languages. The root hash of the graph is computed as a binary Merkle tree over all leaf-node hashes, with lexicographic ordering at each level.
Frozen surface. The node schema, edge types, hash computation algorithm, and domain separator are frozen after v1.0 publication. Any change to these surfaces requires a major version increment, a published migration guide, and a minimum 12-month overlap window.
A valid governance graph MUST satisfy all of the following invariants at every state:
The Replay Engine reconstructs historical governance state from the graph. Given a governance graph and a target timestamp, the engine deterministically produces the exact governance state that existed at that moment. This is not an approximation: it is a byte-identical canonical replay frame.
The replay engine's core invariant: same graph + same timestamp = identical output. This holds across implementations, hardware architectures, and time. The guarantee is quantified:
| Metric | Value | Test Conditions |
|---|---|---|
| Replay Determinism Score | 100.0% | 50,000 operations, cross-implementation comparison |
| Divergence count | 0 | Zero byte-level differences across 50,000 replays |
| Replay latency (10K actions) | 2.5 ms | Full session reconstruction, Graviton4 96-vCPU |
| Replay latency (100K actions) | 18 ms | Full session reconstruction, Graviton4 96-vCPU |
The engine supports three replay modes, each producing a deterministic output frame:
policy-only (active policies at timestamp), memory-only (data-access events and their results), and tool-chain (tool invocations and their governance outcomes). Partial replay frames are strict subsets of the full replay frame.HATS:v1:fork:).A replay frame is the output of a replay operation. Its structure is frozen:
{
"frame_version": 2,
"replay_mode": "full" | "partial:policy-only" | "partial:memory-only"
| "partial:tool-chain" | "fork",
"target_timestamp": "2026-05-18T14:30:00Z",
"graph_root_hash": "a3f8c1d2...", // 32-byte hex
"frame_hash": "b7e4d9f1...", // SHA3-256 of canonical frame bytes
"node_count": 1847,
"edge_count": 3214,
"active_policies": [ ... ], // Deterministic BTreeMap order
"evidence_chains": [ ... ], // Hash-linked, PQ-signed
"checkpoint_ref": "c4a2b8e3...", // Nearest prior checkpoint hash
"replay_integrity": "deterministic" // or "fork:non-authoritative"
}
Every replay frame carries an integrity classification:
| Level | Meaning | Conditions |
|---|---|---|
deterministic | Byte-identical reproduction guaranteed | Full or partial mode, all inputs available, no fork modifications |
checkpoint-bounded | Replay is accurate from the nearest checkpoint forward | Pre-checkpoint graph data unavailable; replay starts from checkpoint state |
fork:non-authoritative | Hypothetical state, not a record of what happened | Fork replay mode with caller-supplied state transitions |
The Conformance Suite is the set of canonical test vectors that define correct verifier behavior. A verifier implementation that passes all vectors is conformant. A verifier that fails any vector is non-conformant. There is no partial conformance.
The suite contains 20 canonical test vectors at v1.0. Each vector has a unique identifier (HATS-VEC-001 through HATS-VEC-020), a frozen input, and a frozen expected output. Vectors are immutable after publication. New vectors receive new identifiers; existing vectors are never modified. A breaking change to any vector requires a transcript version increment.
| Category | Vector IDs | Tests |
|---|---|---|
| Valid receipts | VEC-001 – VEC-004 | Correctly formed receipts with all three PQ signature families. Verifier MUST return VERIFIED. |
| Tampered receipts | VEC-005 – VEC-008 | Receipts with one modified byte in the payload, signature, or chain link. Verifier MUST return specific failure codes. |
| Broken chains | VEC-009 – VEC-011 | Evidence chains with missing predecessors, reordered links, or duplicate entries. Verifier MUST detect the break. |
| Forged hashes | VEC-012 – VEC-013 | Receipts where the commitment does not match the recomputed hash. Tests domain separator correctness. |
| Scope violations | VEC-014 – VEC-015 | Receipts that reference policies outside the attested scope. Verifier MUST reject out-of-scope references. |
| Exposure attestations | VEC-016 – VEC-017 | Receipts that attest data exposure events. Tests correct handling of negative proofs (proved non-exposure). |
| Replay determinism | VEC-018 – VEC-020 | Full replay frame outputs. Verifier MUST produce byte-identical frames to the reference output. |
Each test vector is a self-contained JSON file with the following structure:
{
"vector_id": "HATS-VEC-001",
"version": 1,
"category": "valid-receipt",
"description": "Valid receipt with 3-family PQ signature bundle",
"input": {
"receipt_hex": "...",
"h33_74_hex": "...",
"chain_hex": "..."
},
"expected": {
"result": "VERIFIED",
"error_codes": [],
"frame_hash": null
},
"frozen_at": "2026-05-22T00:00:00Z"
}
Immutability rule. Once a vector is published, its input and expected fields never change. If a bug is found in a vector, a new corrected vector is published with a new ID, and the original is marked deprecated (but never deleted).
The Verifier Model defines how independent parties verify HATS attestations without trusting the vendor. The model's core principle: the specification is the authority, not the vendor. Any party, with any implementation, at any time, given the same inputs, MUST reach the same verification result.
| Property | Requirement |
|---|---|
| No API key required | Verification MUST NOT require authentication with H33 or any vendor. The verification algorithm is fully public. |
| No network required | Offline verification MUST be supported. All inputs necessary for verification (receipt, signatures, chain data) can be bundled for offline use. |
| No vendor trust | A verifier does not need to trust H33. The specification defines the algorithm; any correct implementation reaches the same result. |
| Deterministic output | Given identical inputs, every conformant verifier produces identical output. This is tested by the Conformance Suite. |
The canonical verification procedure is a five-step pipeline. Each step is mandatory. Failure at any step terminates verification with a specific error code.
HATS_ERR_SCHEMA.HATS_ERR_HASH.predecessor_hash matches the hash of the preceding receipt. Walk the chain backwards to a checkpoint or genesis. Reject broken chains with HATS_ERR_CHAIN.HATS_ERR_SIG_{family}.HATS_ERR_REPLAY.Three reference verification paths are supported:
$ hats-verify \
--receipt governance-receipt.json \
--chain chain-bundle.json \
--offline
Step 1: Schema validation [PASS]
Step 2: Hash recomputation [PASS] a3f8c1d2e4b5...
Step 3: Chain integrity [PASS] 47 links verified
Step 4: Signature verification
ML-DSA-65 [PASS]
FALCON-512 [PASS]
SLH-DSA-SHA2-128f [PASS]
Step 5: Replay determinism [PASS] frame_hash matches
Result: VERIFIED (5/5 steps passed, 0 warnings)
Evidence Chains are hash-linked sequences of governance events forming an immutable operational history. Each event in the chain references the hash of its predecessor. Any deletion, insertion, or reordering of events breaks the chain and is detectable by any verifier.
Every receipt in a chain carries a predecessor_hash field: the SHA3-256 digest of the immediately preceding receipt's canonical serialization. The first receipt in a chain (the genesis receipt) has predecessor_hash set to 32 zero bytes (0x00...00). This structure makes evidence chains a cryptographic singly-linked list.
Receipt[0]: predecessor_hash = 0x0000...0000 (genesis)
receipt_hash = SHA3-256(domain || canonical_bytes)
↓
Receipt[1]: predecessor_hash = receipt_hash(Receipt[0])
receipt_hash = SHA3-256(domain || canonical_bytes)
↓
Receipt[2]: predecessor_hash = receipt_hash(Receipt[1])
receipt_hash = SHA3-256(domain || canonical_bytes)
↓
... continues ...
The protocol defines five chain types, each scoped to a specific accountability domain:
| Chain Type | Scope | Description |
|---|---|---|
session | Single session | All governance events within one user or agent session. Bounded by session start and session end events. |
agent | Single AI agent | All governance events produced by a specific agent identity across sessions. Enables agent-level accountability and lineage tracking. |
governance | Organization | All policy changes, state transitions, and checkpoint events for an organization. The authoritative chain for governance audit. |
approval | Approval workflow | The sequence of approvals, rejections, and escalations for a specific governance action. Used for multi-party authorization evidence. |
exposure | Data exposure | All events related to sensitive data access, including non-exposure proofs. Supports "prove it wasn't exposed" verification. |
A valid evidence chain MUST satisfy:
predecessor_hash exactly equals the computed hash of the immediately prior receipt.HATS_ERR_CHAIN_GAP.Per-participant accountability. Evidence chains can be scoped to individual participants (human users, AI agents, service accounts). This enables fine-grained attribution: given a chain, a verifier can determine exactly which participant performed which governance-observable action, in what order, and under which policy.
Federation enables cross-organizational governance verification. Multiple independent trust domains, each operating their own HATS deployment, can produce interoperable evidence that a verifier can check without trusting any single organization.
A trust domain is a self-contained HATS deployment: its own governance graph, its own signing keys, its own evidence chains. Federation does not merge trust domains. It creates verifiable links between them.
When Organization A needs to reference a governance decision from Organization B:
Federation node in its own governance graph. This node contains: the hash of B's receipt, B's public key bundle (for signature verification), and a timestamp of when the federation link was created.| Property | Mechanism |
|---|---|
| Quorum-based ordering | When two trust domains produce events with overlapping timestamps, a quorum of federation witnesses determines canonical order. A minimum of 3 witnesses is required; 2-of-3 agreement establishes order. |
| Equivocation detection | If an organization publishes two conflicting governance states for the same timestamp, any federation peer can detect the conflict by comparing checkpoint hashes. Equivocation evidence is itself signed and published. |
| Federation checkpoints | Periodic cross-domain checkpoints that capture the Merkle roots of all participating trust domains at a synchronized time. Checkpoint intervals are configurable per federation agreement. |
| Honest-majority assumption | Federation ordering is secure under an honest-majority assumption among witnesses. If more than half of the quorum witnesses are compromised, ordering guarantees degrade. |
Federation is a Level 4 (Federation) capability. Implementations that do not support federation MUST NOT advertise Level 4 conformance. See Section 10: Capability Profiles.
Enforcement Semantics define how governance constraints are automatically enforced. Enforcement is not advisory logging; it is active constraint application with four progressive levels, deterministic triggers, and structured rejection records.
| Level | Name | Behavior |
|---|---|---|
0 | AuditOnly | Violations are logged and attested but operations proceed. Used during initial deployment and policy tuning. |
1 | Advisory | Violations generate warnings to the operator and are logged. Operations proceed but are flagged in evidence chains. |
2 | Enforced | Violations block the operation. The operation is rejected with a deterministic rejection record. The rejection itself is attested and added to the evidence chain. |
3 | CriticalLockdown | Violations block the operation, freeze the session, and escalate to organizational governance. Requires explicit approval to resume. All lockdown events are PQ-signed. |
The protocol defines 10 enforcement trigger types:
| Trigger | Description |
|---|---|
PolicyViolation | An event violates an active policy constraint. |
ScopeExceedance | An operation attempts to access data or resources outside its authorized scope. |
ChainBreak | An evidence chain integrity violation is detected. |
SignatureFailure | One or more PQ signatures fail verification. |
ReplayDivergence | A replay frame does not match the expected deterministic output. |
TemporalAnomaly | A timestamp violation (non-monotonic, future-dated, or outside tolerance window). |
FederationConflict | Conflicting governance states detected across federated trust domains. |
ExposureThreshold | Sensitive data access frequency exceeds a configured threshold within a time window. |
ModelDrift | An AI model's behavior deviates from its attested baseline beyond the configured tolerance. |
AuthorizationExpiry | A time-bound authorization has expired and the operation attempts to proceed. |
The protocol defines 9 enforcement action types:
| Action | Description |
|---|---|
Log | Record the violation in the evidence chain. No operational impact. |
Warn | Send a warning notification to the operator. Operation continues. |
Reject | Block the operation. Produce a structured rejection record. |
Quarantine | Isolate the operation output for manual review before release. |
Freeze | Suspend the session. Require explicit approval to resume. |
Escalate | Route the violation to a higher governance authority for decision. |
Revoke | Invalidate a prior authorization or credential. |
Rollback | Reverse the governance state to the last valid checkpoint. |
Lockdown | Full session lockdown. All operations blocked. Organizational escalation required. |
When an operation is rejected, the enforcement engine produces a deterministic rejection record. This record is itself PQ-signed and appended to the evidence chain. Rejection records are first-class governance evidence.
{
"rejection_id": "rej-a3f8c1d2...",
"trigger": "PolicyViolation",
"enforcement_level": 2,
"action": "Reject",
"policy_id": "pol-7b3e9f21...",
"event_hash": "e4b5f678...",
"reason": "Data access exceeds authorized scope for this session",
"timestamp": "2026-05-18T14:30:12Z",
"signatures": {
"ml_dsa_65": "...",
"falcon_512": "...",
"slh_dsa_128f": "..."
}
}
Transcript Semantics define the versioned binding between governance state and verification rules. The transcript version is the single most critical compatibility indicator in the protocol: a transcript version increment signals a breaking change in the verification surface.
The current transcript version is 2. This version defines the complete set of frozen surfaces that conformant verifiers must support.
The following surfaces are frozen at transcript version 2. They will not change without a version increment:
| Surface | Description | Frozen Since |
|---|---|---|
| Verifier schema | The JSON structure of verification inputs and outputs | v1 |
| Error codes | All HATS_ERR_* and H74_ERR_* error identifiers and their semantics | v1 |
| Severity levels | Critical, Warning, Info | v1 |
| Requirement IDs | All HATS-REQ-* identifiers in the specification | v1 |
| Replay integrity levels | deterministic, checkpoint-bounded, fork:non-authoritative | v2 |
| Ordering rules | BTreeMap field ordering, lexicographic hash comparison, temporal monotonicity | v1 |
| Hex encoding | Lowercase hex for all hash and key representations | v1 |
| Whitespace rules | No trailing whitespace, LF line endings, no BOM in canonical serialization | v1 |
| Proof profiles | Algorithm suites (see Section 11) | v2 |
| Domain separators | All HATS:v1:* and H33-74:v1:* prefix strings | v1 |
A transcript version increment (MUST be sequential, no gaps) is required when:
Additive changes (new optional fields, new error codes, new capability profiles) do not require a version increment.
Proof Bundles are self-contained evidence packages for independent verification. A proof bundle contains everything a verifier needs to confirm a governance attestation without accessing any external system.
The primary proof bundle format is H33-74: a 74-byte fixed-width post-quantum attestation primitive. The format is split into two regions:
| Region | Size | Contents |
|---|---|---|
| On-chain commitment | 32 bytes | SHA3-256 digest of the full attestation receipt. Published to a public ledger (Bitcoin, Solana, Ethereum, or L2). |
| Cached receipt | 42 bytes | Version, computation type, signature flags, chain target, timestamp delta, receipt locator, tenant ID, and CRC-16 checksum. |
Every proof bundle references a signature bundle stored with the full receipt. The bundle contains three signatures computed over identical canonical receipt bytes:
| Family | Algorithm | Hardness Assumption | Signature Size |
|---|---|---|---|
| Lattice (MLWE) | ML-DSA-65 (FIPS 204) | Module Learning With Errors | 3,309 bytes |
| Lattice (NTRU) | FALCON-512 | Short Integer Solution over NTRU lattices | 690 bytes (avg) |
| Hash-based | SLH-DSA-SHA2-128f (FIPS 205) | Second-preimage resistance of SHA-256 | 17,088 bytes |
Total signature bundle size: approximately 21,087 bytes. This is stored with the full receipt, not in the 74-byte primitive. The primitive carries only a 1-byte signature_flags field indicating which families are present.
The 32-byte on-chain commitment can be anchored to any supported public ledger. The proof bundle format is chain-agnostic: the same 74-byte primitive works regardless of which chain carries the commitment.
| Chain | Method | Identifier |
|---|---|---|
| Bitcoin | Taproot OP_RETURN (BIP-341) | 0x01 |
| Solana | Memo Program instruction | 0x02 |
| Ethereum | Calldata to anchor contract | 0x03 |
| Arbitrum (L2) | Calldata to L2 anchor contract | 0x04 |
| Unanchored | No chain publication | 0x00 |
The H33-74 primitive is always exactly 74 bytes regardless of the complexity of the underlying governance operation. A simple data-access attestation and a complex multi-party federated governance decision both produce the same 74-byte primitive. Complexity is absorbed by the full receipt; the primitive is a constant-size commitment.
Capability Profiles define five progressive tiers of HATS conformance. Each higher profile is a strict superset of the one below it. An implementation claiming a profile MUST satisfy all requirements of that profile and all profiles below it.
| Level | Profile | Requirements | Adds |
|---|---|---|---|
1 |
Core |
Governance graph construction, attestation receipt generation, H33-74 primitive production, evidence chain maintenance, three-family PQ signing, basic verification. | Foundation: graph + receipts + verification |
2 |
Replay |
All of Core, plus: deterministic replay engine (full and partial modes), canonical replay frames, 100.0% replay determinism score, replay integrity classification. | Deterministic replay |
3 |
Enforcement |
All of Replay, plus: automated policy enforcement (all 4 levels), structured rejection semantics, 10 trigger types, 9 action types, enforcement evidence chains. | Policy enforcement |
4 |
Federation |
All of Enforcement, plus: cross-domain governance links, quorum-based ordering, equivocation detection, federation checkpoints, inter-organizational evidence verification. | Cross-domain governance |
5 |
AI-Governance |
All of Federation, plus: agent lineage tracking, model attestation, inference audit chains, model drift detection, tool-use governance, prompt/response evidence chains. | Agent lineage + model attestation |
An implementation declares its capability profile in its attestation receipts via the capability_profile field. Verifiers MUST check that the declared profile is consistent with the features used in the receipt. A receipt that references federation data but declares Core profile is invalid.
Advancing from one profile to the next requires passing the Conformance Suite vectors for the target profile. Profile advancement is not self-declared; it is validated by the conformance testing infrastructure. There is no mechanism to skip levels.
Strict superset property. Level N conformance implies Level 1 through N-1 conformance. A Level 5 (AI-Governance) implementation is also a valid Level 1, 2, 3, and 4 implementation. There are no profile-specific exemptions.
A Cryptographic Profile is a named algorithm suite that defines which cryptographic primitives are used for hashing, signing, and verification. The current production profile is defined below.
| Function | Algorithm | Standard | Hardness Assumption |
|---|---|---|---|
| Hashing | SHA3-256 | NIST FIPS 202 | Keccak sponge (quantum-resistant) |
| Lattice signature | ML-DSA-65 | NIST FIPS 204 | Module Learning With Errors (MLWE) |
| NTRU signature | FALCON-512 | NIST Round 3 selection | Short Integer Solution over NTRU lattices |
| Hash-based signature | SLH-DSA-SHA2-128f-simple | NIST FIPS 205 | Second-preimage resistance of SHA-256 |
The cryptographic profile is designed so that an attacker must simultaneously break three independent mathematical problems to forge an attestation:
Not "three Level 3 families." The current production profile uses ML-DSA-65 (NIST Level 3), FALCON-512 (NIST Level 1), and SLH-DSA-SHA2-128f-simple (NIST Level 1). The bundle's effective security is bounded at Level 1. The correct characterization is "three independent hardness assumptions," not "three Level 3 families."
Every hash computation in the HATS protocol uses a domain separator to prevent cross-context collisions. Domain separators are UTF-8 strings with no null terminator, prepended to the hash input.
| Context | Domain Separator | Length |
|---|---|---|
| H33-74 commitment | H33-74:v1:commitment: | 21 bytes |
| Governance node | HATS:v1:node: | 14 bytes |
| Evidence chain | HATS:v1:chain: | 15 bytes |
| Replay frame | HATS:v1:frame: | 15 bytes |
| Fork replay | HATS:v1:fork: | 14 bytes |
| Rejection record | HATS:v1:reject: | 16 bytes |
| Federation link | HATS:v1:fed: | 13 bytes |
| Checkpoint | HATS:v1:checkpoint: | 20 bytes |
Compatibility Guarantees define the rules for protocol evolution. The HATS protocol is designed to evolve without breaking existing deployments. These guarantees are contractual commitments to implementers and operators.
A frozen surface is a protocol element that will never change without a major version increment. Once frozen, the surface is locked for the lifetime of the current major version. The complete list of frozen surfaces is enumerated in Section 8: Transcript Semantics.
New fields may be added to receipt schemas, graph nodes, and replay frames. Added fields MUST be optional. The hash computation for existing structures uses a conditional hash rule:
// When a new optional field is added:
// - If the field is None/absent: hash is identical to pre-addition hash
// - If the field is present: field bytes are included in hash input
hash_input = domain_separator
|| existing_field_1
|| existing_field_2
|| ...
|| IF new_optional_field IS PRESENT THEN new_optional_field_bytes
// No bytes added if field is absent
// This ensures: hash(old_receipt) == hash(new_receipt_with_none_fields)
This conditional hash rule ensures that adding a new optional field does not change the hash of any existing receipt where that field is absent. Existing verifiers that do not know about the new field will compute the same hash as updated verifiers.
When a breaking change is unavoidable:
The following changes are non-breaking and do not require a version increment:
The following matrix shows which components depend on which. A dependency means the dependent component consumes the depended-upon component's output or requires its invariants to hold. No component redefines the semantics of another.
| Component | Depends On |
|---|---|
Governance Graph | Cryptographic Profiles (hashing, domain separators) |
Replay Engine | Governance Graph, Transcript Semantics, Cryptographic Profiles |
Conformance Suite | Verifier Model, Transcript Semantics, Capability Profiles |
Verifier Model | Governance Graph, Evidence Chains, Cryptographic Profiles, Proof Bundles |
Evidence Chains | Governance Graph, Cryptographic Profiles |
Federation | Governance Graph, Evidence Chains, Cryptographic Profiles |
Enforcement Semantics | Governance Graph, Evidence Chains, Cryptographic Profiles |
Transcript Semantics | Compatibility Guarantees (version rules) |
Proof Bundles | Cryptographic Profiles, Evidence Chains |
Capability Profiles | Conformance Suite, all protocol components (progressive inclusion) |
Cryptographic Profiles | None (foundation layer) |
Compatibility Guarantees | Transcript Semantics (frozen surface rules) |
The following diagram shows the data flow from a governance event through the protocol to a verified attestation:
Governance Event
│
▼
┌──────────────────────┐
│ 1. Graph Insertion │ Event becomes a node in the governance graph.
│ + Edge Creation │ Edges link it to policies, results, predecessors.
└──────────────────────┘
│
▼
┌──────────────────────┐
│ 2. Policy Evaluation │ Event evaluated against active policies.
│ + Enforcement │ Violations trigger enforcement actions.
└──────────────────────┘
│
▼
┌──────────────────────┐
│ 3. Receipt Creation │ Canonical serialization of event + result.
│ + Chain Linking │ predecessor_hash links to prior receipt.
└──────────────────────┘
│
▼
┌──────────────────────┐
│ 4. PQ Signing │ Three signatures over canonical bytes:
│ (3 families) │ ML-DSA-65, FALCON-512, SLH-DSA-128f.
└──────────────────────┘
│
▼
┌──────────────────────┐
│ 5. H33-74 Primitive │ 32-byte commitment + 42-byte cached receipt.
│ Generation │ 74 bytes total. Constant size.
└──────────────────────┘
│
▼
┌──────────────────────┐
│ 6. Chain Anchoring │ 32-byte commitment published to Bitcoin,
│ (optional) │ Solana, Ethereum, or L2.
└──────────────────────┘
│
▼
┌──────────────────────┐
│ 7. Independent │ Any party, any time, offline or online.
│ Verification │ 5-step pipeline. Same input = same result.
└──────────────────────┘