PricingDemo
Log InGet API Key

Governance Proof Model — Specification v1.0.0

Version: 1.0.0
Status: Production
Date: 2026-05-22
Editor: Eric Beans, H33.ai, Inc.
License: Proprietary (Patent Pending)
Canonical URL: https://h33.ai/specifications/governance-proof/

1. Abstract

This document specifies the governance proof model: a directed acyclic graph (DAG) of attested governance decisions that supports deterministic replay, independent verification, and integrity classification. A governance proof captures the full provenance of a governance outcome -- which policies applied, which events triggered evaluation, which routes were selected, and what the result was -- in a structure that any independent verifier can reconstruct from the graph state and a timestamp.

The governance proof model is the foundation for replayable governance in the H33 system. It enables regulators, auditors, insurers, and AI systems to independently reconstruct the trust state that existed at any point in time, verify that the reconstruction is identical to the original, and classify the integrity of the result.

2. Status of This Document

This specification is at Production status. The graph structure, node types, root hash computation, replay semantics, and integrity classification defined herein are frozen per the H33 Protocol Stability policy.

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.

3. Definitions

Governance Graph
A directed acyclic graph (DAG) whose nodes represent governance decisions and whose edges represent dependency relationships between those decisions. Each graph belongs to a single tenant and covers a defined time range.
Governance Node
A vertex in the governance graph. Each node has a type (one of 8 defined types), a unique identifier, a content hash, an attestation receipt reference, and zero or more parent edges.
Governance Edge
A directed edge from a source node to a target node, indicating that the target depends on the source. Edges are typed to indicate the nature of the dependency.
Root Hash
A Merkle root computed over all nodes in the governance graph in BTreeMap (lexicographic) order by node ID. The root hash uniquely identifies a specific graph state.
Replay Frame
A snapshot of reconstructed governance state at a specific timestamp, including the traversal path, the reconstructed decision outcomes, and the integrity classification of the replay.
Integrity Classification
A four-level assessment of the fidelity of a governance replay: INTACT, PARTIAL, DIVERGENT, or BROKEN. See Section 9.

4. Graph Structure

A governance graph is a DAG where nodes represent discrete governance decisions and edges represent dependencies between them. The graph MUST NOT contain cycles. Implementations MUST validate acyclicity when constructing or importing a governance graph.

4.1. Node Types

Eight node types are defined. Implementations MUST support all eight types. Each node type corresponds to a specific governance primitive.

Type CodeNameDescription
0x01RouteA cryptographic routing decision. Determines which computational path (FHE engine, signature family, chain target) was selected for a request. A Route node references the policy that governed the selection.
0x02PolicyA governance policy definition. Contains the policy hash, effective timestamp range, version, and the set of rules that the policy enforces. Policy nodes are leaf nodes (no outgoing dependency edges).
0x03EventAn external event that triggered a governance evaluation. Captures the event type, source, timestamp, and input data commitment. Events are entry points into the graph.
0x04ResultThe outcome of a governance evaluation. Contains the output commitment, the computation type, and references to the Route and Policy nodes that produced it. Every governance evaluation terminates in exactly one Result node.
0x05StateTransitionA change in governance state caused by a Result. Captures the pre-state hash, post-state hash, and the delta that was applied. StateTransition nodes enable forward replay.
0x06CheckpointA periodic integrity checkpoint. Computes and records the root hash of the graph up to that point. Checkpoints enable efficient partial verification without traversing the entire graph.
0x07FederationA cross-tenant governance reference. Links a governance decision in one tenant's graph to a decision in another tenant's graph. Federation nodes carry the remote tenant ID, remote node ID, and a remote root hash for cross-graph verification.
0x08AnchorAn on-chain anchor point. Records the chain target, transaction ID, block height, and the root hash that was anchored. Anchor nodes bind the governance graph to a public ledger timestamp.

4.2. Edge Types

Edge TypeSourceTargetDescription
TRIGGERED_BYRoute, ResultEventThe target event triggered the source evaluation.
GOVERNED_BYRoute, ResultPolicyThe target policy governed the source decision.
ROUTED_THROUGHResultRouteThe result was produced via the target routing decision.
PRODUCESResultStateTransitionThe result produced the target state transition.
CHECKPOINTSCheckpointAnyThe checkpoint covers the target node's state.
FEDERATESFederationAny (remote)Cross-tenant dependency.
ANCHORSAnchorCheckpointThe anchor records the checkpoint's root hash on-chain.

