Gateway 2 and Gateway 3 are forcing higher‑risk building teams to treat information like controlled product, not “project admin”. By 2026, the expectation is that your CDE won’t just store models and RFIs; it will demonstrate disciplined change control, capture occurrence reporting in a usable way, and assemble safety case evidence that can withstand scrutiny long after practical completion. If your CDE is still “a file dump with workflows”, the friction will show up first in programme, then in commercial control, and finally in compliance.
Plain-English: what a CDE must prove at Gateway 2/3
A Common Data Environment (CDE) is no longer judged on whether people can find drawings. For higher‑risk buildings, it needs to prove that the right people made the right decisions, using the right information, at the right time—and that those decisions were properly controlled.
In practice, that means three overlapping evidence threads:
– Change control: a traceable chain from design intent → proposed change → impact assessment → authorisation → implementation → verification.
– Occurrence reporting: a controlled record of safety occurrences and near misses, linked to location, elements, and responsible parties, with closure evidence.
– Safety case evidence: a structured bundle of information that supports the building’s safety claims (design, construction and commissioning evidence), not a last-minute PDF scramble.
A “Gateway-ready” CDE makes these threads searchable, reportable and auditable without heroic manual effort.
How it actually plays out under site pressure (UK scenario)
On a live job in Birmingham—a 16-storey residential scheme with a ground-floor podium and a complex fire strategy—the cladding subcontractor raises a technical query about a cavity barrier interface at a movement joint. The architect issues a revised detail, but the revision arrives just as the façade sequence is about to start and the hoist is booked solid for the week. The package manager agrees a workaround in a Teams call, and the façade foreman instructs installers on the morning briefing. Two days later, an internal inspection flags that the installed arrangement doesn’t match either the old or new detail, and a near miss is logged after a firestop is found partially obstructed behind an EPDM strip. Commercial then disputes whether it’s a variation, a defect, or a design coordination failure. When the project team comes to assemble evidence for Gateway, they can’t clearly show who authorised the change, what was assessed, which flats are affected, and what was checked post-installation.
This is exactly where CDE configuration either protects the project or exposes it.
One configuration principle: treat “change” as an object, not an email
Most teams track change through a mixture of RFIs, design revisions, site instructions, TQs, EWN/CEs, and NCRs. That’s workable until you need to demonstrate control and intent. For Gateway 2/3, the safest approach is to configure your CDE so that a change has its own record—with mandatory fields and links—regardless of how it starts.
At minimum, a change record should be able to connect:
– the triggering event (RFI/TQ, site condition, supplier substitution, programme constraint)
– the affected asset/location (building, level, zone, flat, element)
– the applicable golden thread documents (fire strategy extracts, relevant drawings, specifications, product data)
– the risk impact (especially fire and structural implications)
– the authorisation route (who can approve what, and under which thresholds)
– the verification evidence (inspection/test, photo, sign-off, as-built update)
When configured well, the CDE becomes a “single pane” for what changed, why it changed, and how you proved it’s safe and compliant.
Occurrence reporting: connect the dot between the incident and the build
Occurrence reporting often collapses into two unhelpful extremes: either a standalone H&S system that doesn’t talk to build information, or a project log that’s too informal to be relied upon later. Gateway expectations push you towards a middle ground: occurrence reporting that is controlled, categorised and linked.
Practical CDE setup considerations include:
– A defined taxonomy for occurrences that makes sense on site (fire stopping, compartmentation, structural penetrations, temporary works, MEP pressure testing, etc.).
– Location and element fields that mirror how supervisors actually navigate the building (gridlines, core, riser, flat numbers), not just model object IDs.
– Attachment rules so that evidence is consistent (photos with orientation, annotated mark-ups, inspection sheets, manufacturer guidance).
– Status governance: what “open”, “mitigated”, and “closed” mean, and who can move the status.
– A clean route to convert an occurrence into a change record, NCR, or design query—without retyping everything.
The aim is not “more reporting”. It’s fewer blind spots and faster closure, with an audit trail that doesn’t break.
Safety case evidence: stop bundling documents and start curating claims
Teams often default to gathering documents because that’s what CDEs are good at. Safety case thinking is different: you are curating evidence to support safety claims. Your CDE should reflect that by allowing you to group evidence by safety outcomes, not by discipline folders.
For example, a fire safety evidence set might pull together:
– approved strategy and assumptions
– design information (details, schedules, specifications)
– product selection and substitutions with acceptance rationale
– installation checks and photographic evidence
– test certificates and commissioning results
– deviations, occurrences and how they were resolved
– as-built records showing what was actually installed
The CDE can support this if you configure “evidence packs” or structured collections that draw from controlled sources, rather than exporting whatever happens to be in the latest folder.
What “good” looks like in a Gateway-ready CDE (checklist)
– A dedicated change record type with mandatory fields for safety impact, affected locations, and authoriser role.
– Linked workflows so RFIs/TQs, site instructions, NCRs and occurrences can reference the same change without duplication.
– Permissioning aligned to dutyholder roles, with clear delegation rules for approvals and closures.
– Controlled templates for inspections, sign-offs and photographic evidence so that site teams submit consistent records.
– Audit-friendly versioning that distinguishes “superseded”, “for construction”, and “as built” without ambiguity.
– Search and reporting that can answer “show me all changes affecting compartment lines on Levels 10–12” in minutes, not days.
Common mistakes
# Making the CDE hierarchy mimic the org chart
/> Folders built around “Architect/MEP/Structures” look tidy but hide cross-discipline safety interfaces; the evidence you need later sits in silos and won’t reconcile cleanly.
# Letting approvals happen off-system then backfilling
/> If authorisation sits in email threads or chat messages, you end up attaching screenshots as “evidence”, which undermines confidence and invites disputes.
# Treating occurrences as H&S-only events
/> Where occurrence records don’t link to elements and changes, you lose the ability to prove what was affected, what was fixed, and whether the fix made it into the as-built record.
# Allowing substitutions to bypass change control
/> Supplier-led swaps on availability or lead time often look “minor” until you map them to fire strategy assumptions; if they aren’t forced through the same change object, you’ll miss critical implications.
Interfaces that matter: subcontractors, QA and commercial
CDE configuration isn’t just a digital exercise; it’s an interface management problem.
– Specialist subcontractors need simple capture routes (mobile-friendly forms, quick attachments, minimal typing) otherwise information will stay in notebooks and WhatsApp.
– QA teams need structured inspection evidence that’s consistent across blocks and plots, not free-text comments that can’t be trended.
– Commercial needs the change record to support entitlement and valuation without confusing compliance with compensation events. The same change can be “safety critical” and still require a contractual route; mixing them creates arguments late in the day.
– Design teams need clarity on what constitutes a “controlled revision” versus an informative sketch, because those two behave very differently in an audit.
This is why “CDE owner” can’t sit only with BIM or document control. It must be aligned with package management and dutyholder accountability.
Your next week’s controls (five actions)
# One-week configuration sprint for Gateway workflows
/>
1. Map three recent real changes (one design-led, one site-led, one supply-led) into a single end-to-end change record and note where your CDE currently loses the trail.
2. Build a minimum mandatory field set for change and occurrence records that site staff can complete in under three minutes on a phone.
3. Convert your top five safety-critical interfaces (façade/fire stopping, risers, structural penetrations, plantroom, balconies) into tagged location/element categories inside the CDE.
4. Set an approval matrix by role (not by named person) and apply it to workflow permissions so that “who can close what” is enforced by the system.
5. Assemble one mock safety case evidence pack for a single floor or zone, using only controlled records, and identify what is still living outside the CDE.
By 2026, the differentiator won’t be who has the most information, but who can evidence decisions and outcomes without gaps. The projects that run smoothly through Gateway 2/3 will be the ones where change control, occurrence reporting and safety case evidence are designed into delivery—rather than reconstructed afterwards under pressure.
