Most testing tools hand you a dashboard. Dashboards are great until someone asks the only question that matters in an audit, a security review, or a dispute: "How do I know this is true?"

QuantumVerifi answers that with the Evidence Bundle — a sealed, replayable record of a single verification run. One click from any completed report. It stands on its own: every claim in it is bound to evidence you can recompute yourself, on your own machine, without trusting QuantumVerifi at all.

This post covers what it is, how to use it, why it's safe, and — the important part — how it actually proves what happened.

The purpose: a verdict you can defend#

A QuantumVerifi run ends in a verdict — Verified, Not Verified, a grade, a set of findings. The Evidence Bundle is the paper trail behind that verdict. It exists so the verdict survives contact with a skeptic.

Concretely, it's built for the moments where "trust me" isn't good enough:

Audits and compliance — healthcare, finance, and government reviewers need an artifact they can file, not a URL that might change tomorrow.
Security sign-off — a confirmed finding needs to come with the exact evidence that confirmed it.
Release gates — attach the proof to the PR, not a screenshot.
Disputes — when someone says "it worked on my machine," the bundle says what actually ran, when, and what it produced.

The governing principle behind the whole system is simple: a verdict is only ratified from executed evidence, never from a semantic match. Nothing in the bundle is a guess about what should have happened — it's a record of what did.

What's in the bundle#

The Evidence Bundle ships in two tiers over the same underlying data:

The auditor-readable HTML — a self-contained forensic document titled "Sealed, replayable proof." Open it in any browser, print it, email it. It has:

A masthead identifying the run — target, mode, timestamp, run ID.
A verification banner — green when the chain is intact, red when it isn't — with the counts and the chain head.
Run metadata — the analysis ID, verdict, grade, and the values needed to re-verify.
Findings as exhibits — each one stated plainly: the issue, its detail, its severity, its remediation priority.
The evidence chain lineage — the tamper-evident core (more on this below).
An artifact manifest — every screenshot, video, trace, and report, with its size and SHA-256.
A "how to verify this bundle yourself" section with the exact steps.

The machine-verifiable JSON — the same run, structured for a script. This is what you run your own verifier against. The HTML is for humans; the JSON is for proof.

How to use it#

From any completed report, open the verdict panel. Next to the sealed evidence chain you'll see two controls:

Evidence Bundle — opens the human-readable HTML brief in a new tab. This is the one you send to an auditor or attach to a ticket.
JSON ⭳ — downloads the machine-verifiable bundle (evidence-bundle-<run>.json).

That's it. There's no configuration, no separate export pipeline, and nothing to enable. Every run produces one.

A few things worth knowing:

The HTML is completely self-contained — no external fonts, scripts, or images. It renders offline, years from now, with nothing to phone home to.
It's print-safe. Print to PDF and it switches to a light, ink-friendly document. That PDF is a perfectly good archival copy.
Access is tenant-authenticated — a bundle is scoped to the run's owner, so exporting one never leaks it to anyone who shouldn't have it.

Why it's safe#

Three properties make the bundle safe to move around and safe to rely on.

It's self-contained. Because the HTML pulls in no external assets, there's nothing to compromise after the fact — no CDN that could be swapped, no tracker embedded, no live call that could change what the document says. What you archive is exactly what you'll read later.

It's tamper-evident. The bundle isn't just a list of facts; it's a chain of them. Every event is SHA-256 hashed together with the hash of the event before it. Change any single event — a timestamp, a result, a hash — and its hash changes, which breaks the link to the next event, which breaks every link after that. Tampering doesn't get hidden; it gets exposed, all the way down the chain. If a run's chain is broken, the banner turns red and says so, and every downstream claim is flagged as unproven. The system is designed to make tampering visible, not deniable.

It requires no trust in us. This is the one that matters. The verification steps are printed right in the document, and they run entirely on your side. You don't have to believe QuantumVerifi's math — you re-do it.

How it proves#

Here's the mechanism, concretely.

Every artifact is hashed at capture. When a screenshot, trace, or report is produced during a run, its SHA-256 is computed at that moment and written into the chain. In the manifest these are marked BOUND — the strong seal. A BOUND artifact can't be quietly edited later, because its hash is already committed into an immutable chain of events.

Every event links to its predecessor. Each entry in the lineage carries its own event_hash and the prev_event_hash of the row above it, starting from a genesis event. This is what turns a pile of logs into a chain: the order is cryptographically fixed. You can't insert, delete, or reorder events without every subsequent hash disagreeing.

One hash fingerprints the whole run. The final event — chain.sealed — produces the chain head. That single 64-character hash stands in for the entire run. Publish it, sign it, put it in a ticket. Anyone who later recomputes the chain and lands on a different head knows the record was altered.

Findings are bound to that evidence. A confirmed finding in the bundle isn't a lone assertion — it points at the sealed artifacts that back it: the trace that reproduces it, the screenshot that shows it. And because the strongest evidence in QuantumVerifi is replayable — Playwright traces you can step through frame by frame — a finding isn't "we say so," it's "here's the recording, watch it happen."

Verify it yourself, in three steps

From the JSON bundle, a reviewer with nothing but a SHA-256 implementation can confirm the whole thing:

Re-hash the chain. For each event n, recompute sha256(canonical(event_n) + hash_{n-1}) and compare it to the stored hash_n.
Re-hash the artifacts. For each BOUND artifact, recompute sha256(artifact bytes) and compare it to the manifest.
Check the head. Confirm the final event hash equals the published chain head.

If all three hold, every claim in the document is bound to evidence that hasn't been altered since capture. If any fails, treat the run as unproven — which is exactly the point. The bundle doesn't ask you to trust a green checkmark. It hands you the tools to break it, and lets you conclude it's real when you can't.

The short version#

The Evidence Bundle turns a verification run into something you can hold: sealed at capture, linked into a tamper-evident chain, fingerprinted by a single hash, backed by replayable traces, and verifiable by anyone — offline, without us in the loop.

A dashboard tells you it passed. An Evidence Bundle lets you prove it did.

Run a verification, open the report, and click Evidence Bundle. The proof is already there.