The single architectural decision that shapes everything else in this app is small to state and inconvenient to actually build around: the photo drive is opened strictly read-only, and it is never written to. Not a sidecar file next to the originals, not a hidden folder of metadata, not a rename, not a moved duplicate. The drive that comes in is the drive that goes back out, byte for byte.
That constraint sounds like a nice-to-have until you notice what it rules out. It rules out the entire class of tools that "organize" your files by moving or renaming them. It rules out storing any derived state — thumbnails, face embeddings, event boundaries — anywhere near the originals. Everything the app learns about an archive has to live somewhere else entirely, which meant deciding, early, where "somewhere else" was going to be.
Everything derived lives on the internal disk
The answer is SQLite, on the Mac's internal disk, not the external drive. The index (dates, faces, event boundaries, embeddings for search) and the thumbnail cache both live there, fully separate from the archive itself. Delete the app's data directory and the archive is provably untouched, because nothing about the archive ever depended on that directory existing. Reinstall from scratch and the app rebuilds its understanding by reading the drive again, not by needing to trust a backup of its own state.
SQLite's write-ahead log was the specific piece that mattered most in practice, not in theory. During development there were two literal hard crashes — actual power cuts, not a simulated fault-injection test — mid-write, while the study was running against a real archive. Both times, WAL journaling meant zero data loss: the database came back up in a consistent state on the next launch, picked up roughly where it left off, and didn't require any manual repair. That's the kind of guarantee you want to have needed and not have tested yourself, but between an external drive, a background study running for hours, and a household where the cable occasionally gets bumped, it got tested for real, twice, before launch.
What "read it" actually recovers
A read-only guarantee is only as good as what you can actually extract while honoring it, and metadata in a real family archive is messier than a clean test set. On the founding archive, 92% of files carried usable EXIF dates outright. The remaining 8% needed fallbacks — file system timestamps, folder-name dates, inference from neighboring photos in the same event — and after those fallbacks, coverage reached 98.1%. That last two percent is the honest floor: some files simply carry no signal anywhere, in the file or around it, and no fallback chain invents one from nothing.
Browsable before it's finished understanding
Read-only and derived-state-elsewhere solve the safety problem, but there's a separate patience problem: a full study of a large archive takes hours, and nobody wants to stare at a progress bar before they can look at a single photo. The library becomes browsable within minutes of first pointing the app at a drive — an early pass gets enough of the index and enough thumbnails in place to make basic browsing real, not a mockup of it. The deeper passes (face clustering, event naming, the embeddings that power meaning-search) keep running behind that, quietly filling in richer answers while you're already looking at photos, rather than gating the first useful moment behind the last expensive one.
Resource governance is a rule, not a suggestion
The last piece is the one that's easy to skip and expensive to skip badly: a study that reads and understands a few hundred thousand files is genuinely heavy work, and heavy background work on someone's only Mac, while they're trying to use it for something else, is how "privacy-first local AI" turns into "why is my laptop a space heater." The rule here is a hard one, not a best-effort one: background QoS scheduling so the study never competes for priority with foreground work, adaptive worker counts that back off within seconds of the user becoming active, a hard ceiling on memory use, and an outright pause under battery or thermal pressure. A full study running on a base Mac shouldn't be something you can feel. If it is, that's a bug, not a tradeoff.
All of this — read-only originals, derived state on the internal disk, crash-safe journaling, resource limits that actually hold — adds up to a fairly unglamorous engineering thesis: the interesting part of "local-first" isn't that the AI runs on-device instead of a server, though it does. It's that there's no server to trust in the first place, which means every one of these guarantees only has to be true about one machine, sitting on your desk, that you already trust with everything else on it.