Case Study 2: One Project, Cradle to Grave — A Media Workflow That Survives a Year

This is a constructed teaching walkthrough — an illustrative two-day shoot, followed from the empty folder that exists before it begins to the archived package you reopen a year later. No named people; you are the maker. Every drive, card, and folder decision is shown so you can copy the whole system onto your own next job. The shoot itself is deliberately modest — a small-business branded piece in the product-and-testimonial mold — because the point here is not the shooting; it is everything that keeps the shooting from being lost.

The brief and the constraints

A neighborhood bakery wants a two-to-three-minute branded piece for its website and socials: the owner talking to camera about the family recipe, plenty of B-roll of hands and dough and morning light, one warm music bed, delivered in a horizontal master plus a vertical social cut. You are shooting it solo over two mornings before opening hours. It is, in production terms, a comfortable job — the kind you have done in earlier chapters. The reason it belongs here, in the workflow chapter, is that a "comfortable" job is exactly where people get sloppy about their media, and where a lost card or an un-openable project a year later turns an easy win into a professional embarrassment.

So we are going to shoot it the way a professional actually works: with the whole life of the project designed before the first card goes in the camera. The gear is ordinary — one camera for the interview, the same camera repositioned for B-roll (or a second body if you have one), a shotgun and a lav feeding a small recorder for double-system sound (Chapter 15), and a laptop with an external drive on location. What makes this a case study is not the kit. It is the system wrapped around it.

⚙️ Settings Box: the shoot's media & backup plan (decided before day one). The technical settings for the picture were locked in earlier chapters; here is the plan for the media itself — the part most people never write down.

Decision Choice for this job Why
Project home 2026-05_BAKERY_brand-film/, cloned from _TEMPLATE_PROJECT Same skeleton as every job (§37.1)
Card rule Never wipe a card until 2 verified copies exist (Ch.27) The card is the only place a shoot can die
On-location copies Laptop internal + external SSD, both, each evening Two copies before any card is reused
Off-site (the "1") Nightly upload of that day's media to the cloud A local disaster can't take the whole shoot (§37.3)
Naming DATE_BAKERY_slot_subject_take (§37.2) Sorted, self-describing, portable
Working drive (edit) External SSD Fast enough for smooth playback (§37.4)
Scratch/cache Laptop internal NVMe, separate from media Fast + disposable, not on the only media copy
Master format High-quality master kept in 07_EXPORTS (Ch.36) The thing you'll archive and re-master from

Notice that half of that table is about copies and locations, not cameras. That ratio is the whole point of this chapter, and this case study is that table, lived out over the project's entire life.

Phase 0 — Pre-production: the project exists before the footage does

Here is the move that separates this walkthrough from how most people work: you build the project's folder structure before you shoot a single frame. The evening before day one, you duplicate your _TEMPLATE_PROJECT (§37.1), rename it, and the project now exists as an organized, empty home waiting to be filled.

