Skip to main content

Preserve & Store

TECHNIQUE
📖15 min read

Introduction​

This is Stage 2 of the Research Gate. Collect registered what each source is and fingerprinted it at capture; this stage protects it for the whole life of the project.

The stage has two jobs. Protect the originals: untouched, fingerprinted, findable later. Structure the working copies: a folder layout, naming, and versioning that let you find any file in seconds and show where it came from. Both jobs serve two purposes: efficiency (a 3D project can get very messy, very fast, and without structure you lose time to file hunting and broken links) and accountability (every later stage of the gate produces a claim, and a claim stands or falls on whether its input can be found and proven unchanged).

CRITICAL: Nothing you store is safe until you can find it and prove it is unchanged.

Findability

A good system lets you find a specific file quickly, without remembering where you put it.

Chain of Custody

You need to be able to prove exactly where a file came from and that it has not changed since you received it. Hashing is how you do it.

Reproducibility

Your folder structure is documentation, organization is evidence. Built well, it lets another person understand your process and continue it without you.

What this page is, and is not​

This page is about what happens after a source is registered: you protect the original, keep it separate from everything you work on, and build a layout that makes both findable and provable.

It is not about finding data (that was collect), not about judging whether anything is true (that is analyze), and not about transforming files (that is process).

The Vault​

Call it what you want: vault, sanctuary, master archive. We call it the vault. The name does not matter; the properties do. The first rule of data management is the protection of source material, and the vault is where that rule lives: a protected directory, kept read-only, outside the working tree where you do the work.

  • Create the vault (e.g., /00_Vault) and set it to read-only for everyone.
  • Save all sources here exactly as received or downloaded: same file, same name, same bytes.
DO NOT MODIFY ORIGINALS

Rule #1: Never open an original evidence file in an editor and hit "Save". Rule #2: If you need to analyze a file, make a copy first. Rule #3: Keep originals in a read-only folder, and make sure every original has a hash in the log.

If you accidentally crop a photo or re-save a video with a different codec, you have altered the evidence. The pristine archive is what lets you go back to the source and verify your findings, and it is what you show a reviewer.

The Berkeley Protocol Connection

The Berkeley Protocol[1] warns that digital evidence is easily altered, and its preservation guidance points the same way: keep the original untouched and work on copies. In folder terms: a vault for the originals, a working tree for the copies.

The Evidence Log​

The fingerprint already exists: collect hashed every source at the moment of capture, and ideally every source carries an independent timestamp, so each entry stands on its own. Every source is in the log, the same way.

A hash (SHA-256) is a digital fingerprint of a file: if even one pixel changes, the hash changes completely.

The log is one place where you keep these records. Call it what you want and keep it in whatever shape you want: a CSV file is handy, a database works, a spreadsheet works. What matters is the structure, not the container. Two kinds of entries:

  • Source entries (one per source): what it is, where it came from, when you got it, the hash.
  • Custody entries (one per handover): date, from whom, to whom, hash before, hash after.

The source entries come from collect; you add the custody entries below. The log is append-only: a correction adds an entry, it never rewrites one.

See what this looks like in practice: evidence-log-example.csv is a small log with placeholder values: three source entries, two handovers, one verification pass. Use it as your starting file and replace every placeholder with your own values.

Make the log complete: every file in the vault has a row, and every row has a hash. Every source that has no hash is a hole in the chain: hash it and add the row before anything else happens.

The custody record​

From this stage on, the log tracks three things: what is in the vault, who has custody of it, and when it changes hands. A transfer to another person or system is a log entry: date, from whom, to whom, hash before, hash after. That running record is the chain of custody: the chronological documentation of the custody, control, and transfer of the evidence. The Berkeley Protocol uses the same definition[1], and NIST's preservation guidance states the formal rule: evidence is stored so that the integrity of the original data is preserved and the data stays accessible for the duration of custody[12]. A reviewer who reads the log can replay the life of any file.

