Studio Footage Library

Problem

Evolve Studio's archive of drone and interior home-tour footage, 24,409 files at its frozen baseline, sat on an external drive with no reliable way to know what was in it, where a given clip lived, or whether it was safe to sell. Files were unorganized by house, some folders held return-visit or interleaved clips from more than one property, and nothing distinguished footage that had been checked for visible house numbers, personal information, or other people's homes from footage that had not. Selling any of it as B-roll or as a whole-home package required an answer to two separate questions the raw archive could not answer on its own: which house is this, and is it actually clear to publish.

The stakes of getting the second question wrong are asymmetric. A pack or a home listing ships as a fixed digital product the moment it is uploaded and linked; a clip that shows a readable house number, a phone number, or an unrelated person is not something that can be quietly recalled once a buyer has downloaded it. A one-time manual scan does not scale to tens of thousands of clips and does not survive being redone after the archive itself gets reorganized, since files move as houses are identified and folders get renamed. The build treats data-loss risk from bad moves and disclosure risk from unverified footage as the two failure modes that must be structurally prevented rather than caught by inspection, and the repo's own history shows both risks were realized at least once before the current gates existed.

What was built

A read-only-by-default Python package (media_vault/, stdlib plus ffprobe/ffmpeg, runs on system Python 3.9) turns an unorganized external drive of drone and interior home-tour footage into three products: numbered B-roll packs, a per-home library, and a monthly membership. media_vault.manifest freezes a baseline of every file (size plus a partial sha256) before any move is made; media_vault.moves applies only decisions a human has checked off in a markdown decision log, journaling every rename to review/journal.jsonl and comparing the identity multiset before and after, rolling back on any mismatch. Nothing is ever deleted, and no move happens outside this journaled path.

On top of the safe-move layer sits an identification pipeline: contact sheets and evidence packets built from GPS clustering, date drift, and same-day siblings feed batches of Claude agents (paired reader-plus-skeptic per unit) that propose a house name, which a human signs before moves.apply executes it. A second pipeline, media_vault.packs, cuts sellable clips: select_pack only takes clips flagged sellable: yes in a signed catalog, 8-45 seconds long, at least 3840px wide, round-robining across houses so no single community dominates a pack. stage transcodes the vault's HEVC originals to H.264 4K with audio stripped, and check/assert_clean refuse any staged file that still carries a data track or a location tag by probing it with ffprobe.

A parallel media_vault.homes path sells whole houses: every clip in a folder, remuxed with metadata stripped, packaged with a license and a clip index, keyed to an append-only digit-free registry (review/homes/registry.json) so a folder rename never breaks a sold link. Delivery runs through Cloudflare R2 with presigned, ranged-GET verification before any buy link goes live, and checkout runs through Stripe, including a membership tier backed by signature-verified webhooks and a 24-hour emailed sign-in link. A Python unittest suite covers the manifest, moves, packs, catalog, and homes-review logic.

Technical approach

The core safety invariant is that no move is trusted until it is proven identical on both ends. apply_renames computes an identity multiset, file size plus a sha256 of the first 4 MiB, for every path before a batch runs and again after, and raises rather than completing if the sets don't match; every move is journaled to review/journal.jsonl first so a batch is undoable even mid-failure. The manifest itself is treated as an append-only ledger: a frozen baseline (manifests/2026-09-20.jsonl, 24,409 files) is rebased forward through the journal after every batch rather than replaced, so a bug in one batch's renames cannot silently corrupt the record of what existed before it.

The clearance gate for saleable content is enforced the same way as the move safety, as a hard refusal rather than a checklist. packs.select takes a --cleared JSON list from a full-resolution visual sweep and filters every candidate clip against it before any other selection rule runs, so a clip that scores well on duration and resolution still cannot enter a pack unless it passed the sweep. assert_clean, run via ffprobe after every transcode and again in bulk by packs check, fails the build if a staged file still carries a second data track or a location tag, which catches metadata that survived an upstream review mistake rather than relying on that review being perfect.

