📖 Chapter 02 — Project Archives

The structure that lets you find a project from 2024 in 2030.

Learning Objectives

• Apply a project structure that scales to a decade of work
• Name files so they're findable by humans and tools
• Capture the metadata that turns a folder of files into a project you can revisit
• Distinguish a "project" from a "render" and archive them differently

Introduction

You finished the project. You uploaded it to YouTube. The file is in your archive. Five years pass. You want to find it again. Maybe to use a clip in a new video. Maybe to give a friend the link. Maybe to prove you did the work.

If your archive is just a folder called "Videos" with subfolders named "Final" and "Old," you'll spend an hour finding it. If your archive is structured properly, you'll find it in 30 seconds.

This chapter is about the structure.

The archive convention

Every finished project goes into a folder with this structure:

Every project has the same shape. Every project can be opened, understood, and re-edited from this structure alone.

The naming convention

The folder name: <YEAR>/<PROJECT-SLUG>.

• YEAR: the year the project was completed (or uploaded, for content with a public release date). 2024, 2025, 2026.
• PROJECT-SLUG: a short, lowercase, hyphen-separated name. hawaii-2024, home-server-pt1, moms-80th-birthday.

The slug should be:

• Short (under 30 characters)
• Lowercase
• Hyphen-separated, no spaces, no underscores
• Descriptive but not over-specific ("hawaii-trip" not "hawaii-trip-with-mom-and-dad-and-cousin-2024-v2-final-FINAL")
• Consistent across the project's files (the YouTube title can be different, but the slug is the slug)

Examples from the conversation and adjacent use cases:

README.md: the project metadata

The README.md is the single most important file in the project folder. It's a markdown file with everything someone (including future-you) needs to know about the project. The template:

# Hawaii Family Trip

## Summary
A 12-minute documentary about our family trip to Hawaii in summer 2024.
Captures the resort, the beach day, the hike, the luau, and the
family moments between the scheduled events.

## Release
- YouTube: https://youtube.com/watch?v=XXXXXXXXX
- Premiere: 2024-08-15
- Status: Published

## Credits
- Camera: TK (A camera), Mimi (B camera)
- Edit: TK
- Music: "Aloha" by <artist> (licensed via Artlist)
- Sound design: TK

## Runtime
12:34

## Files
- Master: renders/master/hawaii-family-trip-master.mp4
- Web: renders/web/hawaii-family-trip-web.mp4

## Tech notes
- Shot on Sony A7IV (A) and iPhone 15 Pro (B)
- Edited in DaVinci Resolve 19
- Color graded with FilmConvert Nitrate (Kodak 2383)
- Audio mixed in Audition

## Source
- Camera A: 47 GB, 14 clips, MXF
- Camera B: 22 GB, 38 clips, HEVC
- Audio: 8 GB, 6 tracks, WAV 48kHz/24bit
- Total source: 77 GB

## Revisions
- v1.0: 2024-08-10 — first cut
- v1.1: 2024-08-12 — color and audio adjustments
- v1.2: 2024-08-14 — final tweaks
- v1.3 (released): 2024-08-15

## Lessons learned
- Bring a lav mic for interviews; the on-camera audio was unusable.
- The A7IV overheating issue: shoot in 4K30 not 4K60.
- Next time: scout the luau location the day before.

Every project gets one. Update it as the project evolves. The discipline is what makes the archive useful.

What goes in source/

The source/ directory is the original, untouched camera and audio files. After the project is done, these are immutable — never edit, never reorganize, never delete. If you need to re-edit the project, you start from the source.

Sub-organize by camera or by day, depending on what makes more sense for the project:

• For a one-day shoot: source/camera-A/, source/camera-B/, source/audio/
• For a multi-day shoot: source/day-1/, source/day-2/, etc., with sub-subfolders for cameras

The structure isn't sacred; the principle is. Whatever you choose, be consistent across projects so you always know where to look.

What goes in project/