Routine copies are not custody events. Copying a file out of the vault does not change the evidence, and the hash makes the link: a working copy whose hash matches the vault row is proven to come from it. What does get logged is what you do to the copies: process records every processing step, one line each (what changed, which tool, which settings). Together they close the chain: the original sits in the vault, the copy is tied to it by hash, every change on the copy is recorded, every handover is signed.

You do not need a special system for this. The log is the system, whatever shape it takes. Every entry you add is a link in the chain.

Work on Copies, Never on Originals​

Create the working tree and copy all source material into it. All analysis and processing happens on these copies, never on the vault. Originals and working files never share a folder.

Group by source. Sort the working copies by physical device or origin (e.g., "Source A - CCTV North", "Source B - Witness iPhone"), and give each source its own directory.

Anticipate what process produces. Process will segment the footage into clips and extract frame sequences. Reserve the subfolders for those outputs before they exist, so the segments land in the right place when they do. Which copies are safe to transform is marked by the folder:

/00_Vault                             <-- protected, read-only: the file exactly as received
  [Project]_Master_Compilation_Copy.mov
/01_WORKING_COPIES
  /01_SOURCES
    /SRC_A_CCTV_North
      /Footage <-- The segmented video clip (ProRes/DNxHR)
      /Image_Seq <-- The full PNG/EXR sequence extracted from footage
      /Stills <-- Specific keyframes picked for reference
      /Work <-- Undistorted/Sharpened versions
    /SRC_B_Mobile_Witness
      /Footage
      /Image_Seq
      /Stills
      /Work

The vault sits outside the working tree, untouched; within each source, the Footage/Image_Seq/Stills/Work subfolders mark which copies are safe to transform.

Structure the Working Tree​

There is no single "correct" folder structure, but any valid structure should separate evidence from analysis.

Strategy 1: The Forensic Standard (Evidence-First)​

This structure is designed for accountability. It clearly demarcates the status of every file.

Project_Name/
├── 00_Admin/                  # Methodology notes, logs, correspondence
├── 01_Originals/              # Read Only
│   ├── Received_2024-05-10/
│   └── Received_2024-05-12/
├── 02_Working_Copies/         # Where you actually open files
│   ├── Processed_Images/      # Cropped, brightened, annotated
│   └── Transcriptions/
├── 03_3D_Workspace/           # Your Blender environment
│   ├── Assets/
│   ├── Scenes/
│   └── Textures/
└── 04_Outputs/                # Renders and Reports

Why this works for Chain of Custody:

  • Chronological Intake: The 01_Originals folder is often organized by when data was received, not just what it is. This preserves the timeline of evidence collection.
  • Clear Separation: It is impossible to mistake a processed image for an original.

Strategy 2: The Workflow Flow (Process-First)​

This approach follows the lifecycle of the investigation.

Project_Name/
├── 01_Gather/                 # All raw inputs; pristine files stay read-only here
├── 02_Process/                # Intermediate analysis & cleanup
├── 03_Reconstruct/            # Blender files & modeling
├── 04_Analyze/                # Measurements & simulations
├── 05_Present/                # Final renders & reports
└── 99_Archive/                # Dead ends & old versions

Why this works for Findability:

  • It maps to your mental model of "doing the work."
  • It keeps the active directory (03_Reconstruct) focused on the current task.
  • The separation still holds: untouched files inside 01_Gather stay read-only, and copies move down the pipeline.

Strategy 3: The Hybrid 3D Pipeline​

For complex Blender projects, you need a structure that supports relative paths while maintaining forensic integrity.

Case_ID_Project/
├── 01_Evidence_Vault/       # Hashed, read-only originals
├── 02_Project_Assets/       # The "Blender Root"
│   ├── Reference_Images/    # COPIES of evidence, optimized for Blender
│   ├── Textures/            # Surface maps
│   ├── Models/              # .blend files of individual assets
│   └── Scenes/              # .blend files of reconstruction scenarios
├── 03_Renders/              # Output frames
└── 04_Edit/                 # Video assembly
Relative Paths are Key

