HATS is a publicly available technical conformance standard for continuous AI trustworthiness. This page defines the precise boundary between what HATS verification proves and what it leaves to the producing system. Every guarantee is testable. Every limitation is stated.
Each guarantee below is enforced by the HATS verification pipeline and validated against canonical test vectors. If a conforming implementation cannot reproduce the guarantee, it is non-conformant.
Same inputs produce identical frame hashes. Given the same governance payload, domain separator, and serialization parameters, any conforming verifier will compute the same canonical replay frame — byte-for-byte, every time, on any platform.
Any tampering is detectable. Each governance frame includes a SHA3-256 hash of its predecessor. Modifying, reordering, or omitting any frame in the chain breaks the hash linkage, and any verifier will reject the bundle.
Every attestation bundle carries post-quantum signatures from three independent hardness families: ML-DSA-65 (lattice), FALCON-512 (NTRU lattice), and SLH-DSA-SHA2-128f (stateless hash). A bundle is valid only if all three verify.
Any party can verify without trusting H33. The verification algorithm, serialization rules, and test vectors are public. No API key, no token, no callback to H33 infrastructure is required. Verification is a pure function of the bundle.
Every governance node traces to a prior decision. The directed acyclic graph of governance frames is fully traversable. There are no orphan nodes, no dangling references, and no cycles. Lineage is verified structurally, not by convention.
Bit-identical across implementations. NFC Unicode normalization, little-endian byte ordering, length-prefixed fields, and deterministic map traversal (BTreeMap, lexicographic on 32-byte keys) ensure that serialization is never ambiguous.
Verification contract: If you have a HATS bundle and access to the public verification algorithm, you can independently confirm every guarantee above. No trust delegation. No phone-home. No expiration.
HATS is precise about its scope. The following are explicitly outside the verification boundary. Claiming otherwise would undermine the standard's integrity.
HATS attests what happened, not whether it was right. A governance decision can be fully HATS-conformant and still be a bad decision. The standard verifies the integrity of the record, not the wisdom of the action.
HATS does not guarantee that the producing system is available, responsive, or operational. Availability is an infrastructure concern. HATS is a verification concern. They are orthogonal.
HATS verifies the cryptographic integrity of governance bundles. Protecting the confidentiality of governance data is the producing system's responsibility. HATS does not encrypt, redact, or control access.
HATS verifies what is in the bundle. It cannot prove that nothing was omitted. If a producing system fails to record a governance event, HATS has no mechanism to detect the absence. Completeness is a system-level guarantee, not a verification-level one.
HATS provides evidence, not legal opinions. A HATS-conformant bundle may support a compliance argument, but HATS itself does not assert compliance with any regulation, standard, or contractual obligation.
Design principle: Every non-guarantee above is intentional. Expanding HATS to cover business logic, availability, privacy, completeness, or regulatory compliance would require trust assumptions that undermine independent verification.
HATS guarantees hold under the following assumptions. If any assumption is violated, the guarantees may not hold. Each assumption is grounded in well-studied cryptographic or protocol primitives.
Chain integrity depends on the computational infeasibility of finding an input that hashes to a target SHA3-256 digest. This is the same assumption underlying all modern hash-based integrity schemes. SHA3-256 has no known preimage attacks and a security margin of 256 bits.
Signature validity depends on the existential unforgeability of ML-DSA-65 (Module-LWE), FALCON-512 (NTRU lattice), and SLH-DSA-SHA2-128f (hash-based). An attacker must break all three independent hardness families simultaneously to forge an attestation. This is the three-hardness-assumption design.
For federated deployments where multiple nodes produce governance frames, HATS assumes that a majority of federation nodes are honest. A majority-dishonest federation can produce internally consistent but fraudulent chains. This assumption applies only to federated topologies; single-node deployments do not require it.
Within a trust domain, timestamps must be monotonically non-decreasing. HATS does not require globally synchronized clocks, but it does require that no frame within a single chain has a timestamp earlier than its predecessor. Monotonicity is enforced at verification time.
| Assumption | Type | Failure Mode | Mitigation |
|---|---|---|---|
| SHA3-256 preimage resistance | Cryptographic |
Chain integrity compromised; forged frames accepted | Monitor NIST hash function status; migration path to SHA3-512 defined |
| ML-DSA-65 / FALCON-512 / SLH-DSA-SHA2-128f unforgeability | Cryptographic |
Forged attestation signatures accepted | Three independent hardness families; breaking one does not break the bundle |
| Honest-majority federation | Protocol |
Internally consistent fraudulent chains | Federation audit logs; cross-domain verification; single-node mode as fallback |
| Monotonic timestamps | Protocol |
Temporal ordering violations; replay confusion | Verifier rejects non-monotonic chains; NTP/PTP synchronization recommended |
Deterministic replay is the foundation of HATS verification. The following serialization and traversal rules must be satisfied for replay-grade attestation to hold.
| Requirement | Specification | Rationale |
|---|---|---|
| Canonical serialization | NFC normalization, little-endian, length-prefixed |
Eliminates platform-dependent encoding differences |
| Domain separators | Must match exactly — byte-for-byte | Prevents cross-domain replay and context confusion |
| Optional fields | None hashes to the same value as before the field existed |
Forward compatibility without breaking existing frame hashes |
| Graph traversal | BTreeMap ordering (lexicographic on 32-byte keys) |
Deterministic iteration order across all implementations |
Implementation note: These rules are not recommendations. A verifier that uses HashMap ordering, UTF-8 instead of NFC, or big-endian encoding will produce different frame hashes and fail against the canonical test vectors. There is exactly one correct serialization for every input.
// Canonical frame serialization (pseudocode)
fn serialize_frame(frame: &GovernanceFrame) -> Vec<u8> {
let mut buf = Vec::new();
// 1. Domain separator (exact bytes, no trailing null)
buf.extend(frame.domain_separator.as_bytes());
// 2. NFC-normalized payload
let payload_nfc = unicode_nfc(frame.payload);
buf.extend(&(payload_nfc.len() as u32).to_le_bytes()); // length-prefixed
buf.extend(payload_nfc.as_bytes());
// 3. Optional fields: None -> zero-length prefix
match &frame.metadata {
Some(m) => {
buf.extend(&(m.len() as u32).to_le_bytes());
buf.extend(m.as_bytes());
}
None => buf.extend(&0u32.to_le_bytes()), // hash-stable
}
// 4. Child references: BTreeMap (lexicographic on 32-byte key)
for (key, hash) in &frame.children { // BTreeMap guarantees order
buf.extend(key); // 32 bytes
buf.extend(hash); // 32 bytes
}
buf
}The strongest claim a verification standard can make is: anyone can check our work. We make that claim, and we back it with published test vectors and an open challenge.
| Category | Vectors | Tests |
|---|---|---|
| Chain construction & linking | Frame hash chaining, predecessor validation, genesis frame | 6 |
| PQ signature verification | ML-DSA-65, FALCON-512, SLH-DSA-SHA2-128f — valid and invalid | 6 |
| Serialization edge cases | NFC normalization, empty payloads, maximum-length fields | 4 |
| Optional field handling | None values, forward compatibility, hash stability | 3 |
| Graph traversal ordering | BTreeMap key ordering, multi-child frames, deep DAGs | 4 |
| Rejection semantics | Tampered frames, non-monotonic timestamps, bad signatures | 3 |
Standing commitment: If an independent implementer reproduces all 26 vectors and finds a discrepancy, we will either fix the reference implementation or publish a technical explanation of why the vector is correct. No discrepancy will be left unresolved.
HATS verification requires zero trust in H33. Read the spec, download the vectors, and verify independently.