Last week we submitted a staged Gateway 2 application for a new build residential scheme in Barnet, London. The package was validated by the BSR in a single day. For a scheme of this scale and complexity, that is an exceptional outcome — and one that did not happen by accident.
Eight floors. 112 residential apartments. Four commercial units at ground level. Thirty-one underground parking spaces. A mixed-use scheme of this type generates a compliance picture of considerable depth: structural strategy, fire engineering, acoustic separation, ventilation, drainage, accessibility, overheating risk, energy performance and more — all of which must be addressed to the BSR's standard and evidenced with coherent, internally consistent documentation.
Validation in 24 hours is rare at any scale. At this scale, it speaks to something more than good document management. It speaks to how compliance was approached from the outset.
Why a Staged Application
The Building (Higher-Risk Buildings Procedures) (England) Regulations 2023 permit applicants to submit a Gateway 2 application in stages, where the complexity or phasing of the project makes a single submission impractical or premature. A staged application allows the BSR to review and approve discrete tranches of information, providing the client and design team with greater certainty at each phase without holding back the entire programme.
For a scheme of this nature — a mixed-use development with residential, commercial and basement elements each carrying distinct compliance considerations — a staged approach was the appropriate structural choice. It allowed the submission to be sequenced in a way that reflected the design's own logic, rather than forcing all documentation into a single undifferentiated package.
Choosing the right application structure is itself a compliance decision. Getting it wrong adds delay. Getting it right, as here, creates a cleaner path through BSR assessment.
Embedded in the Design. From Day One.
The design took three months. Throughout that period, compliance was not running alongside it as a separate workstream. It was embedded within it, woven into every decision as the design developed.
We joined the multi-disciplinary team and the appointed Principal Designer from the outset. Not at the end, assembling documents from outputs that had already been finalised. From the beginning, present at every design review, every coordination meeting, every specification update. Each compliance position was built as the design evolved, not retrofitted once it was fixed.
The distinction matters enormously. A compliance team brought in at Stage 4 to produce submission documents is working with a design that is already settled. If there are compliance gaps — and there almost always are — the options are to patch the documentation, revise the design under time pressure, or accept the risk of a requisition. None of those are good options.
A compliance team present from the beginning shapes the design as it happens. Issues are resolved before they are embedded. By the time the submission is assembled, the compliance work is already done. The documents are the evidence of decisions already made, not a last-minute case for decisions that were never properly considered.
Compliance is not a submission activity. It is a design activity. The submission is simply the evidence of work that should already have been done.
A Pool of Experts Across Every Discipline
What made the difference on this scheme was the depth and breadth of the compliance resource deployed. BSR Compliance Service operates a pool of building compliance specialists across all relevant disciplines: structural, fire, mechanical and electrical engineering, acoustics, access, energy and environmental performance, drainage and waterproofing.
Each specialist inputted into the design at the point where their discipline intersected with the compliance requirements. Not in sequence, not in silos, but in parallel and in communication with one another and with the design team. The result was a document set that was internally consistent from first draft to final submission. There were no contradictions between the fire strategy and the architectural drawings. No discrepancies between the structural compliance statement and the specification. No gaps in the duty holder competence evidence.
The BSR's assessors — whether internal or through the external batching model now in operation — are looking for exactly those inconsistencies. A package that presents a unified, coherent compliance case across all Approved Documents does not require the assessor to raise requisitions to resolve contradictions. The path to validation is clear.
Knowing What the BSR Expects
Technical rigour is necessary but not sufficient. A submission can be technically sound and still draw requisitions if it is not structured in the way the BSR expects to receive it.
BSR processes, assessment priorities and documentation conventions are not always transparent from the outside. They are learned through direct engagement with the regime: through submitted applications, through requisition responses, through pre-application meetings, through the experience of knowing what the BSR's assessors are looking for and how they work through a package.
That familiarity shapes how we structure every submission. The sequencing of compliance statements, the referencing conventions used to cross-link documents, the level of evidence provided for duty holder competence, the way the Construction Control Plan and MOR Plan are presented — all of these reflect an understanding of BSR expectations built through repeated engagement with the regime, not theoretical knowledge of the regulations alone.
On the Barnet scheme, that knowledge meant the package arrived at the BSR in a form they could move through quickly. Validation in one working day is the outcome, but the underlying cause is the precision with which the submission was prepared.
What This Means for Other Teams
The Barnet scheme is not an outlier. It is a demonstration of what is consistently achievable when compliance is treated as an integral part of the design process rather than a regulatory hurdle to be cleared at the end of it.
The teams that struggle at Gateway 2 are not, in most cases, working on technically inferior designs. They are working on designs where compliance was not properly embedded, where the document set was assembled rather than built, and where the submission reflects the gaps that inevitably open up when compliance is left too late.
The BSR's faster processing times under the batching model mean those gaps are now surfaced more quickly. Requisitions arrive sooner. Programmes stall faster. The case for getting compliance right from the beginning has never been stronger.
If your project is approaching Gateway 2, or if you are earlier in the design process and want to understand what a properly embedded compliance approach looks like in practice, we are ready to talk.