Chapter 30 — Key Takeaways
The one-page reference to screenshot and re-read before you import a card or set up your library. The images are made elsewhere; this is the card that keeps you from losing them.
The one rule that prevents the most loss
A file is never allowed to exist in only one place for longer than it takes to copy it. Corollary: never format a card until a verified second copy exists. Corollary: one copy is zero backups.
The pipeline at a glance (§30.1)
[ CARD ] → INGEST → [ LIBRARY ] + [ BACKUP ] + [ OFFSITE ] → CULL → KEYWORD → DEVELOP → DELIVER + ARCHIVE
1 copy copy·verify· 3 copies = safe rate tag finish export·freeze
DANGER rename·back up keepers keepers
| Stage | The job | The one-line rule |
|---|---|---|
| Ingest | Card → managed library | Copy (don't move) → verify count → rename → back up, then format |
| Cull | Take → keepers | Reject the dead fast; rate the survivors; keep one of each duplicate |
| Keyword | Keepers → findable | File by capture, find by keyword; tag the whole take, then the keepers |
| Develop | Keepers → finished | Non-destructive; develop only keepers (Chapters 26–29) |
| Deliver | Master → exports | Export purpose-built copies; never touch the master |
| Archive | Project → long term | Self-contained, documented, open-format, 3-2-1 |
Ingest checklist (run every shoot — §30.1)
- [ ] Copy, don't move, off the card (leave originals until verified + backed up)
- [ ] Verify the copy — file count matches (487 on card = 487 in library), or checksum confirms
- [ ] Rename to your convention on the way in (not later)
- [ ] Back up — a second copy to a different drive, ideally in the same import action
- [ ] Then and only then format the card (copy #2 must demonstrably exist first)
The two-pass cull (§30.2)
| Pass | Speed | The single question | Action | Typical result |
|---|---|---|---|---|
| 1 — Reject | Fast (~2–3 s/frame) | "Is this frame technically dead?" | Reject (flag/X). Don't rate. | 600 → ~120 (cut 70–90%) |
| 2 — Select | Slower; compare | "How good is this — vs. its near-twins?" | Rate ★★★ / ★★★★ / ★★★★★; keep one of each cluster | ~120 → ~15 keepers |
| 3 — Commit | Later, cool head | "Develop or delete?" | Delete (or 90-day rejects folder); develop ★★★★+ |
A lean library |
Rating shorthand: ★★★ solid keeper · ★★★★ strong, worth developing, portfolio candidate · ★★★★★ best of the shoot (rare; the one you'd print). On a phone: the Favorite heart is a one-bit keeper flag.
Why passes beat one sweep: rejecting (fast, reflexive pattern-match against failure) and selecting (slow comparative judgment) are different mental jobs that poison each other if mixed. Split them.
Findability: keywords & metadata (§30.3)
Principle: folders store, keywords retrieve. A photo lives in one dated folder but carries many keywords, so it surfaces in every relevant search.
| Metadata type | Examples | Who adds it | Makes library searchable? |
|---|---|---|---|
| Automatic (EXIF) | date, camera, lens, exposure, GPS | the camera, at capture | indirectly |
| Descriptive | keywords, rating, caption/alt text, copyright, named location | you | yes — this is the searchable layer |
Keyword in layers (cheap → expensive):
| Effort | What | Covers |
|---|---|---|
| 30 seconds | Whole take: location · broad subject · season/event · client | Most future searches |
| A few minutes | Keepers only: specific subject · person's name · mood · project code | Precise retrieval |
| Free | Let the machine tag faces, places, common objects | The generic layer |
Caption = alt text. A good caption ("Red maple in river fog, north trail, late afternoon") is searchable and a screen-reader description at once — findability and inclusion in one field.
The 3-2-1 backup rule (§30.4) — the most important table in the chapter
| Number | Means | Defends against |
|---|---|---|
| 3 copies | working library + local backup + offsite | Any single failure — you always have spares |
| 2 media | not all on identical hardware (e.g. SSD + HDD + cloud) | A common failure mode (bad drive batch, corruption, ransomware) hitting identical copies the same way |
| 1 offsite | cloud, or a drive elsewhere | A site-wide disaster (fire, flood, theft, surge) that destroys one building at once |
Make it survive contact with reality:
- [ ] Automatic, not "when I remember" — a manual backup is the one you'll forget at the worst moment
- [ ] Offsite is the cloud's job — the cloud is your offsite leg, not your whole plan
- [ ] Verify 2–3× a year — actually restore a file from the backup; an untested backup is a hope
- [ ] Archives obey 3-2-1 too — they sit untouched for years, exactly long enough for a lone drive to die
Folders & naming that scale to 10,000 (§30.5)
Photography/
├── 2026/
│ ├── 2026-10-14 park-maple-fog/
│ └── 2026-10-18 intersection-saturday/
└── 2027/ …
File: 2026-10-18_intersection-saturday_0042.dng
└── DATE ──┘ └─── shoot slug ───┘ └seq┘ ext
| Folder principle | Why |
|---|---|
Date-first YYYY/YYYY-MM-DD shoot/ |
Sorts chronologically forever; never asks "which subject folder?" |
| One shoot per folder | No folder ever holds thousands of files |
| Year buckets at top | Top level stays human (a dozen years, not 4,000 shoots) |
| File-name property | Meaning |
|---|---|
| Unique | date + shoot + sequence never collides → can't overwrite another file |
| Sortable | leading YYYY-MM-DD lines files up in capture order |
| Informative | readable out of context |
| Portable | lowercase, no spaces, hyphens/underscores → works on every system & upload |
Rule: choose one convention and never deviate. A consistent "good enough" scheme beats a perfect one you abandon.
The catalog: map vs. territory (§30.5, from Ch.26)
- The catalog = the map (pointers to originals + edit recipes + ratings + keywords). The folders = the territory (the actual files).
- Never move the territory without the map. Reorganizing photo folders in the file browser outside the catalog breaks every link → "missing" photos (files are fine, pointers dangle).
- Do all moving/renaming inside the catalog. If links break, use locate/relocate — never re-import (that makes duplicates and orphans your ratings).
Delivery & archiving (§30.6)
| Working library | Delivery exports | Archive | |
|---|---|---|---|
| Job | fast, active work | purpose-built copies | stable, complete, long-term |
| Lifespan | now | disposable (re-export anytime) | years/decades |
| Rule | keep it lean | never touch the master | self-contained + 3-2-1 + open formats |
Archive package (self-contained): originals + edit recipe/sidecars + full-res finals (TIFF/JPEG, opens
in anything) + delivered exports + a plain-text _README.txt (what/when/for whom/the detail future-you
forgets). Store offsite.
Top mistakes → fixes
| ⚠️ Mistake | Fix |
|---|---|
| Format card after one copy / on a glance | Format only when a verified second copy exists |
| "Keep everything just in case" hoard | Trust the reject pass; rejects folder, purge at 90 days |
| Mixing reject + select in one sweep | Two passes: kill the dead fast, then rate survivors |
| Smart subject-folders | File by date; let keywords do retrieval |
Camera names (IMG_4471) |
Rename at ingest to a unique, sortable, portable convention |
| Backup = "when I remember" | Automate it; verify a few times a year |
| Cloud as the whole plan | Cloud is the offsite leg of 3-2-1, not all of it |
| Moving folders outside the catalog | Move inside the catalog; recover with relocate, not re-import |
| Delivering / overwriting the master | Export purpose-built copies; master stays sacred |
Portfolio Checkpoint (this chapter)
Cull, rate, keyword, and back up everything so far — turn the growing pile of keepers into a managed, findable collection:
- [ ] Cull the whole body of work (two-pass); portfolio candidates rise to ★★★★, the best to ★★★★★
- [ ] Organize & name into a clean
YYYY/YYYY-MM-DD shoot/tree with consistent file names - [ ] Keyword every image by chapter/technique, subject, and location (so Chapter 40 assembles by search)
- [ ] Back up to 3-2-1 — this collection is now the most valuable thing on your drives
Not a new frame — a real collection. A portfolio you can't find or could lose is a liability, not a portfolio.
First-defined terms (this chapter)
| Term | One-line meaning |
|---|---|
| Ingest | Bringing images into your managed system — copy, verify, rename, back up — before anything else |
| Culling | Reviewing a take and selecting keepers; deciding what to keep, develop, or discard |
| Metadata | Information stored with a photo — automatic (EXIF) + descriptive (you add) |
| Keyword | A searchable descriptive tag for what a photo is of/about |
| The 3-2-1 backup rule | 3 copies, 2 media, 1 offsite |
| Catalog | The database mapping originals to their edits/ratings/keywords (Ch.26) |
| Archive | A finished project moved to stable, self-contained, recoverable long-term storage |
| File-naming convention | A fixed rule for file names: unique, sortable, informative, portable |