Container Information States ISO 19650: WIP, Shared, Published, Archived

Anyone working with an ISO 19650 compliant CDE eventually faces a seemingly trivial question: “What state is this file in?” The answer is far more than technical – It is regulatory, contractual, operational.

Within ISO 19650, information containers move through four defined states across the project information lifecycle: Work in Progress (WIP), Shared, Published, and Archived. Each state determines who can access, edit, approve, or rely on the information, with every transition governed by documented workflows and authorization rules.

Understanding these states is essential to transforming a CDE from a simple document repository into a true information governance platform. In this article, we explore what each state represents, how transitions between states are managed, and how an advanced CDE supports these processes operationally and transparently.

If you have not yet read our introduction to the ISO 19650 compliant CDE, we recommend starting there first. This article focuses on one of its most critical and technically detailed aspects: the lifecycle management of information containers.s.

The lifecycle of the information container: four states, one process

ISO 19650-1 (§12) defines four main states that each information container goes through during the project. This is not a rigid sequence: a container can revert to previous states if deficiencies are found, and not all containers reach archiving at the same time.

The states are:

• Work in Progress (WIP) – being worked on internally by the team producing the content;
• Shared – shared with other teams or disciplines for coordination;
• Published (or Published for use) – published and approved for contractual use;
• Archived – archived as historical reference.

Each state is characterized by four elements: who has access to the container, what they can do, how the transition to the next state occurs, why the container is in that phase.

The general cycle scheme

The transition between states occurs through the CRA (Check, Review, Approve) process – verification, review, and approval – governed by ISO 19650-2. Each transition leaves a trace in the CDE’s audit trail.

General scheme of the state cycle of a CDE

Status 1 — Work in Progress (WIP): the team’s workspace

Work in Progress is the initial status of each informational container. It’s the space in which the team producing the content – typically a Task Team in ISO 19650 terminology – works freely without exposing the material to others.

Who accesses the WIP

Only the members of the Task Team that is producing the informational container. Other disciplines, the client, the verifier, and other teams do not have visibility on the content in WIP.

What can be done

In WIP, the team maintains full operational control over the informational container, with the freedom to:

• create, modify, and delete content freely;
• test solutions, iterate, make mistakes;
• collaborate internally within the team without formalities;
• associate preliminary but not yet definitive metadata.

Operational characteristics

WIP is the only state in which the informational container can be deleted (before formal sharing). Once the container transitions to Shared, any modifications create a new tracked revision.

Typical suitability code

The associated suitability code is generally S0 (Initial status) or equivalent, indicating that the container has not yet undergone internal verification.

The transition to Shared

When the Task Team believes that the container is ready to be shared with other disciplines, it initiates the internal check (technical self-verification) process. Only after a positive check can the container transition to Shared. This transition is typically authorized by the Task Team Manager or the BIM Coordinator.

Status 2 — Shared: sharing for coordination

The Shared status marks the transition from internal use to interdisciplinary use. The container is now visible to other project teams and the Lead Appointed Party (the coordinating entity for the entire informational assignment).

Who accesses the Shared container

When a container transitions to the Shared status, its visibility extends to:

• the Task Team that produced it (with limited modification rights);
• the other Task Teams of the project (in read mode, for coordination);
• the Lead Appointed Party (for review and verification);
• the client (Appointing Party) depending on the rules of the Informational Specifications.

What can be done

In the Shared status, the informational container becomes a coordination tool among disciplines, therefore it can be used to:

• consult the container for coordination activities;
• annotate, comment, raise issues (typically via BCF);
• verify consistency, clash detection, disciplinary coordination;
• request modifications from the producing Task Team through the formal process.

In the Shared status, the content cannot be used for construction or contractual decisions: it is coordination material, not published material.

Typical suitability codes

The Shared status includes different suitability codes depending on the purpose of sharing:

• S1 – Suitable for Coordination;
• S2 – Suitable for Information;
• S3 – Suitable for Internal Review and Comment;
• S4 – Suitable for Stage Approval;
• S6/S7 – Suitable for PIM Authorization / AIM Authorization.

Each code has different contractual and operational implications and must be consistent with the project phase.

The transition to Published

