# HATS Governance Specification — v1.0

**Source of truth:** https://h33.ai/standards/specification/  
**Spec version:** v1.0  
**License:** Apache-2.0 (verification surfaces) / proprietary (signing pipeline)  
**Status:** Working draft. The canonical HTML rendering at the URL above remains authoritative for any normative conflict.

This document is a portable Markdown extract of the HATS Governance Specification
hosted at h33.ai. It is intended for:
- offline reading by auditors, regulators, and implementers
- diffable spec tracking under version control
- LLM ingestion as an institutional artifact

For the canonical rendering with anchored sections, test vectors, and live
cross-references, see the URL above.

---

# HATS Governance Specification



H33 AI Trust Standard — Governance Protocol Specification



                Version
                1.0.0


                Date
                2026-05-17


                Editor
                Eric Beans


                Status
                Draft




            [Download Markdown](/docs/HATS-GOVERNANCE-SPEC-v1.md)
            [Download PDF](/docs/HATS-GOVERNANCE-SPEC-v1.pdf)






## Abstract



This specification defines the HATS (H33 AI Trust Standard) Governance Protocol — a vendor-neutral, implementation-agnostic standard for cryptographic operational governance. HATS defines how operational decisions are recorded, linked, replayed, verified, and enforced across distributed systems.


A HATS-compliant system produces a formally verifiable governance graph where every operational decision is a node, every dependency is an edge, and the entire structure can be independently verified by any party without trusting the platform that produced it.





## Status of This Document



This is a Draft specification. Normative requirements use RFC 2119 keywords: MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, OPTIONAL.





## 1. Conformance Terminology


### 1.1 RFC 2119 Keywords



The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.


### 1.2 Conformance Levels



**HATS-Compliant:** An implementation that satisfies all MUST requirements for at least one Governance Capability Profile (Section 17).


**HATS-Compatible:** An implementation that can consume and produce HATS governance artifacts but may not satisfy all MUST requirements.


**HATS-Conformant:** An implementation that passes the full HATS Conformance Suite for its declared Capability Profile.


**Verifier-Grade:** An implementation capable of independently verifying HATS governance bundles with zero infrastructure dependencies.


**Replay-Grade:** An implementation capable of deterministic governance replay producing identical frame hashes as any other Replay-Grade implementation given identical inputs.





## 2. Node Types


### 2.1 Governance Node Envelope



Every governance node MUST expose the following fields:





| Field | Type | Required | Description |



| `node_type` | Enum | REQUIRED | One of the 8 defined node types |

| `canonical_hash` | Byte[32] | REQUIRED | Commitment hash over all node content |

| `transcript_version` | Uint8 | REQUIRED | Protocol version at creation time |

| `signer_key_id` | Byte[32] | REQUIRED | Hash of the signer's public key |

| `parent_refs` | Array<Byte[32]> | REQUIRED | Hashes of parent governance nodes |

| `timestamp_ms` | Uint64 | REQUIRED | Creation time (ms since Unix epoch) |

| `tenant_id_hash` | Byte[32] | OPTIONAL | Hash of the tenant/account identity |





HATS-N-001
Every governance node MUST contain all REQUIRED fields.


HATS-N-002
The `canonical_hash` MUST be computed using the Canonical Serialization rules (Section 5) and the active Cryptographic Profile (Section 6).


HATS-N-003
The `signer_key_id` MUST be the hash of the signer's public key using the active hash function.


### 2.2 Node Type Definitions





| Type ID | Name | Description | Min Parents |



| 1 | Route | Engine selection decision | 0 |

| 2 | Policy | Policy gate evaluation | 1 (Route) |

| 3 | Event | Authenticated operation | 0–2 (Route, Policy) |

| 4 | Result | Computation output | 1–3 (Route, Policy, Event) |

| 5 | StateTransition | Governed state mutation | 4 (Route, Policy, Result, Event) |

