HATS Record v1

§1Abstract

This specification defines HATS Record v1, the canonical artifact produced by an implementation of the H33 AI Trust Standard. A HATS record is a deterministically verifiable, post-quantum signed envelope that binds eight layers of the H33 cryptographic stack — from the 74-byte substrate primitive at the base, through upstream cryptographic engines and orchestration patents, to chain anchors and tenant bindings at the top — into a single artifact that any independent verifier can replay years later without trusting the issuer.

The record is chain-portable, engine-portable, and vendor-portable. It is signed under three independent post-quantum signature families. It can be anchored to multiple chains simultaneously. It can be replayed deterministically against a published canonical replay frame. Its verification answer is identical across any conformant implementation.

This document is normative for HATS implementations and is the authoritative source for the layer schemas, encoding rules, and verification protocol referenced elsewhere in the H33 documentation set.

§2Goals and non-goals

Goals

• Bind the full H33 stack into a single artifact whose verification answer is deterministic across independent implementations.
• Survive chain migrations, vendor changes, operator failure, and future cryptographic engine changes without re-issuance.
• Enable an auditor, regulator, or counterparty to verify the record using only the published specification and the open-source verifier — no trust in H33, no dependence on H33 infrastructure, no requirement that the original issuer remain online.
• Provide post-quantum verification guarantees against current and future cryptanalytic developments by using three independent NIST-standardized signature families in parallel.
• Maintain a clear public/proprietary boundary: verification artifacts and protocols are public; signing pipelines and computation engines may remain proprietary.

Non-goals

• This specification does not define the upstream cryptographic engines themselves (STARK, FHE, ZK-SNARK, biometric fusion). It defines how their outputs are bound into the record.
• This specification does not mandate a particular chain or set of chains for anchoring. Anchor presence is optional and pluralistic.
• This specification does not standardize the production-side signing pipeline. Implementations may sign through any path that produces a conformant envelope.
• This specification does not define record completeness semantics. A conformant verification of a HATS record asserts that the record is bit-identical to what was signed at issuance; it does not assert that the record represents every event the underlying case ever had.

§3Terminology

HATS record

The canonical artifact defined by this specification. The full eight-layer envelope.

Substrate

The 74-byte post-quantum signed receipt at the base of the stack. Layer 0.

Upstream engine

Any cryptographic engine that produces an output bound into the substrate. STARK, BFV/CKKS FHE, ML-DSA signing pipelines, biometric fusion, and conformance vector emitters are all upstream engines.

Canonical replay frame

The deterministic structure against which any independent verifier evaluates a record. The canonical replay frame is published as part of this specification and is the basis for verifier equivalence.

Independent verifier implementation

Any implementation of the verification protocol defined in §16 that produces the same per-check verdicts as the reference implementation on every record in the immutable conformance corpus.

Structured rejection semantics

Every verification outcome is typed. A PASS or FAIL is accompanied by a structured per-check verdict array. There are no untyped failures.

Replay-grade attestation

An attestation whose verification can be reproduced deterministically by an independent verifier at any future time using only the published artifact, the published specification, and the open-source verifier.

Deterministic conformance verification

The property that, given the same record and the same conformance vector, every independent verifier implementation produces the same per-check verdict.

Three-family PQ signature envelope

The signature wrapper used at every layer of the stack. Composed of an ML-DSA-65 signature, a FALCON-512 signature, and an SLH-DSA-128f signature, all over the same canonical payload.

Conformance corpus

The immutable set of canonical records and expected verdicts against which conformant implementations are validated.

Boundary

The public-versus-proprietary delineation defined in §21. The verification side of the protocol is fully public; the computation side may be proprietary.

Throughout this specification, the key words MUST, MUST NOT, SHOULD, and MAY are used per RFC 2119 semantics.

§4Layered architecture

A HATS record is composed of eight conceptual layers. Layers 0 through 2 are foundational and apply to every H33 artifact. Layer 3 is the HATS-specific envelope. Layers 4 through 7 are the operational, verification, and binding wrappers that turn a record into something a third party can replay.

Each layer is independently verifiable. A conformant verification proceeds layer-by-layer; a failure at any layer produces a structured rejection that names the layer, the field, and the check that failed.

