Somebody searches the library, finds four versions of the same product shot, and has no way to tell which one is current. So they ask in a channel, someone answers from memory, and the wrong one goes to print.
The library was not wrong. It contained all four. It just had no opinion about any of them, because the only states it modelled were present and absent.
Short answer: an asset needs a state, the state needs to be visible in search, and every transition between states needs a defined trigger and a recorded actor. Seven states cover almost every enterprise case: draft, in review, approved, published, superseded, expired, archived. Without them a DAM is a well-indexed pile, and people go back to asking colleagues, because a colleague at least has an opinion.
The seven states
Draft. In the system, not usable. Working files, first cuts, material awaiting selection. Excluded from default search. The reason to hold drafts at all is that the alternative is people holding them on desktops, where they are invisible and unbacked.
In review. Submitted for approval, with a named approver and a due date. Visible to the review path only.
Approved. Cleared for use. This is the state most search should default to, and getting that default right is most of what makes a library trustworthy.
Published. In active use on at least one surface. Distinct from approved, and the distinction matters: approved means allowed, published means currently out there. You cannot execute a recall without knowing which assets are published and where.
Superseded. A newer version exists. Still resolvable, because things printed last year should keep working, but never offered as a new choice.
Expired. Rights have ended. Not deleted, not usable. Findable deliberately, invisible by default. The behaviour required at this transition is the subject of rights and expiry as first-class asset data.
Archived. Past active life, retained for record or legal reasons. Often on cheaper storage, often with slower retrieval, and that is fine as long as the metadata stays in the main index so people can find out it exists.
Most implementations model three of these. The four that get skipped, published, superseded, expired and archived, are exactly the four that determine whether the library can be trusted.
What each transition requires
A state is only meaningful if the transition into it is controlled. Three properties per transition, every time:
- A trigger. Human action, elapsed time, or an event from another system. Write it down. Transitions with no defined trigger do not happen.
- A recorded actor. Who or what caused it, with a timestamp. This is your audit evidence and it should be a by-product of the transition, not something anyone assembles later.
- A downstream consequence. What else changes. Search visibility, notifications, cache invalidation, an event emitted to consuming systems.
That third property is where implementations usually fall short. An asset that becomes expired inside the DAM while remaining live on a public page has changed a field, not a state. The event mechanism that closes that gap is covered as pattern two in integration patterns for an enterprise DAM, and notification hooks are the usual implementation.
The unofficial path
There is always one. In most organisations it is approved-to-published without passing through review, because a deadline moved and someone with authority said go.
Do not design it out. Design it in, with a record.
An emergency path that requires a named override reason and a nominated approver gives you three things: the work gets done, the exception is visible, and the exception rate becomes a metric you can review. An emergency path that does not exist officially gets used anyway, off-system, and produces no record at all.
Exception rate is one of the more useful numbers in the whole governance framework. A rising override rate means the standard path is too slow, which is a process problem you can fix rather than a compliance problem you can only report.
Versions, variants and derivatives
Three different things, routinely conflated, and the conflation is why version questions are so hard to answer.
A version is the same asset, changed. Retouched, colour corrected, updated logo. Linear history, one current version, older ones retained. Platform-level version management handles this, and it should be automatic rather than a naming convention.
A variant is a deliberately different asset in the same family. The winter version of the campaign key visual, the alternate model, the horizontal composition. These are siblings, each with its own lifecycle state, and they are not versions of each other even though people file them that way.
A derivative is a mechanical output. The 400px crop, the WebP conversion, the CMYK export. Under a derivation model these are not stored at all, they are produced from the current version on request, which means they cannot be stale and they have no lifecycle of their own. That is the property discussed in single source of truth is an architecture.
If your library treats all three as “files that look similar”, version questions become unanswerable, which is the situation described at the top of this piece.
Where does retention fit?
At the end, and it is the part almost every implementation defers indefinitely.
Retention means two decisions per asset class: how long it is kept after active use, and what happens then. Records management has a century of thinking on this and the principles carry over directly, with one difference specific to visual material: images of identifiable people carry obligations under GDPR that do not attach to most other document types, so “keep everything forever” is not the risk-free default it appears to be.
Practical guidance:
- Set retention by class, not by asset. Product photography, campaign material, event photography, brand assets. Four to six classes covers most estates.
- Default to retain, but define the exceptions. Material with identifiable people and material with expired third-party rights are the two classes where indefinite retention is an active risk.
- Never hard-delete without an approval path. Deletion is the one irreversible operation in the whole system and it deserves a named approver and a record.
- Archive is a state, not a location. Moving to cheap storage is an implementation detail. What matters is that the asset stays findable and its metadata stays in the index.
Starting before the asset exists
The highest-leverage change available in lifecycle design is to start it at the brief rather than at the upload.
When a shoot is commissioned, everything you will later ask a cataloguer to guess is already known and written down: the campaign, the products, the market, the intended channels, the licensing terms negotiated with the photographer. Capturing that as a record before any asset exists, then attaching arriving assets to it, converts cataloguing from an act of reconstruction into an act of association.
The difference in both cost and quality is substantial, and it removes most of the contribution burden that drives the pattern in why DAM rollouts fail. It also means the rights fields are populated by the person who actually negotiated the rights, which is the only person who reliably knows them.
Very few organisations do this. The ones that do have noticeably better libraries, and it is a process change rather than a platform feature, so it is available to you regardless of what you have bought.
Keep the model small
Seven states is not a target, it is a ceiling. If your workflow diagram has fourteen states and nine conditional branches, it will be implemented once, understood by two people, and routed around by everyone else.
The test is whether a contributor can describe the lifecycle from memory. If they cannot, it is not a lifecycle, it is a specification, and specifications do not govern behaviour.
The field model that carries the state is in the metadata schema an enterprise actually needs, status as a search facet is covered in designing a taxonomy people actually use, and the reason any of it matters is in what enterprise DAM actually is.