Cloud-deployed · Private Appliance · Scoped Pilot
Digital evidence that survives the system that created it.
HX-Provenance issues signed receipts, exports portable evidence bundles, and supports independent online or offline verification for AI outputs, compliance records, digital artifacts, and other business-critical records.
Once a record leaves the system that created it, proving what was created, and that it has not changed, usually depends on screenshots, exported reports, and trust in the operator. HX-Provenance replaces that with evidence that verifies on its own.
A signed artifact receipt records the artifact identity and proof context.
Integrity verification detects alteration of signed artifacts or receipt material.
Signer attribution links the receipt to the expected appliance or issuer policy.
Evidence bundles package proof for audit, legal, compliance, or external review.
Offline verification supports review without relying on a live vendor dashboard.
The appliance runs inside the customer-controlled environment. Keys, receipts, and evidence storage stay with the customer.
The appliance deploys into your cloud environment, keeping records, signing keys and verification under customer control. It integrates with existing applications and governance processes without requiring a separate vendor-managed verification service.
Choose HX-Provenance for direct API integration with your applications, ML pipelines and record systems.
Choose this listing when you need the private adapter that connects Vertex AI workflows to the appliance, with Cloud Storage evidence retention and optional BigQuery receipt indexing.
Choose the AWS Marketplace appliance for deployment in your AWS environment. The listing includes launch and usage instructions.
A private deployment requires agreement on packaging, integration, key custody, licensing and the evidence to be supplied.
Review the selected listing for current prices, trial eligibility, credit limits and cancellation terms. Trial eligibility and credits are specific to each listing, including Vertex AI. A separately agreed hosted API evaluation has different operating and key-custody arrangements; confirm those before sending records.
The AWS public listing, checked on , shows US$11.996 per running appliance instance-hour for software. At that rate, one instance running for 730 hours incurs US$8,757.08 in software charges, before AWS infrastructure.
Set the planned instance count and running hours, then include compute, storage, networking, integration and ongoing operation in the comparison. This calculation uses the published AWS rate; trial eligibility, negotiated offers and other deployment routes have their own terms. Budget against the selected listing and your current offer.
Review the documented evaluation example and acceptance criteria
The appliance VM, records and signing keys remain in the customer's Google Cloud project. The diagram distinguishes application traffic, evidence verification, optional customer storage and deployment-time marketplace delivery.
HX-Provenance · Private Appliance on Google Cloud
The appliance VM, records and signing keys remain in the customer's Google Cloud project.
Customer applications
Data and ML pipelines, CI/CD and compliance tooling.
POST /v1/provenance/exactAdmin API key. Issues an ML-DSA-65 signed receipt.
Third-party auditors
Regulators and your customers' customers.
POST /v1/provenance/verifyPublic and read-only, no key. Or verify offline with the release-matched verifier.
Google Cloud Marketplace
Delivers the VM image at deploy time. Not in the runtime path.
Google Cloud · End-customer tenant
The customer's GCP project, Google Cloud Marketplace Pattern 1. The whole product workload runs here, with no partner-tenant, on-premises or other-cloud components at runtime.
VPC network, customer-managed · ingress HTTPS :443 only
Compute Engine · HX-Provenance appliance VM
n4-standard-4 · 4 vCPU · 16 GiB · Ubuntu 24.04 LTS · CPU-only
:443TLS 1.2/1.3, AEAD only. Proxies requests to the service on loopback.127.0.0.1:8001ML-DSA-65 signing and verification (FIPS 204), with a per-instance key generated at first boot.10 GiB · corpus data 100 GiBCloud Storage
Your own bucket and project. Evidence-bundle exports.
Cloud Logging and Monitoring
Your own project. Ops Agent ships service and nginx logs and host metrics.
Runtime data pathDeploy time or optional
The illustrated 4-vCPU appliance configuration and the brief's 2-vCPU benchmark are different documented configurations.
The published brief explains independent review of critical records, customer control and long-term verification. It reports 214.8 receipts per second with zero errors across 1,000 requests on its documented 2-vCPU deployment.
Verify through your deployed appliance or with the supplied offline verifier. Establish the expected issuer key independently of the file being checked.
Use the documented verification endpoint in your deployed environment and inspect its complete verdict.
Read appliance documentation →Use the matching verifier, receipt or bundle, and expected issuer public key. Include the original artifact when required by the procedure.
Read offline verification steps →The hosted convenience portal is being prepared. Current public guidance explains the workflow and how to arrange an evidence review.
Review verification options →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. 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.
The substrate underneath both surfaces, for engineers, security reviewers, and procurement reviewers who need to verify the claims above.
The illustrative excerpt below summarizes fields described for 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 use canonical JSON with sorted keys and stable separators so the signed bytes and their hashes are reproducible across compatible implementations. Signatures can differ when the signing mode uses fresh randomness; verification still checks the same canonical bytes against the expected issuer key. Future-version receipts produced by newer servers are explicitly rejected by older verifiers with a structured error rather than silent acceptance.
NIST-standardized primitives, with post-quantum ML-DSA-65 signatures.
Receipt signing and verification
Authenticated encryption of evidence bundles
Content binding, signer fingerprinting
Randomness inside the module boundary
Derived keys
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.
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
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.
AWS-resident customers requiring dedicated tenancy or VPC isolation rather than shared cloud
Enterprise on-prem with vSphere or ESXi
KVM, Proxmox, and OpenStack deployments in Linux virtualization, private cloud, and federal cloud environments
Containerized enterprise deployments and air-gapped Kubernetes clusters
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.
The cryptographic substrate underneath HX-Provenance was demonstrated end to end on December 3, 2025 by signing and independently verifying results returned by a Rigetti Ankaa-3 superconducting QPU, 84 qubits, running on AWS Braket in us-west-1. ML-DSA-65 signature generation and verification applied to the returned records. 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.
Four named methods are filed as Patent Pending under the underlying provenance package.
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.
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. Specific regulatory compliance requires the customer deployment, operational practices, and audit posture in addition to the cryptographic substrate.
For a separately agreed hosted API evaluation, 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.
HX-Provenance integrates with applications through its API, SDKs and command-line tools. The selected deployment determines access, key custody and the verification procedure.
Integration options include Python and TypeScript SDKs and CLI support for Bash and PowerShell environments. Confirm the tooling and versions supplied with your deployment.
Integration covers issuing receipts, exporting evidence and checking it against an independently established issuer key.
Evaluate integration and receipt handling with representative records, including export and independent verification. Define retention requirements and acceptance criteria before a production appliance pilot.
Cloud trial terms follow the selected marketplace listing. A hosted API evaluation requires a separate agreement on access and key custody.
AI outputs, compliance records, cyber incident artifacts and other critical records that must remain independently verifiable after transfer, retention or replacement of the originating system.
The record to sign, expected issuer identity, retention requirements, and key-custody policy.
Signed receipts and exportable bundles with the material needed for offline verification.
Verification establishes integrity within its stated scope; it does not establish whether the underlying output is correct.
Availability: Google Cloud · AWS · Private Appliance · Scoped pilot.