5. Node Schema

All nodes share a common base schema. Type-specific fields extend the base.

5.1. Base Fields (All Node Types)

FieldTypeDescription
node_idstring (UUID v4)Unique identifier for this node.
node_typeuint8One of the 8 defined type codes (Section 4.1).
tenant_idstring (UUID v4)Owning tenant.
timestampstring (ISO 8601)Time the node was created. UTC with Z suffix.
content_hashstring (hex, 64 chars)SHA3-256 digest of the node's type-specific content (see Section 5.2-5.9).
receipt_idstring (UUID v4)Reference to the attestation receipt that attests this node.
parent_edgesarray of objectsEdges to parent nodes. Each element has edge_type (string) and target_node_id (UUID v4).

5.2. Route Node

Additional fields: selected_engine (string), selected_chain (string), policy_version (uint32), routing_criteria (object).

5.3. Policy Node

Additional fields: policy_id (UUID v4), policy_version (uint32), effective_from (ISO 8601), effective_until (ISO 8601 or null for indefinite), rules_hash (hex, 64 chars).

5.4. Event Node

Additional fields: event_type (string), source (string), input_commitment (hex, 64 chars).

5.5. Result Node

Additional fields: computation_type (string, per H33-74 Section 5), output_commitment (hex, 64 chars), success (boolean).

5.6. StateTransition Node

Additional fields: pre_state_hash (hex, 64 chars), post_state_hash (hex, 64 chars), delta_hash (hex, 64 chars).

5.7. Checkpoint Node

Additional fields: root_hash (hex, 64 chars), node_count (uint64), coverage_from (ISO 8601), coverage_until (ISO 8601).

5.8. Federation Node

Additional fields: remote_tenant_id (UUID v4), remote_node_id (UUID v4), remote_root_hash (hex, 64 chars).

5.9. Anchor Node

Additional fields: chain_target (string: "bitcoin", "solana", "ethereum"), transaction_id (string), block_height (uint64), anchored_root_hash (hex, 64 chars).

6. Root Hash Computation

The root hash of a governance graph is computed as a Merkle root over all nodes. The computation proceeds as follows:

  1. Collect. Gather all nodes in the graph.
  2. Sort. Sort nodes lexicographically by node_id (UTF-8 string comparison). This is equivalent to BTreeMap ordering in Rust.
  3. Leaf hashes. For each node, compute the leaf hash: SHA3-256("H33:gov:v1:leaf:" || node_id_bytes || content_hash_bytes). The domain separator is the UTF-8 encoding of H33:gov:v1:leaf: (17 bytes).
  4. Merkle tree. Construct a binary Merkle tree over the leaf hashes. If the number of leaves is not a power of two, duplicate the last leaf to pad. Internal nodes are computed as: SHA3-256("H33:gov:v1:node:" || left_hash || right_hash).
  5. Root. The root of the Merkle tree is the governance graph root hash.

The deterministic ordering (BTreeMap by node_id) ensures that any implementation computing the root hash over the same set of nodes will produce the identical result, regardless of the order in which nodes were inserted.

Pseudocode: Root hash computation
fn compute_root_hash(nodes: &[GovernanceNode]) -> [u8; 32] { let mut sorted = nodes.to_vec(); sorted.sort_by(|a, b| a.node_id.cmp(&b.node_id)); let leaves: Vec<[u8; 32]> = sorted.iter().map(|n| { sha3_256(b"H33:gov:v1:leaf:" || n.node_id.as_bytes() || n.content_hash) }).collect(); merkle_root(leaves, b"H33:gov:v1:node:") }

7. Replay Semantics

Deterministic replay is the reconstruction of governance state at a specified timestamp by traversing the governance graph. Replay is the mechanism by which independent verifiers confirm that a governance outcome was produced correctly.

