Evidence Packs, Not Screenshots
A screenshot can communicate a result. An evidence pack can be inspected, checked, and re-verified later. That is the difference between presentation and portable evidence.
Research Note: presentation can summarize a result, but evidence has to travel
Highlights
- Evidence packs package reports, manifests, checksums, and verification surfaces into a portable bundle.
- The important difference is not aesthetics. It is re-verifiability.
- An evidence pack can still be weak or incomplete, so inspectable packaging and strong distributable evidence must stay distinct.
A screenshot is useful when the goal is to show someone what happened. It is weak when the goal is to let someone else check what happened.
That is the gap evidence packs are designed to close.
The public InvarLock evidence-pack docs describe a bundle that is meant to travel: reports, a reviewer summary, manifest, checksums, a package-native signature bundle when signed, and command paths for inspect, key generation, build, and verify. That is a much stronger evidence surface than a static dashboard capture.
What Evidence Packs Contain
The evidence-pack guide is explicit that the pack is not just a zip-shaped convenience wrapper. It has a structure: README.md as reviewer summary, manifest.json, checksums.sha256, report bundles, result summaries, and manifest.signature.json when the pack is signed.
That structure matters because each part does a different job.
The reports carry the evaluation outputs. The manifest describes the pack, binds its references, and now carries an evidence_level summary. The checksums file seals the hashed contents. The signature bundle makes package-native verification portable. Together they create something a third party can inspect and verify later.
Why Inspect, Build, And Verify Matter
This is where package-native commands matter more than file layout alone.
invarlock advanced evidence-pack inspect gives a read-only summary of the received pack. invarlock advanced evidence-pack keygen creates the Ed25519 signing key pair for package-native signatures. invarlock advanced evidence-pack build assembles a pack from existing artifacts, but the current docs require more than a loose artifact pointer: each --report is an explicit evaluation.report.json path, the adjacent runtime.manifest.json has to travel with it, and signed output produces manifest.signature.json. invarlock advanced evidence-pack verify then checks the manifest, checksums, bundled references, signature bundle, and bundled reports. That turns the evidence pack into an operational evidence object rather than a hand-curated archive.
The internals doc makes the verification path even clearer: the pack verifier checks manifest binding to checksums, digest-backed references, the package-native signature bundle, fail-closed behavior when the signature is missing, and nested report verification.
Inspectable vs Strong Distributable Evidence
The public docs are careful not to blur these states, and the evidence-pack story depends on preserving that discipline.
An evidence pack can be inspectable and structured without yet counting as strong distributable evidence. The public docs draw the stronger line at a signed manifest, strict verification, bundled clean reports retaining runtime.manifest.json, and a PASS final verdict.
That distinction is exactly why evidence packs are better than screenshots. They do not ask the reviewer for a vague trust decision. They expose a ladder of stronger and weaker verification states.
Why Portability Changes Review Quality
Portable evidence changes the review posture.
When a result arrives as a screenshot, the reviewer mainly decides whether the presenter seems credible. When it arrives as an evidence pack, the reviewer can inspect the manifest, check the checksum sealing, and rerun verification on the bundled reports. That is a different quality of review.
This is the real gain. The bundle carries enough structure that trust can move from "who showed me this" toward "what can I check about this."
What Evidence Packs Still Do Not Prove
Evidence packs make a deliberately bounded promise.
Evidence packs do not prove that the dataset choice was representative. They do not prove that the task answers deployment questions. They do not prove content safety or broad transfer claims. And they do not rescue a weak underlying report.
What they do secure is smaller and still valuable: the evidence bundle is portable, structured, and re-verifiable at the package level.
Claim Map
The practical path is:
- assemble reports and result artifacts into a pack
- bind them with
manifest.json,checksums.sha256, and a package-native signature bundle - inspect the pack
- verify the pack, ideally in strict mode
That is a stronger evidentiary workflow than sending a reviewer a screenshot and a paragraph.
Limitations
- This post explains the public evidence-pack workflow; it does not introduce a new evidence pack artifact.
- Portable evidence is stronger than screenshots for re-verification, but packaging alone does not prove the evaluation claim.
Sources
More in Research Note
Continue through nearby posts in the same reading thread.
Research Note
Runtime Manifests and Why Provenance Must Travel With the Result
A strong evaluation result should carry its runtime provenance with it. In InvarLock, that means the runtime manifest travels next to the report and is rechecked by invarlock verify.
Research Note
What Belongs in evaluation.report.json
An evaluation report is strongest when it is treated as a stable evidence contract: a small required core, meaningful optional blocks, and a clear boundary around what still lives outside the JSON.
Research Note
Calibration Is the Product Surface, Not a Side Utility
Calibration is not just analysis around the product. It changes how thresholds are derived, when correction paths may turn on, and which policy values later govern reports.