Skip to content
HolonomiX

Offline 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. A hosted upload verifier is not yet available.

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.

Download the verification demo · ZIPRead the package instructions

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.

  • 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.py

    On Windows, use .venv\Scripts\python.exe for 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.

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

Interpreting 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.

Downloadable verification example

Return to the evidence indexCheck product-specific controls