7.1. Replay Invariants

  1. Determinism. Given the same graph and the same replay timestamp, any conformant verifier MUST produce the identical replay frame.
  2. Completeness. A replay MUST traverse all nodes with timestamp <= replay_timestamp. Nodes with timestamps after the replay timestamp MUST be excluded.
  3. Ordering. Nodes are processed in topological order (dependencies before dependents). Where topological order is ambiguous (no dependency between two nodes), nodes are processed in lexicographic order by node_id.
  4. Edge validation. For each edge traversed, the verifier MUST confirm that the target node's attestation receipt is valid (per Attestation Receipt Schema).
  5. State accumulation. The replay accumulates a state object by applying StateTransition nodes in order. The final state MUST match the post_state_hash of the last StateTransition at or before the replay timestamp.

7.2. Replay Procedure

  1. Select all nodes where timestamp <= replay_timestamp.
  2. Validate the subgraph is a valid DAG (no cycles).
  3. Compute a topological sort of the selected nodes.
  4. For each node in topological order:
    • Verify the node's attestation receipt.
    • Verify all parent edges: each target_node_id exists in the selected set and has a valid attestation.
    • If the node is a StateTransition, apply the transition to the accumulated state.
    • Record the node in the traversal path.
  5. Compute the root hash of the selected subgraph.
  6. Classify the replay integrity (Section 9).
  7. Produce the replay frame (Section 8).
Example: Execute a governance replay
$ h33 replay-governance \ --tenant a1b2c3d4-e5f6-4789-abcd-ef0123456789 \ --timestamp 2026-05-18T09:14:22Z \ --verify-receipts \ --output replay-frame.json Nodes selected: 347 / 412 (before cutoff) Topological sort: OK (DAG validated) Receipts verified: 347 / 347 State transitions: 89 applied Root hash: b7e4f2a1... Integrity: INTACT Replay frame: written to replay-frame.json

8. Replay Frame

A replay frame is the output of a governance replay. It is a self-contained JSON document that captures the reconstructed state, the traversal path, and the integrity classification.

FieldTypeDescription
frame_idstring (UUID v4)Unique identifier for this replay frame.
tenant_idstring (UUID v4)The tenant whose governance was replayed.
replay_timestampstring (ISO 8601)The timestamp at which replay was performed.
root_hashstring (hex, 64 chars)The Merkle root of the subgraph selected for replay.
node_countintegerNumber of nodes included in the replay.
state_hashstring (hex, 64 chars)SHA3-256 of the final accumulated governance state.
traversal_patharray of strings (UUID v4)Ordered list of node IDs in the order they were processed.
integritystringOne of: "INTACT", "PARTIAL", "DIVERGENT", "BROKEN".
divergence_detailsarray of objects (or null)Present only when integrity is not "INTACT". Each object identifies the divergent node and the nature of the divergence.
generated_atstring (ISO 8601)When the replay frame was generated.

9. Integrity Classification Levels

Every replay produces an integrity classification. Conformant verifiers MUST compute and report the classification exactly as defined here.

LevelCodeCriteriaMeaning
INTACT 0 All nodes verified, all edges valid, all receipts valid, state hash matches, root hash matches any existing checkpoint. The governance state at the replay timestamp is fully reconstructible and matches the original. No divergence detected.
PARTIAL 1 All verifiable nodes passed, but one or more nodes could not be verified because their attestation receipts were unavailable (e.g., RCPT_ERR_CHAIN_FETCH). The governance state is likely correct but cannot be fully confirmed. The unverifiable nodes are identified in divergence_details.
DIVERGENT 2 One or more nodes produce a different content hash or state transition output than expected. The graph structure is intact (no missing nodes or broken edges), but the data has changed. The governance state can be reconstructed but does not match the original. This indicates data mutation after attestation.
BROKEN 3 The graph structure itself is invalid: missing nodes, broken edges, cycle detected, or signature verification failure. The governance state cannot be reconstructed. The graph has been corrupted or tampered with.

An integrity classification of DIVERGENT or BROKEN is a non-repudiable finding. The replay frame, including the divergence_details, serves as evidence of governance failure. Conformant systems MUST retain replay frames with DIVERGENT or BROKEN classification for the full retention period defined by the applicable HATS compliance tier.

10. Verification Algorithm

An independent verifier MUST execute the following steps to verify a governance graph or replay frame.

