When a file enters a case, EMP Intake records what it is and hashes it with SHA-256, and preserves that original unchanged. Evidence you derive from an intake records a link back to the file it came from. Statements, locked incident maps, and export packages each retain their own hashed artifacts, and every material change to the case is written to an append-only audit record. A reviewer can check included files and follow the source relationships recorded by each supported workflow.
1. The five integrity objects
The EMP Intake data model has five integrity objects. Audit-log and custody-event rows cannot be updated after insert; protected evidence hashes and package integrity fields cannot be changed once written. Ordinary case and evidence metadata may be updated, with those changes recorded in the audit trail. Statements, Incident Maps and Timeline Recon also keep workflow-specific records and artifacts. Statements and locked incident maps also retain their own hashed, chained artifacts.
- Cases: the top-level investigation. Number, status, investigator, and lifecycle timestamps.
- Evidence items: digital files and physical-item records. Imported files have a SHA-256 baseline and captured source timestamps. Physical items have descriptions and custody history; attached digital photos and documents have their own file-integrity records.
- Custody events: recorded transfers and handling actions, append-only. Where a supported associated digital file is available, EMP computes a verification hash for that file, not the physical object.
- Packages: export records, each carrying its own integrity hash and a sequential version number.
- Logs: the append-only audit trail.
2. Intake objects: the canonical originals
An intake object represents a file as it first crossed the threshold into the case. It is hashed once, on arrival, and never modified. Its bytes live in a case-scoped evidence library on the workstation, with that arrival hash recorded against the evidence record. EMP captures available source-file timestamps at intake. The operator records the source device and other intake details. When you derive a new evidence item from an intake, EMP records the parent it came from and the method used, so the export package can trace derived evidence back to the original it descends from.
3. Derived evidence, working material, and annotations
Derived evidence (a copy, an extraction, a screenshot) is registered as its own evidence item that records the parent it came from and how it was derived. The original is never modified, and its intake hash stays verifiable. Working material you add while building the case (notes, tasks, findings, and typed entities) is recorded in the case, and material case, evidence, and custody changes are written to the append-only audit trail with the acting user and time. EMP does not claim that every note or interface edit becomes a new, separately hashed object.
4. Provenance and the audit record
Provenance is recorded where the workflow supports it, rather than as one universal graph over every object. Evidence carries its intake hash and its derived-from lineage. Each finalized Statement retains a hashed PDF, chained to the prior revision's hash. Each locked incident map retains a hashed PNG, never rewritten, with predecessor chaining. Each export package records its own container hash and a sequential version. Around all of it, the append-only audit log records the material case, evidence, custody, administrative, and export events, so what happened to the case stays on the record. High-frequency reads, navigation, and display preferences are intentionally left out of the append-only trail.
- Intake: the canonical original, hashed on arrival.
- Derived evidence: a copy or extraction that records its parent and method.
- Retained artifacts: finalized Statements, locked incident-map PNGs, and export packages, each independently hashed.
5. How the schema is serialized at export
At export, the objects and their recorded relationships are serialized to a versioned ZIP: each object emitted alongside the hash that identifies it, the originals bit-for-bit, and a manifest that indexes the whole package. The manifest records hashes for declared exported files, including originals, retained artifacts and generated reports. Source relationships are included where the workflow records them; the completed ZIP hash is stored separately in EMP's package and export-audit records. The exact byte-level layout is documented on the export-packages page.