Naming, Containers & the Golden Thread

ISO 19650 calls each managed unit of information an information container — a model, drawing, document or dataset held in the CDE. The point of the term is that these are the things being versioned, statused and named; the CDE manages containers, not loose files.

Each container gets a structured name built from coded fields — typically the project, the originating organisation, the volume or zone, the level, the type of information, the discipline, and a sequential number, plus status and revision codes. Rather than 'ground floor plan final', a container carries a consistent code that a person *or a computer* can read: which project, whose work, what part of the building, what kind of document, which version, at what status. It looks bureaucratic, and it is transformative — because a coded, consistent name is what lets you filter ten thousand containers down to 'the current, published architectural plans for level 3' in seconds, and lets software route, check and assemble information automatically. Consistency is the whole value: a naming rule everyone follows beats a cleverer one only some obey.

A container's name is only part of its identity. Alongside it travels metadata: its status (the CDE state and suitability — is this WIP, shared, published?), its revision (which version this is), and its history. This is what connects naming back to the CDE of lesson 5.1: the states are meaningful precisely because each container carries, unambiguously, where it is in its lifecycle and which revision you are looking at.

This matters most at the moment of trust. When you open a container to build from, its status and revision tell you — without guesswork — whether it is the current, authorised version. Superseded revisions are archived, not deleted, so there is always a traceable answer to 'what was the approved information on this date?'. That combination — a name you can read, a status you can trust, a revision you can trace, and a history you cannot lose — is what turns storage into an auditable record. It is the difference between 'a file exists somewhere' and 'this exact, authorised version was current when that decision was made'.

All of this builds to the golden thread: the idea that a building should have a continuous, reliable, accessible and up-to-date record of the information that matters — especially for safety — traceable across its entire life, from design through construction into decades of operation and change. The term rose to prominence after the Grenfell Tower fire in the UK, where a fatal part of the failure was that no one could reliably say what the building was actually made of; the golden thread is the response — information kept trustworthy and findable so that, years later, the right answer is available to the people who need it.

The honest point is that the golden thread is a *discipline*, not a document. It exists only for as long as people keep working through the CDE, naming containers properly, statusing and revising honestly, and never doing critical work in private files outside the system. The moment someone maintains the real fire strategy on their own laptop, the thread is broken — and you do not discover the break until you desperately need the information and it is not there, or not trustworthy. Naming and container discipline sound like housekeeping; they are, in fact, how a building keeps a memory it can stake lives on. That is why the dull topic is one of the serious ones.