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/relocatenever 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