Metadata is the product: why your folder structure is a liability

A document controller gets an email asking something that ought to be easy: which revision of the level three ceiling layout was current when the grid was set out, and who had been sent it. Since then the tree has been restructured twice and one consultant has been novated. She finds three PDFs carrying the same sheet number, in three directories, with three modified dates, and one of them lives in a folder somebody optimistically called ISSUED_USE_THIS. None of those files is a forgery. None of them is an answer either.

File-centric projects treat the path as identity: the drawing is wherever the last person saved it. Data-centric projects treat the file as a payload and keep the claims that travel with it — what state the container is in, what suitability it carries, which revision was issued, and which companies received it. Those claims are what somebody comes back for long afterwards, and they are the part a reorganisation cannot quietly rewrite.

Every tree is a snapshot of who had write access

A project folder structure is never "the standard", whatever the front of the BEP says. It is a photograph of whoever had write access in the fortnight the job was stood up. One branch per consultant. One per work stage. One named after a package that was later split in two. One called FINAL, then FINAL_v2, then the one above. Someone is "on BIM". The plotter still sings.

Then the job moves, as jobs do. A joint venture forms. A design team is novated. A package is carved up. The information manager who knew which cupboard was live takes a role somewhere else and takes the knowledge with her; it was never written down anywhere the system could enforce. The tree does not update itself. People copy. They invent a parallel branch for the new arrangement and keep the old path "for reference". The same container now sits in three directories with three modified dates and one filename that still looks perfectly current.

A path is not a fact about the container. It is a fact about the last person who had a mouse. When identity is P-MEP/Issued/CDE_Published/AR-A-2010_C02.pdf, a rename becomes an identity crisis, a move becomes a silent supersede, and a copy becomes a second live sheet. None of those three acts is recorded as an issue. All of them look, to whoever opens the folder next, like ordinary filing.

Which is roughly how the unofficial set ends up in the trailer, and there is no villain in the story. A site team cannot rely on a tree built for an arrangement of companies that no longer exists, so the hut keeps its own printed set, the office argues with a screenshot, and later a claim fails for want of a contemporaneous file that everybody remembers seeing.

The only question a tree can answer is "where is it?"

That is the operating question on a file-centric job, and everyone has a practised answer. Coordinators send a deep link. Document controllers name a mapped drive. Package managers attach a zip from last Thursday. Each answer assumes location is enough: if you can open the file, you have the record.

You do not. Opening a file tells you what the pixels say. It does not tell you whether that container is work in progress, shared for coordination, published for construction, or archived because it was superseded on Tuesday afternoon. It does not tell you what the receiving party was allowed to do with it. It does not tell you which issued identity you are holding, or who was sent it as a deliberate act rather than who happened to have the folder open that week.

So file-centric jobs fail in a characteristic way. Two competent people are each "looking at the latest" and looking at different objects. The tree will not settle it. It offers both paths and a modified date, and a modified date records a save, not an authorisation.

The four claims that are actually the product

The product of information management is not the PDF; the PDF is what you transmit. The product is four claims attached to the container, each of which survives a reorganisation.

State is where the container sits in a managed process: work in progress, shared, published, archive. ISO 19650 describes a common data environment as an agreed source for collecting, managing and disseminating each information container through that process. A state is only a state if a gate enforces it. A folder named Published is a costume, and anyone with write access can dress a file in it. If one container can occupy two states at once — a shared copy emailed out, a published copy in the library, a hut print from last month — then what you have is directories.

Suitability is what the next person is permitted to do with it. In UK practice that is the status code: suitable for coordination, for information, for review, for a named published purpose. The code is a sentence about permitted use, and a path cannot hold a sentence. _S2 in a filename is folklore the moment somebody forgets to change it, and a column nobody is obliged to complete is decoration. Suitability becomes a fact when it can stop a plot, a buy, or an issue.

Revision is the issued identity: which series, which number, what it supersedes. C02 is a statement about what the site, the fabricator and the reviewer may rely on — not a save counter, and not "whatever is in the Issued folder today". Overwriting the file and keeping a version stack in the platform records who saved. It does not retire C01. If a superseded sheet can still be plotted as though it were current, revision is a rumour about a path rather than a property of the container.

Recipient is who received the issued set, as an act. An issued set is bounded: these revisions, this purpose, this list of companies, this moment. A transmittal is the evidence of it. Folders have uploads and downloads; they have no recipients. "They have access to the Published folder" is a hope that the right person opened the right cupboard on the right day.

Hold those four still and the job becomes specific. The container is the same object whether it sits under Architect, MEP, or a temporary JV branch that will be gone by Christmas. What changed is a view. What did not change is the claim.

Queries outlive the tree

A folder answers one question: what is in this cupboard. A metadata record answers the questions a job, a claim and a facilities team actually put to it.

What was in Published for this package on a named date? Which construction-series revisions went to the steel fabricator last month? Which containers still carry a coordination suitability while sitting somewhere named Published? Who received C02, and did they also get the instruction that superseded it?

Those are queries, and they do not care that the design team was novated in week forty or that the package was renamed twice. They fail on a file-centric job because the facts were never attached to the container in the first place. They were implied by a path that has since ceased to exist, or that now exists twice.

The golden thread, the delay file and the handover dataset are the same requirement in a harder setting: can you reconstruct the claim without first reconstructing the tree? If the honest answer is "we would have to walk folder history and old email", the work ahead of you is archaeology, and it will be billed as such.

The usual objections

The naming convention is the metadata, you will say. A well-run convention is a genuine kindness to humans and I would not want to lose one. It still cannot hold a state, a suitability, a revision series or a recipient list. A filename can hint. It cannot enforce, and it cannot be queried once somebody breaks the hint.

The columns are already there, someone else will say. Columns that can be skipped, contradicted by the title block, or left sitting on S2 for a year are a form rather than a product. The product is the claim the next process is forced to look at.

People find things by browsing, which is true, right up to the point where the organigram moves. Browse is a view, and views can be generated: all published electrical sheets for this level, current revision only. A view can be rebuilt after a restructure. A tree that is the identity cannot.

There are already WIP, Shared, Published and Archive folders, so surely the states are done. Four cupboards are still cupboards. The test is whether the system can stop a work-in-progress model being treated as published without a recorded review, and whether it can show the sequence of states for one container. Reconstruct that from folder history and what you have is a story about directories.

Recipients are a transmittal problem, not a folder problem — and yes, precisely. A tree cannot hold a transmittal. Treating the folder as the system of record is exactly how the transmittal degrades into an optional PDF in a parallel cupboard that nobody audits.

The appointing party should stop accepting a folder tree as the CDE. Before the next environment is nominated — or before the next novation, if you are already live — require that state, suitability, revision and recipient sit on the container and can be queried after the organigram moves. Ask the vendor, or your own team, to answer those four questions for one issued set while you watch. If they have to walk folder history and old email, you are buying a cupboard. Writing that test into the information protocol costs an afternoon with the protocol and the labour of treating transmittals as first-class records. Redesigning the tree does not.