What Happens If H33 Disappears?

Click "Run verification" to execute. The verifier will load the bundle, compute SHA-256, check the envelope signatures, and emit a verdict — using only resources available locally.

1. The question

A reasonable question. Here is the honest answer.

Imagine H33 shuts down tomorrow. The company is acquired and the product is sunsetted. The startup runs out of funding. The website goes dark. The team disperses. The Github org is taken private.

What happens to the search results you have already attested? What happens to the bundles your regulators expect you to produce? What happens to the evidence you have on file?

The answer is the same for all three: verification still succeeds. You do not lose your evidence when H33 stops existing.

2. What you still have

When H33 disappears, you still have:

Your bundles

Every search result H33 attested for you is a self-contained file. JSON, hashes, signatures, and references — all in one bundle. Your team keeps the file. Your auditors get a copy. Your court receives the bundle as evidence. The bundle was always yours; H33 just signed parts of it.

Your verifier

The verifier is open source under Apache 2.0. You can download it today. You can keep a copy on your laptop, your air-gapped network, your archival storage. When H33 disappears, your local copy still runs. The binary does not phone home. The binary does not check for updates. The binary does not need a license. It just verifies your bundles.

Your published conformance vectors

The conformance vectors that prove the verifier produces the right output are published as files at h33.ai/conformance/. You download them. You keep them. Any third party can run a fresh implementation of the verifier against the vectors and confirm it produces byte-identical output. The vectors are how you know your verifier is the same verifier H33 published.

Your standards-based cryptography

H33 uses NIST-standard post-quantum cryptography — ML-DSA, SLH-DSA, ML-KEM. These algorithms are not H33 inventions. They are published NIST FIPS standards. Other implementations exist. Other auditors can verify them.

Your customer-held keys (Federal customers)

If you are a Federal-profile customer, you already hold your own cryptographic keys in your own HSM. H33 never had operational access to your signing keys. When H33 disappears, your keys are still yours, still HSM-protected, still capable of producing signatures that other implementations can verify.

3. Trust boundary diagram

Who needs to be reachable for verification to succeed? The diagram makes the answer explicit.

If H33 is offline, sanctioned, acquired, sunset, or actively hostile, this verification still succeeds. The bundle is the artifact. The verifier reads it. The conformance vectors prove the verifier behaves correctly. Anchor confirmation, if needed, queries a public chain RPC — and that RPC can be operated by anyone.

4. What still works (mechanism)

When you run the verifier on a bundle, even after H33 is gone:

1. The verifier reads the bundle bytes.
2. The verifier checks each cryptographic signature using public keys that are also in the bundle or on file with you.
3. The verifier validates each hash chain.
4. The verifier confirms that the policy committed before the model produced output, that the corpus was pinned before retrieval began, that the citations bind specific byte ranges to specific evidence items.
5. The verifier produces a verdict: PASS, FAIL, or INCONCLUSIVE.

None of these steps requires an H33 endpoint. None requires a network call to h33.ai. None requires a license check. None requires an H33-issued credential.

When H33 is gone, the verifier still runs. The verdict it produces is still meaningful. The bundle it verified is still authoritative. This is not a promise. This is how the system is built.

5. Cascade timeline — what survives over time

A practical view of degradation if H33 is gone. Each cell shows the state at that time horizon and the resources required to keep verifying.

6. What you lose

We will be honest about what stops working.

New attestations stop

H33 will no longer produce new bundles. If H33's API was your source of new attestations, that source stops. You either run your own implementation of the substrate (it is open source, with published specs and conformance vectors) or you migrate to another vendor.

H33's hosted services go offline

The hosted revocation registry stops. The hosted demo bundles stop. The h33.ai website stops. Customer-hosted alternatives can be stood up — but the H33-operated services go offline.

H33's support stops

Engineering escalations, solution architecture conversations, sales engineering — all stop. You either operate the substrate yourself or you do not get help.

What does NOT happen

Existing bundles do not become invalid. Existing signatures do not expire because H33 is gone. Existing evidence is not retroactively revoked. Existing audit records remain audit records.

7. Threat model

What scenarios is the survives-H33 posture designed to address?

• Voluntary discontinuity. H33 winds down operations, acquired and sunsetted, or pivots away from this product line. Verification continues using all customer-held resources.
• Involuntary discontinuity. Insolvency, lawsuit, or regulatory action against H33. Same posture: customer-held resources continue to verify.
• Active hostility. A successor entity to H33 attempts to deny verification or invalidate prior bundles. The verifier binary is Apache 2.0; the conformance vectors are published; the cryptography is standards-based. There is no kill switch for a successor to flip.
• Network sanction. H33's commercial endpoints are blocked from a jurisdiction. Federal-mode customers already operate the substrate locally with their own keys; verification is unaffected.
• Compromise of H33's signing infrastructure. An attacker compromises H33 keys after the customer's bundles are already signed. Pre-existing bundles remain verifiable using the embedded signatures and the published authority capabilities at time of issuance. New bundles from H33 cannot be trusted post-incident; pre-incident bundles are unaffected.
• Conformance vector tampering. An attacker modifies the published conformance vectors on h33.ai after the customer has independently archived them. The customer's archived copy is the authoritative one; future implementations can be checked against the customer's archive, not the live h33.ai copy.

