Deployed · Live on marketplace
HX-Provenance
Verifiable inference. Exact recall, cryptographically and numerically.
A hosted Cloud API for fast onramp; a sealed Private Appliance for regulated, sovereign, and air-gapped environments. One verification standard.
In plain language
Most AI systems can show you what they produced. They cannot prove it.
They cannot prove the output came from the model the user thinks it came from. They cannot prove the output was not altered after it was produced. They cannot prove that running the same input through the same model again would produce the same output. And they cannot prove any of this in a way that survives without trust in the company that hosted the computation.
For a lot of AI use cases, none of that matters. A customer-service chatbot does not need to be reproducible. A marketing image does not need an evidence chain. For other use cases, it is the whole game.
There is no good answer to any of these questions today. The audit-trail products on the market record that something happened; they do not prove what the something was. The notarization services time-stamp data; they say nothing about whether the data is the actual model output. The cryptographic signing tools sign whatever you give them; they cannot tell you that the thing you gave them is the real computation.
HX-Provenance is the product that proves it. It does this by combining three things that have not been combined before in a single product surface: cryptographic content binding so the output cannot be altered without detection, post-quantum signatures that will still be valid after the cryptographic standards transition the federal government has mandated by 2031 and the commercial market by 2035, and bit-exact reproducible computation so the same input always produces the same output on conforming hardware.
What gets shipped to the customer is a small piece of evidence attached to every output. That piece of evidence can be verified later, by anyone, without trusting HolonomiX, without calling back to a server, and without depending on any specific cloud provider. The customer can hand that evidence to a regulator, an auditor, a counterparty, or a court, and the verification works.
What you can prove
Two selling surfaces
Cloud is the fastest way to start using verifiable inference. Appliance is the only way some buyers can use it at all.
They share the same engineering substrate, the same evidence schema, and the same verification standard. They are sold to different buyers with different operational constraints.
A customer who starts on the Cloud and grows into a procurement that mandates customer-controlled keys can graduate to the Appliance without changing receipt schemas, verification logic, or integration code.
Verification independence
Verification must not require trust in HolonomiX, in the issuing infrastructure, or in any specific cloud provider.
Three independent verification paths ship with the product.
Offline verification is the path that survives a HolonomiX outage, an issuer change, or a multi-decade evidence-retention requirement.
The evidence bundle
Evidence bundles are portable, signed, offline-verifiable archives that package one or more receipts with all metadata required for independent verification.
evidence-bundle/ receipt.json Canonical receipt(s) artifact_manifest.json Hashes of referenced artifacts verification_result.json Issuer-side verification record public_key.json Issuer public key for offline verify signature_metadata.json Algorithm IDs, key fingerprints timestamp_metadata.json Issued-at and clock-source metadata workspace_metadata.json Tenant and environment scope bundle.sig Bundle-level ML-DSA-65 signature
Bundles are exportable as ZIP, tar.zst, or a directory tree. The bundle-level signature binds all contents together; tampering with any component invalidates the bundle. An auditor with the bundle and the issuer public key can verify the entire chain offline.
Evidence portability across the two surfaces is structural, not a roadmap item. A receipt issued by HX-Provenance Cloud verifies under the Private Appliance verifier without modification, and the reverse holds. The exact-receipt schema used by HX-SDP for inference output verification is verifiable under both HX-Provenance verifiers, which is the cross-product integration path.
Technical substrate
The substrate underneath both surfaces, for engineers, security reviewers, and procurement reviewers who need to verify the claims above.
Receipt schema
Receipts are emitted under canonical schema hx.provenance.receipt/v1.1. The schema is stable, fixture-tested, and backward-compatible with hx.exact.receipt/v1.1 for HX-SDP exact-recall verification.
{
"schema": "hx.provenance.receipt/v1.1",
"receipt_id": "...",
"tenant_id": "...",
"artifact_id": "...",
"artifact_hash": "sha256:...",
"issued_at": "ISO-8601 UTC",
"signer_key_id": "...",
"signer_public_fingerprint": "sha256:...",
"signature_algorithm": "ML-DSA-65",
"signature": "...",
"verification_metadata": { ... }
}
Receipts are deterministically serialized, with canonical JSON, sorted keys, and stable separators, so the artifact hash and signature are reproducible across implementations. Future-version receipts produced by newer servers are explicitly rejected by older verifiers with a structured error rather than silent acceptance.
Cryptographic primitives
NIST-finalized post-quantum primitives throughout.
Module structure
The cryptographic module is built to FIPS 140-3 architecture, addressing the eleven security requirement areas defined by ISO/IEC 19790. Cryptographic services are available only in the OPERATIONAL state. Errors transition the module to ERROR. Zeroize is terminal.
Known Answer Tests at module initialization for every approved algorithm, with vectors from NIST CAVP and the NIST PQC project. The module refuses to enter OPERATIONAL if any test fails.
Secret keys are stored under controlled permissions, accessed through a key-provider abstraction, and zeroized on shutdown using platform secure-memory primitives.
The logical boundary is defined in code. Every cryptographic operation in the product flows through the module; no out-of-boundary cryptography is permitted in production deployments.
CAVP algorithm validation and CMVP module validation are on the enterprise roadmap, gated by buyer commitment. The module is built to the standard. Customers with a procurement requirement for validated modules can engage on the validation path as part of an enterprise contract.
What the Cloud surface exposes
A small, deliberately constrained API.
POST /v1/provenance/receipt Issue a receipt for an artifact
POST /v1/provenance/verify Verify a receipt; deterministic verdict
POST /v1/provenance/exact HX-SDP exact-receipt compatibility path
GET /v1/provenance/receipt/{id} Retrieve a previously issued receipt
GET /v1/provenance/public-key Issuer public key for offline verification
GET /v1/provenance/workspaces/{id}/usage Workspace usage and quota
Delivery and control
The Private Appliance ships as a sealed deployment bundle across multiple delivery shapes. The signed runtime payload is the same in every shape; the differences are packaging.
What the customer controls
Generated on the appliance at first boot. Stored on the appliance under customer-controlled permissions. They never leave the customer environment.
Receipts and evidence bundles persist in the customer storage backend: local, customer-managed object storage, or customer database.
Local verifier and offline verifier ship inside the appliance. No call-home. No required HolonomiX endpoint.
Annual per-appliance license as a signed JWT with customer ID, tier, expiry, and feature scope. Install, verification, and rotation work without network access.
Every shipped file is hashed and the manifest is signed with an offline release key. The appliance verifies its own manifest at first boot and refuses to start if verification fails.
A release-blocking validation script runs fourteen gates covering DNS and TLS posture, health, authentication boundary, public verification, receipt issue and verify, tamper rejection, schema compatibility, bundle export, workspace quota, rate limiting, persistence, backup status, and metrics. The customer security team can run it independently.
Each release ships with a CycloneDX SBOM, vulnerability scan report, build provenance, validation summary, signed release attestation, and offline verification instructions.
Proof points
Hardware-verified execution
The cryptographic substrate underneath HX-Provenance was first demonstrated end to end on real post-quantum hardware on December 3, 2025: ML-DSA-65 signature generation and verification of quantum-circuit execution results from a Rigetti Ankaa-3 superconducting QPU, 84 qubits, running on AWS Braket in us-west-1. The full chain ran through: circuit submitted, results returned, results signed under ML-DSA-65, signature verified by an independent verifier, evidence bundle exported and re-verified offline.
Patent posture
Four named methods are filed as Patent Pending under the underlying provenance package.
- Post-quantum cryptographic signing of computational job provenance.
- CRYSTALS-Dilithium-3, that is NIST FIPS 204 ML-DSA-65, signature integration with execution-unit results.
- Tamper-evident evidence chain construction for verifiable computations.
- Multi-backend provenance attestation across heterogeneous execution environments.
Engineering substrate
The product is built on a 25,000-line internal substrate in Python and Rust that has been the subject of formal verification work in Rust, with Verus proofs on the safety-critical core, FIPS 140-3 architectural alignment across the eleven security areas, and continuous internal validation against NIST CAVP test vectors. The substrate has been hardened over five months of internal use.
What HX-Provenance is not
Boundary clarity matters. The product is deliberately scoped, and the following claims are explicitly not made.
HX-Provenance does not require, integrate with, or compete against blockchain infrastructure. It is post-quantum cryptographic evidence, not a distributed consensus system.
Receipts are cryptographic evidence of artifact integrity. Legal weight in any specific jurisdiction is a separate determination requiring counsel review, and is the customer responsibility.
The product produces evidence aligned with NIST FIPS standards and the CNSA 2.0 transition timeline. Specific regulatory compliance requires the customer deployment, operational practices, and audit posture in addition to the cryptographic substrate.
On the Cloud surface, HolonomiX persists receipts and evidence bundles per workspace plan. In the Private Appliance, customer data never leaves the customer environment. Responsibility for primary data lives with the customer in both cases.
HX-Provenance is a standalone product, separable from the HX-SDP data plane. It does not require GPU infrastructure and it does not require any HolonomiX inference platform. It can be integrated with any system that produces artifacts requiring durable proof.