HX-Provenance
Receipt and bundle verification for a deployed appliance, including the expected issuer key and offline workflow.
Read the offline guideRequest a proof-pack reviewOffline evidence verification
Verification requires the instructions and verifier for the product and evidence version being reviewed. For public-key signatures, the expected issuer key must be established independently of the supplied evidence. Shared-secret verification modes require their own trust material and procedure.
The downloadable HX-Provenance demo includes a synthetic signed record and standalone verifiers. Product-specific instructions below cover evidence from a deployed system. With JavaScript enabled, this page also runs the demo checks and verifies HX-Provenance receipts in your browser. Files you check are not uploaded.
HX-Provenance verification demo
The package contains a synthetic record, its ML-DSA-65 signed receipt and evidence bundle, and matching standalone verifiers. Seven cases cover valid artifacts, altered content and an unexpected issuer key.
About 70 KB. Python 3.11 or later; checked with Python 3.12. Install the supplied dependencies once, then verification runs offline without an appliance or account.
Run the seven checks in this browser
This page fetches the same package, checks every file against its SHA256SUMS, and runs the seven cases through a JavaScript port of the included verifiers. The port returns the same exit codes and messages as the Python tools.
| Case | Expected | Result |
|---|
Demo public key
HolonomiX publishes this SHA-256 fingerprint for the demo-only public key through this website. Compare it with the key in the download. For real evidence, establish your expected issuer through an independently trusted channel.
d9bf869b298636bbe7ad0226b4a4063da60b2a8ca5863a9dc9ff31b1a9f7367e
Running the included verifiers
Open a terminal in the extracted folder, then run:
python3 -m venv .venv .venv/bin/python -m pip install -r verifier/requirements.txt .venv/bin/python verify_demo.pyOn Windows, use
.venv\Scripts\python.exefor the environment's Python executable. The README also includes direct verifier commands with the expected fingerprint.Expected verification results
The original receipt and bundle must pass. The altered record, altered receipt, altered bundle, and two wrong-key checks must be rejected. The runner reports whether each of the seven outcomes matches its expectation.
Scope of the demo
These checks demonstrate signed-content integrity, artifact binding, and expected-key checks on a fictional record. The package records its source snapshot, exact verifier hashes, observed results, and reproduction environment. It is not a production release attestation, customer result, performance benchmark, or proof that a record's statement is true.
The key was created only for this example. No production signing key or customer data was used. The package contains the public key only.
Check a receipt or bundle in this browser
Verify an HX-Provenance receipt, or an evidence bundle in the json-dir format, with the same port of the demo's verifiers. Your files are read by this browser and are not uploaded.
A valid result establishes signed-content integrity under the issuer key you pinned. It does not establish that a record's statement is true. What a verification result establishes
Deployment verification requirements
Complete evidence package
Obtain the complete receipt or package, its required linked material, and the original artifact when the verification procedure requires it.
Expected issuer and trust material
For public-key signatures, confirm the issuer key or fingerprint through an independently controlled channel. A public key included in the same file does not, on its own, identify the issuer you intended to trust. HX-AIFactoryTwin also documents a shared-secret HMAC mode, which requires its supplied secret and procedure rather than an independent public-key check.
Product and version compatibility
Use the verifier and documented procedure supplied for that product and evidence version. Retain the verdict, verification context, and any failed checks.
Product verification procedures
Public guides and requests for release-specific material are identified for each product below. Use the instructions and verification tools supplied for the release being reviewed.
HX-AEIR
Package structure, independently pinned keys, linked evidence, tamper checks, and the scope of an incident record.
Read the evidence workflowDownload the guide · PDFHX-Fusion
The local runtime candidate has a release self-test, frozen qualification records and exact canonical/packet recovery checks. These are runtime checks, not independent public-key signature verification.
Review runtime qualificationHX-SDP
Release evidence and validation records for your delivered Private Appliance or scoped pilot.
Read release-verification stepsRequest an SDP evidence reviewHX-PQC
Request the lifecycle evidence and verification procedure supplied for your appliance or pilot release. Offline evidence checks do not establish full air-gapped operation of a planned edition.
Request PQC verification instructionsHX-AIFactoryTwin
Verification depends on the supplied release and signing mode. Ed25519 checks use the expected issuer public key; HMAC checks require the shared secret and its supplied procedure.
Request Twin verification instructionsHX-MDAO-TP
Request the verification material for your scoped pilot's validity and acceptance evidence. Formal certificates apply to specified invariants. Model validity and empirical accuracy require their own evidence.
Request MDAO verification instructionsInterpreting verification results
What does a successful check establish?
The verifier checks the conditions defined by its product and evidence format, such as signed-content integrity, the expected issuer key, and required linkages. Review the complete verdict for the checks performed and any reported failures.
Does a valid signature prove that an output is correct?
No. Integrity and issuer checks do not establish the factual correctness of an AI output, the validity of a physical model, legal admissibility, or the root cause of an incident. Those questions need their own evidence.
What should I do with a failed check?
Retain the original material and verification output. Follow the product procedure to distinguish an altered artifact, wrong issuer key, unsupported version, missing dependency, or incomplete package. Do not treat an unchecked or failed artifact as verified.
What does the public sample contain?
The downloadable HX-Provenance example includes a signed synthetic record, an evidence bundle, standalone verifiers, and deliberate rejection cases. Use product-specific artifacts and the matching verifier when reviewing a real deployment.
HX-Fusion runtime checks
Use the matching release self-test and frozen qualification records to inspect canonical result and packet-byte recovery. The v1.0.0-rc1 CPU runtime candidate retains decision and issuance history; it does not establish a production public-key signing authority or prove transport delivery.