If the container passes the verification and approval process (Check, Review, Approve) conducted by the Lead Appointed Party and/or the Appointing Party, it transitions to Published. If non-conformities are found, the container returns to WIP with correction instructions (rework loop).

Status 3 — Published: the container approved for use

The Published status marks the official approval of the information container by the Appointing Party (the client). From this moment, the container has contractual value and can be used for the operational decisions of the project — executive design, construction, testing, management.

Who has access to Published

Read access is typically extended to all parties involved in the project, according to the rules of the Information Specification. Modification rights are, however, extremely limited: a Published container cannot be modified directly. Any change requires opening a new revision, which starts the cycle from WIP.

What can be done

Once the Published status is reached, the information container takes on a different role compared to the previous phases and can:

• use the container for contractual activities, construction, management;
• consult in a definitive and authoritative manner;
• cite in contractual documents and formal communications;
• NOT modify directly: a new revision must be opened.

Typical suitability codes

• A1-AN – Authorized for [scope] (authorized for a specific purpose);
• B1-BN – Partially signed-off (partially approved, with reservations);
• CR – As Constructed Record (record of the construction);
• PR – Published Record (final archive publication).

The code specifies the scope of authorized use: for example, A1 may mean “Authorized for Construction”, CR “As-built record”, etc.

Revision codes

Alongside suitability codes, revisions of the container are tracked with revision codes:

• P01, P02, P03… – design phase revisions (Pre-construction)
• C01, C02, C03… – construction phase revisions (Construction)

The combination of suitability code and revision code uniquely identifies the semantic state of the container: “S2-P03” means “suitable for information, third pre-construction revision.”

The transition to Archived

At the end of the operational use of the information container – typically at the end of the project phase or the end of the assignment – the container is archived. This does not mean removing it: it means freezing it in a state of permanent read-only.

Status 4 — Archived: the immutable historical reference

The Archived status retains the information container as a historical reference. It is the final state of the life cycle, but does not imply obsolescence: on the contrary, it represents the authoritative memory of the project.

Who has access to Archived

Access is typically guaranteed in read-only mode to all parties who had visibility rights on the Published container. Archiving does not eliminate consultation rights but blocks any modification.

What can be done

In the Archived state, the information container loses every active operational function and is preserved as stable evidence of the project’s information path where one can:

• consult the container for historical reference, audits, disputes;
• export for transfers to third-party systems (e.g., CAFM during Facility Management);
• NOT modify, NOT delete: the container is frozen.

Why archiving is critical

From a regulatory and contractual perspective, the Archived status is the objective evidence of what has been produced, approved, and used during the project. It is the documentary basis for:

• Compliance audits (ISO 9001, ISO 19650-5, safety)
• Contractual disputes between the client and the engaged parties
• Third-party verifications (inspectors, control bodies)
• Information transfer to Facility Management (handover)
• Post-construction environmental assessment (LCA, EPD verification).

How an advanced CDE operationally manages states

The standard describes the states, but it is the CDE platform that makes them operational. The behaviors that differentiate a mature CDE from a cloud storage solution concern the management of states.

Clear display of the status

Every information container must immediately and unambiguously display its current status, with text labels. An advanced CDE offers filterable views by status, allowing the CDE Manager to monitor in real-time the distribution of containers throughout the cycle.

Transitions regulated by workflows

The transition between states does not occur by arbitrary action: it is the result of a structured workflow that the CDE automatically activates. The workflow identifies the involved parties (by role or user), notifies them, collects approvals, and records the transition in the audit trail.

An advanced CDE platform allows configuring different workflows for different types of containers: a structural IFC model will follow a different workflow from a contractual document, and a mature CDE allows defining these flows granularly.

Permissions conditioned by status

Access and allowed actions depend on the status: a user may have modification rights on the WIP container but only read rights when it switches to Shared. The CDE must automatically manage this dynamic permission matrix, without requiring manual intervention at every transition.

Consistent versioning with states

Every status transition can generate a new version of the container. In particular, returning from Shared to WIP after a revision generates a new version of the content while keeping the previous one visible as historical reference. When a revision is uploaded, the ongoing workflow on the previous version is interrupted in the state it is in and remains consultable as an archive of the process. A new process can start on the new version consistent with the updated content.