§5Layer 0 — H33-74 substrate

Substrate invariants

1. The substrate MUST be exactly 74 bytes wire-format.
2. The substrate version MUST NOT be modified to extend the primitive. Extensions MUST bind via the off-chain verification_hash mechanism.
3. The commitment MUST be SHA3-256, not SHA-2 or BLAKE-family.
4. The substrate MUST be reproducible byte-for-byte given the same canonical payload and the same epoch key set.

§6Layer 1 — Upstream cryptographic engine

Upstream invariants

1. Every engine MUST publish a normative description of its inputs, outputs, and VK format.
2. Every engine MUST emit a determinism vector that allows an independent verifier to reproduce the public-input commitments deterministically.
3. An engine MAY change versions; every version change MUST produce a distinct engine_id. Records signed under different engine_ids are distinct records, never the same record under two interpretations.

§7Layer 2 — Q-Sign / Agent-Zero / CIP orchestration

§8Layer 3 — HATS record (AI-specific structured envelope)

§9Layer 4 — Replay bundle

§10Layer 5 — Signed verification report

§11Layer 6 — Chain anchor

Anchor invariants

1. The set of anchors on a record MAY change over time. A record that gains a new anchor remains the same record.
2. The absence of any anchor does NOT invalidate a record. The substrate is the source of truth.
3. An anchor's verification MUST be independent of H33 infrastructure. A verifier validates the anchor by querying the chain directly.

§12Layer 7 — Tenant and spine binding

§13Cross-cutting elements

The following elements appear at every layer above Layer 0 and are normative for conformant implementations.

PQ signature envelope

The three-family envelope (ML-DSA-65 + FALCON-512 + SLH-DSA-128f) wraps every layer's canonical payload. The envelope is independently verifiable per family; a record passes the envelope check if and only if all three families verify.

PQ epoch identifier

Every signed layer carries the epoch_id under which it was signed, sourced from h33-substrate-pubkeys-v1. Key rotation is monotonic; epochs are never reused.

Boundary marker

Every artifact carries a boundary marker declaring its public-versus-proprietary status, per BOUNDARY.md. Verification-side artifacts are public; computation-side artifacts may be proprietary.

Conformance corpus membership

If the record is a member of the immutable conformance corpus, its corpus identifier MUST be present and MUST resolve in the published corpus index.

Patent family reference

Every layer carries a reference to the patent family invariants document section that defines its behavior. Implementations MAY use this reference for compliance traceability.

§14Canonical encoding and hash discipline

Canonical JSON

All layers serialize to JSON in canonical form for hashing. Canonical form requires:

1. Object keys sorted lexicographically by code point at every nesting level.
2. No insignificant whitespace.
3. Strings encoded UTF-8, with all non-ASCII characters escaped via \uXXXX only where required to produce valid JSON.
4. Numbers serialized in their shortest round-trip form; no trailing zeros, no leading plus sign, no exponential notation for integers.
5. Boolean and null literals lowercase.

Canonical CBOR

Implementations MAY additionally serialize to CBOR per RFC 8949 deterministic encoding rules. Where both encodings exist for the same record, they MUST produce the same commitment hash when canonicalized through their respective rules.

Hash function

The canonical hash function for HATS Record v1 is SHA3-256 (FIPS 202). SHA-2 family hashes are NOT canonical; their use in upstream-engine outputs is permitted only when the engine's normative specification mandates them and they are subsequently bound through a SHA3-256 commitment at the substrate.

§15PQ signature envelope

The three-family PQ signature envelope is the wrapper that secures every signed layer. The envelope consists of three independent signatures over the same canonical payload, computed with three independent NIST-standardized post-quantum signature schemes.

A record verifies under the envelope if and only if all three signatures verify under their respective schemes against the same canonical payload using public keys resolved from the epoch registry at the record's epoch_id.

The use of three families is defense in depth: a future cryptanalytic advance against any single family does not invalidate the envelope, because the other two families remain unaffected. A conformant implementation MUST verify all three; partial verification (e.g., "ML-DSA only") is non-conformant.

§16Verification protocol

A conformant verifier evaluates a HATS record against the following ordered, ten-check protocol. The check identifiers are stable and form the basis of the structured rejection semantics defined in §3.