The NLE project files. For Premiere, the .prproj file plus any project-media folders. For DaVinci Resolve, the .drp file plus the cache and gallery. For Final Cut, the .fcpbundle.

Also here: proxy media (lower-res versions used for editing, in case the original footage is too heavy for the laptop) and auto-saves (the editor's automatic backups during the edit session).

What goes in renders/

All the output files. The "master" is the highest-quality delivery format (ProRes 422 HQ, DNxHR HQX, or similar) — the file you'd use to make further changes or to re-export to other formats. The "web" is the YouTube version (H.264, 1080p or 4K, ~20 Mbps). The "social" is shorter clips for Instagram, TikTok, etc.

Name the files descriptively: hawaii-family-trip-master.mov, hawaii-family-trip-web.mp4, hawaii-family-trip-clip-1-vertical.mp4. Never final.mp4 or FINAL_v2.mp4 — there is no "final" in an archive.

What goes in assets/

Things you used in the project but didn't create yourself: licensed music, sound effects, stock footage, custom graphics, fonts. Include the license info in the README so future-you knows whether you can re-use the asset in another project.

What goes in docs/

Anything textual: scripts, briefs, contracts, email threads with collaborators, notes to self. This is the project's "paper trail" — the part that makes the project understandable to someone other than the person who made it.

Why this is worth the effort

The first time you set up a project this way, it takes an extra 30 minutes. The fifth time, it takes 5 minutes. The fiftieth time, it's automatic. The reward is in years 2, 5, and 10:

• Year 2: a friend asks "hey, can I get that video you made about X?" You find it in 30 seconds. You send the link.
• Year 5: you want to make a "best of" video. You browse the archive, find 50 candidates, pick the best 20.
• Year 10: a young filmmaker asks how you got started. You show them your archive. The discipline is visible. They learn from it.

The cost is small. The reward is permanent.

The "what if I forget" defense

The honest concern: "I'm not going to actually keep this up. I'll archive the first 3 projects properly and then go back to chaos."

Two counters:

1. Make it part of the "finished" definition. A project isn't done until the archive structure exists. The render and the archive happen in the same session, not "later."
2. Write a script. The "archive this project" script is a few lines that creates the folder structure and copies the files. Once you have it, the cost of doing it right is small.

The script

Save this as ~/bin/archive-project.sh:

#!/bin/bash
# Usage: archive-project.sh "YEAR/PROJECT-SLUG" "Project Title"

set -e
SLUG="$1"
TITLE="$2"
DEST="/mnt/tank/Media/Archive/$SLUG"

mkdir -p "$DEST"/{source,project,renders/{master,web,social},assets/{music,sfx,graphics,fonts},docs}

cat > "$DEST/README.md" << EOF
# $TITLE

## Summary
<one paragraph>

## Release
- Premiere: YYYY-MM-DD
- Status: in-progress

## Tech notes
- NLE: 
- Camera:
- Audio:

## Revisions
- v0.1: $(date +%Y-%m-%d) — initial archive
EOF

echo "Created $DEST"
echo "Now copy your source files into $DEST/source/"
echo "And your project files into $DEST/project/"

Run archive-project.sh "2025/our-first-vlog" "Our First Vlog" and you have the structure. The cost of doing it right is one command.

Engineering Note

Summary

Every project gets the same folder structure: source, project, renders, assets, docs, README.md. The slug is short, lowercase, hyphenated. The README captures the metadata: summary, credits, tech notes, revisions, lessons learned. Use a script to create the structure. Treat the archive as the most important deliverable. The discipline is what makes the archive useful in 5 years.

Checklist

• ⬜ Save the archive-project.sh script
• ⬜ Use it for the next finished project
• ⬜ After 3 months, audit: are you keeping it up?
• ⬜ Update the README template as you discover fields you wish you'd captured

Looking Ahead

Chapter 03 is the active project scratch — the in-progress side of the same workflow. The archive is for finished work; the scratch is for work in motion. The scratch is fast, ephemeral, and lives on the laptop.

Ch 02 · v0.1 · drafted from the original ChatGPT conversation, July 2026