HATS Attestation Schema — v1.0.0

1. Overview

A HATS attestation payload is the primary structured record produced by the HATS (H33 Attestation & Trust Standard) protocol. It encodes a complete governance graph, the cryptographic root hash binding that graph, the set of post-quantum signers that attested it, and the verification status at time of production.

This schema defines the JSON representation of that payload. Producers (attestation engines, governance pipelines) MUST emit payloads conforming to this schema. Consumers (verifiers, auditors, downstream systems) SHOULD validate incoming payloads against this schema before processing.

The payload is designed for machine consumption. It contains no presentation-layer fields. Human-readable representations are derived from this payload, never the reverse.

2. Definitions

Attestation Payload

A JSON object conforming to this schema that represents a single HATS attestation event. Contains the governance graph, root hash, signer set, and verification status.

Governance Graph

A directed acyclic graph (DAG) of governance nodes connected by edges. Each node represents a discrete governance decision, control evaluation, or policy checkpoint. Each edge represents a causal or dependency relationship.

Root Hash

A SHA3-256 digest computed over the canonical serialization of the governance graph. Serves as the binding commitment between the graph structure and any external anchors (chain, H33-74 receipt).

Signer Set

The set of post-quantum signature algorithms used to attest the payload. A conformant signer set includes ML-DSA-65, FALCON-512, and SLH-DSA-SHA2-128f-simple.

Verification Status

An enumeration indicating the result of the most recent verification pass over the payload. One of: INTACT, PARTIAL, DIVERGENT, BROKEN.

Proof Profile

A string identifier specifying the cryptographic profile under which the attestation was produced. Determines hash function, signature algorithms, and serialization rules.

3. JSON Schema Definition

The following is the formal JSON Schema (draft 2020-12) for a HATS attestation payload.

4. Field Definitions

Field	Type	Required	Description	Constraints
schema_version	string	Yes	Schema version identifier. Fixed to "1.0.0" for this version.	Constant: "1.0.0"
transcript_version	integer	Yes	Monotonically increasing version for this governance chain. Each new attestation in the same chain increments this value.	Minimum: 1
governance_graph	object	Yes	The governance graph containing nodes and edges.	Must contain nodes (min 1) and edges arrays.
root_hash	string	Yes	SHA3-256 hex digest of the canonical governance graph serialization.	Exactly 64 lowercase hex characters.
timestamp	string	Yes	ISO 8601 timestamp of when the attestation was produced.	Must include timezone offset or Z.
signer_set	object	Yes	The three PQ signature entries that signed this attestation.	Must contain ml_dsa, falcon, slh_dsa.
verification_status	string	Yes	Result of the most recent verification pass.	Enum: INTACT, PARTIAL, DIVERGENT, BROKEN
proof_profile	string	Yes	Cryptographic proof profile identifier (e.g., "HATS-PROFILE-PQ-SHA3-256-v1").	Non-empty string.
metadata	object	No	Optional metadata. Not covered by root_hash. Intended for non-cryptographic annotations.	Schema-free object.

5. Governance Node Schema

Each node in the governance_graph.nodes array represents a discrete governance event. Nodes are identified by UUID and typed by their role in the governance DAG.

Field	Type	Required	Description
node_id	string (UUID)	Yes	Unique identifier for this node. UUID v4 format.
node_type	string (enum)	Yes	DECISION, CONTROL, POLICY, ATTESTATION, or CHECKPOINT.
hash	string (hex64)	Yes	SHA3-256 digest of this node's canonical content.
timestamp	string (ISO 8601)	Yes	When this governance event occurred.
payload	object	No	Node-specific payload. Structure varies by node_type.
parent_ids	array of UUIDs	No	IDs of parent nodes in the DAG. Empty or absent for root nodes.

5.1. Node Type Semantics

• DECISION — A governance decision made by a human or automated agent. The payload contains the decision rationale and outcome.
• CONTROL — A control evaluation result. The payload contains the control identifier, evaluation result (pass/fail), and evidence references.
• POLICY — A policy definition or update. The payload contains the policy document hash and version.
• ATTESTATION — A cryptographic attestation event. The payload contains the attested computation reference and H33-74 receipt identifier.
• CHECKPOINT — A periodic state checkpoint. The payload contains the cumulative state hash up to this point in the governance chain.

6. Governance Edge Schema

Each edge in the governance_graph.edges array represents a directed relationship between two nodes.

Field	Type	Required	Description
source	string (UUID)	Yes	The originating node ID. Must reference a valid node_id in the nodes array.
target	string (UUID)	Yes	The destination node ID. Must reference a valid node_id in the nodes array.
edge_type	string (enum)	Yes	DEPENDS_ON, CAUSES, ATTESTS, or SUPERSEDES.

6.1. Edge Type Semantics