| 6 | Checkpoint | Integrity snapshot | 0 |

| 7 | Federation | Multi-node aggregation | 1+ (Checkpoints) |

| 8 | Anchor | External binding | 1 (Federation) |





HATS-N-004
Implementations MAY define additional node types using the extension namespace (Section 21). Extended node types MUST use type IDs >= 100.


HATS-N-005
StateTransition nodes MUST have at least 4 parent references (Route, Policy, Result, Event).





## 3. Receipt Schemas


### 3.1 Common Receipt Fields



Every receipt MUST include:





| Field | Type | Description |



| `receipt_hash` | Byte[32] | Commitment over all receipt fields |

| `pq_signature` | Bytes | Post-quantum signature over `receipt_hash` |

| `signer_key_id` | Byte[32] | Hash of signer's public key |

| `signature_algorithm` | String | Algorithm identifier from active profile |

| `timestamp_ms` | Uint64 | Receipt creation time |

| `transcript_version` | Uint8 | Protocol version |





HATS-R-001
The `receipt_hash` MUST be computed using Canonical Serialization (Section 5).


HATS-R-002
The `pq_signature` MUST be computed over the raw `receipt_hash` bytes, not over a serialized representation.


### 3.2 Route Decision Receipt





| Field | Type | Required |



| `request_hash` | Byte[32] | REQUIRED |

| `selected_engine` | String | REQUIRED |

| `rejected_engines` | Array<{engine, reason}> | REQUIRED |

| `policy_version` | String | REQUIRED |

| `security_target` | String | REQUIRED |

| `hardware_snapshot_id` | String | REQUIRED |

| `latency_target_us` | Uint64 | REQUIRED |

| `credit_cost` | Uint32 | REQUIRED |

| `stage1_hash` | Byte[32] | REQUIRED |





HATS-R-003
Every Route Decision Receipt MUST include at least one rejected engine OR document that only one engine was eligible.


### 3.3 Policy Decision Receipt





| Field | Type | Required |



| `policy_id` | String | REQUIRED |

| `policy_version` | String | REQUIRED |

| `request_hash` | Byte[32] | REQUIRED |

| `route_receipt_hash` | Byte[32] | REQUIRED |

| `decision` | Enum(Allowed, Denied) | REQUIRED |

| `enforcement_mode` | Enum(Enforce, AuditOnly) | REQUIRED |

| `required_security_target` | String | REQUIRED |

| `data_classification` | String | REQUIRED |

| `tenant_id_hash` | Byte[32] | REQUIRED |





HATS-R-004
A Denied policy decision MUST NOT produce a successful execution event in the same governance lineage.


### 3.4 Result Attestation Receipt





| Field | Type | Required |



| `request_hash` | Byte[32] | REQUIRED |

| `route_receipt_hash` | Byte[32] | REQUIRED |

| `policy_decision_hash` | Byte[32] | REQUIRED |

| `event_hash` | Byte[32] | REQUIRED |

| `engine_id` | String | REQUIRED |

| `parameter_set_id` | String | REQUIRED |

| `input_commitment` | Byte[32] | REQUIRED |

| `output_commitment` | Byte[32] | REQUIRED |

| `status` | Enum(Success, Failed) | REQUIRED |

| `error_code` | String | OPTIONAL |





HATS-R-005
A Failed result MUST NOT be bound to a successful governed execution event.


### 3.5 State Transition Receipt





| Field | Type | Required |



| `state_namespace` | String | REQUIRED |

| `namespace_sequence` | Uint64 | REQUIRED |

| `prior_state_commitment` | Byte[32] | REQUIRED |

| `new_state_commitment` | Byte[32] | REQUIRED |

| `mutation_id` | String | REQUIRED |

| `tenant_id_hash` | Byte[32] | REQUIRED |

| `actor_identity_hash` | Byte[32] | REQUIRED |





HATS-R-006
Within a namespace, transition N+1's `prior_state_commitment` MUST equal transition N's `new_state_commitment`.