8. Limitations — what this does not promise

• This page does not promise that specific implementations of the verifier (versions, builds, binaries) will continue to be maintained. It promises that the source is Apache 2.0 and the conformance vectors are published, so verification continues to be buildable from open materials.
• This page does not promise indefinite mathematical security. Cryptographic algorithms have lifecycle bounds. Bundle re-signing under updated standards is a known operational pattern; the page promises survival of existing bundles within the current algorithm lifecycle window, not eternal cryptographic security.
• This page does not promise that revocation registries hosted at h33.ai continue to be available. Customer-side mirror registries are recommended for organizations whose use case depends on revocation status lookup.
• This page does not promise H33 continues to provide commercial support, escalation, or sales engineering. The page is about structural verification posture, not commercial relationship continuity.

9. Why this is structural, not promised

Other vendors will say "your evidence is safe with us." H33 says something stronger: your evidence does not depend on H33 being alive.

The difference matters because promises break. Structures do not.

The verifier is open source

Apache 2.0. The source code is on GitHub. You can compile it yourself. You can audit it. You can fork it. When H33 is gone, the GitHub repository remains accessible (Apache 2.0 includes a permanent license to use, modify, and distribute). If GitHub also disappears, you keep your local checkout.

The conformance vectors are published

The vectors that prove the verifier produces correct output are files on the internet today. You can mirror them. You can include them in your archival storage. You can reference them in your procurement contracts. When H33 is gone, the vectors are still files; mirrors and archives still work.

The cryptography is standard

ML-DSA, SLH-DSA, ML-KEM, SHA3 — all NIST FIPS standards. NIST does not need H33 to exist for the standards to remain valid. Other implementations of the same standards already exist. When H33 is gone, other implementations of the same standards still work.

Federal customers hold their own keys

If you are a Federal-profile customer, your signing keys are in your HSM, under your operational control. H33 publishes the ceremony guidance (9A) and the revocation architecture (9B), but the actual keys are yours. When H33 is gone, your keys remain yours.

The independence is not a feature. The independence is the design. Every architectural decision H33 made was made with this scenario in mind. The verifier output literally says "H33 was not contacted during this verification" — not because it is a marketing tagline, but because it is the structural truth about how verification works.

10. Technical FAQ

Q: What about H33's revocation registry?
A: The registry is hosted by H33. When H33 disappears, the hosted registry goes offline. The records-forever discipline means existing records are still in archives. Customers can stand up a mirror or operate their own registry. Federal customers already operate their own registry.

Q: What about future audits of past bundles?
A: Past bundles do not require live H33 services to audit. The verifier consumes the bundle file plus the published conformance vectors. Both are independently available.

Q: What about my data inside H33's hosted services?
A: H33's hosted services for the substrate API have customer data retention policies that meet enterprise customer requirements. If H33 winds down, customers have export rights to their data per those policies. Federal customers do not have data hosted at H33; Federal customers operate the substrate themselves.

Q: What if H33 is acquired?
A: If H33 is acquired and the acquirer maintains the substrate, this page becomes hypothetical. If the acquirer sunsets the substrate, the answers on this page apply.

11. Verification procedures

Three ways to verify a bundle without contacting H33, ordered from fastest to most thorough:

1. Browser verification. Open /verifier/ and use the "Verify in browser" section. Loads any bundle, computes SHA-256 via Web Crypto, runs the structural envelope check. Verdict in <15 seconds. No install. No H33 endpoint.
2. Trust Card render. Open /trust-card/. Loads a bundle, renders the 6-field Trust Card from real data, exposes a tamper test. Same browser-side check, plus a printable one-page artifact you can hand a regulator.
3. Native CLI verifier. Download h33-verifier from /downloads/ (Apache 2.0, 3 platforms). Run h33-verifier verify bundle.json from a regulator's laptop. The binary makes no network call. Conformance vectors at h33.ai/conformance/v0.2/ can be archived locally for indefinite future use.

12. References

• H33 Portability Verifier — CLI binary + browser verification surface
• Trust Card live generator — one-page portable attestation
• Avalanche live demo — full 8-step pipeline including STARK ZK proof of encrypted compliance
• Portable artifact — concept overview
• Independent verification — verification model
• Verifier downloads — binaries + source tarball + release manifest
• Demo bundle — the reference bundle used by the simulator above
• NIST FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) — the cryptographic standards underlying the envelope signatures

This page is intentionally honest. We do not promise H33 will exist forever. We demonstrate that H33's continued existence is not a condition of your evidence being valid.

Bundle + Attestation + Submission + Verifier all agree. No H33 contact required.