In Blender, use Relative Paths (File > External Data > Make Paths Relative). This allows you to move the entire Case_ID_Project folder to an external drive or archive without breaking texture links.

Naming​

A filename is the first piece of metadata you see. A good name tells you what it is, which project it belongs to, when it was made, and which version it is, without opening it.

The "Smart" Filename​

Construct filenames using consistent blocks: [Date]_[Project]_[Description]_[Version].[Ext]

  • Date: 2024-05-20 (ISO 8601 format: YYYY-MM-DD. Sorts chronologically.)
  • Project: Case402 (Keeps files grouped if they get moved.)
  • Description: SitePhoto_NorthWall (Be specific but concise.)
  • Version: v03 (Useful for tracking changes.)

Bad: test.blend, final_final_v2.jpg, DCIM4022.JPG Good: 2024-05-20_Case402_SiteModel_v03.blend

Pick the convention once, and it is the one you keep for the whole project. A naming scheme that survives handover is one a stranger can sort by date and project without asking you.

Versioning​

In 3D work, files corrupt and approaches fail. Versioning is your safety net.

  • Incremental Saves: Use Blender's + button in the Save dialog to auto-increment (Scene_v01.blend -> Scene_v02.blend).
  • Milestone Saves: Before a major change (e.g., "Applying all modifiers"), save a version named Scene_v05_PreCollapse.blend.
  • The "Published" Folder: Keep your working folder full of versions, but copy only the final, approved version to a Published or Master folder. This prevents linking to unstable work.
  • Never overwrite an unversioned file. If a file has no version number, it has no undo.
Version the software, not just the files

A reconstruction must be re-runnable years from now. For every tool that touches the work, record tool name, version, key settings, and date in the project record. Process adds one row per processing step. And hash derived products alongside originals: the log holds original + derived pairs, so any working copy can be tied back to the exact file it was made from.

Durability​

Preservation is not complete until you have answered: where is this stored, and is it protected against loss or tampering?

  • Where: the working copy lives on the machine you work on; the vault and the evidence log need at minimum an off-site copy (cloud, external drive). For a long-running project, keep a third copy offline. Back up before you need it.
  • Access control: Who can modify the vault? Read-only permissions for everyone but a designated custodian; collaborate covers how custody moves between people.
  • Re-hash on a schedule, not only on handover: storage media degrade silently (bit rot), and files can change with nobody touching them. The archival practice is called fixity, and its framing is plain: fixity is the digital equivalent of storing paper in acid-free folders[8]. The loop: hash at receipt, store the hashes, re-hash on every access or move[8]. A mismatch means tampering or media failure; either way, restore from the known-good copy and re-verify.
  • Longevity: Choose formats that won't require legacy software to read later; keep the evidence log alongside the data, not in a separate system.
Chain of custody note

The presence of backups is an additional safety net for the chain of custody that began in collect: if an original is ever lost, the backup + hash log allows you to prove what the pristine source was.

Keep the Seal​

The practice above, named: the fixity loop. Hash at intake (collect), re-hash on every move and on a schedule (Durability), and re-verify before every handover. Log each verification in the evidence log.

How to verify​

  1. Recompute: run the hash function (SHA-256) on the file now.
  2. Compare: the hash must match the log. If it matches, the file is byte-identical to the one hashed at intake. If it does not, stop: investigate before touching anything else.
Hashing tools
  • Windows (PowerShell): Get-FileHash filename.jpg
  • Mac/Linux (terminal): shasum -a 256 filename.jpg
  • GUI: tools like QuickHash or HashCheck integrate into the file explorer.

The handover package: BagIt​

Handing work to a court, a client, or a collaborator means the archive has to stand on its own: a stranger should be able to verify in minutes that nothing changed. The formal option is BagIt (RFC 8493[2]).

BagIt is a format, not software. The RFC defines a packaging layout: a folder with a manifest and some tag files. There is no vendor, no license, no installation. Any tool that writes a hash can implement it. The reference tool is bagit-python, maintained by the Library of Congress: pip install bagit, then bagit.py on the command line[7]. The Forensic Capture extension from collect can also export bags, with an offline verifier.

