Across the UK, pre‑construction teams are under fresh scrutiny to prove—before works start—that designs, products and controls stack up. The Building Safety Regulator is consistently asking for clear, consistent digital evidence. Not glossy PDFs, but structured information that shows who decided what, when, and on what basis. Getting that right is less about buying yet another platform and more about tightening the workflows that feed your common data environment, so evidence stands up without a week of midnight scrambles.
TL;DR
/>
– Treat Gateway 2 evidence as structured data plus documents: provenance, completeness and change control matter as much as content.
– Build a model-to-document thread with named responsibilities, digital sign‑offs and tamper‑evident audit trails.
– Use controlled workflows: automatic metadata, status rules and substitution gates that force product and competence proof before approval.
– Present one, coherent pack: a navigable index, model snapshots that match drawings, and a clean change log.
– Prepare now for “product passports” and machine‑readable certificates; today’s naming standards and templates make tomorrow’s compliance easier.
What ‘digital evidence’ actually means at Gateway 2
/> “Digital evidence” isn’t a file dump. It’s a verifiable chain of information showing that the design is coordinated, risks are identified and managed, products are specified with performance intent, and people are competent to deliver. The best teams present this in a common data environment (CDE) that applies consistent naming, versioning and status codes, so an auditor can trace a decision from the model to the drawing to the specification and the approval.
At a practical level, that means three layers:
– Structured data: model properties, data drops, registers and schedules that can be searched and cross‑checked.
– Controlled documents: drawings, specifications, strategies and method statements with correct metadata and status.
– Provenance and permissions: time‑stamped approvals, responsibilities and a visible change history.
You don’t need to solve everything with BIM automation, but the model must echo what’s on the drawings and in the specification. Regulators tend to be reassured when product performance intent is explicit (not just brand names), when competence is evidenced through CVs, training records or third‑party certifications, and when change control is more than a spreadsheet tucked in someone’s inbox.
How the workflow lands on real UK projects
/> Pre‑con teams should build the Gateway 2 pack as part of BAU, not as an end‑of‑tender sprint. A design responsibility matrix sets who owns which element. A document controller enforces naming and status rules. The digital manager aligns model properties to the schedules you’ll submit. Subcontractor proposals move through a controlled submittal workflow that requires product data (and any certification evidence) before acceptance. Each approval captures who signed, when, and under what revision, and the CDE protects that record.
Models are validated against employer’s information requirements and fire/life safety strategies using rule‑based checks where available. Where automation isn’t feasible, teams run documented manual checks and store the results in the same environment. Product substitutions trigger a defined gate: update the spec, show equivalence against the performance intent, adjust risk assessments, and record the decision with attachments. This is where many packs fall down—substitutions happen informally and the trail disappears into emails.
H3: Scenario — mixed‑use residential under podium pressure
A main contractor in Manchester is gearing up to start a mixed‑use residential block above a podium car park. The programme is tight because utility diversions have slipped, and the client wants steelwork off the critical path. The façade subcontractor proposes a different insulation to hit a lead‑time window, but the fire strategy and cavity barriers are tightly coordinated. The design manager routes the change through the CDE: the substitution form, performance datasheets, and the updated model views land in a tracked workflow. The building control liaison picks up the change in a weekly review, with a clear comparison to the original specification and a risk note tied to the fire stopping details. The approval is digitally signed; the drawing and model revisions are frozen with “Accepted for Use” status. When the regulator asks how the decision was made, the team opens a single link that shows the full trail—no frantic email searches, no conflicting files.
Pitfalls and fixes when building your pack
/> The biggest risk is inconsistency. If the model says one cavity barrier and the drawing shows another, the pack reads as unreliable. Fix this by agreeing a single source of truth for each data item and using controlled model snapshots to lock visuals to each document revision.
Another frequent gap is competence evidence. A regulator isn’t looking for marketing brochures; they want to see role‑specific competence and responsibility lines. Create a simple competence matrix linked to people, packages and tasks, and store certifications in the same CDE folder structure as the package they relate to.
Product data often arrives late and messy. Set templates for product submissions with minimum fields: performance intent, standards met, installation guidance, maintenance needs and traceability. If a supplier can’t meet the template, it’s a red flag to surface early.
Email approvals sink many teams. If sign‑offs aren’t captured in the CDE with the right revision and status, your evidence looks flaky. Make it easier to do the right thing: push approvals through the platform, enable digital signatures, and train leads to avoid side‑channel green lights.
H3: Common mistakes
– Treating the CDE as a file server. Without enforced metadata and status codes, you lose traceability and confidence.
– Relying on brand names instead of performance intent. When substitutions appear, you can’t show like‑for‑like justification.
– Letting models drift from drawings. If views don’t align with issued drawings, auditors will question your overall control.
– Leaving competence evidence to HR folders. If it’s not tied to packages and approvals, it won’t be found when queried.
H3: Checklist — a Gateway 2 evidence set that tends to pass
– One navigable index (register) linking the model view, key drawings, specifications, and strategy documents for each system.
– Change log that ties every design/product change to a reason, a risk note, and an approval with date and name.
– Package‑level product templates completed by the supply chain, including performance criteria and supporting documentation.
– Competence matrix showing role, responsibility, and evidence of training or third‑party credentials for critical tasks.
– Model validation reports and/or checklists stored with the related model version and marked with “Approved” status.
– Document control rules applied: naming, versioning, status codes and digital signatures with an audit trail.
– A simple “how to read this pack” note for the regulator that explains structure, status codes and where to find change records.
What to watch next for Gateway 2 tech
/> Market momentum is building around machine‑readable product data and certificates—think product passports tied to QR codes on submittals, ready to flow into install and handover phases. Expect CDEs to lean harder on automation: metadata extraction from PDFs, rule‑based status transitions, and API links to product registries and competence databases, reducing manual keying and error.
The direction is clear: fewer attachments, more structured, provable information. Before your next project meeting, ask: is our change control gate watertight, can we prove competence against critical tasks, and does our model actually match the drawings we’ll submit?
FAQ
/>
Is a BIM model enough to satisfy Gateway 2 evidence expectations?
No. A model helps, but regulators usually want the model plus coordinated drawings, specifications, strategies and a visible approval trail. The pack needs to show performance intent, risks and responsibilities, not just geometry.
# Do we need a specific CDE brand to be compliant?
/> There’s no single mandated platform. What matters is controlled access, enforced metadata, versioning, status codes and an audit trail that can be presented clearly. Many teams achieve this with familiar UK‑used CDEs configured to match their information requirements.
# How should subcontractors feed into the evidence set?
/> Set clear submittal templates and deadlines at procurement, and make the CDE submission route the only accepted path. Tie each subcontractor’s evidence to the relevant package folder with status gates; avoid approvals by email that sit outside the audit trail.
# What counts as acceptable competence evidence?
/> Aim for role‑specific and task‑relevant proof: CVs, training records, third‑party certificates, and internal authorisations mapped to the responsibility matrix. Store it next to the package it relates to and link it to approvals, so it’s easy to find during review.
# How do we handle late product substitutions without derailing the pack?
/> Use a formal substitution workflow in the CDE: capture the reason, show equivalence to performance intent, update the risk register and the spec, and route it for digital approval. Freeze revised drawings and model views to the same status so the change is coherent and defensible.
