Verifying a determinism certificate

Certificate structure

A Determinism Certificate is a JSON document with three top-level sections:

• provenance

  The full ProvenanceManifest: engine_version, engine_build_hash, executor, platform, op, config_digest, seed, input_oids, output_oids, wall_clock_ms, created_at, manifest_hash.

• conformance

  The evidence block: suite_version, numerics_version, backend (cpu-rust / cuda / metal), local_self_test (pass/fail). Suite version and numerics version identify which conformance vectors were checked.

• signature

  Optional. Algorithm: Ed25519. Public key ID: identifies the installation. The signature covers the serialised provenance + conformance sections. Verifying the signature proves which installation produced the certificate; it is not required to verify the output OIDs.

Exporting a certificate from Studio

In Studio, open the Provenance screen for any completed run. The Export button produces two files:

• +result.certificate.json — the machine-readable certificate for the verifier
• +result.certificate.html — a printable summary for inclusion in a paper appendix

The certificate is also written automatically to the run output directory as result.certificate.json alongside provenance.json and any report files.

Installing the free verifier

The verifier is part of the open vikshep-compute repository. Build it from source with a Rust toolchain:

git clone https://github.com/samvardhan03/vikshep-compute.git
cd vikshep-compute
cargo build --release -p vikshep-conformance

The binary is at target/release/vikshep-conformance. Add it to your PATH or use it with a full path. No account or internet connection is required after build.

Python package

The verifier is also exposed in the Python package for use in analysis pipelines:

pip install -e "backend/ingest[scattering]"

from vikshep_compute import verify_certificate
result = verify_certificate("result.certificate.json", inputs_dir="./inputs/")
print(result.status)  # "VERIFIED" or "MISMATCH"

Running the verifier

Pass the certificate file and the directory containing the original input files:

vikshep-conformance verify result.certificate.json --inputs ./inputs/

Successful output

VERIFIED  output OIDs match (12 / 12)
Tier-1 computations: 12  backend: cpu-rust  numerics_version: 3
Certificate signed by: vsk_key_abc123  (Ed25519 — key not in trust store; signature valid)

Mismatch output (tampered or different version)

MISMATCH  1 of 12 output OIDs differ

OID     expected                      got
s1_0    a3f9c2b1d4e5f6a7b8c9d0e1f2a3  7b2c4e6f8a0b2d4e6f8a0b2d4e6f8a0b

Tier-1 computations: 12  backend: cpu-rust  numerics_version: 3

A MISMATCH does not necessarily mean fraud — it may indicate a different engine version or a different numerics version. Check the numerics_version field in the certificate against the version the verifier reports. If the versions match and you still get a MISMATCH, contact the result author.

Conformance self-test

To verify that your build of the engine produces the expected conformance hashes:

cargo run -p vikshep-conformance -- hashes

This command prints the expected hash report for the current numerics version. The CI at github.com/samvardhan03/vikshep-compute/actions runs this on every commit across Linux x86_64 and macOS AArch64.

Including a certificate in a paper

The recommended citation for a Vikshep result in a paper is:

• 01Export the certificate as HTML from Studio → Provenance → Export.
• 02Include the certificate HTML as a supplementary appendix or in the data availability statement.
• 03Provide the free verifier command so reviewers can re-run the computation.
• 04Optional: include the certificate JSON in your data archive (Zenodo, CDS, etc.).

The free verifier is open source, requires no account, and works offline. A reviewer does not need to install Vikshep Studio to verify a result — only the verifier and the original input files.