A bag is a folder with three required parts:

  • bagit.txt: the bag declaration: the BagIt version and the character encoding of the bag's text files.
  • manifest-sha256.txt: a list of every file in the bag with its SHA-256 fingerprint. This is the machine-checkable evidence log.
  • data/: the files themselves, unchanged.

bag-info.txt is optional and holds the project metadata: who packed it, when, with which software. An optional tagmanifest-sha256.txt fingerprints the tag files themselves, so the seal covers the seal.

Packing a bag is one command. Verification is one command: the tool recomputes every fingerprint and compares it with the manifest; if anything changed, the seal fails.

You do not need BagIt for every project. A hashed, read-only master folder plus the evidence log carries most investigations. BagIt is the step up for when the work leaves your hands.

The conformance line

bag-info.txt can hold one line declaring which standards the bag follows, e.g. ISO/IEC 27037; BagIt RFC 8493 v1.0; CASE/UCO; RFC 3161. The receiver then knows which rules the seal obeys without opening a single file.

Beyond BagIt​

  • The bare minimum: a hashed, read-only folder plus a manifest file you can check with one command (sha256sum -c manifest.txt on Linux/macOS). This is DIY BagIt: fine for small projects where no receiver expects a standard.
  • RO-Crate[10]: packaging for research products. The same bag idea, plus identifiers and FAIR metadata; it can wrap a BagIt. It is the step up when the output becomes a research artifact that others cite. Chard et al. developed BagIt-RO exactly at this seam: a bag that carries the analysis context (tools, versions, parameters) with the data is the one a third party can re-run and check[9].
  • C2PA / Content Credentials[11]: a different axis, not a replacement. C2PA records content provenance inside the media (who created it, what changed); BagIt proves the bytes did not change. A source file can carry both.
  • The field's shortlist: repositories that package digital material compare a small set of formats; a late-2025 survey compared five, and BagIt and RO-Crate were on the list[13]. For an integrity-first handover, BagIt remains the default.

The Standards Behind This Practice​

The practice on this page follows the same rules that professional digital forensics follows. The main standards, in plain words:

StandardWhat it isWhat it covers here
ISO/IEC 27037:2012[3]International guidelines for the handling of digital evidenceThe four verbs of the whole pipeline: identify, collect, acquire, preserve
SWGDE 18-F-002 v2.0 (2025)[4]Working-group best practice for collecting items that contain digital evidence (computers, storage media)The care rules: collect without altering, and document how
BagIt, RFC 8493[2]A standard package for digital evidence with a built-in manifestThe handover archive: declaration, manifest, and payload in one verifiable folder
CASE[5] / UCO[6]Community ontologies (machine-readable vocabularies) for describing digital investigationsHow to describe evidence and custody steps so other analysts and tools can read them
NIST digital evidence preservation[12]Guidance for evidence handlers on storing digital evidence under custodyWhere it survives: integrity preserved, access ensured, custody documented

Summary​

This stage turns "I have the files" into "I can find them and prove they are unchanged." In order:

  1. Vault. A read-only folder for the originals, outside the working tree. You work on copies, never on the originals.
  2. Log. Every original is fingerprinted at capture (collect); custody rows record who holds the vault and every handover. The log is the chain of custody.
  3. Copies. Working tree by source; the subfolders mark which files are safe to transform.
  4. Structure. One layout that separates evidence from analysis, applied consistently.
  5. Naming. One convention: date, project, description, version. The one you pick is the one you keep.
  6. Versions. A version before any change you cannot undo; tools and settings recorded; derived products hashed alongside originals.
  7. Survive. An off-site copy, a designated custodian, a scheduled re-hash (bit rot is silent).
  8. Seal. Re-verify before every handover; BagIt when the work leaves your hands.

The stage ends where Verify begins: the originals are sealed in the vault, the log is open, and the material is ready to be judged.

Resources​

  • Research Gate, Stage 2 of the gate: this page
  • Verify, next stage: is this material what it claims to be?