HATS-R-007
Duplicate `mutation_id` values within the same namespace MUST be rejected.


### 3.6 Enforcement Decision Receipt





| Field | Type | Required |



| `trigger` | String | REQUIRED |

| `action` | String | REQUIRED |

| `level` | Enum (Section 15) | REQUIRED |

| `affected_tenant` | Byte[32] | OPTIONAL |

| `affected_namespace` | String | OPTIONAL |

| `policy_profile_template` | String | REQUIRED |





HATS-R-008
Every enforcement decision MUST itself be signed and auditable. Enforcement operates within the governance chain, not outside it.





## 4. Graph Semantics


### 4.1 Directed Acyclic Graph



The governance graph is a directed acyclic graph (DAG) where nodes are governance objects and edges are parent references.



HATS-G-001
The governance graph MUST be acyclic. Implementations MUST reject graphs containing cycles.


HATS-G-002
Every `parent_ref` in a node MUST reference a node that exists in the graph (no orphan references).


HATS-G-003
The graph MUST NOT contain nodes where a tenanted child references a parent with a different `tenant_id_hash` (cross-tenant contamination).


HATS-G-004
All nodes within a governance graph MUST share the same `transcript_version`, unless the graph spans a documented version migration.


HATS-G-005
StateTransition nodes MUST have at least 4 parent references (Route, Policy, Result, Event). Fewer indicates incomplete governance lineage.


### 4.2 Graph Root Hash



HATS-G-006
The graph root hash MUST be computed by sorting all nodes by `(node_type, canonical_hash)` and hashing the sorted sequence with a domain separator.


HATS-G-007
The graph root hash MUST be deterministic: identical logical graphs MUST produce identical root hashes regardless of node insertion order.


### 4.3 Merkle Root



HATS-G-008
The graph Merkle root MUST be computed over the sorted `canonical_hash` values using a binary Merkle tree with a domain separator. Non-power-of-two counts MUST be padded with zero hashes.





## 5. Canonical Serialization Semantics


### 5.1 Purpose



Canonical serialization ensures that identical logical content produces identical byte sequences across implementations, languages, architectures, and compiler versions.


HATS-S-001
Implementations MUST use the canonical serialization rules defined in this section for all hash computations.


### 5.2 Integer Encoding



HATS-S-002
All integers MUST be encoded in little-endian byte order.



| Type | Encoding |


| Uint8 | 1 byte |

| Uint16 | 2 bytes, little-endian |

| Uint32 | 4 bytes, little-endian |

| Uint64 | 8 bytes, little-endian |




### 5.3 String Encoding



HATS-S-003
Strings MUST be encoded as a Uint32 length prefix followed by UTF-8 bytes.


HATS-S-004
Strings MUST be NFC-normalized (Unicode Normalization Form C) before encoding.


HATS-S-005
Empty strings MUST be encoded as a Uint32 zero length prefix (4 zero bytes). Empty is NOT the same as absent.


### 5.4 Byte Arrays



HATS-S-006
Fixed-size byte arrays (e.g., Byte[32]) MUST be encoded as raw bytes without a length prefix.


HATS-S-007
Variable-size byte arrays MUST be encoded as a Uint32 length prefix followed by the raw bytes.


### 5.5 Booleans



HATS-S-008
Booleans MUST be encoded as a single byte: `0x00` for false, `0x01` for true.


### 5.6 Null / Optional Values



HATS-S-009
Optional fields that are present MUST be preceded by a presence byte `0x01` followed by the encoded value.


HATS-S-010
Optional fields that are absent MUST be encoded as a single byte `0x00`.


### 5.7 Arrays



HATS-S-011
Arrays MUST be encoded as a Uint32 element count followed by each element in order.


### 5.8 Maps



HATS-S-012
Maps MUST be encoded as a Uint32 entry count followed by key-value pairs sorted by the canonical byte encoding of the key (lexicographic byte order).


