Why should anyone trust H33?

H33 doesn't ask anyone to trust it. H33 produces signed evidence under triple-family post-quantum signatures (ML-DSA-87 + SLH-DSA-256 + FALCON-1024) attesting code, configuration, policies, execution state, and authority state — using the same primitives sold to customers. Every claim has a bundle URL, a SHA3-384 hash, and a verifier command. Anyone can verify independently with the open-source h33-verifier CLI.

What does H33 attest about itself?

Five pillars against the H33-PQ Verified standard. Pillar 1 — Portable Evidence: signed receipts of every portable evidence artifact published this cycle. Pillar 2 — Authority Preservation: the patent-filing authority lineage as a signed 5-level chain. Pillar 3 — Privacy Preservation: release-readiness scored under H33 FHE-IQ without exposing the input. Pillar 4 — Independent Verification: open-source verifier and conformance vectors. Pillar 5 — Post-Quantum Security: triple-family PQ across the entire trust path at NIST L1/L3/L5.

What happens if H33's attestation fails?

Failure is observable. Four failure modes are explicitly defined: Attestation Missing (no bundle for the cycle), Attestation Stale (cycle_id older than current quarter), Attestation Revoked (revocation record under the release principal), Attestation Failed (signature tampered, lineage broken, or schema violated). Each mode has a customer-visible signal and a verifier exit code. Real failure-mode test vectors are published so the verifier can be exercised against tampered bundles before they ever appear in production.

Is this the same as a SOC 2 report?

No. SOC 2 is auditor-attested — a third party signs that they reviewed the controls. H33 Self-Attestation is substrate-attested — H33 produces cryptographic signatures over hashes of the actual artifacts, and anyone with the verifier CLI can confirm the signatures and hashes match. SOC 2 says we looked at it. Self-Attestation says here are the bytes — verify them yourself. The two complement each other.

What is the H33-PQ Verified standard?

H33-PQ Verified is the open conformance standard that defines how a post-quantum trust system should attest itself. It specifies five pillars (Portable Evidence, Authority Preservation, Privacy Preservation, Independent Verification, Post-Quantum Security), the bundle schemas each pillar produces, the verifier interface, and the rules for publishing structure without exposing decision content. H33 is customer #1.

Where do I download the bundles?

Bundle inventory lives at https://h33.ai/pq-verified/h33-self-attestation/bundles/manifest.json. Each pillar lists its bundle URL, schema URL, SHA3-384 hash, and verifier command. Failure-mode test vectors live in the same directory under test-vectors/.

H33 Self-Attestation — Why trust H33? Verify it.

01 / RISK

AI trust is mostly assertion.

Every AI vendor — including H33 — makes claims about its own behavior. Those claims are typically self-reported, unaudited at the cryptographic layer, unverifiable by third parties, and impossible to reproduce six months later. Customers, regulators, and auditors are increasingly asking for a different shape of evidence.

Risk

Self-reported claims.

"We use post-quantum cryptography." "We have governance controls." "Our agents are bounded." All asserted. None cryptographically signed at the vendor's substrate layer with a verifier anyone can run.

Risk

Unverifiable history.

A SOC 2 report names a point in time. A status page shows the last hour. Neither lets a counterparty independently confirm what shipped, under what authority, on what date — cryptographically, after the fact.

Risk

Impossible to reproduce.

When a customer asks "show me the code state when you signed our deployment," most vendors can describe it but not prove it. Hash chains exist internally; verifiable hash chains for third parties usually do not.

02 / CONTROL

H33 continuously attests itself.

Code, configuration, policies, execution state, and authority state — all signed under triple-family post-quantum signatures (ML-DSA-87 + SLH-DSA-256s + FALCON-1024), all queryable, all reproducible against the H33-PQ Verified standard. Five pillars, each with a real bundle, a real schema, and a real verifier command.

PILLAR 1 Portable Evidence Preparing

Signed receipts of every portable evidence artifact H33 publishes this cycle. Each artifact carries a verifier command anyone can run, a SHA3-384 hash of its bytes, and a profile tag (commercial / federal). Bundle structure is final and contains real hashes; release-key signatures land at cycle close.

bundle: evidence-receipt-2026Q2.json schema: pillar1-evidence-receipt.schema.json sha3_384: b8210f7fb8…0107bc79c

PILLAR 2 Authority Preservation Preparing

The patent-filing authority lineage as a signed 5-level chain. Real hashes of real H33-Root patent work. Decision content is never exposed; only the chain structure, hashes, and signatures. Anyone can confirm the lineage held without ever seeing what was decided.

bundle: governance-lineage-2026Q2.json schema: pillar2-governance-lineage.schema.json sha3_384: d286bbcbe8…a045781bb0

PILLAR 3 Privacy Preservation Preparing

