The Starting Point
The original CaseLens was a message browser. Law firms working on cases involving digital evidence — Slack exports, email archives, internal chat logs — need a way to review that data without handing it to an expensive third-party e-discovery platform or, worse, opening raw JSON files in a text editor.
The first build handled the core use case: load a structured case export, browse message threads with full sender and timestamp context, keyword search across the dataset, filter by channel or sender, and export findings to CSV. Read-only case states protected the source data from accidental modification. Light and dark themes for extended review sessions.
That was a complete, useful tool. Then the problem got bigger.
Phase 1–3: Distribution and the MOTW Problem
Getting CaseLens onto a law firm's server introduced the first real constraint: Windows
blocks DLLs from loading off network share paths. A --onedir PyInstaller
build that worked perfectly on a local drive failed immediately when run from a mapped
server path, because the runtime couldn't load its own dependencies.
The fix was --onefile: a single .exe that self-extracts to %TEMP%
on launch. Slower startup, but no path restrictions and no directory to manage. That became
permanent packaging discipline — every subsequent build ships as a single, self-contained executable.
The Mark of the Web (MOTW) flag is a related nuisance. Files distributed from external sources get tagged by Windows as potentially unsafe, which causes execution warnings and, in some enterprise environments, outright blocks. Stripping MOTW as a build step was added to the standard pipeline before any distribution.
Phases 4–6: The Evidence Processing Suite
Legal discovery isn't just text. Cases increasingly involve video recordings, photographs, screenshots, and other media that need to be reviewed, catalogued, and included in evidence documentation. That's what the Evidence Processing Suite (EPS) addressed.
Phase 4 added frame extraction from video evidence using vendored FFmpeg — bundled directly into the executable so there's no separate install required on the target machine. Given a video file, CaseLens extracts frames at a specified interval, names them with timestamps, and writes them to a structured output directory.
Phase 5 added OCR via Tesseract, also vendored and bundled. Extracted frames (or any image evidence) can be run through OCR to produce machine-readable text — useful for screenshots of text conversations, document photographs, or any image where the text content matters more than the visual.
Phase 6 produced contact sheets: grid-format PDFs of extracted frames with timestamps, designed for efficient attorney review. Instead of opening 200 individual images, a reviewer gets a document that shows the full timeline at a glance and can flag the frames that matter.
Phases 7–9: Chain of Custody and Pipeline Automation
Legal evidence has an integrity requirement that most software doesn't: you need to be able to prove that what you're reviewing is what was originally collected, and that it hasn't been modified.
Phase 7 added SHA-256 hash verification for all evidence files. Every file in a case gets a hash computed at intake, stored in the case record, and verified on subsequent loads. Tampering shows up immediately as a hash mismatch.
Phase 8 built out the evidence PDF pipeline — packaging extracted frames, OCR output, contact sheets, and metadata into structured PDF evidence packages formatted for legal use.
Phase 9 was the automated pipeline button: a single UI control that runs the full evidence processing sequence — extract frames, run OCR, generate contact sheets, compute hashes, produce evidence PDFs — in one operation. What had been a multi-step manual process became one click.
Deployment
CaseLens was deployed to P:\Support Staff\Tools\CaseLens on the Adams Jones
server. The initial --onedir build failed (the DLL load issue described above).
The repackaged --onefile build — a single CaseLens.exe at ~22MB —
validated cleanly and has been in active internal use since deployment.
No third-party licensing. No install procedure. One file, copied to the server, available to every machine on the network that can reach that share.
What Nine Phases Actually Means
This didn't get planned as a nine-phase build. It got planned as "build a message browser" and then expanded as the real use case revealed itself in a working environment. Each phase addressed something that only became visible once the previous one was actually being used.
That's not scope creep — that's the difference between building for an imagined user and building for a real one. The tool that got deployed is substantially more valuable than the tool that was originally scoped, because the scope was informed by what the real workflow actually required.