### 5.9 Struct / Record Fields



HATS-S-013
Struct fields MUST be encoded in declaration order as specified in this document. Field order is part of the canonical format.


### 5.10 Domain Separators



HATS-S-014
Every hash computation MUST begin with a domain separator string that identifies the object type. Domain separators are NOT length-prefixed — they are raw ASCII bytes.




| Object | Domain Separator |


| Route Receipt | `H33_ROUTE_DECISION_RECEIPT_V1:` |

| Policy Receipt | `H33_POLICY_DECISION_RECEIPT_V1:` |

| Result Receipt | `H33_RESULT_ATTESTATION_V1:` |

| State Transition | `H33_STATE_TRANSITION_V1:` |

| Enforcement Receipt | `H33_ENFORCEMENT_DECISION_V1:` |

| Integrity Receipt | `H33_INTEGRITY_RECEIPT_V1:` |

| Checkpoint | `H33_INTEGRITY_CHECKPOINT_V1:` |

| Federation | `H33_FEDERATION_CHECKPOINT_V1:` |

| Anchor | `H33_ANCHOR_RECORD_V1:` |

| Graph Root | `H33_GOVERNANCE_GRAPH_V1:` |

| Graph Merkle | `H33_GRAPH_MERKLE:` |

| Replay Frame | `H33_REPLAY_FRAME_V1:` |

| Replay Diff | `H33_REPLAY_DIFF_V1:` |




### 5.11 Timestamp Precision



HATS-S-015
All timestamps MUST be encoded as Uint64 milliseconds since Unix epoch (1970-01-01T00:00:00Z). Microsecond or nanosecond precision MUST NOT be used in canonical serialization.





## 6. Cryptographic Agility Profiles


### 6.1 Profile Structure



A Cryptographic Profile defines the hash function, signature algorithm, and any additional cryptographic parameters.


HATS-C-001
Every HATS governance artifact MUST declare its Cryptographic Profile.


### 6.2 REQUIRED Baseline Profile



Profile ID: `HATS-PROFILE-PQ-SHA3-256-v1`




| Parameter | Value |


| Hash Function | SHA3-256 (FIPS 202) |

| Signature Algorithm | ML-DSA-65 (FIPS 204) or ML-DSA-87 |

| Hash Output | 32 bytes |

| Signature Output | Variable (ML-DSA) |

| Key ID Derivation | SHA3-256 of public key bytes |





HATS-C-002
All HATS-Compliant implementations MUST support `HATS-PROFILE-PQ-SHA3-256-v1`.


### 6.3 OPTIONAL Profiles




| Profile ID | Hash | Signature | Status |


| `HATS-PROFILE-BLAKE3-v1` | BLAKE3 | ML-DSA-65 | OPTIONAL |

| `HATS-PROFILE-STARK-POSEIDON-v1` | Poseidon | STARK proof | OPTIONAL |

| `HATS-PROFILE-HYBRID-v1` | SHA3-256 | ML-DSA-65 + Ed25519 | OPTIONAL |





HATS-C-003
Implementations MAY define additional profiles using the extension namespace (Section 21). Custom profiles MUST use the prefix `x-hats-profile-`.


### 6.4 Profile Negotiation



HATS-C-004
When a verifier encounters a bundle using an unsupported profile, it MUST reject the bundle with error `UNSUPPORTED_PROFILE` rather than silently degrading.


HATS-C-005
Profile migration within a governance graph MUST be documented via a transcript version increment.





## 7. Determinism Requirements



This section defines the most critical property of the HATS standard: given identical inputs, compliant implementations MUST produce identical outputs.



HATS-D-001
Given identical governance graph content and identical replay target (timestamp or checkpoint hash), compliant Replay-Grade implementations MUST produce identical frame hashes.


HATS-D-002
Given identical governance graph content, compliant implementations MUST produce identical graph root hashes regardless of node insertion order.


