H33 Trust Model

What H33 can see, what H33 can modify, what H33 can verify, and what survives if H33 disappears.

This page documents the trust model H33 operates under. It is intended for enterprise architects evaluating H33 for sensitive use cases, security reviewers assessing the model's claims, and compliance officers documenting the H33 boundary as part of risk assessment.

Why H33 needs a trust model

Most vendors do not document their trust model explicitly. The default assumption is broad access: their software runs on their infrastructure, they hold the keys, they can read the data, they can change the data. This is acceptable for many use cases but not for institutional evidence. AI decisions reference proprietary models and personal data. Insurance claims reference protected information. Federal evidence may be classified. The vendor that produces the evidence cannot be assumed to have broad access. H33's trust model is bounded. The bounds are documented here.

What H33 can see

H33's visibility into customer evidence is bounded by deployment topology. In the on-premises / customer-controlled deployment. H33 software runs in customer infrastructure. H33 has no visibility into the customer's data, decisions, or evidence bundles. The customer holds the signing keys; the customer holds the bundles. In the H33-hosted SaaS deployment. H33 operates the infrastructure that runs the bundle-generation pipeline. H33 has visibility into the data the pipeline processes. H33 does not have visibility into bundles after they are generated and transferred to customer storage. The customer holds the signing keys (via customer-held HSM integration). In the federated deployment. H33 provides the substrate; the customer operates the pipeline. H33 has visibility limited to substrate's operational telemetry. The customer holds keys, bundles, and verification. H33 does not retain copies of customer evidence under any deployment topology.

What H33 can modify

H33's ability to modify customer evidence is bounded by cryptographic signatures. The bundle once signed. H33 cannot modify a bundle after signing without invalidating the signatures. The three-family signature design means H33 would need to forge signatures across ML-DSA-65, FALCON-512, and SLH-DSA-128f simultaneously, which is computationally infeasible. The bundle's anchor. H33 cannot modify the on-chain anchor after it is published. The verifier. H33 maintains the reference verifier. Customers and external parties can review the verifier's source code, build it from source, and run conformance tests. The schema. H33 publishes the schema. Modification of the schema affects future bundles, not existing ones. In summary: H33 cannot modify existing signed bundles, cannot modify on-chain anchors, and cannot modify the verifier without public visibility.

What H33 can verify

H33's verification capability is the same as any external party's. H33's verifier is the same open-source verifier external parties use. H33 has no special verification access. H33 can verify bundles the customer provides (typically for support). H33 cannot verify bundles the customer has not provided. H33's verification result is the same as the customer's verification result on the same bundle. H33's verification is not privileged. There is no "H33-side master key" that produces a different verification result than the customer's verifier would.

What survives if H33 disappears

This is the load-bearing question for institutional evidence. The bundles survive. They are JSON files. The customer holds them. The signatures survive. They are NIST-standard post-quantum signatures. The schema survives. It is published. The verifier survives. It is open source. The anchors survive. They are on public blockchains. The verification result survives. A bundle that verifies today verifies tomorrow, next year, and in 25 years, subject to the three-family signature design holding against future cryptanalysis. What does not survive: H33's commercial support, H33's roadmap and future schema versions, H33's customer-success relationships, H33's hosted services. For evidence verification, none of these are required.

Threat scenarios

S1. H33 is compelled to disclose customer evidence. Under the bounded deployment models, H33 does not have the evidence. S2. H33's keys are compromised. In customer-held-key deployments, this does not affect customer evidence. S3. H33 is acquired. Customer evidence remains with the customer. The bundles continue to verify regardless of H33's corporate ownership. S4. H33 ceases operations. Customer evidence continues to verify. The verifier continues to work. S5. H33's reference verifier has a vulnerability. The open-source code allows external audit. S6. H33 attempts to retroactively change behavior. Existing bundles are signed under their original signatures. Existing schema versions are frozen. Retroactive behavior changes are not architecturally possible.

Common questions

Does H33 have copies of my bundles?
Under the bounded deployment models, no. H33 produces the bundle and transfers it to customer storage; H33 does not retain a copy.

Who holds the signing keys?
In on-premises and federated deployments, the customer. In SaaS deployments, the customer (via HSM integration) or joint custody arrangements.

Can H33 read my evidence?
Under on-premises and federated deployments, no. Under SaaS, H33 has operational visibility into pipeline-stage data but not into signed bundles.

What if H33 is acquired by an adversary?
Existing bundles remain valid. The verifier remains open source. The schema remains published. The acquirer cannot retroactively modify existing evidence.

Can I run H33 in a fully customer-controlled environment?
Yes. The on-premises deployment provides the strongest isolation. H33 software runs entirely in your infrastructure.

Get Started

Run the demo Download the verifier Download a bundle