Release-readiness scored under H33 FHE-IQ. The release input is never exposed in plaintext — only ciphertext hashes, the FHE circuit hash, and the attested output classification. Awaiting H33-native FHE-IQ runtime; no third-party FHE library will ever back this bundle.

bundle: release-readiness-2026Q2.json schema: pillar3-privacy-release-readiness.schema.json sha3_384: a1ddaead3c…b03073ecb

PILLAR 4 Independent Verification Verified

Open-source verifier (h33-verifier, Apache-2.0, Rust) plus published conformance vectors. Anyone can download the binary, run it against any bundle on this page, and confirm the result. Third-party implementations against the published schemas must produce identical verdicts.

$ h33-verifier --version
$ h33-verifier verify-conformance

tool: h33-verifier CLI · Apache-2.0 · 3.1 MB Rust binary vectors: conformance/agent-vectors/v1/

PILLAR 5 Post-Quantum Security Verified

Triple-family post-quantum signatures across the entire trust path. NIST L1, L3, and L5 covered. No classical-only crypto in the production signing or verification path. Every signed artifact on this page is signed under all three primitives so a single algorithmic compromise does not collapse the trust chain.

$ h33-verifier verify-pq --algorithms ml-dsa,slh-dsa,falcon

algorithms: ML-DSA-87 (FIPS 204, L5) · SLH-DSA-256s (FIPS 205, L5) · FALCON-1024 (NIST L5) levels covered: L1, L3, L5 across the public API surface

03 / PROOF

The current attestation.

Not "trust us." Verify it. Below is the live manifest for the current bootstrap cycle. Download the bundles. Run the verifier. Confirm the hashes match. Repeat in six months from a copy you saved — same bytes, same result.

cycle_id

2026-Q2-001

standard

H33-PQ Verified v1.0

issuer

H33.ai, Inc. · principal h33-release-key-2026q2

manifest

bundles/manifest.json

deep-dive

Standards page (technical)

verifier

h33-verifier CLI (Apache-2.0) · PQ-Video credential verifier

pillars verified

2 of 5 (4 · 5)

pillars preparing

3 of 5 (1 · 2 · 3) — structural bundles ready, release-key signatures land at cycle close

Manifest hash PENDING_AT_CYCLE_CLOSE — computed and signed when all five pillars are populated. The hash anchors a stable byte sequence; signing that hash under triple-PQ produces the final cycle attestation.

04 / FAILURE

What happens if H33 fails?

Failure is observable. Four failure modes are explicitly defined, each with a customer-visible signal and a verifier exit code. Real failure-mode test vectors are published so the verifier can be exercised against tampered bundles before they ever appear in production.

∅ Attestation Missing

No bundle published for the current cycle. The manifest does not list an entry for the pillar, or the listed URL returns 404.

customer signal: this page lists no current cycle bundle for that pillar
verifier: h33-verifier verify --bundle <url> → exit 2 · bundle_missing
manifest field: pillar entry absent or bundle_url resolves to 404

! Attestation Stale

Cycle ID is older than the current quarter. Bundle was once valid but the publication cadence has lapsed. Auditors and customers should treat the attestation as expired.

customer signal: cycle_id on this page reads a prior quarter
verifier: h33-verifier verify --bundle <url> → exit 1 · cycle_stale
manifest field: cycle_id lt; current quarter as defined by the standard

× Attestation Revoked

A revocation record under the release principal explicitly invalidates a previously-published bundle. Verifier exits with a revocation code, and this page surfaces the revocation reason.

customer signal: a revocation banner appears above the affected pillar card
verifier: h33-verifier verify --bundle <url> → exit 3 · revoked_at_cycle:<id>
manifest field: revocations array carries a signed revocation entry referencing the bundle hash

× Attestation Failed

The bundle exists but the verifier rejects it. Signature mismatch, lineage break, or schema violation. The H33 verifier fails closed and emits a specific failure code identifying which check broke.

customer signal: this page surfaces the verifier failure code from the last attempted cycle close
verifier: h33-verifier verify --bundle <url> → exit 1 · signature_invalid | lineage_broken | schema_violation
test vectors: bundles/test-vectors/

The real failure vectors are published. Anyone — auditor, customer, regulator, security researcher — can download:
· invalid-signature-pillar2.json — tampered node-hash signature · expected: signature_invalid
· invalid-lineage-pillar2.json — parent-hash chain broken between levels · expected: lineage_broken
· invalid-schema-pillar2.json — missing required field · expected: schema_violation

Run the H33 verifier against these to confirm it fails closed — before trusting it against any production bundle.

Why trust H33? Verify it.

AI trust is mostly assertion.

H33 continuously attests itself.

The current attestation.

What happens if H33 fails?

Risk · Control · Proof.

Customer #1 of the H33-PQ Verified standard is H33.