HATS-D-003
Given identical receipt fields, compliant implementations MUST produce identical `receipt_hash` values.


HATS-D-004
Given identical input to a deterministic router, compliant implementations MUST produce identical routing decisions and identical stage1 determinism hashes.


HATS-D-005
Determinism MUST be tested using the HATS Conformance Suite test vectors. An implementation that produces different hashes from the test vectors is NOT HATS-Conformant.


HATS-D-006
Floating-point arithmetic MUST NOT be used in any hash computation or canonical serialization path. All values MUST be integer or fixed-point.





## 8. Replay Semantics


### 8.1 Replay Frame



A Replay Frame is a deterministic snapshot of governance state at a point in time.


HATS-RP-001
A Replay Frame MUST include: timestamp, integrity root, active transcript versions, active signers, active policies, namespace states, node counts, total nodes, integrity checks, and frame hash.


HATS-RP-002
The frame hash MUST be computed using Canonical Serialization over all frame fields in the order specified in HATS-RP-001.


### 8.2 Replay Modes




| Mode | Description |


| Point-in-time | Snapshot at a specific timestamp |

| Forward | Frames at each distinct timestamp, ascending |

| Reverse | Same frames, descending |

| Timeline | Evenly-spaced frames between two timestamps |

| Scoped | Filtered by tenant, namespace, policy, or transcript version |





HATS-RP-003
Forward and reverse replay of the same time range MUST produce the same set of frames (in reversed order).


### 8.3 Replay Diff



HATS-RP-004
A Replay Diff MUST include: from/to timestamps, policies added/removed, state changes, new routes, signers added/removed, transcript version changes, integrity divergence flag, and diff hash.


HATS-RP-005
Diffing the same timestamp against itself MUST produce an empty diff with `integrity_diverged = false`.





## 9. Partial Replay Semantics


### 9.1 Partial Graph Export



HATS-PR-001
Implementations MUST support exporting a subgraph: given a set of root node hashes, return all nodes reachable via parent references.


HATS-PR-002
A partial graph export MUST be a valid HATS governance graph in its own right, with its own root hash.


### 9.2 Scoped Replay



HATS-PR-003
Scoped replay MUST support filtering by: tenant, namespace, policy hash, route hash, and transcript version.


HATS-PR-004
Infrastructure nodes (those with `tenant_id_hash = null`) MUST be included in tenant-scoped replay unless explicitly excluded.


### 9.3 Checkpoint Resume



HATS-PR-005
Replay MUST support resuming from a checkpoint. Given a checkpoint hash, the replay engine MUST produce the same frame as replaying from the beginning to the checkpoint's timestamp.


### 9.4 Replay Completeness



HATS-PR-006
Implementations MUST report when a scoped replay encounters parent references that point outside the scope. These MUST be reported as "missing lineage" warnings, not silent omissions.





## 10. Verification Semantics


### 10.1 Verification Input



HATS-V-001
The verification input MUST be a self-contained bundle: an array of governance nodes plus public keys. No external data sources or network access REQUIRED.


### 10.2 Required Checks



HATS-V-002
A HATS-Compliant verifier MUST perform these checks:




| ID | Check | Severity |


| `HATS-V-CHECK-001` | All nodes have valid `canonical_hash` (recomputed and matched) | FATAL |

| `HATS-V-CHECK-002` | All parent references point to existing nodes | FATAL |

| `HATS-V-CHECK-003` | No cycles in the graph | FATAL |

| `HATS-V-CHECK-004` | No cross-tenant contamination | FATAL |

| `HATS-V-CHECK-005` | Consistent transcript version | FATAL |

| `HATS-V-CHECK-006` | StateTransition nodes have >= 4 parents | ERROR |

| `HATS-V-CHECK-007` | Signatures verify against declared public keys | FATAL |

| `HATS-V-CHECK-008` | Timestamps are monotonic within signer | WARNING |

