An agency with six years of client work does not have six years of proof. It has a shared drive, a project management tool nobody fully trusts, and a set of file modification dates that were never built to survive a dispute. The work exists. The evidence about when each piece existed mostly does not.
The gap becomes visible at the worst possible moment: a client questions who delivered a concept and when, a former contractor claims credit for something that shipped a year earlier, or a competitor's release looks close enough to yours that someone asks for proof of the original date. By then it is too late to build the record you needed. The real fix is to have already made a habit of producing it.
The backlog is not the actual problem
Teams that think about sealing a whole library usually picture it as one enormous task: thousands of files, a wish to protect everything at once, and a project that feels too large to start. That framing is the wrong one, and it is the reason most teams never start at all.
The real exposure is smaller and ongoing rather than historical. Every week a design studio ships new mockups, every sprint a software team cuts a new build, every campaign a marketing team produces new creative. That output is what is actually at risk, because it is still being negotiated, licensed, sold, or handed to clients who might one day ask where an idea came from. The old catalogue matters less than people assume. The flow of new work matters more.
What sealing a library actually means
There is no single action that seals a thousand files as one undivided block, and that is by design rather than a limitation. Each file gets its own cryptographic hash, a value derived from its exact bytes, and its own qualified electronic timestamp from a Qualified Trust Service Provider. Under eIDAS, a qualified electronic timestamp carries a legal presumption as to the date and time it indicates and the integrity of the data it is bound to, and that presumption attaches to one specific file, not to a folder description sitting above it. A record covering "the Q3 campaign" as a bundle would prove nothing about any individual asset inside it. A record covering each asset on its own proves exactly that asset, checkable independently of everything else in the set.
What changes for a team handling volume is not the unit being sealed, it is the workflow around sealing many units in sequence: a consistent naming habit, a clear owner for the step, and a routine that turns fifty files into an afternoon rather than a quarter-long project. The proof itself stays exactly as granular as it would be for one freelancer sealing one file.
Two different problems need two different plans
Split the library in two instead of trying to solve it in a single motion.
Forward flow. New work is the easier half. Put sealing at a fixed point in the delivery process, such as internal sign-off or the moment a deliverable goes to the client, and it costs a few minutes per asset rather than becoming a separate project. A team that adopts this today builds a complete, current record without ever touching the old material.
Backlog. Older work does not need the same treatment as new work, and treating it that way is usually why the backlog never gets touched at all. Instead of a full migration, triage it: what is currently in a dispute, what is licensed or sold and therefore carries commercial exposure, what belongs to a client relationship where a question is plausible. Seal that subset first. The rest can wait, and most of it will never need anything more than the option to seal it later if a specific reason comes up.
Declaring how each piece was made
For teams producing volume, the declaration step is where consistency matters most. Every asset gets labelled honestly at the point of sealing: AI generated, AI modified, AI assisted, or human authored, chosen per file rather than applied as one answer for the whole library. A studio that mixes AI-assisted concepting with hand-finished output cannot use a single label for everything without that label becoming wrong for part of the set.
The declaration is bound to the same hash as the timestamp, not stored in a spreadsheet next to it. That distinction matters more as a library grows, not less. A spreadsheet of claims drifts out of sync with a folder of files the moment either one is touched on its own; a declaration bound to the file it describes has nothing to drift against, because there is nothing to reconcile.
Content-level protection beyond file custody
Sealing proves who held a specific file and when. A separate layer addresses a different question that comes up for teams with large libraries specifically: what happens to the content itself once it circulates. An ISCC content hash, entered into a public database without exposing the underlying file, makes the content identifiable for infringement checks and for licensing conversations, including with parties training AI models on scraped material. For a single sealed sketch this layer matters less. For a library of hundreds of assets that get reused, adapted, and licensed over years, it is the part that keeps tracking the content after the file itself has left your hands.
Who does the sealing on a team
On a one-person operation this question does not exist. On a team it needs an answer before volume becomes a habit rather than after. The practical pattern is to put sealing at the same point as sign-off, so the person approving a deliverable is the same person confirming the record, instead of adding a second review cycle that nobody owns. A step with no owner gets skipped the first busy week, and busy weeks are exactly when the most client work is being produced.
Keeping an index that means something
A certificate on its own is only useful if someone can find it later. A simple index, one line per sealed asset with the file name, the date, and the certificate link, does more for a growing library than any amount of individual diligence on each file. It turns "did we seal that?" from a search through old emails into a lookup that takes seconds, and it is the difference between a habit that survives staff turnover and one that quietly stops the day the person who understood it leaves.
What a client sees when they check the record
The reason any of this is worth doing for a team rather than an individual is the same reason it is worth doing at all: somebody outside the organisation can check the record without an account and without contacting anyone. For an agency, that somebody is usually a client asking about ownership of a deliverable, or a counterparty in a licensing discussion who wants to confirm what was actually agreed and when.
A verification link does not care whether it points at file one of a thousand or the only file a freelancer ever sealed. Each record stands on its own, checked against the exact bytes it was issued for, independent of everything else in the library it came from. The value is also not confined by geography: the hash and the timestamp are technically checkable by anyone, in any country, with no login required, though how any specific court weighs that evidence remains a matter of that court's own procedural rules. Scale changes how a team gets there. It does not change what the record does once it exists.
Where this fits for agencies specifically
Agencies carry a particular version of this problem, because ownership questions come up more often when work is produced for someone else. A design delivered to a client, a concept pitched and not selected, a build handed over before final payment clears: each of these is a moment where "who made this and when" can turn into a real disagreement. Our page for agencies covers how sealed records fit into that kind of client relationship in more detail, and how the underlying flow works walks through a single file end to end if you want the mechanics before scaling up.
