Why Gateway 3 applications stall: the four failure modes

Why do Gateway 3 applications stall?

Because the completion certificate is an evidence test, and the evidence is assembled, or not, during construction. The Building Safety Regulator has been unusually clear about why applications stall, naming four recurring failure modes. None of them is a surprise, and none of them is really a Gateway 3 problem. They are construction-phase problems that only become visible when you try to certify the building. That is the single most useful thing to understand: by the time an application stalls for one of these reasons, the cheap moment to fix it has already passed.

The developers who have moved through Gateway 3 fastest are the ones who maintained accurate information during the build and kept the regulator informed, so completion was a collation exercise rather than an archaeology project. Everything below is how to be one of them.

Failure mode one: gaps in fire and structural safety documentation

The first reason applications stall is missing or incomplete documentation on the two things the regime cares about most: fire safety and structural safety. The regulator cannot certify what it cannot see evidenced. A fire strategy that relies on a detail with no supporting test data, a structural element with no verification record, a performance claim with no product evidence behind it, each is a hole the determination falls into.

The fix is to treat the safety documentation as a live deliverable from Gateway 2, mapped to the fire and structural strategy, with a named owner for each piece of evidence. Know, at any point in the build, which safety-critical claims are evidenced and which are not, and close the gaps as the work happens rather than discovering them when you assemble the application.

Failure mode two: weak change control records

The second reason is change control that does not hold up. Between Gateways 2 and 3, every deviation from the approved design is supposed to run through formal change control: major changes approved by the BSR before the affected work proceeds, notifiable changes logged and proceeding unless the regulator objects within 14 days, all of it captured in the change control log. When that discipline is weak, the completion application arrives with an approved design, a different building, and no coherent account of how one became the other.

The fix is discipline in the moment. Log every change with its date, its reason, its classification and its authorisation, as it is decided. A change control log that is maintained in real time is a short, defensible document. One reconstructed at handover is a liability, because the gaps in it are exactly the questions the regulator will ask.

Failure mode three: as-built discrepancies

The third reason, and the one the final inspection is built to catch, is a mismatch between the as-built drawings and the systems or materials actually installed. This is where the paper building and the physical building diverge. It happens quietly: a substitution here, an install detail there, a product swapped for an equivalent that was never quite equivalent, none of it captured. Then the inspector stands in the building, compares it to the record, and finds they do not agree.

The fix is to capture what is actually installed as it is installed, with contemporaneous records made by the people doing the work. Photographic records, inspection and test plans completed at the time, product and batch information taken as materials arrive: these are the raw material of a truthful as-built record. Then reconcile the as-built against the design before you apply, so any remaining discrepancy is one you have found and explained, not one the regulator finds for you.

Failure mode four: safety-system integration and commissioning gaps

The fourth reason is safety systems that have not been shown to work together. Modern higher-risk buildings depend on integrated safety systems, detection, alarm, suppression, smoke control, and the regulator wants evidence not just that each was installed but that they were commissioned and that they function as a coordinated whole. Commissioning evidence that is missing, partial or late is a common reason the determination cannot complete.

The fix is to plan commissioning as a sequenced, evidenced activity with enough programme float, and to capture the results as formal records. Integration testing in particular needs to be scheduled early enough that a failure leaves time to fix and retest, rather than being discovered in the final run-up to a fixed occupation date.

The common thread: evidence discipline from Gateway 2

Read the four failure modes together and the pattern is obvious. Every one is an evidence problem, and every one is cheaper to prevent during the build than to cure at handover. The projects that stall are the ones that treated the golden thread as a filing job for the end. The projects that fly are the ones where records were captured contemporaneously, changes were controlled as they happened, the as-built was kept honest, and commissioning was evidenced as it was done.

Start the evidence discipline at Gateway 2, not three months before handover. Decide who captures what, in what form, with what metadata, and hold that discipline through the whole build. Do that, and Gateway 3 becomes the collation exercise the fast movers describe. Skip it, and you join the queue, doing archaeology on your own project while a fixed occupation date bears down on you.