| `HATS-V-CHECK-009` | Child timestamps >= parent timestamps | WARNING |

| `HATS-V-CHECK-010` | No duplicate `canonical_hash` values | FATAL |




### 10.3 Verification Output



HATS-V-003
The verification output MUST include: valid (boolean), nodes_verified (count), errors (array of strings), warnings (array of strings), graph root hash, and Merkle root.


### 10.4 Exit Codes




| Code | Meaning |


| `0` | Valid |

| `1` | Invalid (verification failed) |

| `2` | Error (malformed input) |





HATS-V-004
Verifiers MUST NOT silently succeed on partial verification. If any FATAL check fails, the overall result MUST be `valid = false`.







## 11. Transcript Semantics




Defines transcript versioning (HATS-T-001 through HATS-T-004), version compatibility rules, and the requirement that mixed transcript versions include migration records. Current transcript version: 2. [See full specification for complete content.](/docs/HATS-GOVERNANCE-SPEC-v1.md)






## 12. Trust Domain Semantics




Defines tenant isolation (HATS-TD-001 through HATS-TD-006), signer trust domains, federation trust boundaries, and staging vs production separation. Infrastructure nodes with null tenant_id_hash may appear in any lineage. [See full specification for complete content.](/docs/HATS-GOVERNANCE-SPEC-v1.md)






## 13. Time Semantics




Defines timestamp source documentation, UTC requirement, monotonicity within signers, child-parent ordering, and clock skew tolerance of up to 5 seconds between federated nodes (HATS-TM-001 through HATS-TM-007). [See full specification for complete content.](/docs/HATS-GOVERNANCE-SPEC-v1.md)






## 14. Enforcement Semantics




Enforcement decisions are governed governance nodes (HATS-E-001, HATS-E-002). Defines 10 trigger types (PROFILE_DRIFT through CROSS_TENANT_CONTAMINATION) and 9 enforcement actions (BLOCK_EXECUTION through RAISE_CRITICAL_EVENT). [See full specification for complete content.](/docs/HATS-GOVERNANCE-SPEC-v1.md)






## 15. Enforcement Severity Levels




Six severity levels from INFO (0) through TERMINATED (5). Implementations must support at least levels 0, 1, and 4. Severity is monotonically increasing per incident (HATS-EL-001 through HATS-EL-003). [See full specification for complete content.](/docs/HATS-GOVERNANCE-SPEC-v1.md)






## 16. Evidence Chain Semantics




Evidence references cite governance nodes by canonical_hash. Defines verification status (VERIFIED, UNVERIFIED, PENDING), replay citations, and full governance ancestry traversal (HATS-EC-001 through HATS-EC-005). [See full specification for complete content.](/docs/HATS-GOVERNANCE-SPEC-v1.md)






## 17. Governance Capability Profiles




Five capability profiles: HATS-Core, HATS-Replay, HATS-Enforcement, HATS-Federation, and HATS-AI-Governance. Each includes its parent. Implementations must declare supported profiles (HATS-CP-001, HATS-CP-002). [See full specification for complete content.](/docs/HATS-GOVERNANCE-SPEC-v1.md)






## 18. Compliance Profile Semantics




Namespaced policy profiles for SEC, HIPAA, GLBA, Basel III, Solvency II, NYDFS, and DORA. Defines profile inheritance, strictest-requirement-prevails override semantics, and minimum replay retention (HATS-CMP-001 through HATS-CMP-005). [See full specification for complete content.](/docs/HATS-GOVERNANCE-SPEC-v1.md)






## 19. AI Governance Semantics




Extension for HATS v1; normative in v2. Reserves 5 AI node types (PromptRecord, ToolCallRecord, MemoryAccessRecord, InferenceRecord, AutonomousActionRecord) and reserved fields including model_id, prompt_hash, and confidence (HATS-AI-001, HATS-AI-002). [See full specification for complete content.](/docs/HATS-GOVERNANCE-SPEC-v1.md)