House identification runs as a two-role agent pipeline rather than a single pass: a reader proposes a house name from a contact sheet and GPS/time evidence packet, and a paired skeptic has to independently agree at high confidence before a house name is signed into the decision log. Nothing renames a folder until a human checks a box against that log, and moves.signed_renames only reads checked lines under a batch's own heading, so a proposal that never got signed off cannot execute by accident.

The per-home product reuses the same manifest and journal machinery but adds an append-only registry (review/homes/registry.json) keyed by opaque IDs rather than by folder name, specifically so that a later folder rename, which the identification pipeline does constantly as houses get named more precisely, cannot break a link a customer has already been sold. scripts/migrate_house_refs.py is the one path allowed to touch that registry when a rename happens, and it rewrites every other house-keyed file in the same operation so nothing drifts out of sync.

Creative approach

Craft

The product decision embedded in the code is what a customer is allowed to see, not just what looks good. assert_clean runs on every staged file and refuses anything that still carries a GPS or a second data track, so the clearance boundary is enforced by a program property rather than by a person remembering to strip metadata by hand. The naming convention for a pack file (slug() in packs.py) strips all-digit tokens and known builder names from a house folder name before it ever reaches a filename customers download, so a street number cannot leak through a purchase artifact even if it survived the human review pass. The per-home registry is deliberately append-only with digit-free titles, which is a content decision made structural: a house identifier can never regress into carrying an address once it has one.

The pack-selection scoring function (_score) picks clips closest to an 18-second orbit rather than the longest available clip, which reads as a small taste call folded into otherwise mechanical selection code: the target length is chosen for what a buyer experiences watching a drone orbit, not for what maximizes total footage shipped.

Reframe

The build treats 'this footage is clean enough to sell' as a claim that needs the same verification discipline as a financial reconciliation, not a one-time judgment call. The repo's invariant list states a pack ships only clips a full-resolution sweep cleared with two independent readers, and packs select --cleared enforces that at the code level by refusing anything outside the cleared list, even if it otherwise matches every other selection rule. That reframes clearance from a manual step that happens once, upstream of packaging, into a gate the packaging code itself cannot be bypassed around.

A second reframe shows up in how the per-home product got built. The invariant language and tooling (identity multiset, journaled moves) were built first for the safety of the intake and identification pass, before any per-home product existed. Selling whole homes rather than only curated packs came later, extending the same clearance and delivery machinery to a second, simpler product instead of building bespoke review tooling for it, which is why both products share one registry-and-journal foundation rather than each shipping its own.

Process and what failed

The handoff log records a round-two sweep that pulled clips from an already-shipped pack after house numbers, a phone number, and one dud were found readable in full resolution, meaning the first clearance pass was not sufficient and had to be redone at full resolution before the pack could be trusted. A subsequent full-resolution sweep pulled 28 shipped clips for the same class of problem, and replacement clips were queued through their own independent full-resolution check rather than swapped in unreviewed. The runbook itself accumulated corrections after mistakes: it now explicitly warns never to pipe moves apply or a test runner through tail before &&, because doing so had already masked three failing runs as passed. It also documents that a folder created by one batch cannot be renamed until that batch's manifest rebase completes, because the baseline check reads a stale manifest file and rolls back with a zero baseline otherwise, a failure mode discovered by hitting it.

Outcome

The pipeline is live and selling. Three B-roll packs are on sale (Davenport/Champions Gate, 30 clips at $79; Central Florida New Construction, 46 clips at $99; Ocala/Marion County, 26 clips at $69). The per-home library prices each of 247 reviewed homes at $49, and a home lists publicly once its R2 archive verifies. A $99/month membership (10 homes per billing period) is live with a signature-verified Stripe webhook and an emailed sign-in link. The store, its home library and its members route all returned HTTP 200 in production on 2026-09-23.

What is not done: the membership has no members yet, per the repo's handoff, so there is no usage data to report. A Saint Cloud pack is parked with only 3 usable clips, and a Florida Lifestyle pack has no footage at all, so neither ships; the store shows the latter as opening soon. An end-to-end purchase by a real buyer, from membership sign-in through a single-home download, has not been recorded yet. No revenue or conversion figures exist anywhere in the repo, so none are claimed; the honest state is a working, verified delivery pipeline with live products and no reported sales volume yet.