Gateway strategy and submission support.
A Gateway submission is examined as a whole. Evidence that is individually correct can still fail to demonstrate what the submission asserts, because the assertion was never stated and the package was assembled rather than argued. The work that avoids that is done before the submission is made, not after the first request for information.
The position
Where this usually starts
At Gateway 2 the design is developed, the team is large, and the submission is being pulled together from what each discipline has produced. Nobody has read the package as a single argument, and the interfaces between disciplines are where the questions will come from. At Gateway 3 the same problem reappears in a different form: the building was built, changes were made, and the as-built information has to be reconciled with the information that was approved.
We review the submission as a reviewer would read it. What the package is asserting, what it relies on to assert it, where the disciplines disagree, where a change was made and not carried through the evidence, and where the as-built information does not yet align with the approved design. We say what is missing and what would close it, while there is still time to act on it, so that avoidable issues are identified before submission rather than after the first request for information.
Scope of work
What we are instructed to do
At Gateway 2, often written GW2, we set the submission strategy, review the package before it is made, and identify the evidence the assessment process will examine. The package is read as a single argument rather than as a set of discipline outputs: what it asserts, what supports the assertion, and where the disciplines disagree. Conflicts go back to the originating specialist rather than being resolved unilaterally. Alongside that sits the building control strategy: route, sequencing, engagement, and what each stage will require before it is reached.
At Gateway 3, GW3, the question is whether the as-built information, the golden thread and the supporting evidence can demonstrate how the completed building aligns with the design that was approved. That turns on change control, on whether changes made during construction were recorded, justified and carried through the evidence, and on the interfaces where fire, structure, fabric and construction sequence meet. Those interfaces are where a package is most often found to be incomplete.
Submission readiness
Read against what the regulator can refuse on
A building control approval application is not judged on the quality of any single document. It is judged on whether the package, taken together, meets what the regulations require of it.
Regulation 7(1) sets the grounds. The regulator must grant approval unless the application does not meet those requirements, or does not carry enough detail to decide whether the work would comply, or shows work that would contravene the building regulations, or shows change control, information keeping, mandatory occurrence reporting or competence arrangements that would be likely to contravene the requirements governing them. A readiness review reads the package against those four grounds and says which of them it is currently exposed on.
What you get
A schedule: each prescribed document, whether it is there, whether it does what the regulations require of it, what is missing, what would close it and who holds it. Where a document is present but does not support the assertion it exists to support, we say so, because that is the gap that produces the first request for information.
Need a clear position from complex building safety evidence?
Send us the reports, the issue and the decision you need to make. We will tell you whether the evidence supports the position, what remains uncertain and what a proportionate next step looks like.