## 20. Replay Integrity Levels




Five integrity levels: STRUCTURALLY_VALID, CRYPTOGRAPHICALLY_VALID, FEDERATION_VALID, FULLY_REPLAYABLE, ENFORCEMENT_COMPLETE. Each implies all lower levels (HATS-RI-001, HATS-RI-002). [See full specification for complete content.](/docs/HATS-GOVERNANCE-SPEC-v1.md)






## 21. Reserved Extension Namespaces




Four reserved namespace prefixes: HATS: (normative), x-hats- (experimental), vendor.{name}. (vendor), experimental. (community). Extension node types must use IDs >= 100 (HATS-NS-001 through HATS-NS-003). [See full specification for complete content.](/docs/HATS-GOVERNANCE-SPEC-v1.md)






## 22. Compatibility Guarantees




Schema registry with versioned receipt schemas and minimum compatible versions. Defines 5 breaking changes (adding required fields, changing serialization order, changing domain separators, changing hash algorithms, removing required fields) requiring transcript version increment (HATS-COMPAT-001 through HATS-COMPAT-004). [See full specification for complete content.](/docs/HATS-GOVERNANCE-SPEC-v1.md)






## 23. Future-Proofing




Deprecated fields accepted for 2+ major versions. 12-month minimum migration window for transcript version changes. Algorithm replacement process with 6-month transition. Receipt schemas never deleted (HATS-FP-001 through HATS-FP-005). [See full specification for complete content.](/docs/HATS-GOVERNANCE-SPEC-v1.md)






## 24. Canonical Binary Encoding




Exact binary layouts for governance nodes and receipts ensuring cross-language hash parity. Any two conformant implementations given the same logical node must produce byte-identical encodings (HATS-BE-001 through HATS-BE-004). [See full specification for complete content.](/docs/HATS-GOVERNANCE-SPEC-v1.md)






## 25. Replay Witness Format




Compact signed proofs of governance state at a point in time. Four witness completeness levels: HASH_ONLY, ROOT_ATTESTED, MERKLE_PROVEN, FULL_REPLAY. Partial replay attestation requirements (HATS-RW-001 through HATS-RW-005). [See full specification for complete content.](/docs/HATS-GOVERNANCE-SPEC-v1.md)






## 26. Canonical Error Codes




26 verifier error codes under the HATS_ERR_ prefix covering cycle detection, orphan refs, hash mismatches, signature failures, cross-tenant contamination, clock anomalies, and more. Vendor extensions use HATS_ERR_VENDOR_{NAME}_ prefix (HATS-ERR-001 through HATS-ERR-003). [See full specification for complete content.](/docs/HATS-GOVERNANCE-SPEC-v1.md)






## 27. Governance Object Identity




The canonical_hash is permanent identity. Content changes create new nodes. Transcript migration preserves original hashes. No hash aliasing permitted (HATS-ID-001 through HATS-ID-007). [See full specification for complete content.](/docs/HATS-GOVERNANCE-SPEC-v1.md)






## 28. Federation Quorum Semantics




Quorum threshold and staleness window. Status reporting (HEALTHY, DEGRADED, FAILED). Equivocation detection and exclusion. Partition-safe replay and reconciliation on rejoin (HATS-FQ-001 through HATS-FQ-009). [See full specification for complete content.](/docs/HATS-GOVERNANCE-SPEC-v1.md)






## 29. AI Agent Lineage Reservations




10 reserved AI node types (IDs 101-110): PromptNode, ToolCallNode, RetrievalNode, MemoryMutationNode, InferenceNode, AutonomousActionNode, HumanApprovalNode, EscalationNode, MemoryAccessNode, ConfidenceGateNode. Cross-tenant memory access must be detectable (HATS-AIR-001 through HATS-AIR-004). [See full specification for complete content.](/docs/HATS-GOVERNANCE-SPEC-v1.md)