FIGURE CS2.1 — The project folder, built the night BEFORE the shoot (empty, waiting)

  /VIDEO/2026/2026-05_BAKERY_brand-film/
  ├── 00_README.txt        ◄─ started NOW: client, contact, specs, delivery date
  ├── 01_FOOTAGE/
  │    ├── CAM-A_interview/     (empty — but the shelf exists)
  │    └── B-ROLL/              (empty)
  ├── 02_AUDIO/
  │    ├── RECORDER/            (empty)
  │    └── ROOM-TONE/           (empty)
  ├── 03_MUSIC-SFX/            (the licensed track will land here + its license)
  ├── 04_GRAPHICS/
  │    ├── FONTS/               (the brand font goes here NOW if you have it)
  │    └── LOGO/                (the bakery's logo, once they send it)
  ├── 05_PROJECT/             (the edit project file will be created here)
  ├── 06_PROXIES/             (disposable — will be generated in the edit)
  ├── 07_EXPORTS/             (master + deliverables at the end)
  └── 08_DOCS/                (brief, shot list, release form — release printed to bring!)

Building the tree empty does three quiet, valuable things. First, it turns "where does this go?" into a question you already answered — every card, file, and document has a shelf before it exists. Second, it surfaces what you still need: staring at an empty 04_GRAPHICS/LOGO/ reminds you to ask the client for a high-resolution logo now, not at 11 p.m. during the edit; the empty 08_DOCS/ reminds you to print the model release (Chapter 38) to bring to the shoot. Third, it starts the 00_README while the facts are fresh — client name, contact, the delivery specs, the deadline — so the manifest that will make this project reopenable a year from now is already being written on day zero.

You also drop the brief and the shot list into 08_DOCS/ and, if the bakery has sent its logo and brand font, they go straight into 04_GRAPHICS/. The project is not shot. But it is born organized, which is the only state in which organization is free.

Phase 1 — On set, day one: the card is the only place it can die

Morning one: the interview. You light the owner by the window (Chapter 13), rig the lav and the shotgun to the recorder (Chapter 15), and get the answers. Good work — and now the most dangerous window in the project opens, because everything you just captured exists in exactly one place each: a camera card and a recorder card, both small, both losable, both a single accident from erasing the morning.

Your on-set discipline treats those cards as radioactive until they are copied. During the shoot you label as you swap: a full card goes into a specific slot of your card wallet (say, "shot" on the left, "empty" on the right) so you can never confuse a card you've filled with one you've cleared. You do not format a card in the camera to reclaim space, no matter how tempting when you're running low — because a formatted card is a wiped tape (see Case Study 1), and this morning's interview only exists on it.

Then, over the lunch break and again that evening, you run the offload — the Chapter 27 pipeline, in the field:

FIGURE CS2.2 — The field offload: two copies before any card is reused (day one)

  [ CAM card ]  ──verified copy──►  LAPTOP  /01_FOOTAGE/CAM-A_interview/
       │                       └──►  EXT SSD /01_FOOTAGE/CAM-A_interview/
       │
  [ REC card ]  ──verified copy──►  LAPTOP  /02_AUDIO/RECORDER/
       │                       └──►  EXT SSD /02_AUDIO/RECORDER/
       │
       ├─► CONFIRM both copies exist and play  ──►  ONLY THEN is a card reusable
       │
       └─► that evening:  upload the day's media to the CLOUD   ◄─ the off-site "1"

   End of day one, every clip exists in THREE places (laptop, SSD, cloud),
   on TWO media types (local drives + cloud), with ONE off-site (cloud).
   That is 3-2-1, achieved on location, before you sleep.

Two details make FIGURE CS2.2 professional rather than merely careful. First, verified copies (Chapter 27's checksum offload), so a silent copy error is caught on location while the card still exists — not three weeks later in the edit. Second, the nightly cloud upload: it is slow, it runs while you eat and sleep, and it is the single most important thing you do all day, because until that upload finishes, both your other copies are in the same bag in the same room, and a hotel fire or a stolen car would take the entire shoot. The cloud copy is the one that is somewhere else. By the time you go to bed on day one, the interview and its audio exist in three places across two media with one off-site — full 3-2-1 — and only now would you ever consider reformatting a card.

You name as you offload, too. Rather than leaving the camera's gibberish, you rename (or apply your editor's rename-on-import) into the scheme from §37.2, so the morning's files read like a sentence instead of a serial number.

FIGURE CS2.3 — Naming applied to the two-day shoot (sorted, self-describing)

  2026-05-14_BAKERY_int-A_owner_t01.mov      day 1 interview, take 1
  2026-05-14_BAKERY_int-A_owner_t02.mov      take 2
  2026-05-14_BAKERY_broll_dough_t01.mov      day 1 B-roll: kneading dough
  2026-05-14_BAKERY_broll_oven_t01.mov       day 1 B-roll: the oven
  2026-05-14_BAKERY_rec_int_t01.wav          recorder audio for the interview
  2026-05-14_BAKERY_roomtone_kitchen.wav     30 sec of room tone (Ch.15!)
  2026-05-15_BAKERY_broll_window_t01.mov     day 2 B-roll: morning window light
  2026-05-15_BAKERY_broll_hands_t02.mov      day 2 B-roll: hands, take 2

  Sorted by name, they group by DAY, then by SLOT (int / broll / rec / roomtone),
  then read in order. A stranger — including you in a year — can read the shoot
  from the file list alone. No clip is ever called "MVI_4417" again.

Phase 2 — On set, day two: the same system, no thinking required

Morning two is the B-roll: hands, dough, the oven, steam, the window light, the finished loaves. Because you built the system on day zero and ran it on day one, day two costs you no additional decisions. The cards go in the "shot" slots; the offload runs at lunch to laptop and SSD, verified; the naming follows the scheme with tomorrow's date; the cloud upload runs that night. The workflow has become invisible, which is exactly what a good workflow is supposed to be — a thing you do without deciding to, so your whole attention stays on the light and the loaves.

This is the payoff of a template and a checklist meeting each other: by the second day of a job, the media management is muscle memory, and you have not once had to stop and wonder where a file goes or whether a card is safe. That invisibility is not laziness; it is the hardest-won professionalism in this book.

✂️ In the Edit. Feel what you've bought yourself for the edit to come. Every clip is already named so you can find it, already in the right folder so the project will see it, already synced-ready because the room tone and recorder files sit labeled beside the picture, and already safe in three places so no failure between now and the edit can cost you the shoot. Compare the alternative — two cards of gibberish-named clips, one copy, dumped on a desktop "to sort later" — and you can already predict the edit that awaits that version: a day lost to hunting and syncing before a single cut, and a low hum of anxiety that the one copy might not survive the wait. The organized shoot is not a different skill from the messy one. It is the same shoot, plus habits, and the habits are the whole margin.

Phase 3 — The edit: fast where it counts, safe everywhere

Back at your desk, the project is trivial to open into an edit, because everything the edit needs is already true. You point the editor at the external SSD copy and set up your drives by job (§37.4):

FIGURE CS2.4 — Edit-phase drive layout: fast for work, cheap for safety

  INTERNAL NVMe (fastest) ──►  OS + apps + SCRATCH/CACHE + PROXIES
                               (disposable; hammered constantly; NOT the only media copy)

  EXTERNAL SSD (fast)     ──►  THE WORKING PROJECT  ◄── you edit here; smooth 4K playback
                               /2026-05_BAKERY_brand-film/  (the whole tree from CS2.1)

  EXTERNAL HDD (cheap)    ──►  LOCAL BACKUP of the working project (copy at rest)

  CLOUD (off-site)        ──►  the nightly-uploaded originals + the project file
                               ── the "1" that survives a local disaster

   3 copies (SSD + HDD + cloud) · 2 media (local drives + cloud) · 1 off-site (cloud).
   3-2-1 is CONTINUOUS through the edit, not a thing you do at the end.

Inside the project you build the bins to mirror the folders (Chapter 27), generate proxies into 06_PROXIES/ if the footage stutters, sync the recorder audio to the interview by the clap, pull your selects, and cut. All of that is Chapter 27's craft; what this chapter adds is the discipline wrapped around it: the scratch and proxies live on the fast internal drive (disposable, regenerable, never your only media copy); the working project lives on the fast SSD; a cheap HDD holds a local backup you refresh as you go; and the cloud copy from the shoot is still your off-site. You never drop below 3-2-1, not for a single day of the edit.

And you version like a professional (§37.2). As the cut evolves, the project file and your exports climb through _vNN — never once touching the word "final":

FIGURE CS2.5 — Versioning through the edit (the discipline that prevents "final_FINAL_v2")

  BAKERY_edit_v01.drp   first assembly / string-out
  BAKERY_edit_v02.drp   rough cut, whole piece top to bottom
  BAKERY_edit_v03.drp   fine cut, sent to client for review
  BAKERY_edit_v04.drp   client notes addressed
  BAKERY_edit_v05_LOCK.drp   approved — picture locked

  Exports track the same climb:
  BAKERY_youtube-1080p_v03.mp4   ◄─ the review copy you actually sent (you can PROVE which)
  BAKERY_MASTER_prores-1080p_2026-05-28.mov  ◄─ the high-quality master (Ch.36)

When the client asks "which version did you send me last Tuesday?", you do not guess — the review copy is v03, unambiguously, sitting in 07_EXPORTS/. That certainty is worth real money and real trust, and it costs nothing but the discipline of two climbing digits.

There is a quieter safety habit running under the whole edit, too. You save the project file often, and you let the editor keep its automatic project backups on (into 05_PROJECT/) — because a project file, like any file, can corrupt, and a project that crashes with an hour of un-saved cutting is its own small forty-minutes-of-work disaster. Incremental saves (v01, v02, v03…) also mean that if v07 ever opens broken, you can fall back to v06 and lose an increment, not the film. This is 3-2-1's spirit applied to the project file itself: never let the only copy of your edit decisions live one crash away from gone. None of it is dramatic; all of it is the difference between a bad afternoon and a lost week.

And it is worth naming, plainly, the version of this project that didn't get built this way — because it is the version most people actually ship. In that alternate story, the two mornings' cards were dumped into a single desktop folder called "bakery final," un-named and un-verified; the edit ran off that one copy with no backup; proxies and cache and eleven draft exports piled up until the drive was full; and at "wrap," the delivered file was saved somewhere and the rest left to rot on a drive that was later wiped for the next job. That project also got delivered, and the client was also happy — on delivery day. The two versions are indistinguishable until the moment, months later, when something is asked of the project again. Then one of them answers in an hour and the other cannot answer at all. The entire value of this case study lives in that gap, and the gap is made of habits, not talent.

Phase 4 — Delivery, then the moment everyone skips: the archive

You deliver (Chapter 36): the high-quality master and the platform deliverables — the horizontal web cut and the vertical social cut — all exported into 07_EXPORTS/, captioned, to spec. The client is delighted. The job, as far as most people are concerned, is done.

It is not done. The fast SSD this project lives on is needed for the next job, and the project as it stands is bloated with disposable proxies and cache and a dozen draft exports. So you do the professional's last step, the one that makes the difference a year from now: you archive it (§37.5).

FIGURE CS2.6 — The archive package at wrap (lean, complete, reopenable)

  BAKERY_brand-film_ARCHIVE_2026-05-28/
  ├── 00_README.txt   ◄─ finished manifest: cut in <editor> v<version>; 1080p, 25 fps;
  │                      master = 07_EXPORTS/BAKERY_MASTER_prores-1080p_2026-05-28.mov;
  │                      fonts: <brand font>; LUT: none; music: <track> (license enclosed);
  │                      delivered 2026-05-28; client contact enclosed.
  ├── 01_FOOTAGE/     ◄─ KEEP: all camera originals (irreplaceable masters)
  ├── 02_AUDIO/       ◄─ KEEP: recorder files + room tone
  ├── 03_MUSIC-SFX/   ◄─ KEEP: the track + its LICENSE file (proof of rights — Ch.38)
  ├── 04_GRAPHICS/    ◄─ KEEP: logo + FONTS (or the titles reflow in a year)
  ├── 05_PROJECT/     ◄─ KEEP: BAKERY_edit_v05_LOCK.drp
  ├── 07_EXPORTS/     ◄─ KEEP: the MASTER + the delivered web & social cuts + captions
  └── 08_DOCS/        ◄─ KEEP: brief, SIGNED release, invoice, delivery note

  STRIPPED OUT (regenerable / noise):  06_PROXIES/ · render cache · v01–v04 drafts ·
  duplicate exports · camera card system junk.

  THEN 3-2-1 THE ARCHIVE:  two durable copies (e.g., two HDDs) + the cloud/off-site one.
  Move it off the fast SSD into /VIDEO/_ARCHIVE/.  The SSD is now free for the next job.

You consolidate the project and its used media into that one self-contained folder (your editor's project-archive/consolidate function; Appendix E), strip the proxies and cache and the v01–v04 drafts, finish the 00_README manifest, and confirm the master, the signed release, the music license, and the fonts are all inside. Then you 3-2-1 the archive itself — because an archive is data like any other, and one copy in a drawer is one flood from gone — and move it into /VIDEO/_ARCHIVE/, freeing the SSD for tomorrow's job. Total time: perhaps twenty minutes. Value: the entire next scene.

Phase 5 — One year later: the phone rings

Fast-forward twelve months. The bakery is opening a second location and wants the video updated: swap the closing logo card for the new two-location branding and re-export. In the un-archived version of this story, this is a catastrophe — the project was on an SSD long since repurposed, the media was "somewhere," the brand font is gone, and what should be a small change is a day of forensic reconstruction, if it is possible at all.

In this story, it is a coffee-length task:

FIGURE CS2.7 — The reopen-in-a-year test (the whole chapter, passing)

  1  Open /VIDEO/_ARCHIVE/BAKERY_brand-film_ARCHIVE_2026-05-28/
  2  Read 00_README.txt  ──►  cut in <editor> v<version>, 1080p 25fps, master + fonts noted
  3  Copy the archive to the working SSD           (never edit off the archive)
  4  Open 05_PROJECT/BAKERY_edit_v05_LOCK.drp
        └─►  every clip ONLINE (media was inside the folder, relative paths — §37.6)
        └─►  titles correct (the FONT was in 04_GRAPHICS/FONTS)
        └─►  music intact and licensed (track + license in 03_MUSIC-SFX)
  5  Save as BAKERY_edit_v06.drp, swap the logo, re-export ─► deliver in an hour.

   The project reopened whole because, a year ago, you spent twenty minutes
   making it reopenable. That trade — twenty minutes then for a whole day now —
   is the entire economic case for this chapter.

The project opens whole. Every clip is online because the media lived inside the project folder and was referenced relatively (§37.6), so copying the archive to a new drive didn't break a single link. The titles render correctly because the font traveled in 04_GRAPHICS/FONTS. The music is intact and its license is right there to prove your rights. You make the change, bump to v06, re-export from the preserved master, and deliver before lunch — and the client, without ever knowing why, experiences you as the rare professional who "still has everything." That reputation, earned silently by a folder structure and a twenty-minute archive, is worth more than any single job.

And notice the second-order payoff, because it is where the money actually is. A one-hour turnaround on a year-old change is not just convenient — it is profitable in a way the original job never was, because there is no re-shoot, no re-grade, no reconstruction, almost no overhead between the client's request and your invoice. The freelancer who lost the project has to quote days (or decline the work and lose the client to someone who kept theirs); you quote an hour and keep a client for life. Over a career, the compounding value of a back catalog that reopens — repeat business, quick re-versions for new platforms, clips harvested for reels and pitches — dwarfs the trivial cost of the drives and the twenty minutes it took to archive each job. The archive is not an expense you tolerate for safety. It is an asset that keeps paying, quietly, for as long as you keep it alive.

Discussion questions

  1. The whole system was built before the shoot (Phase 0). What specific problems did building the empty folder tree the night before prevent — and why is "organize later" almost always more expensive than "organize first"?
  2. In FIGURE CS2.2, the nightly cloud upload is called "the single most important thing you do all day." Make that argument in your own words. What disaster does it, and only it, defend against?
  3. The naming scheme (FIGURE CS2.3) means "a stranger can read the shoot from the file list alone." Who is that stranger, usually — and why does naming for them pay off most a year later?
  4. Trace where 3-2-1 exists at each phase — on set, in the edit, and in the archive. Why is it described as "continuous, not a thing you do at the end"?
  5. The archive (FIGURE CS2.6) deliberately strips out proxies, cache, and draft exports. Why is a leaner archive a better archive, not a riskier one?
  6. Phase 5 reopens in an hour because of choices made a year earlier. Identify the three earlier decisions that most directly made the reopen painless, and what would have broken if each had been skipped.

Your turn: run one project through the whole life

Take a real project — ideally one of your three portfolio pieces — and walk it through this exact lifecycle, or as much of it as applies.

  • Build first. If it isn't already, put the project into the template structure (§37.1), retrofitting media inside the folder and relinking rather than renaming on disk.
  • Get to 3-2-1 today. Ensure three copies, two media, one off-site — set up whichever is missing right now.
  • Version honestly. Rename your project files and exports into _vNN, and find (and rename) any file with "final" in its name.
  • Archive it. Consolidate, strip the disposable files, write the 00_README, and 3-2-1 the package.
  • Test the reopen. Rename or unplug your working copy, open the project from the archive alone, and confirm every clip, font, and grade survives. Fix whatever comes up offline.

If, at the end, you can open the archived project cold and change it, you have done for your own work exactly what this case study did for the bakery film — and exactly what Case Study 1's lost programs needed and didn't get. That capability, repeated on every job, is what "never losing forty hours of work" actually looks like in practice.

Key takeaways

  • Design the whole life of the project before the shoot. Cloning the template and building the empty folder tree on day zero is the cheapest, highest-leverage move in the entire workflow — it makes every later "where does this go?" already answered.
  • On set, the card is the only place the shoot can die. Verified copies to two drives before any card is reused, plus a nightly off-site upload, gets you to full 3-2-1 on location, before you sleep.
  • Name as you offload, into a scheme a stranger can read — because the stranger is usually you, a year later.
  • 3-2-1 is continuous, not a final step: three copies across two media with one off-site, from the first card through the edit to the archive, without ever dropping below it.
  • Version with climbing digits, never "final." v05_LOCK beats final_FINAL_v2 every time the client asks "which one did you send?"
  • Archive at wrap: lean and complete. Keep the irreplaceable (originals, project, master, fonts, licenses, releases), strip the regenerable (proxies, cache, drafts), write the README, and 3-2-1 the package.
  • The reopen-in-a-year test is the whole point. Twenty minutes of archiving today buys back an entire day — and a client's trust — a year from now. That trade is the economic case for everything in this chapter.