LOCAL VERIFYAligned: 2026-03-14

Verify EPI Rail packs locally.

Technical reviewers can use epi-cli locally once a full reviewer pack or controlled demo bundle is on disk. First-touch reviewers should start with the curated /proof preview. EPI Viewer sits between those two layers when a full pack is available.

The public trust layer is /proof. The local integrity layer is /verify. The full reviewer pack remains the complete artifact layer.

Local verification confirms that the pack on your machine still matches the expected Civitas structure and emits its own pass/fail record.

Preview sandbox Curated proof preview View EPI Rail

Where verify fits

Use /proof to inspect the curated public preview. Use EPI Viewer to review a complete pack when one is available. Use /verify to confirm locally that the full pack on disk still matches the expected Civitas structure.

What it confirms

Required files, schema validity, mismatch state, and verifier posture, with a stable JSON record the reviewer can retain.

Why local matters

The reviewer runs the check on their own machine after delivery or controlled download. Trust comes from the delivered artifact set and the local result, not from a remote assertion.

What to inspect first

Economic buyers should start with /proof. Technical reviewers should move to EPI Viewer and the CLI once a full pack is available.

Choose the review path

Both paths answer the same question: does the full pack on disk still match the Civitas artifact contract?

Reviewer path without CLI

Start with /proof to understand the curated preview and the artifact boundary.
If you have the full pack, open it in EPI Viewer and confirm the pack is readable and the verification posture is legible.
Use the CLI only if you need replayable local confirmation.

Reviewer path with CLI

Start from a full reviewer pack or controlled demo bundle stored locally.
Run the exact epi-cli verify command below with --json.
Read ok, missing_files, schema_errors, and mismatches; treat ok: false as an invalid pack until rebuilt.

What to inspect in 60 seconds

Start from a local full reviewer pack or controlled demo bundle.
Run verify to emit verify.json and confirm the outcome.
If needed, compare the result against the artifact boundary described on /proof.

Signals that matter

ok: true means the pack passed the aggregate verification check.
missing_files should be empty for valid bundles.
schema_errors and mismatches should both be empty for a clean pack.
verifier_ok should be true; verifier_json.checked_entries_count shows how much was actually checked.

Where pack identity lives

Pack identity metadata is carried by the decision-pack contract inside the full reviewer pack, under pack_meta.

The curated /proof preview summarizes that identity without exposing the full raw contract by default.

Local verify commands

Start with /proof for the curated public preview. Move to EPI Viewer once you have a full pack. Use CLI only for replayable local confirmation.

Run the command below against a local pack.zip. If a checksum file was provided in customer delivery, compare it locally after verify completes.

Troubleshooting / Support pack

$pack = ".\pack.zip"
.\tools\epi\epi-cli.exe verify $pack --json | Out-File -Encoding utf8 .\verify.json

Get-Content .\verify.json

if (Test-Path ".\SHA256.txt") {
  Get-FileHash .\pack.zip -Algorithm SHA256
  Select-String -Path .\SHA256.txt -Pattern "pack.zip"
}

DecisionPack.pdf is derived from DecisionPack.html. PDF hashes can still vary with Chromium metadata fields such asCreationDate,ModDate, andID. Verification should treat the full pack plus verify.json as the integrity anchor; PDF variance alone does not imply evidence drift.