## 30. Graph Compression Semantics




Five compression modes (NONE required, 4 reserved: CHECKPOINT_FOLDED, MERKLE_PRUNED, RECURSIVE_ACCUMULATED, PROOF_AGGREGATED). Compressed graphs must include decompression witnesses and preserve logical root hash (HATS-GC-001 through HATS-GC-004). [See full specification for complete content.](/docs/HATS-GOVERNANCE-SPEC-v1.md)






## 31. Signed Spec Releases




Release artifacts include spec document, SHA3-256 hash, ML-DSA-65 signature, changelog, compatibility statement, migration requirements, and test vector updates. Semantic versioning. Signed releases available for 10+ years (HATS-SR-001 through HATS-SR-004). [See full specification for complete content.](/docs/HATS-GOVERNANCE-SPEC-v1.md)








## A. Requirement Index




Complete index of all 147 normative requirements across 31 sections, plus 26 error codes and 10 reserved AI node types. [See full specification for complete content.](/docs/HATS-GOVERNANCE-SPEC-v1.md)






## B. Cryptographic Profile Registry




Registry of 4 cryptographic profiles: PQ-SHA3-256-v1 (required), BLAKE3-v1, STARK-POSEIDON-v1, and HYBRID-v1 (optional). [See full specification for complete content.](/docs/HATS-GOVERNANCE-SPEC-v1.md)






## C. Canonical Error Code Registry




All 26 HATS_ERR_ codes with section references and severity classifications (FATAL, ERROR, WARNING). [See full specification for complete content.](/docs/HATS-GOVERNANCE-SPEC-v1.md)






## D. Replay Determinism Test Corpus




26 planned test vectors across 7 categories: valid graph replay, corrupted graph detection, transcript migration, federation split, cross-language parity, AI governance lineage, and compression roundtrip. Published at `https://hats.h33.ai/test-vectors/v1/`. [See full specification for complete content.](/docs/HATS-GOVERNANCE-SPEC-v1.md)






## E. Binary Encoding Examples




Worked examples of GovernanceNode encoding, string encoding, and the critical distinction between empty string encoding (4 zero bytes) and absent optional encoding (1 zero byte). [See full specification for complete content.](/docs/HATS-GOVERNANCE-SPEC-v1.md)






## F. Glossary




| Term | Definition |


| **Governance Graph** | Directed acyclic graph of governance nodes and their parent references |

| **Governance Node** | A single attestation in the governance graph, identified by its canonical hash |

| **Receipt** | A signed record of a governance decision, containing a commitment hash and PQ signature |

| **Replay Frame** | Deterministic snapshot of governance state at a point in time |

| **Replay Diff** | Computed delta between two replay frames |

| **Replay Witness** | Compact signed proof that a specific governance state existed at a specific time |

| **Canonical Serialization** | Deterministic byte encoding rules ensuring identical hashes across implementations |

| **Transcript Version** | Protocol version governing serialization format and verification rules |

| **Trust Domain** | Operational boundary defining which signers have authority |

| **Capability Profile** | Subset of HATS requirements an implementation claims to support |

| **Cryptographic Profile** | Configuration specifying hash function and signature algorithm |

| **Evidence Chain** | Ordered sequence of governance node references substantiating an explanation |

| **Equivocation** | A federation node submitting conflicting checkpoints for the same time window |

| **Quorum** | Minimum number of federation nodes required for valid aggregation |

| **Compression Witness** | Proof that a compressed graph represents the same logical content as the uncompressed original |

| **Lineage** | The chain of parent references from a node back to the governance root |








            HATS Governance Specification v1.0 — H33.ai, Inc.

            Reference Implementation: [github.com/H33ai-postquantum](https://github.com/H33ai-postquantum)

            Test Vectors: [hats.h33.ai/test-vectors/v1/](https://hats.h33.ai/test-vectors/v1/)

---

*End of HATS Governance Specification v1.0 extract.*