Gateway 3 Evidence: What a CDE Can and Cannot Show a Regulator

Gateway 3 Evidence: What a CDE Can and Cannot Show a Regulator

Most higher-risk building projects already run on a common data environment. The documents are there, the folders are tidy, and the permissions are set. Then someone from the Building Safety Regulator asks a question shaped like this: show me the fire-stopping records for this floor, who signed them off, and what the drawing said at the time. That is when the difference between storing documents and holding evidence stops being academic.

This is not a guide to the regime itself. If you need the duty holders, the gateways and the golden thread explained, start with our Building Safety Act implementation guide. This is narrower: what a records system can actually answer under questioning, and what it cannot, whichever product you use.

The question a folder cannot answer

A CDE answers where is the file. An audit asks what was true at the time, and who decided it. Those are different questions, and the gap between them is where handover programmes lose weeks.

Three things make the second question hard in a folder-based system. The document you are looking at now may not be the revision that was issued when the work happened. The person who approved it is recorded in an email rather than on the record. And the photograph proving installation sits in a different system entirely, named IMG_4471.jpg.

None of that is a criticism of any particular product. It is a property of storing files rather than recording decisions.

What a records system should be able to prove

Rather than list features, it is more useful to list the questions a regulator or an opposing expert can reasonably ask, and be honest about which ones a system answers by construction rather than by someone remembering.

1. Is this the number I think it is?

Document numbering that is merely a convention drifts. Two teams create FS-101 and fs-101 and the register now has two truths. In XO Docs, document numbers are unique per project and document type, enforced by the database and case-insensitive, so the collision is refused rather than discovered later. Numbering is configured at company level and can be overridden per project, because real organisations have both a standard and exceptions to it.

2. Who moved this, and when?

Every revision status change records who acted, when, and the status before and after. Not a modified-date on a file, which tells you almost nothing under questioning, but the transition itself as a recorded event.

3. What did the recipient actually receive?

A transmittal records the document number, title, revision and version as they were at the moment it was issued. If the document moves on afterwards, the transmittal still says what was sent. That is the difference between a link and a record.

4. Could this have been issued out of process?

Submitting for review and issuing can be blocked by your own governance rules, and when a block fires it names the rule and the reason. Workflow launches are recorded whether or not they started, with a reason code, so a process that did not run leaves a trace instead of silence.

5. Was any of this generated rather than decided?

Machine-suggested document metadata is never applied without a person confirming it, and each suggestion run is retained with the provider, the provider version, the input fingerprint and a confidence basis. In a dispute, being able to say which fields a human confirmed is worth more than the suggestion itself.

6. Can the site evidence be checked?

Evidence pack versions are sealed with a SHA-256 manifest of their contents and protected against modification at the database level. A sealed version cannot be altered or deleted, and the write is rejected rather than logged. Alongside that, templates are versioned and publishing one requires two people, and issues carry an append-only history of what happened to them.

7. Was the person qualified, and did you check before the work?

Eligibility is evaluated before an assessment and blocking results are refused, not warned about. Where someone overrides a warning, the override is recorded. Requirement sets are versioned, so the standard you applied last year is still readable this year.

One detail here matters more than it first appears. Recording a CSCS-style card stores a hash and an encrypted lookup payload, never the card number, and every verification attempt is logged. You can check a card without ever holding the thing that would matter if you were breached.

What we do not claim, and why that is the useful part

Every vendor in this space, including us, is under commercial pressure to describe compliance software as though it produces compliance. It does not. A records system supports the people who carry the duty; it does not carry the duty for them. So here are the claims we decline to make, each one because the code does not support it today.

• Competence is not pinned to a physical location. You will see diagrams elsewhere in this market showing an auditor clicking a wall panel to reveal the installer's certifications. Our competence records carry no spatial reference, and there is no per-person qualification record to surface that way. Relevance is derived from project membership, which is a weaker and more honest thing.
• Issuing a revision does not make it tamper-evident. Issuing changes status and emits durable evidence. It is not, by itself, a hash-verified freeze of the document, and we do not describe it as one.
• Documents are not "Gateway-ready by default". What exists is a bounded snapshot at issue time. Assembling a gateway submission is still work that people do.
• We cannot prove a recipient read a transmittal. A provider delivery receipt evidences delivery, not human attention, and treating the two as the same thing is how disputes start.
• Competency does not block work across the platform by default. Field readiness reads competency and renders it as ready, warn or blocked, and nothing on that path refuses an action. The exception is time capture, where eligibility can be configured to refuse a clock-in and competency is one of the inputs it reads. Unless that is switched on, a competency record shows a state; it does not stop anyone doing anything.
• Nothing here certifies, guarantees or promises compliance. Dutyholders remain responsible for submissions, declarations and legal conclusions.

That list is longer than most competitors would publish. We think it is the more valuable half of the page, because a claim you can check is worth more than a claim that sounds impressive, and every item above is one fewer surprise on the day someone tests it.

Choosing between them

A common data environment remains the right tool for upstream design coordination, model federation and the document exchange between consultants. Nothing above suggests replacing one.

The question worth asking is narrower: when the record is challenged months later, does your system reconstruct what was true at the time, or does it show you the current state of a folder and leave the reconstruction to whoever still works there? If it is the second, the gap is not going to close on its own, and Gateway 3 is a poor place to discover it.

You can see how the evidence side works in XO Docs, XO Field and XO Comp, or read the golden thread overview for how the pieces fit together.