Verify an evidence pack (for examiners)

This page is for the examiner or auditor who received an evidence pack. You can check it on your own computer, with no network connection and no account on the institution’s appliance. The check does not ask you to trust the institution’s administrator or GigID Labs. It trusts one value you hold separately: the evidence key ID printed on the institution’s signed key registration sheet.

What you need

The pack: a ZIP file named like evidence-<serial>-<from>-to-<to>-<fingerprint>.zip, exactly as the institution downloaded it.
The key ID: 64 hexadecimal characters, from the key registration sheet. Get the sheet through a different channel from the pack, for example on paper at the start of the exam.
The verifier: the verify mode of the appliance program, which runs on Windows, macOS and Linux. Ask the institution or GigID Labs for a copy for your computer, and check it against SHA256SUMS as described in Run it on your computer. Running verify changes nothing and sends nothing anywhere.

You can also verify a pack by hand with sha256sum, jq and OpenSSL. See Verify a pack by hand.

Verify the pack

Open a terminal (Terminal on a Mac, PowerShell on Windows) in the folder with the pack and the verifier.
Run the verifier with the key ID from the sheet:
Terminal window
```
appliance verify -trust cc911e1df79b8b7b97229eb8c163c1405b581680af2cb940386f74437c7aa524 evidence-pack.zip
```
Use your own file names: ./appliance_darwin_arm64 verify ... on a Mac, .\appliance_windows_amd64.exe verify ... on Windows. The Verify tab of the institution’s Evidence page shows the same command with their key ID filled in.
Read the first line of the report: Result: PASS, or the name of what failed.

It takes well under a second for a typical pack.

If you verified an earlier pack

Give the earlier pack too. The verifier checks it first, then proves the new pack’s log extends it, so no entry from before was changed or removed in between:

appliance verify -prev last-quarter.zip -trust <key ID> this-quarter.zip

If the institution streams its log to a SIEM or emails checkpoints off the box, you can give those copies as well, with -anchor checkpoint.txt (once per file). Either way, check 6 then proves history against a copy the institution’s appliance does not control.

$ appliance verify -prev pack.zip -trust cc911e1df79b8b7b97229eb8c163c1405b581680af2cb940386f74437c7aa524 pack-week2.zipPrevious pack pack.zip: PASS, fingerprint 33f9acb1d1132b67e38b5bd0b2c35123f5b2032a84f8a034be6604fc338815f1EVIDENCE PACK VERIFICATIONResult:            PASSVerified at:       2026-10-24T09:05:24ZPack fingerprint:  64b1a70c850fe8f630ac24e249799fcc1afa1a8b5859007f97bdfbe4f9ad77cbSigner key ID:     cc911e1df79b8b7b97229eb8c163c1405b581680af2cb940386f74437c7aa524Trusted via:       trusted key IDAppliance:         DEV01 (version dev)Build digest:      67440c787f3f4a937137e06b54d84cabb5c6ff019e4034733f90e2dd1fd31983Period:            2026-07-26T04:00:00Z to 2026-10-25T04:00:00ZLog:               gigidlabs.com/appliance/DEV01, size 264Log root:          qUGW5l91GHGFMUo6h0GzK7S62Iq7wlw1l5j9rnCLctw=Entries:           264 (seq 0 to 263, 2026-10-24T08:50:26Z to 2026-10-24T09:05:00Z)Decisions:         34Reviews:           1Exceptions:        6Devices:           approved 28, not_approved 6Coverage:          100.0% of source-days since install covered (covered 4)Assurance tier:    software_protectedDetection proofs:  coverageCrosswalk:         CIS Controls v8.1 / NIST CSF 2.0 / 12 CFR 30 App. B, 364 App. B, 748 App. A (2026-10)FIPS 140-3 mode:   offAnchored to:       CHECKPOINTS NOT ANCHOREDSeparation:        SINGLE-OPERATOR MODE (one person held Admin and Reviewer)Checks:  1. Signing key is trusted (registration sheet or previous pack)   PASS     key cc911e1df79b8b7b97229eb8c163c1405b581680af2cb940386f74437c7aa524, trusted via trusted key ID  2. Manifest signature (DSSE, Ed25519) is valid                    PASS     Ed25519 signature over the manifest is valid  3. Every file matches its SHA-256 in the manifest                 PASS     44 files match their manifest digests  4. Checkpoint signature is valid and matches the manifest         PASS     checkpoint for gigidlabs.com/appliance/DEV01 at size 264 is signed by a trusted key  5. Every entry has a valid inclusion proof to the checkpoint      PASS     264 entries (seq 0 to 263) and 35 cited entries are in the signed log  6. History is consistent with earlier checkpoints                 PASS     consistent with 1 independent checkpoint(s): size 181  7. Recomputed totals match the manifest counts                    PASS     entries, decisions, reviews, exceptions, devices and coverage all match[exit 0]

A real run: the earlier pack passes first, then the new pack passes all seven checks, with check 6 consistent with the earlier checkpoint.