Modules associated with states

An advanced CDE allows associating structured modules (checklists, verification sheets, technical validations) with the states of the container. A module can be fillable only when the container is in Shared or become mandatory before authorizing the transition to Published. This allows conditioning transitions to the gathering of structured data, not just to a generic approval.

Suitability codes: the reference guide

Suitability codes are the semantic complement of statuses. While the status tells “where” the container is in the cycle, the suitability code tells “for what” it is suitable at that moment.

Complete table of ISO 19650 suitability codes

Note on variability

The suitability codes listed here are those recommended by the UK BIM Framework standards and widely adopted as an international reference. ISO 19650 does not impose exact codes: each organization or project can adopt its own convention, provided it is defined in the Information Specification.

Revision codes: version traceability

In addition to suitability codes, revision codes track the version of the container. The most common convention:

• P01, P02, P03… for design stage revisions (pre-construction);
• C01, C02, C03… for construction stage revisions (construction);
• some organizations add D01 for revisions after handover to the client (deployed).

The combination “Suitability – Revision” (e.g., “S2 – P03”, “A1 – C02”) uniquely identifies the semantic status of the container at a specific moment.

How they are managed in the CDE

An advanced CDE automatically generates revision codes incrementing them with each new version, avoiding manual naming errors. The system must also prevent the “reuse” of already used codes (e.g., skipping from P01 to P03 without passing through P02) to maintain consistency and traceability.

Common errors in status management

After years of implementing the CDE in AEC projects, some recurring errors arise that are good to know to avoid:

• Confusing Shared with Published: Shared is not published. It has no contractual value, cannot be used for operational decisions, and does not justify construction. Using a Shared container as if it were Published is one of the most frequent causes of disputes.
• Skipping the Shared phase: some teams upload containers directly in Published status without going through Shared. This bypasses the interdisciplinary coordination process and can lead to undetected clashes, inconsistencies between disciplines, and failure to align with information requirements.
• Treating archiving as deletion: the archived container should not be deleted: it should be frozen in read-only mode. Permanent deletion may violate contractual and regulatory retention obligations and compromise the ability to defend against disputes.
• Directly modifying the Published: a Published container cannot be modified; any change requires a new revision that retraces the cycle. “Silently” modifying a Published container (often for “small corrections”) nullifies traceability and undermines the validity of the entire information process.
• Permissions inconsistent with status: allowing a Task Team to freely modify a Shared container, or worse, a Published one, from another discipline is a serious configuration error of the CDE. Permissions must be conditional on the status and segregated by role.

The 10 requirements of an ISO 19650 compliant CDE platform

Correct management of statuses is just one of the ten fundamental requirements of a compliant CDE platform. If you are evaluating a platform or want to verify the compliance of the one you are using, we have prepared a free tool:

Try the interactive states simulator — View the lifecycle of the information container, click on each status to discover permissions, actors, codes, and transitions. Ideal for team training and onboarding new users.

The CDE as an ecosystem: state management in real platforms

Advanced CDE platforms implement state management in ways that go beyond mere labeling. In ACCA’s usBIM ecosystem, for example, usBIM.platform — the ISO 19650-compliant CDE — manages the states of the information container as active workflow elements, with regulated transitions, clear visualization of progress status, and full traceability.

Around usBIM.platform, the ecosystem provides specific tools for the activities carried out in the different states:

• in the WIP state, the team collaborates using apps such as usBIM.editor and usBIM.writer for content creation and editing;
• in the Shared state, tools such as usBIM.clash for coordination, usBIM.bcf for interdisciplinary issue tracking, usBIM.compare for revision comparison, and usBIM.federation for the federation of discipline-specific models come into play;
• for information quality, which determines the transition to the Shared and Published states, usBIM.dataquality provides IDS validation according to the requirements of the Information Requirements Specification;
• in the Published and Archived states, the platform guarantees read-only access, full audit trail, consistent versioning, and export to downstream systems (e.g. usBIM.maint for Facility Management during the handover phase).

The value lies in the fact that the states are not only managed by the platform, but orchestrated with specialized apps: each state automatically enables the appropriate tools and workflows, reducing the risk of operational errors.