HATS records additionally MUST pass HATS-specific extension checks defined by their record_kind. For adversarial_resilience records, the extension checks include:

• CHK-AR-01: CKA scores fall within their declared band (M1 high, M2 low).
• CHK-AR-02: Attack corpus configuration is reproducible from the declared RNG seed and parameter set.
• CHK-AR-03: Risk estimate is reproducible from per-surrogate outcomes via the declared estimator.
• CHK-AR-04: Regulatory mapping entries each resolve against the framework registry.

A conformant verifier emits a signed verification report (Layer 5) for every record it evaluates, regardless of pass or fail.

§17Replay protocol

Replay is the deterministic re-evaluation of a HATS record against the canonical replay frame published with this specification. Replay is the primitive that gives this specification its name: a HATS record can be replayed years later, by any party, with any conformant implementation, and the verdict will be the same.

The replay protocol proceeds in four phases:

1. Resolve. The verifier resolves the canonical replay frame, the engine descriptor, the conformance vector, and the epoch keys.
2. Recompute. The verifier recomputes every declared hash, every commitment, every continuity root, and every substrate binding.
3. Re-evaluate. The verifier re-evaluates the verification protocol (§16) against the recomputed values.
4. Report. The verifier emits a signed verification report (Layer 5) with per-check verdicts.

Two conformant verifiers replaying the same record against the same canonical frame and the same epoch keys MUST produce per-check verdicts that are byte-identical. This is the deterministic conformance verification property and it is what makes the verifier independent of H33.

§18Verifier identity binding

Every conformant verifier instance carries its own ML-DSA-65 keypair stored at a well-known path (~/.config/h33-verify/identity.json in the reference implementation). The verifier's public key fingerprint (SHA3-256) is its stable identity for purposes of signed verification reports.

A signed verification report (Layer 5) does NOT prove that a particular verifier identity belongs to a particular natural person or organization. That binding is established out of band — via an allow-list, a regulator-published registry, or a verifier identity certificate issued by a third party. The signed report only proves that some verifier with this public-key fingerprint produced this verdict on this bundle at this time.

Implementations SHOULD publish their verifier identity fingerprints alongside the reports they emit so that consumers can independently validate against a registry of their choice.

§19Regulatory mapping

HATS records are designed to map cleanly to existing regulatory frameworks. v1 defines normative mappings for the following frameworks; extensions may be registered via the conformance corpus.

§20Conformance corpus

The conformance corpus is the immutable set of canonical HATS records and expected per-check verdicts against which conformant implementations are validated.

• The corpus is append-only. Records once admitted cannot be removed or modified.
• Every corpus record carries a stable corpus identifier referenced in records that claim corpus membership.
• Conformant implementations MUST produce the published per-check verdicts on every corpus record. Implementations that diverge on any verdict are non-conformant.
• Positive conformance vectors are published openly. Negative conformance vectors are reserved for a separate continuation per patent strategy and are released through controlled channels.

§21Boundary discipline (public vs. proprietary)

The H33 stack maintains a strict boundary between verification artifacts (public) and computation artifacts (proprietary). This boundary is normative for HATS implementations and is documented in the BOUNDARY.md governance document.

Cross-boundary moves require explicit governance approval; implementations that opaquely shift artifacts across the boundary are non-conformant.

§22Security considerations

Cryptographic assumptions

HATS Record v1 relies on the security of SHA3-256, ML-DSA-65, FALCON-512, and SLH-DSA-128f. Use of three independent post-quantum signature families is intentional defense in depth against future cryptanalytic developments. A break of any single family does not break the envelope.

Verifier independence

The protocol is designed so that an independent verifier can validate a record using only the published specification, the open-source verifier source, and the public-key registry. No trust in H33 infrastructure is required. Implementations MUST NOT introduce verifier behaviors that depend on H33-hosted services.

Epoch key compromise

If an epoch key is compromised, the affected epoch is revoked via a normative revocation entry in the public-key registry. Records signed under a revoked epoch MUST be flagged by conformant verifiers. The conformance corpus retains the record for historical replay but marks the epoch revoked.

Engine compromise

