- Watch out
- What it costs
- Experienced readers
- Remember
- In BIMpedia
Every container in a common data environment has a name, built from the project's naming fields, that never changes. But the same container is worked on, shared, revised, approved and finally kept as a record. What changes, and what tells people how far to trust it, is its metadata.
Think of the name as the container's identity and the metadata as its current label. ISO 19650 asks for at least three attributes on every container: its status, its revision and its classification. The CDE adds others automatically (who uploaded it, when, file size). The UK National Annex gives a standard list of codes, summarised in the Pedia entry on suitability and revision codes.
Three questions, three attributes
| Attribute | The question it answers | Examples | Changes when |
|---|---|---|---|
| Status (suitability) | What may I use this for? | S1 coordination, S2 information, S3 review and comment, A1 authorised | It moves between CDE states or its purpose changes |
| Revision | Which version is this? | P01.1 in progress, P02 shared, C01 published | Its content changes |
| Classification | What is it about? | A Uniclass code for the system or element | Rarely; it's set at the start |
Each move is a decision: check before sharing, authorise before publishing. Information that needs changes goes back to work in progress.
Status follows the container through the CDE: a task team's work in progress is S0; when shared it gets a suitability (S1 for coordination, S2 for information, S3 for comment); once the lead appointed party authorises and the appointing party accepts it, it is published with an authorised status (A-codes), and at the end it becomes a record.
- • Your task team
Each move widens who may rely on the model, so each move needs a decision. Clash detection runs on shared models, never on someone’s work in progress.
The engineer shares a general arrangement drawing for coordination. The title block says "Preliminary", but in the CDE it was uploaded with a blank status. The steelwork contractor downloads the newest file and orders sections. Two weeks later the drawing is revised; three tonnes of steel are wrong.
The CDE won't accept an upload without a status from the project's list. The drawing is S2, and the steelwork contractor's procedure says only A-status drawings may be used for orders. They wait for the published C01 at A1, which arrives with the revised sizes.
The name and the metadata must agree
Codes are stored in the CDE, and drawings usually print them in the title block too. The two must say the same thing. Make one of them the source (the CDE) and fill the title block from it where the software allows; check a sample at every issue.
Here are four containers in a project CDE. For each, say what is wrong (if anything) and what it should be.
| Container | State in CDE | Status | Revision |
|---|---|---|---|
| A: Level 02 MEP model | Shared | S1 | C01 |
| B: Ground floor GA drawing | Work in progress | S3 | P02 |
| C: Door schedule | Published | A1 | C02 |
| D: Structural model, stage 3 | Shared | (blank) | P03 |
Key takeaways
- The name identifies the container for its whole life; status, revision and classification are metadata that change or describe it.
- Status (suitability) says what the information may be used for; revision says which version it is; classification says what it is about.
- Shared information uses preliminary revisions (P01, P02); published information uses contractual ones (C01). Work in progress adds a point version (P01.1).
- Codes live in the CDE's metadata and must match what's printed on the drawing; the project's own list in the information standard is the one that counts.
Your notes
Related tool
Keep the drawing list with revisions and status, check numbers, and issue transmittals.
Open Drawing Register and Transmittals →