The EMP Export Package format

The EMP Export Package format

Open spec · EMP-EXPORT v1.0

EMP case packages use a documented ZIP or folder layout. Included content depends on export selections and licence entitlements. With Manifest enabled, the package includes JSON, checksum text, a manifest PDF and a standalone verifier. Password-protected ZIPs require Manifest; standalone reports and workspace backups use separate formats. We publish it because an export only verifies without the vendor if the format the recipient checks against is open. Here it is, in full. SHA-256 is the integrity check. The product is the case workspace around it.

Who this is for: the person on the receiving end of an evidence package, opposing counsel, a court, a peer agency, or an integrator who has to confirm the files are unaltered and read them into another system.

The package: a versioned ZIP, fixed layout

One click produces one package: a ZIP, or an uncompressed folder of the same name. The structure is stable, so a recipient always knows where to look and a script can validate it without guessing. Folders depend on selection, entitlement and eligible retained content. Core supports case-package export; Standard and Professional add Audit Timeline, Chain of Custody and Incident Maps, while Professional adds Timeline Recon and Link Analysis.

The package ships as a ZIP or an uncompressed folder. A password-protected package is a WinZip AES-256 compatible ZIP, and the Manifest is always included in that case.

manifest.json: the source of truth for the files

Plain JSON. It records the case, who exported it and when, the producing software version, and one entry per object with that object's own SHA-256, grouped by artifact type. The checksum of the finished ZIP itself is a separate integrity layer and lives outside the package (see the container hash, below).

Each object entry

Common integrity fields are sha256, relativePath, filename and sizeBytes. Intake metadata applies where the entry type supplies it; generated reports do not have to include importedAt.

The container hash: recorded outside the ZIP

The manifest is written before the archive is built, so it can describe the file checksums but does not contain the hash of the finished ZIP that carries it. After the ZIP is complete, EMP computes SHA-256 over the exact archive bytes and records that value in the package record and the append-only export audit metadata inside EMP, outside the package. EMP's own verification rehashes the on-disk ZIP and compares it with that stored value. A recipient who wants to verify the exact ZIP container, rather than the extracted files, needs that expected value from the exporting party's EMP record or another trusted channel.

How do you verify an export package?

With Manifest enabled, the package includes a standalone verifier. Command-line tools can check the listed file hashes, but do not reproduce all package-policy checks.

1. Extract the package, keeping the folder structure intact (supply the password first for a protected ZIP).
2. In a browser: open verify_integrity.html from the extracted package and point it at the extracted folder. It re-hashes every file against the manifest and reports each as intact, modified, or missing, with nothing uploaded.
3. On the command line: from the package root, run sha256sum -c "Manifest/manifest.txt" (or Get-FileHash in PowerShell for a single file). Investigate mismatched, missing or unreadable files separately. Get-FileHash calculates a hash; compare it with the expected value. The checksum list does not detect arbitrary extra files.

# GNU coreutils / WSL: check listed files from the extracted package root
sha256sum -c "Manifest/manifest.txt"   # → OK / FAILED, per file

# PowerShell: calculate one file hash, then compare the expected value
Get-FileHash "Files\Evidence\CASE-2026-0272_evidence.png" -Algorithm SHA256

To verify the exact ZIP container as well, ask the exporting party for the recorded package hash (EMP stores it in the package record and export audit metadata, outside the ZIP) and compare it with the SHA-256 you compute over the ZIP file itself.

Prefer the hosted route? The free in-browser verifier on our site runs the same SHA-256 checks locally. Use a supported ZIP or an extracted folder, with nothing uploaded. Extract protected ZIPs first and follow the verifier's instructions for unsupported or large archives.

A passing verification shows one thing: the checked bytes match the supplied manifest. A manifest alone does not authenticate the sender; retain the expected package hash through a trusted channel. It is not proof of admissibility; the court decides that. EMP is NIST SP 800-86 / 800-101 aligned as a design target, not certified, and is tamper-evident, not tamper-proof.

Versioned and open

This is EMP-EXPORT v1.0. The format is versioned and additive: later versions may add optional fields, and the manifest always records the producing software version. This page describes the current package format. Manifest-enabled packages include verify_integrity.html for recipient checks without EMP.

Put the format to the test

The spec is only useful if you can act on it. Two free, self-serve ways:

• Verify a sample export in your browser: drop in an EMP package and re-hash every file against this manifest, nothing installed, nothing uploaded.
• Start the 14-day trial and produce your own export, then check it against the format described here.