If an upstream engine is found to produce unsound outputs (e.g., a STARK soundness break), records depending on that engine MUST be re-evaluated. The conformance corpus preserves the original verdicts; consumers SHOULD additionally consult the engine's security advisory channel.

Replay attack resistance

Records are bound to their epoch, their canonical frame, and their bundle hash. Replay of a record against a different epoch or frame produces a verdict failure at CHK-04 or CHK-09. Cross-record substitution is structurally impossible at CHK-10.

§23Privacy considerations

HATS records do NOT carry PII by design. Sensitive payloads are bound by commitment and stored off the record. The record carries the commitment and the metadata necessary for verification; the payload itself remains under whatever access control the issuer applies.

For records produced by privacy-preserving engines (STARK proofs of KYC/OFAC/age on Solana, Bitcoin, Polygon, or Zcash), the public inputs MUST be limited to the regulatory category being proven. The underlying private inputs MUST NOT be derivable from the record.

Conformant implementations MUST NOT include personally identifying information in the regulatory mapping notes or in extension fields. Regulatory mappings reference framework articles; they do not summarize personal data.

§24Reference implementations

• h33-replay-verify — Rust CLI implementing §16 verification protocol. Compiled to WASM for browser use. Source at github.com/H33ai/h33-replay-verifier, Apache-2.0.
• h33-verify v0.2.0 — Signed verification report producer (Layer 5). Per-instance ML-DSA-65 keypair at ~/.config/h33-verify/identity.json. 31 tests at release.
• verify-the-story playground — Browser-resident WASM verifier with ML-DSA-65 transcript verification via @noble/post-quantum. Hosted at /verify-the-story/playground/. Zero network calls after page load.
• tokenize the world — Scenes 1 and 2 of the canonical operating-model walk-through, also running the same WASM verifier core. Hosted at /tokenize/ and /tokenize/replay/.
• h33-Solana — On-chain STARK + PQ-signed proof of regulatory category on Solana mainnet. Program ID 5eAwAv59YqpnSBMj59KeXhDdLqmn99HBYSjrb6jcLbC5. Hosted try-it at /solana-privacy/.

§25Patent linkage

This specification instantiates claims from the following H33 patent filings. The list is informative; the normative constitution is the family architecture invariants document.

The family architecture invariants document is load-bearing for this specification. Implementations MUST consult it for any cross-patent semantic question.

§26Versioning and change control

Semantic versioning

This specification follows semantic versioning. The current version is v1.0.0. Breaking changes increment the major version. Additive, backward-compatible changes increment the minor. Editorial changes increment the patch.

Change control

• Cross-boundary changes (moving an artifact between public and proprietary) require explicit governance approval per BOUNDARY.md.
• Substrate version bumps are NEVER permitted as a mechanism to widen the 74-byte primitive. Extensions MUST bind off-chain via verification_hash.
• Spine v1.1 routing is frozen. New routes appear under fresh version bumps, never via silent extension.
• Conformance corpus admissions are append-only and require explicit standards-group review.

Errata

Editorial errata against v1.0.0 will be published at /hats/spec/hats-record-v1/errata.md as discovered. Errata never change normative requirements; normative changes require a minor or major version bump.

§AAppendix A — Example HATS record

The following is an example HATS record of record_kind: adversarial_resilience in canonical JSON form. The example is illustrative; values are placeholder.

