The image is cleared. For what, and until when?

Approval and permission are different records

Approval is a record about the work. Someone with the standing to accept it did accept it, on a date, in a defined scope. That record describes an event, and events do not change afterwards.

Permission is a record about an agreement. It states what another party allowed: which uses, which channels, which markets, and for how long. Its subject is not the image but the arrangement around the image – a model release, a license term, a client's clearance for one campaign and not the next.

A single asset carries both. A product photograph can be approved for release in March and licensed for European web use for twelve months. In April the two records agree. The following March, one of them has stopped being true and nothing in the library shows it.

Teams tend to store the first and remember the second. The approval is visible because it was made in the library. The permission was agreed in a contract, a call, or a thread with the photographer, and it stayed where that conversation happened.

The permission record usually lives outside the library

In practice the terms sit in four places: signed agreements in a contract system or a shared drive, an email confirming that a shoot covers one campaign, a line in a brief, and a colleague's memory of what was agreed on a call. Each of those is a real record. None of them is attached to the asset.

That separation is not carelessness. It follows from how the agreements were made – before the asset existed, in a different system, by people whose responsibility was the contract rather than the library. The image arrives later, and nothing carries the terms across with it.

The terms also vary inside a single delivery. One shoot can produce frames with a model release and frames without, images licensed for print but not for paid social, and a handful cleared for one market only. A note held at project level cannot express that, because the note applies to the project while the differences apply to individual frames. Whatever holds the terms has to be as granular as the asset.

The cost of the separation is unevenly distributed. The people who negotiated the agreement rarely need to look it up, because they were there. The person who needs it eighteen months later was not: a new hire, a team in another market, an agency briefed to refresh a campaign from existing material.

The question arrives at the moment of retrieval

Someone searches the library for a usable frame and finds one. It is approved, well described, high resolution, and nothing on it suggests a limit. The asset looks finished, because in every respect the library can show, it is.

From there the failure goes in one of two directions. The first is visible: the asset runs somewhere its terms never covered, and the problem surfaces after publication. The second is quieter and more common. Nobody can confirm the terms quickly, so the asset is left alone and something gets reshot that the organization already held the rights to use.

The second outcome rarely appears in a report. It is filed as production cost rather than as a retrieval failure, which is how the underlying gap persists for years without being named.

Both directions have the same root. The library was asked a question it never held the information to answer, and it answered anyway – by presenting an asset that looks unrestricted, because nothing on it recorded a restriction.

Permission is the one record that expires on its own

Everything else in a visual library stays true until someone changes it. A caption is accurate until it is edited. A tag remains until it is removed. An approval stays accurate indefinitely, because it records what a person decided on a date, and that never stops being what they decided.

Permission behaves differently. It stops being true while nothing changes – not the file, not the metadata, not anyone's attention. A date passes. The asset reads exactly as it did the day before, and it is now wrong.

This is why relying on memory fails structurally rather than through negligence. People remember decisions. Durations have to be written down, because nothing prompts anyone to recall one.

It also explains why published treatments of this topic move so quickly to alerting. Vendor material describes expiration dates, notification windows, and automatic changes to visibility when a term lapses. That is sound, and it assumes the terms were captured on the asset in the first place. In most libraries they were not, which puts the real work upstream of any alert.

The structural requirement is modest. What a party permitted has to be an attribute of the asset, carrying a date, rather than a fact somebody knows. Then "can we still use this" is answered by the file instead of by an errand.

In moodcase visual asset management, Asset Metadata holds structured fields on the asset itself on team plans. Usage Licenses are available in upper team tiers for teams that need license terms recorded as such. Access Control, and granular link permissions on paid plans, define who can reach an asset, which is a related but separate question from what the asset was cleared for. Approvals and workflow states are recorded, not inferred. What was decided about the work and what a party permitted stay two records, because they answer two questions.