Frequently Asked Questions (FAQ)

What are the states of the information container?

The states of the information container are the four phases of the project information lifecycle defined by ISO 19650: Work in Progress (WIP), Shared, Published, Archived. Each state determines who can view, modify, and use the container, with transition rules tracked and authorized.

What are the four ISO 19650 states?

The four states are: Work in Progress (WIP), under internal team processing; Shared, shared for interdisciplinary coordination; Published, approved for contractual use; Archived, archived as immutable historical reference.

What does WIP mean in the CDE?

WIP (Work in Progress) is the initial state of the information container, in which only the producing team (Task Team) has access. In this state, content can be freely modified and deleted. It is the only state in which the container can be deleted before formal sharing.

What is the difference between Shared and Published?

The Shared container is shared among disciplines for coordination but has no contractual value. The Published container is formally approved by the client (Appointing Party) and can be used for operational decisions, construction, and contracting. Shared does not equate to Published.

What is the CRA process?

The CRA (Check, Review, Approve) is the process of verification, review, and approval that governs the transitions between states of the information container. It is regulated by ISO 19650-2 and is the mechanism through which a container moves from Shared to Published.

Can a Published container be modified?

No, an information container in the Published state cannot be modified directly. Any change requires the opening of a new revision that restarts the cycle from the WIP state. This ensures the traceability and contractual immutability of published versions.

What happens when a new version of a file is uploaded to the CDE?

When a new version of an information container is uploaded, the previous version is retained in the history. If there was an ongoing workflow on the previous version, it is typically interrupted in its current state and remains available as historical reference, while a new process can start on the new version.

Is archiving in the CDE the same as deletion?

No, archiving an information container means freezing it in permanent read-only form. It should not be deleted: the archived container represents the objective evidence of what was produced and approved during the project, and it is essential for audits, disputes, and transfers to Facility Management.

Who authorizes transitions between states?

Authorizations depend on the transition: the move from WIP to Shared is typically authorized by the Task Team Manager or the BIM Coordinator. The transition from Shared to Published is authorized by the Lead Appointed Party and/or the Appointing Party (client). The transition from Published to Archived occurs according to the rules of the Information Specification, usually at the end of a phase or project.

What are Task Teams, Lead Appointed Party, and Appointing Party?

These are the three levels of informational roles defined by ISO 19650-1. The Appointing Party is the client requesting the project information. The Lead Appointed Party is the main appointed party (e.g., general contractor) coordinating the other parties. Task Teams are the specific work teams that produce the informational containers (e.g., structural team, MEP team).

How is the rework of an information container managed?

If non-conformities are found during the verification of a Shared container, the container returns to the WIP state with correction indications. The Task Team makes the changes and returns the container to Shared as a new revision. The CRA cycle restarts. The entire process — including the interrupted workflow — remains available in the audit trail.

How are states displayed in the CDE?

An advanced CDE platform must show the status of each information container immediately and unambiguously, typically with color codes, text labels, and suitability codes visible directly in the file list. It must also offer filterable views by state and a project dashboard with the aggregated distribution of states.

What happens if a container never reaches the Published state?

Not all containers reach Published. Some may remain in WIP or be deleted before sharing. Others may be shared but then surpassed by subsequent versions that are published in their place. The important thing is that the audit trail records the actual path followed by each container.

Essential Glossary

Appointing Party – Client, entity that requests project information.

Archived – Final state of the information container: archived in read-only form as historical reference.

CDE – Common Data Environment. ISO 19650 compliant Data Sharing Environment.

Information Container – Basic unit of information in the CDE, with structured metadata.

CRA – Check, Review, Approve. Process of verification, review, and approval.

Lead Appointed Party – Main appointed party, coordinator of the information project.

Published – State of the information container approved for contractual use.

Revision Code – Code that identifies the version of the container (P01, P02, C01, C02…).

Rework – Return of the container to the WIP state after a negative review.

Shared – State of the container shared for interdisciplinary coordination.

Suitability Code – Code of suitability indicating the purpose of use of the container (S0-S7, A1-AN, B1-BN, CR, PR).

Task Team – Work team that produces a specific information container.

WIP – Work in Progress. Initial state of the container, under internal team processing.