Archive note, April 2026: This post is based on early digital asset management design notes from the DAM project and Model Hub.
Most digital asset management systems want to become the center of the universe.
They ingest the files, create database records, manage metadata, expose search, generate previews, and eventually become the only comfortable way to understand what exists. That can work, but it creates a risk: the application becomes more authoritative than the archive.
The DAM design went in the other direction.
Files stay the source of truth.
The Storage Comes First
The design starts with TrueNAS and ZFS as authoritative storage. Not a web app. Not a CMS. Not a database pretending it owns the originals.
The storage layout is tenant- and project-scoped, with deterministic paths for shoots, library material, exports, and system data. Originals are preserved. Derivatives are generated for the surfaces that need them. Manifests and logs live beside the assets they describe.
That structure matters because photo archives outlive applications.
The app can change. The search index can be rebuilt. A worker can be rewritten. But the file tree, checksums, embedded metadata, and manifests should still make sense.
Identity Is More Than A Filename
The design uses both UUIDs and SHA-256 checksums.
The UUID gives each asset a stable identity inside the system. The checksum proves whether a file’s content has changed. Together, they make the archive less dependent on filenames, folder accidents, or temporary ingest state.
That is especially important in photography workflows, where filenames are often reused by cameras, exports may be renamed, and edited versions may multiply quickly.
A good archive should be able to answer basic questions:
- Have I seen this file before?
- Is this original unchanged?
- Which derivative came from which master?
- What metadata was known at ingest time?
- What happened during processing?
Those answers should not require trusting memory.
Derivatives Are Consumers, Not Masters
The DAM design draws a hard boundary between originals and consumers.
WordPress, portfolio sites, client galleries, and other CMS surfaces should read derivatives. They should not mutate or rename originals. If a web surface needs a smaller WebP, it gets a derivative. If a gallery needs display files, it gets exports. The archive remains intact behind the scenes.
This sounds obvious until a workflow gets busy. Then shortcuts appear.
A client-ready JPEG gets dragged into the wrong folder. A CMS plugin “optimizes” a file in place. A resized image becomes the only surviving copy because it was easier to upload than preserve the original.
The DAM rules are designed to prevent that kind of erosion.
File-Centric Does Not Mean Primitive
Keeping files authoritative does not mean avoiding automation.
The design includes a file-based job queue, ingest states, immutable originals, derivative generation, IPTC/XMP metadata, manifests, and logs. Services can still add value. They just do not own the archive.
That distinction is the project.
The DAM is not trying to be a shiny interface first. It is trying to make the storage layer durable, inspectable, and boring enough to trust.
For creative work, boring is underrated. A portfolio can be rebuilt. A web gallery can be redesigned. A database can be migrated.
Lost originals are harder to forgive.