10.1. Graph Verification

  1. Acyclicity. Verify the graph is a DAG. Error: GOV_ERR_CYCLE.
  2. Node type validity. Verify all node_type values are in the range 0x01-0x08. Error: GOV_ERR_NODE_TYPE.
  3. Edge validity. Verify all edges reference existing nodes and conform to the allowed source/target type pairs in Section 4.2. Error: GOV_ERR_EDGE.
  4. Content hash. For each node, recompute the content_hash from the type-specific fields. Compare. Error: GOV_ERR_CONTENT_HASH.
  5. Receipt validation. For each node, fetch and verify the referenced attestation receipt per Attestation Receipt Schema, Section 8. Error: GOV_ERR_RECEIPT.
  6. Root hash. Compute the root hash per Section 6. Compare to any Checkpoint nodes. Error: GOV_ERR_ROOT_HASH.
  7. Anchor verification. For each Anchor node, verify the anchored_root_hash exists on the indicated chain at the indicated block height. Error: GOV_ERR_ANCHOR.

10.2. Replay Frame Verification

  1. Verify the root_hash in the frame matches a recomputed root hash over the claimed traversal_path nodes.
  2. Verify the state_hash by replaying all StateTransition nodes in the traversal order.
  3. Verify the integrity classification is correct given the results of steps 1-2 and any divergence_details.

11. Failure Modes

Error CodeConditionSeverity
GOV_ERR_CYCLEGraph contains a cycleCritical
GOV_ERR_NODE_TYPEUnknown or invalid node typeCritical
GOV_ERR_EDGEEdge references nonexistent node or invalid source/target pairCritical
GOV_ERR_CONTENT_HASHRecomputed content hash does not match node's content_hashCritical
GOV_ERR_RECEIPTReferenced attestation receipt failed verificationCritical
GOV_ERR_RECEIPT_FETCHAttestation receipt could not be retrievedWarning
GOV_ERR_ROOT_HASHComputed root hash does not match Checkpoint nodeCritical
GOV_ERR_ANCHOROn-chain anchor not found or hash mismatchWarning
GOV_ERR_REPLAY_STATEAccumulated state hash does not match expected post_state_hashCritical
GOV_ERR_REPLAY_ORDERTraversal path does not match topological orderCritical
GOV_ERR_FEDERATIONRemote tenant's root hash does not match remote_root_hashCritical
GOV_ERR_TIMESTAMPNode timestamp is in the future beyond tolerance or violates causal orderingCritical

12. Conformance Requirements

An implementation claiming conformance to this specification MUST:

  1. Support all 8 node types and all 7 edge types defined in Section 4.
  2. Validate graph acyclicity upon construction and upon import.
  3. Compute root hashes per Section 6 using SHA3-256 with the specified domain separators.
  4. Implement the replay procedure in Section 7.2 producing deterministic replay frames.
  5. Compute integrity classifications per Section 9 exactly as defined.
  6. Implement the full verification algorithm in Section 10 including all 12 error codes in Section 11.
  7. Produce structured error output including the error code and severity for each failure.
  8. Retain replay frames with DIVERGENT or BROKEN classification for the applicable retention period.
  9. Process nodes in topological order during replay, using lexicographic node_id order to break ties.
  10. Reference valid attestation receipts (per Attestation Receipt Schema) for every governance node.

Implementations SHOULD:

  1. Support Federation nodes for cross-tenant governance verification.
  2. Support Anchor nodes for on-chain binding of governance graph state.
  3. Generate periodic Checkpoint nodes to enable efficient partial verification.
  4. Participate in the HATS Conformance Suite governance replay test vectors.

13. Relationship to HATS

The governance proof model implements the requirements of HATS Standard Section 4 ("Continuous Governance Verification"). Specifically:

HATS is a publicly available technical conformance standard for continuous AI trustworthiness; certification under HATS provides independently verifiable evidence that a system satisfies the standard's defined controls.

14. Changelog

VersionDateChanges
1.0.02026-05-22Initial publication. 8 node types, 7 edge types, root hash algorithm, replay semantics, integrity classification, and verification algorithm defined. 12 error codes enumerated. HATS Section 4 mapping documented.

15. References

15.1. Normative References

15.2. Informative References