• DEPENDS_ON — Target node is a dependency of source node. Source cannot be valid without target.
• CAUSES — Source node causally precedes target node in the governance sequence.
• ATTESTS — Source node cryptographically attests the content of target node.
• SUPERSEDES — Source node replaces target node. Target is deprecated but retained in the graph for auditability.

7. Cryptographic Assumptions

The HATS attestation payload relies on the following cryptographic primitives and their associated hardness assumptions:

• SHA3-256 (NIST FIPS 202) — Used for root_hash and individual node hash fields. Collision resistance assumed.
• ML-DSA-65 (NIST FIPS 204) — Module-Lattice Digital Signature Algorithm. Security relies on the hardness of MLWE.
• FALCON-512 (NIST PQC Round 3) — NTRU-lattice-based signature. Security relies on the hardness of NTRU lattice problems.
• SLH-DSA-SHA2-128f-simple (NIST FIPS 205) — Stateless Hash-Based Digital Signature Algorithm. Security relies only on the collision resistance of the underlying hash function.

An attacker must break all three independent hardness assumptions simultaneously to forge a valid signer set.

8. Canonical Valid Example

9. Canonical Invalid Example

The following payload is invalid for the annotated reasons.

A conformant validator MUST reject this payload with errors for each annotated violation.

10. Verification Flow

To verify a HATS attestation payload, a conformant verifier MUST perform the following steps in order:

1. Schema validation. Validate the payload against the JSON Schema defined in Section 3. Reject if validation fails.
2. Graph integrity. Verify that every source and target in edges references a valid node_id in nodes. Verify no cycles exist (the graph is a DAG).
3. Node hash verification. For each node, recompute SHA3-256(canonical_node_bytes) and compare to the node's hash field. Any mismatch means the node has been tampered with.
4. Root hash verification. Compute the root hash over the canonical graph serialization. Compare to root_hash. Mismatch indicates graph-level tampering.
5. Signature verification. Verify all three signatures in signer_set against the root_hash. All three MUST pass. If any signature fails, the attestation is BROKEN.
6. Temporal validation. Verify that all node timestamps are earlier than or equal to the payload timestamp. Verify transcript_version is greater than any previously seen version for this governance chain.
7. Set verification_status. Based on the results: INTACT (all pass), PARTIAL (graph valid, signatures incomplete), DIVERGENT (root hash mismatch), BROKEN (signature failure or structural corruption).

11. Failure Modes

Failure Code	Description	Severity	Recovery
SCHEMA_INVALID	Payload does not conform to the JSON Schema. Missing required fields, wrong types, or constraint violations.	Fatal	Fix payload at producer.
ROOT_HASH_MISMATCH	Recomputed root hash does not match root_hash field. Graph has been modified after signing.	Fatal	Discard payload. Request re-attestation.
NODE_HASH_MISMATCH	One or more node hashes do not match recomputed values. Individual nodes have been tampered with.	Fatal	Identify affected nodes. Request re-attestation.
SIGNATURE_INVALID	One or more signatures in signer_set fail verification.	Fatal	Do not trust. Investigate key compromise.
SIGNATURE_MISSING	Fewer than three signature families present in signer_set.	Fatal	Producer must sign with all three families.
GRAPH_CYCLE	The governance graph contains a cycle. DAG constraint violated.	Fatal	Fix graph at producer.
DANGLING_EDGE	An edge references a node_id not present in nodes.	Fatal	Include missing node or remove edge.
TIMESTAMP_FUTURE	Payload timestamp is in the future relative to verifier's clock (beyond allowed skew).	Warning	Check clock synchronization.
VERSION_REGRESSION	transcript_version is less than or equal to a previously verified version for this chain.	Fatal	Possible replay attack. Reject.

12. Conformance Requirements

12.1. Producers

An implementation that produces HATS attestation payloads MUST:

1. Emit payloads that pass validation against the JSON Schema in Section 3.
2. Compute root_hash as SHA3-256 over the canonical graph serialization (deterministic field ordering, UTF-8 encoding, no whitespace).
3. Compute each node hash as SHA3-256 over the node's canonical serialization (same rules).
4. Sign the root_hash with all three PQ signature families and populate signer_set accordingly.
5. Increment transcript_version monotonically for each new attestation in the same governance chain.
6. Set verification_status to "INTACT" at time of production (the producer has just verified its own output).

12.2. Consumers

An implementation that consumes HATS attestation payloads MUST:

1. Validate the payload against the JSON Schema before processing any field.
2. Verify all three signatures. If any signature fails, set local verification_status to "BROKEN" and halt processing.
3. Verify root_hash by recomputation. If mismatch, set verification_status to "DIVERGENT".
4. Reject payloads with transcript_version less than or equal to the last verified version (replay protection).

Consumers SHOULD verify individual node hashes. Consumers MAY process metadata for non-critical purposes but MUST NOT treat metadata as cryptographically bound.