Understand what a BIM CDE is, how a Common Data Environment works under ISO 19650, and how to control revisions, states, approvals, access, deliverables, and traceability.
Check it out!
A project may have all files centralized on a cloud platform and still operate with unreliable information. Imagine a team with three versions of the same electrical design named ELETRICA_FINAL.pdf, ELETRICA_FINAL_02.pdf, and ELETRICA_REV3_APROVADO.pdf. All documents are in the same repository, yet no one can confidently state which revision is valid for coordination, which was only checked internally, which is authorized for construction, who approved the change, or which version was superseded.
This scenario shows why CDE BIM — Common Data Environment — should not be understood as a synonym for a shared folder, corporate drive, or storage software. A CDE is part of the information-management process: it must support identification, states, revisions, classification, permissions, transitions, records of responsibility, and criteria that make it possible to know not only where information is located, but under what condition it may be used.
ABNT NBR ISO 19650-2 treats the CDE as infrastructure required for collaborative information production. The standard establishes that the environment must support unique identification of information containers, agreed coding, assignment of status, revision and classification, controlled transitions between states, recording of user and date, and access control at the container level. The same normative process then connects the CDE to quality assurance, review, approval for sharing, authorization, acceptance, and archiving.
The thesis of this article is straightforward: a CDE creates value only when it turns storage into operational information governance. Technology is necessary, but the outcome depends on requirements, roles, transition rules, metadata, acceptance criteria, and disciplined use.
A CDE is not simply “where the file is.” It is the environment that allows teams to know which information is valid, which revision applies, for what purpose, under whose responsibility, and with what evidence of approval or acceptance.
What is a BIM CDE and why is it more than a cloud folder?
CDE stands for Common Data Environment. In the context of BIM information management, a CDE is the environment in which information containers are produced, shared, reviewed, authorized, accepted, and preserved in a controlled manner.
The term “information container” is important because a CDE does not deal only with three-dimensional models. A container may be a BIM model, drawing, technical memorandum, spreadsheet, report, specification, calculation file, record, or another identifiable set of information that forms part of the delivery process.
For this reason, the discussion about CDEs is broader than choosing a BIM platform. The real problem is creating a controlled source of information for the project.
Centralization is not the same as control
Consider a project involving architecture, structural engineering, electrical engineering, HVAC, and project management. All teams receive access to the same cloud storage. Each designer creates its own folders and publishes files whenever it believes a revision is ready.
Within a few weeks, files appear with names such as:
ARQ_FINAL.rvt
ARQ_FINAL_NOVO.rvt
ARQ_REV04_COORD.rvt
ESTRUTURA_OK.ifc
ELETRICA_APROVADO.dwg
ELETRICA_APROVADO_CORRIGIDO.dwg
Centralization exists. Governance does not.
The team still has to determine, through human interpretation, which file is current, what “OK” means, who authorized “APPROVED,” whether the previous revision remains valid, whether the document is only for coordination or for construction, and who must be informed when a revision is superseded.
This type of process works while the project is small, people know one another, and team memory resolves ambiguities. In multidisciplinary projects, long-term contracts, multiple companies, or staff turnover, it becomes an engineering risk.
The central CDE question is: “what may this information be used for?”
Imagine that the electrical designer has completed a model revision. Before sharing it with other disciplines, its own team still needs to verify naming, required parameters, technical consistency, and internal coordination.
The file exists, but it should not yet be used by other disciplines.
Later, the team completes its internal review and releases the model for coordination. The information can now be used as a reference by other teams, but this does not necessarily mean that it is authorized for construction.
At another stage, a specific set of documents may be authorized as a formal deliverable.
Therefore, a CDE must make it possible to distinguish the condition of use from the mere existence of the file.
The difference may seem administrative, but it has technical consequences. An HVAC team coordinating ducts against an electrical revision that is still in development may generate dozens of false clashes. A contractor using a drawing shared for coordination as if it were released for construction may build a solution that has not yet been authorized.
A CDE is not a specific product
Another common mistake is to turn the acronym CDE into a synonym for a particular commercial platform.
There are software products capable of supporting CDE workflows, document control, models, revisions, approvals, issues, permissions, and history. But the CDE concept does not belong to any specific vendor.
A technology solution should be evaluated against process requirements. It must support the workflow established for that project, including the required permissions, metadata, transitions, records, and integrations.
This distinction is also important in procurement. Writing “use platform X” does not replace defining how information will be identified, classified, checked, shared, authorized, and accepted.
ABNT NBR ISO 19650-2 itself provides that the appointing party may host and manage the CDE directly, contract a third party, or later transfer specific functions to a lead appointed party. The requirement is functional: the environment must support the established process.
A CDE can be distributed
Another relevant point is that a Common Data Environment does not necessarily mean “a single physical system where everything happens.” ABNT NBR ISO 19650-2 provides, during mobilization, for configuring and testing both the project CDE and a distributed delivery-team CDE, including its connection to the project environment where applicable.
This better reflects the reality of many projects. A design firm may have its internal production environment; the coordinator may use a specific platform for federation and issues; the client may maintain the official delivery environment. The challenge is ensuring that boundaries and exchanges are controlled.
Governance must answer:
1. where information is produced; 2. when it leaves the internal environment; 3. which checks occur before sharing; 4. how information enters the official CDE; 5. who may use it and for what purpose; 6. how revisions and supersessions are recorded; 7. how the final deliverable is authorized and accepted.
Without this definition, multiple platforms simply multiply points of uncertainty.
The value of a CDE lies in trust, not in storage volume
A CDE containing terabytes of documents can be technically worse than a smaller, well-governed environment.
The success metric is not the number of files. It is the ability to answer questions such as:
- which revision is current?
- what is the state of that information?
- who is the responsible author?
- who checked and approved it?
- when did the state transition occur?
- which classification was applied?
- who has access?
- for what use is the information released?
- what was superseded?
- what evidence demonstrates acceptance?
When these answers are traceable, the CDE stops being a repository and begins functioning as decision-making infrastructure.
The article on Information Management in BIM and ISO 19650 presents the broader process in which the CDE is embedded. Here, the focus is on understanding how this infrastructure is materialized in the project’s day-to-day workflow.
How information flows inside a CDE
A mature CDE does not treat every file as equivalent. Information moves through states and control points as it matures.
In practice, different organizations may adopt specific terminology or implementations, but the principle remains stable: information under development should not have the same condition of use as information that has been reviewed, shared, authorized, or accepted.
Work in progress: information still belongs to the authoring team
At the beginning of the flow, the team produces information in its working environment.
Imagine the electrical model of a building. The designer is adjusting cable-tray routes, panel locations, feeders, and technical spaces. During this stage, the team may save the file dozens of times per day. Some changes are incomplete. Some objects have been moved temporarily. Others are still awaiting calculations or a coordinator decision.
It would be inappropriate for every save to automatically become a reference for architecture, structural engineering, and HVAC.
Working information must remain clearly identified as work in progress until it passes the established checks.
This does not mean hiding the design. It means preserving the author’s responsibility and preventing provisional information from being interpreted as a valid reference.
Quality assurance and checking come before sharing
ABNT NBR ISO 19650-2 requires each team to perform quality-assurance checks on its information containers before reviewing them for sharing.
This distinction is important because “the file opens” does not mean “the file complies.”
Checks may verify, for example:
- identification convention;
- presence of required metadata;
- container structure;
- information standards;
- naming requirements;
- file integrity;
- required properties or classifications;
- consistency with organizational procedures.
Some of these checks may be automated. But the standard itself essentially warns that compliance checking does not replace technical review and approval of the information’s suitability.
This creates a useful distinction:
compliance checking answers whether the container follows established rules;
technical review answers whether the information is suitable for its intended use.
A model can be perfectly named, classified, and populated and still contain an incorrect engineering solution.
Approval for sharing is not the same as authorization as a deliverable
After checking, the team reviews the information and decides whether it may be shared.
Consider the electrical model again. The team has completed its internal analysis and believes that revision can be used by structural and HVAC teams for coordination. It then assigns the corresponding state and releases the information into the workflow.
From that point onward, other participants may use it according to the defined purpose.
However, sharing should not be confused with final authorization of the information model.
Under the ABNT NBR ISO 19650-2 process, before delivery to the appointing party, teams submit their information to the lead appointed party for authorization. The lead party checks the information model against the MIDP, exchange information requirements, acceptance criteria, and the required level of information.
Only after this authorization does the information proceed to review and acceptance by the appointing party.
This sequence creates different controls:
team production → checking → review → sharing → coordination → submission → authorization → acceptance.
A good CDE must support these distinctions without relying on improvised file names.
Complete example: from electrical revision to client acceptance
Consider the container ELE-Z01-M3, corresponding to the electrical model of a specific zone.
The electrical team produces revision R05 in its working environment. During production, the file should not be used by other disciplines because it contains changes that have not yet been checked.
When the team completes the revision, it performs the required checks. The model has correct identification, classification, required parameters, and a valid structure. The responsible engineer then reviews the content and approves R05 for sharing.
Architecture, structural engineering, and HVAC begin using R05 for coordination. Two issues arise: a cable tray clashes with a beam, and a panel has insufficient maintenance clearance. The issues return to the electrical team.
The team corrects the model and produces R06. The new revision again goes through checking and review before sharing.
At the delivery milestone, the lead appointed party consolidates the containers listed in the MIDP and checks the information model. If the deliverable meets the requirements, it is authorized for submission to the client.
The appointing party then reviews the package against its requirements and acceptance criteria. If accepted, that set becomes a formal deliverable.
Notice that the same “electrical model” passed through several conditions of use. The CDE must make that history traceable.
Revision, state, and purpose are not synonyms
This distinction prevents many errors.
Revision indicates an evolution of the container.
State indicates its condition within the workflow.
Purpose or suitability indicates the use for which it has been released.
A newer revision is not automatically the valid revision for every purpose.
For example, R06 may still be under development while R05 remains the latest revision approved for coordination. If the platform simply sorts by date and shows “R06” as the most recent file, a participant may use information that has not yet been released.
The CDE must preserve the distinction between most recent and current for a defined use.
Most recent does not automatically mean current. A new revision may remain under development while the previous one continues to be valid for coordination, construction, or another defined use.
The transition must leave an audit trail
ABNT NBR ISO 19650-2 requires the CDE to record the user name and date when container revisions transition between states.
This record has technical, contractual, and management value.
If a project built a specific solution, the team must be able to reconstruct which information was authorized at that time. If a revision was superseded, the transition must be identifiable. If an approval was incorrect, the history should show who performed the action and when.
Without history, the platform may show the current situation but does not explain how the project arrived there.
Archiving is not simply moving old files to another folder
At the end of the delivery phase, ABNT NBR ISO 19650-2 requires the accepted set of information containers in the CDE to be archived, considering future needs for the asset information model, access requirements, reuse, and retention policies.
This means closeout must preserve context.
An old file without metadata, state, revision, authorship, or a link to its deliverable may have little value years later. An archived set with traceability, by contrast, supports audits, maintenance, retrofits, expansion, contractual disputes, and reconstruction of the technical history.
This is where the CDE begins to connect with Engineering As-Built and asset governance during operations.
What a CDE must control to be reliable
A platform may offer dozens of features and still fail at basic controls. For this reason, evaluating a CDE should begin with governance dimensions, not with the software vendor’s commercial feature list.
ABNT NBR ISO 19650-2 provides a particularly objective basis by requiring unique identification, coding, state, revision, classification, recorded transitions, and controlled access at the information-container level.
The table below translates these foundations into engineering questions.
| Dimension | What the CDE must control | Audit question |
| identification | unique container code | can this document/model be distinguished unequivocally? |
| coding | standardized field values | does everyone use the same convention, or does each company invent its own naming scheme? |
| revision | container evolution | which revision is current and which ones were superseded? |
| state/suitability | condition of use | may this information be used for internal work, coordination, authorization, or construction? |
| classification | information context and organization | does the classification allow the content to be located, filtered, and interpreted? |
| authorship | responsibility for production | who is accountable for the information? |
| transition | change between states | who changed the condition of use and when? |
| access | read, modify, and approve | does each participant have only the authority required? |
| history | transaction record | can the sequence of decisions be reconstructed? |
| acceptance | deliverable-review outcome | is there evidence that the requirement was met? |
Unique identification prevents the file name from carrying all the intelligence
In informal environments, people try to place in the file name everything the system itself does not control.
Names appear such as:
ELETRICA_BLOCOA_EXECUTIVO_REV4_APROVADO_FINAL_07-08-26.pdf
The name attempts to communicate discipline, location, phase, revision, state, and date at the same time.
The problem is that each person may interpret or write it differently. Small differences break filters and automation. One team uses ELE; another EL; another ELETRICA. One participant writes REV04; another R4.
In a CDE, identification should follow an agreed and documented convention, with consistent fields and codes. The name stops being free-form narrative and becomes part of an information system.
Revision must be controlled without erasing history
Overwriting the previous file and keeping only the latest copy reduces traceability.
An engineering process needs to know what changed and in what sequence. This is especially important when different revisions were used in meetings, procurement, construction, or approvals.
Proper revision management does not mean everyone must have unrestricted access to every version. It means the system preserves history and presents the correct revision according to context and permissions.
State must have operational meaning
A label creates value only when it changes process behavior.
If “shared” and “authorized” appear as two different labels but any user may treat them in the same way, governance is merely decorative.
States must be associated with rules:
- who may promote the information;
- which checks are required before the transition;
- who may use the container after the transition;
- for what purpose it may be used;
- what record is stored;
- how rejection or return for correction occurs.
This logic turns the workflow into a control mechanism.
A state without a rule is only a label. To create governance, each transition needs clearly defined authority, checks, condition of use, and audit record.
Classification allows information to be found and reused consistently
ABNT NBR ISO 19650-2 relates information-container classification to the framework defined by ABNT NBR ISO 12006-2.
In practice, classification is an additional layer of meaning. It helps organize information by systems, elements, types, or other structures required by the project and the asset.
The issue is similar to that discussed in the article on Information Classification in BIM and NBR 15965: when teams use different concepts to describe the same thing, search, integration, and reuse deteriorate.
Access should not mean “everyone edits everything”
Collaboration does not mean absence of control.
A designer needs to edit the containers under its responsibility. A coordinator may need to review and comment. A lead appointed party may have authority to authorize. The client may need to accept. Other participants may be read-only.
If any user can modify an accepted deliverable, the value of acceptance is reduced.
Access therefore needs to be designed at the required level, considering reading, writing, review, state transition, authorization, and administration.
The standard also provides that the appointing party specify functional and non-functional requirements when CDE hosting, management, or support is contracted to third parties. Depending on the project context, this opens room for criteria such as availability, performance, security, interoperability, retention, and continuity.
Metadata is part of information engineering
A file contains content. Metadata explains the context of that content.
Discipline, zone, container type, revision, state, classification, authorship, and purpose are examples of information that makes it possible to filter, control, and automate the environment.
Imagine a project with 15,000 containers. Manually browsing folders is insufficient. The team needs to query, for example:
all electrical documents for zone 03, at a specific revision, authorized for a defined purpose and modified after a specific milestone.
This is reliable only if metadata is structured.
The CDE must control information without creating useless bureaucracy
Overly complex governance also fails.
If every transition requires twenty fields, five approvals, and tasks that do not change risk or quality, users start looking for shortcuts. Parallel spreadsheets, approval emails, and sharing outside the official environment appear.
The process should be proportional to the project’s complexity, risk, and needs.
Small projects may operate with simpler workflows. Large capital programs, critical infrastructure, data centers, hospitals, or projects involving multiple contractors may require more sophisticated controls.
The principle is to maintain enough control for information to be trustworthy, without turning the CDE into an obstacle to production.
CDE, ISO 19650, and other information-management instruments
The CDE does not operate in isolation. It is the operational infrastructure of a broader system of requirements, responsibilities, and delivery plans.
Under ABNT NBR ISO 19650-2, the appointing party first establishes needs, information requirements, delivery milestones, standards, methods and procedures, reference information, and shared resources. Within this context, it establishes the CDE and the information protocol.
Teams then respond to the appointment, develop and confirm the BEP, detail responsibilities, and structure the TIDP and MIDP. During mobilization, technology and the CDE are configured and tested. Only then does collaborative production occur in a controlled manner.
This sequence explains why simply buying software at the beginning of a project rarely solves the problem.
Requirements define what must be delivered; the CDE supports how delivery is controlled
A client may need to receive a federated model at a defined milestone, with specific properties, associated documentation, and defined acceptance criteria.
This requirement does not originate in the CDE. It originates in the information needs of the organization, project, or asset.
The CDE provides the infrastructure to ensure that containers produced against that requirement are identified, reviewed, shared, authorized, and accepted in a traceable manner.
Therefore:
a requirement without a CDE may produce deliverables that are difficult to control;
a CDE without a requirement may perfectly control information that no one actually needed to produce.
The two layers must be connected.
The BEP organizes the information-management strategy
The BIM BEP explains how the delivery team intends to conduct the information-management aspects of the appointment.
The BEP may include delivery strategy, roles, responsibilities, federation, standards, methods, procedures, software, hardware, and IT infrastructure.
The CDE is the environment where a relevant portion of these rules becomes operational.
If the BEP states that models must pass a specific check before federation, the CDE workflow should support that rule. If it defines an identification convention, the environment should apply it. If it establishes approval responsibilities, permissions need to reflect those roles.
A BEP disconnected from the CDE becomes a statement of intent. A CDE disconnected from the BEP becomes a tool without a process.
BEP and CDE need to work together. The BEP defines information-management rules; the CDE should turn those rules into controlled identification, permissions, transitions, deliverables, and evidence.
TIDP and MIDP turn deliverables into planned commitments
Each task team develops its TIDP — Task Information Delivery Plan, identifying the containers it will produce, dependencies, required level of information, duration, responsible author, and delivery dates.
The lead appointed party combines these plans into the MIDP — Master Information Delivery Plan.
The CDE should align with this planning.
Imagine that the MIDP calls for delivery of the electrical model, calculation memorandum, and single-line diagram by a defined milestone. The platform may contain hundreds of electrical files, but the process must recognize which containers formally constitute that deliverable.
This relationship makes it possible to measure completeness, identify delays, review the package, and record acceptance.
CDE and the federated model: sharing does not mean merging authorship
In BIM coordination, models from different disciplines may be federated for joint analysis.
The CDE provides the shared containers with the appropriate state. The coordinator uses this information to compose the federated model and perform analyses.
This does not mean the coordinator becomes the author of the disciplinary models.
If a clash is found between a cable tray and the structure, the issue returns to the responsible teams. The designer corrects the information at its source, passes through the workflow again, and publishes a new revision.
This logic preserves accountability and connects directly with the articles on Open BIM, IFC Files, and Clash Detection.
CDE and LOD/LOIN: the environment must know what should be there
The article on BIM LOD and LOIN showed that quality does not mean producing the maximum possible level of detail.
Likewise, the CDE should not reward information volume.
A deliverable must be evaluated against the required level of information. ABNT NBR ISO 19650-2 requires acceptance criteria to consider the level of information required for each information requirement.
This changes the audit question. It is not enough to ask “is the file in the CDE?”. The question must be:
does the delivered container contain the information it should contain for this milestone and this purpose?
CDE, PIM, AIM, and transition to operations
During the delivery phase, the project information model — PIM — is progressively developed. At closeout, relevant information may feed the asset information model — AIM — to support operations and maintenance.
The CDE needs to preserve this continuity.
ABNT NBR ISO 19650-2 states that, after acceptance of the completed project information model, containers should be archived considering what will be needed as part of the AIM, future access, reuse, and retention.
This makes closeout a governance issue, not merely a backup task.
An As-Built without approval history, supplier documents not associated with the asset, models without a valid revision, or records scattered across email reduce the quality of the transition.
This creates a direct bridge between the CDE, Engineering As-Built, and document management throughout the lifecycle.
CDE and ENGiOS: governance beyond the project
The CDE is particularly important during the information production and delivery flow of a project. But engineering organizations face broader challenges: contracts, technical documents, revisions, evidence, acceptance, As-Built, assets, project history, and institutional knowledge.
For this reason, the CDE can be understood as one layer of a broader digital technical-governance architecture.
The Common Data Environment and BIM Information Management solution specifically structures requirements, processes, responsibilities, and technology for the CDE. ENGiOS™, in turn, broadens the discussion to technical management, documentation, and engineering governance.
The connection should not be based on a generic software promise. The criterion remains the same: each technology layer must meet the requirements and processes that the organization actually intends to govern.
How to implement, audit, and avoid the most common CDE errors
Implementing a CDE does not begin by creating folders. It begins by defining the process that those folders, metadata, permissions, and workflows must support.
The most defensible sequence is:
need → requirements → roles → information standard → containers → metadata → states → transitions → permissions → technology → testing → mobilization → production → audit.
This order reduces the risk of adapting engineering to the limitations of a tool selected too early.
1. Define the purpose of the environment
Before configuring any platform, determine what the CDE must solve.
The objective may include multidisciplinary coordination, document delivery, model management, technical approval, revision control, contractor handover, transition to operations, or a combination of these uses.
An environment focused only on design coordination will have different requirements from a CDE intended for a capital program with dozens of contracts and transition to asset management.
The question is not “which software are we going to use?”. The initial question is:
which decisions and deliverables need to be supported by information?
2. Define responsibilities and authority
Every workflow needs clear roles.
Who administers the CDE?
Who defines standards?
Who creates users?
Who may change metadata?
Who approves information for sharing?
Who authorizes deliverables?
Who accepts on behalf of the client?
Who handles rejections?
Who preserves the archive at closeout?
These functions may be distributed among the client, project manager, designers, contractor, and third parties. The important point is to avoid implicit authority.
3. Structure identification, classification, and metadata before migrating files
Creating thousands of documents before finalizing the taxonomy creates rework.
The team should define the conventions and codes that will be used in the environment. This includes enough fields to distinguish containers and support relevant filters.
The principle is to find balance. Too little metadata creates ambiguity; too much metadata creates poor adoption and inconsistent completion.
A practical question helps:
which filters will be required to locate, review, deliver, and audit information?
If no one uses a given field for decisions, automation, search, or control, it may not need to be mandatory.
4. Model states and transitions
The workflow should be designed before it is automated.
For each transition, define:
- origin state;
- destination state;
- person responsible for the action;
- prerequisite checks;
- mandatory fields;
- resulting condition of use;
- required notification;
- possibility of rejection;
- audit record.
This turns the flow into a verifiable process.
An example:
| Transition | Responsible party | Minimum check | Result |
| production → ready for review | author | fields and file complete | container available to the internal reviewer |
| review → sharing | team lead | compliance + technical suitability | reference available for coordination |
| shared → submission | appointed party | issues addressed and milestone met | deliverable ready for authorization |
| submission → authorized | lead appointed party | MIDP + EIR + acceptance criteria | package authorized for client submission |
| authorized → accepted | appointing party | requirements and acceptance criteria | deliverable formally accepted |
The table is illustrative. The actual workflow must reflect the contract and governance defined for each project.
5. Configure permissions consistent with responsibility
A platform may have a perfect workflow on paper and still fail because users have excessive privileges.
If an author can approve their own document when segregation of duties should exist, the control loses strength. If any participant can delete evidence or alter information that has already been accepted, traceability is compromised.
Permissions need to be tested by scenario, not merely checked against a matrix.
Create test users with different roles and simulate creation, editing, reading, sharing, rejection, authorization, acceptance, supersession, and archiving.
6. Test the CDE before real production
Mobilization is an explicit point in ABNT NBR ISO 19650-2. The lead appointed party should configure and test software, hardware, and IT infrastructure, the project CDE, any distributed environments, exchanges between teams, and delivery to the appointing party.
This means the first critical milestone should not be the first real test of the process.
A pilot can use a small package of documents and models to verify identification conventions, permissions, notifications, review, rejection, transitions, download and viewing, interoperability, auditing, reports, the behavior of superseded revisions, and access to history.
Problems found at this stage cost far less than problems discovered during a contractual delivery.
7. Train the process, not only the interface
Teaching “where to click” is not enough.
Users need to understand why they should not share information under development, what a given state means, when one revision supersedes another, and what consequences follow from authorizing a deliverable.
Without this understanding, the team uses the platform as a sophisticated drive.
Training should include engineering scenarios. For example:
“You are the electrical designer. You completed R04, but the check found missing required properties. What should happen?”
“You are the coordinator. R05 is under development and R04 is shared. Which one may enter the federation?”
“You are the appointing party. The package was authorized by the lead party, but evidence for a requirement is missing. Do you accept or reject it?”
This type of exercise builds operational understanding.
8. Audit the environment’s actual behavior
A CDE can be well configured and poorly used.
An audit should observe not only configuration but the users’ actual behavior.
Useful indicators include containers without valid identification, duplicate revisions, states incompatible with the project phase, deliverables without an owner, rejections without justification, approvals outside the workflow, files sent in parallel by email, excessive permissions, items shared without checking, overdue MIDP deliverables, and information accepted without evidence against criteria.
The audit should also verify whether the team has created a “shadow CDE”: external folders, messaging groups, public links, or parallel spreadsheets that have become the real source of information.
The most common project errors
The table below summarizes signs that the environment exists technically but governance remains weak.
| Symptom | Risk | Process correction |
| files called “final” | ambiguous condition of use | control revision and state through metadata/workflow |
| everyone edits everything | loss of accountability | permissions by role and container |
| new revision replaces the old one with no history | audit becomes impossible | preserve versions and transitions |
| sharing by email | parallel source of truth | require formal exchange through the defined environment |
| approval in informal messages | acceptance without evidence | record the decision in the workflow |
| latest model automatically enters federation | use of unreleased information | filter by the appropriate state |
| optional metadata completed inconsistently | fragile search and automation | controlled codes and validation |
| software selected before the process | workflow adapted to the tool | define functional requirements before selection |
| hundreds of mandatory fields | low adoption and fictitious data | apply proportionality and LOIN |
| closeout treated as backup | loss of context for operations | archive with revision, state, access, and retention defined |
How to know whether a CDE is mature
A mature CDE allows someone who did not participate in the project’s daily conversations to understand the state of the information.
That is a useful test.
If a new coordinator joins the team and needs to call three people to find out which drawing to use, the environment still depends on tacit memory.
If the coordinator can identify the current revision, condition of use, author, history, criteria, and related documents directly in the system, the information is more institutionalized.
Maturity also appears when a decision can be audited months or years later without manually reconstructing emails.
When structuring a Common Data Environment and BIM Information Management, A3A connects requirements, responsibilities, metadata, workflows, acceptance criteria, mobilization, and environment auditing.
CDE as a procurement and acceptance instrument
The subject has an important commercial implication.
In engineering contracts, defining “delivery via CDE” is not enough. The contract or its associated documents need to establish, as applicable, container structure, identification convention, states and purposes, revisions, responsibilities, information requirements, acceptance criteria, milestone dates, formats, access rules, intellectual property, licensing, retention, and final delivery.
This turns the CDE into a measurement and acceptance mechanism.
A delivery stops being “the file was sent” and becomes “the planned set was delivered, at the correct revision, with the appropriate state, required information, and evidence of acceptance.”
This approach is particularly relevant in Owner’s Engineering, project management, EPC/EPCM contracts, detailed design, multidisciplinary construction, and technical handover.
When to hire specialized support to structure the CDE
External support tends to create more value when the project involves multiple contractors, large document volumes, formal BIM requirements, transition to operations, contracts with complex milestones, or a history of revision and approval failures.
In these scenarios, the challenge is not simply configuring a platform. It is translating engineering requirements into an operational process, responsibility matrix, naming convention, metadata, workflow, acceptance criteria, mobilization plan, training, and audit.
A3A structures this layer through the Common Data Environment and BIM Information Management solution, connecting the CDE to information management, coordination, technical documentation, and project governance.
Conclusion
A BIM CDE is not merely a common place to store files. It is information-management infrastructure capable of distinguishing what is under development from what may be shared, authorized, accepted, and preserved.
ABNT NBR ISO 19650-2 provides objective requirements for this infrastructure: unique identification, agreed coding, state, revision, classification, transition between states, user and date records, and controlled access by container. The normative process also connects the environment to quality checking, review, authorization, acceptance, and archiving.
The practical result is an important change in the question being asked. Instead of “where is the file?”, the team asks:
what information is this, who is responsible for it, which revision is current, for what purpose may it be used, who authorized its state, and what evidence demonstrates that the requirement was met?
That is the difference between storage and governance.
Technology remains essential, but it is not sufficient. A mature CDE requires clear requirements, defined roles, consistent metadata, states with operational meaning, coherent permissions, mobilization testing, training, and continuous auditing.
When these layers work together, the environment reduces ambiguity, improves coordination, strengthens contractual traceability, and creates a more reliable foundation for design, construction, handover, As-Built, and operations.
For this reason, the most important decision in a CDE implementation is not to choose the platform first. It is to define which information flow must be governed and what evidence will make that flow trustworthy.
Technical references
[1] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 19650-1:2018 — Organization and digitization of information about buildings and civil engineering works, including building information modelling (BIM) — Information management using building information modelling — Part 1: Concepts and principles. Geneva: ISO, 2018.
[2] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 19650-2:2018 — Organization and digitization of information about buildings and civil engineering works, including building information modelling (BIM) — Information management using building information modelling — Part 2: Delivery phase of the assets. Geneva: ISO, 2018.
Frequently asked questions
A BIM CDE is the Common Data Environment used to control the production, sharing, review, authorization, acceptance, and preservation of project information. It is not merely storage: it must support states, revisions, identification, classification, access, and traceability.
CDE means Common Data Environment. In the context of the ISO 19650 series, it is an essential part of the information-management infrastructure.
No. Commercial platforms may implement CDE workflows and functionality, but a CDE is an information-management concept and process. The tool should be selected and configured according to project requirements.
A shared folder centralizes files. A CDE must also control identification, revision, state, classification, permissions, transitions, history, and the condition of use of information. Centralization without these controls does not guarantee governance.
ABNT NBR ISO 19650-2 establishes, among other points, a unique container identifier, agreed coding, state, revision, classification, transitions between states, user and date records, and controlled access at the container level.
Revision records the evolution of the container. State represents its condition within the process and influences the purpose for which the information may be used. A newer revision may still be under development while the previous revision remains valid for coordination.
ABNT NBR ISO 19650-2 recommends that the project CDE be operational before the invitation to tender, allowing information to be shared with prospective organizations in a controlled manner. During mobilization, the environment and exchanges should be configured and tested.
The BEP organizes the team’s information-management strategy. The TIDP and MIDP plan which containers will be produced and when. The CDE operationally supports the production, sharing, review, authorization, delivery, and acceptance of that information.
Yes. ABNT NBR ISO 19650-2 provides for the possibility of a distributed delivery-team CDE connected to the project CDE. The critical point is to control boundaries, responsibilities, states, and exchanges between environments.
A sign of maturity is being able to identify, without relying on memory or parallel conversations, the current revision, its state, author, purpose, history, approval, and acceptance criterion. The environment should also prevent parallel sources of information outside the official workflow.
Complementary technical materials
Solutions
- Common Data Environment and BIM Information Management
- Requirements, Evidence, and Acceptance Criteria Management
- Electronic Technical Document Management and Revision Control
- ENGiOS™
Services
- Design Coordination and Integration
- Detailed Engineering Design
- Project Management / Owner’s Engineering
Technical guides
- Complete Guide to BIM and Design Coordination
- Complete Guide to Design Coordination
- Complete Guide to Project Management
Whitepapers
Technical articles
- Information Management in BIM and ISO 19650
- BIM BEP
- IFC Files in BIM
- Open BIM
- BIM LOD
- Engineering Design Coordination
eBook