Read the report

The header says what the pack covers: the appliance, the period, the log size, and counts of entries, decisions, reviews, exceptions and devices, and the coverage figure. Then three disclosures that are not failures but that you should read:

Line	What it means
Anchored to: CHECKPOINTS NOT ANCHORED	No checkpoint copies are held outside the appliance yet. Check 6 can only be done with an earlier pack or an outside copy.
Separation: SINGLE-OPERATOR MODE	One person held both Admin and Reviewer, so decisions were not independently reviewed.
History: NOT CHECKED	You gave no earlier pack or outside checkpoint, so check 6 did not run. The pack can still pass.

The report also prints the frameworks the institution’s controls view refers to, as a label (the crosswalk line), and whether the appliance’s FIPS 140-3 cryptographic mode was on. Devices seen only by a network scan are counted separately, because a scan is a point-in-time snapshot, not monitoring.

The seven checks

#	Check	If it fails
1	The signing key is the one on the registration sheet, or was handed off from it with a handoff signed by both keys.	UNKNOWN SIGNER
2	The manifest’s signature is valid.	TAMPERED
3	Every file matches its SHA-256 in the manifest, and none is missing.	TAMPERED, naming the file
4	The checkpoint is signed by the same key and matches the manifest.	TAMPERED
5	Every log entry is in the signed log, in order, with its proof.	TAMPERED, naming the entry
6	History was not rewritten, against earlier packs and outside checkpoints.	HISTORY REWRITTEN, or HISTORY NOT CHECKED
7	Every total and every cited row agrees with the entries, including every bulk sign-off.	INCONSISTENT

A pack whose ZIP structure is not exactly what the appliance writes (for example one unzipped and zipped again) fails as MALFORMED before any check runs.

When the result is not PASS

$ appliance verify -trust cc911e1df79b8b7b97229eb8c163c1405b581680af2cb940386f74437c7aa524 pack-edited.zipEVIDENCE PACK VERIFICATIONResult:            TAMPEREDReason:            inventory.csv has SHA-256 00951cdee49cd0043f6c0b330b264e169f5145a4427582bbd913781b10a6e2b0, manifest says d1a167f91c009a0ede446cb27fd4b7f46653c20f11327be06d0949fdefa65532Verified at:       2026-10-24T09:05:24ZPack fingerprint:  33f9acb1d1132b67e38b5bd0b2c35123f5b2032a84f8a034be6604fc338815f1Signer key ID:     cc911e1df79b8b7b97229eb8c163c1405b581680af2cb940386f74437c7aa524Trusted via:       trusted key IDChecks:  1. Signing key is trusted (registration sheet or previous pack)   PASS     key cc911e1df79b8b7b97229eb8c163c1405b581680af2cb940386f74437c7aa524, trusted via trusted key ID  2. Manifest signature (DSSE, Ed25519) is valid                    PASS     Ed25519 signature over the manifest is valid  3. Every file matches its SHA-256 in the manifest                 FAIL     inventory.csv has SHA-256 00951cdee49cd0043f6c0b330b264e169f5145a4427582bbd913781b10a6e2b0, manifest says d1a167f91c009a0ede446cb27fd4b7f46653c20f11327be06d0949fdefa65532  4. Checkpoint signature is valid and matches the manifest         SKIPPED  5. Every entry has a valid inclusion proof to the checkpoint      SKIPPED  6. History is consistent with earlier checkpoints                 SKIPPED  7. Recomputed totals match the manifest counts                    SKIPPED[exit 4]

A real run: one row of inventory.csv was changed inside the ZIP. Check 3 names the file and both hashes.

Result	Exit code	What to do
PASS	0	Nothing. The pack is complete for its period and unchanged since it was signed.
UNKNOWN SIGNER	3	Compare the key ID you typed with the sheet. If it matches, ask the institution how the appliance’s key changed.
TAMPERED	4	A file or entry changed after signing. Ask for a fresh copy of the original download.
HISTORY REWRITTEN	5	The log no longer extends a checkpoint you trusted. Treat the pack as untrustworthy and raise it with the institution.
INCONSISTENT	6	The totals do not match the entries. Ask for a fresh copy.
MALFORMED	7	The ZIP was altered or re-created. Ask for the original download.
HISTORY NOT CHECKED	8	You gave a checkpoint the verifier could not compare. Check you gave the right file.

Exit code 2 means the command was typed wrong; 1 means another error, such as a file that cannot be read. The full meaning of each result is in Verifier results.

For scripts and SIEMs

Add -json for the same report as JSON.

Signed answers and board reports

A Rewind answer (what was connected at a past moment) is checked the same way, with -answer: appliance verify -trust <key ID> -answer answer.zip.
A board report is checked with appliance report-verify -trust <key ID> board-report.zip, which also recomputes every figure from the log and fails with NUMBERS DIFFER if one does not follow.

See the verify and report-verify references.