HATS Governance Specification

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

12. Trust Domain Semantics

13. Time Semantics

14. Enforcement Semantics

15. Enforcement Severity Levels

16. Evidence Chain Semantics

17. Governance Capability Profiles

18. Compliance Profile Semantics

19. AI Governance Semantics

20. Replay Integrity Levels

21. Reserved Extension Namespaces

22. Compatibility Guarantees

23. Future-Proofing

24. Canonical Binary Encoding

25. Replay Witness Format

26. Canonical Error Codes

27. Governance Object Identity

28. Federation Quorum Semantics

29. AI Agent Lineage Reservations

30. Graph Compression Semantics

31. Signed Spec Releases

A. Requirement Index

B. Cryptographic Profile Registry

C. Canonical Error Code Registry

D. Replay Determinism Test Corpus

E. Binary Encoding Examples

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