ISO 19650 sets out how project teams exchange documentation through a common data environment (CDE). One of its most practical elements is the document status lifecycle — four stages that define who can see a given file and what can be done with it. In most implementations they look like this: WIP, Shared, Published, Archived.
WIP — work in progress
A document marked WIP is a draft. Only the team producing it can see it — the rest of the project has no access. That’s deliberate: a drawing or specification at an early stage may contain mistakes, unfinished sections, or variants that will end up discarded. While a document sits in WIP, its author can revise it freely, or even delete it — nobody else depends on it yet.
Shared
Once a draft is ready to be coordinated with other disciplines, it moves to Shared. From that point the whole project team can see it — architect, structural engineer, contractor. This is a coordination stage, not a final release: an architect might share a floor plan so the structural engineer can mark it up, before anyone builds from it. A shared document can still be replaced by a new revision, with no formal-issue trail attached.
Published
Published is the formal issue of a document by the firm leading the project — the point at which it becomes the basis for further work, for example construction. It’s also a line that can’t be crossed back over: a published document cannot be deleted. If something needs fixing, a new revision is created to replace it — but the previous version stays, as a record of what was issued and when.
Archived
When a new revision replaces a published document, the old version doesn’t disappear — it moves to the archive. Archived means read-only access: nobody is working on that file anymore, but the whole project team can go back to it to check which version was in effect at a given time. That matters practically, not just for tidiness — if there’s ever a dispute about what was agreed and when, the archive is the evidence.
Why this works
The strength of this model isn’t in the status names themselves, but in the fact that each one answers two concrete questions: who can see the document, and what can be done with it. Without that distinction, teams fall back on old habits — emailing files “for information”, overwriting versions on a shared drive, and guessing whether a file called “final” is actually final. In DocuBIM, these four statuses are built into how a document is handled: a published file can’t be deleted, and every status change is recorded in its history.