// HATS Record v1 — example adversarial_resilience record
{
  "agent_id": "agt_01HZQYNB3X...",
  "attack_corpus": {
    "ensemble": "AutoAttack",
    "members": ["APGD", "FAB", "Square"],
    "config": { "epsilon": 0.03, "norm": "Linf" },
    "rng_seed": "0x9f8a..."
  },
  "bound_to_replay": true,
  "case_id": "case_2026_05_30_a",
  "chain_anchors": [
    { "chain_id": "polygon", "anchor_status": "confirmed", "block_number": 62318441, "tx_hash": "0x4af..." },
    { "chain_id": "bitcoin", "anchor_status": "confirmed", "block_number": 911022, "tx_hash": "e3b0..." },
    { "chain_id": "ethereum", "anchor_status": "confirmed", "block_number": 21558109, "tx_hash": "0xc7a..." }
  ],
  "continuity_root_id": "crt_01HZQYNC5...",
  "epoch_id": 17,
  "per_surrogate_outcomes": [
    { "surrogate_id": "densenet201", "attack_id": "autoattack_v1", "success_count": 412, "sample_count": 2000 },
    { "surrogate_id": "vgg19", "attack_id": "autoattack_v1", "success_count": 438, "sample_count": 2000 },
    { "surrogate_id": "resnet152", "attack_id": "autoattack_v1", "success_count": 479, "sample_count": 2000 },
    { "surrogate_id": "mobilenetv2", "attack_id": "autoattack_v1", "success_count": 198, "sample_count": 2000 },
    { "surrogate_id": "efficientnet_b0", "attack_id": "autoattack_v1", "success_count": 221, "sample_count": 2000 }
  ],
  "pq_signature_envelope": {
    "ml_dsa_65": "...",
    "falcon_512": "...",
    "slh_dsa_128f": "..."
  },
  "record_id": "0x5a7c9d3b...74-byte...",
  "record_kind": "adversarial_resilience",
  "regulatory_mapping": [
    { "framework_id": "eu_ai_act", "articles": ["12", "15"] },
    { "framework_id": "nist_ai_rmf", "articles": ["TEVV"] },
    { "framework_id": "owasp_ai_exchange", "articles": ["adversarial_risk"] }
  ],
  "risk_estimate": {
    "mean": 0.196,
    "std": 0.041,
    "ci_95_low": 0.116,
    "ci_95_high": 0.276,
    "estimator_metadata": { "family": "bayesian_regression", "prior": "beta(1,1)" }
  },
  "spine_route_membership": "hats.adversarial",
  "substrate_version": 1,
  "surrogate_set_M1": [
    { "model_name": "DenseNet-201", "cka_score": 0.587, "transfer_rate": 0.206 },
    { "model_name": "VGG-19", "cka_score": 0.612, "transfer_rate": 0.219 },
    { "model_name": "ResNet-152", "cka_score": 0.694, "transfer_rate": 0.240 }
  ],
  "surrogate_set_M2": [
    { "model_name": "MobileNetV2", "cka_score": 0.298, "transfer_rate": 0.099 },
    { "model_name": "EfficientNet-B0", "cka_score": 0.331, "transfer_rate": 0.111 }
  ],
  "target_model_identity": {
    "model_name": "ResNet-50",
    "dataset": "ImageNet-1K",
    "weight_hash": "0x4e1b...",
    "version": "v1.0",
    "stage": "pre-production"
  },
  "tenant_id": "tnt_01HZ...",
  "verifier_binding": {
    "hats_verify_cli_version": "v0.2.0",
    "container_digest": "sha256:9af...",
    "identity_fingerprint": "0xb31f..."
  }
}

§BAppendix B — Example signed verification report

// h33-signed-verify-report-v0.1 — example
{
  "bundle_hash": "0x5a7c9d3b...32 bytes...",
  "detached_signature": "ML-DSA-65 signature bytes...",
  "per_check_verdicts": [
    { "check_id": "CHK-01", "result": "pass" },
    { "check_id": "CHK-02", "result": "pass" },
    { "check_id": "CHK-03", "result": "pass" },
    { "check_id": "CHK-04", "result": "pass" },
    { "check_id": "CHK-05", "result": "pass" },
    { "check_id": "CHK-06", "result": "pass" },
    { "check_id": "CHK-07", "result": "pass" },
    { "check_id": "CHK-08", "result": "pass" },
    { "check_id": "CHK-09", "result": "pass" },
    { "check_id": "CHK-10", "result": "pass" },
    { "check_id": "CHK-AR-01", "result": "pass" },
    { "check_id": "CHK-AR-02", "result": "pass" },
    { "check_id": "CHK-AR-03", "result": "pass" },
    { "check_id": "CHK-AR-04", "result": "pass" }
  ],
  "timestamp_utc": "2026-05-30T23:50:00Z",
  "transcript_schema_version": "h33-signed-verify-report-v0.1",
  "verifier_identity_fingerprint": "0xb31f...32 bytes...",
  "verifier_public_key": "ML-DSA-65 public key bytes...",
  "verifier_version": "v0.2.0"
}

§CAppendix C — Regulatory crosswalk index