A design review can come back clean and still leave your firm carrying the risk. The report speaks for the parts of the scheme it opened, and it says nothing at all about the rest.
The error nobody caught until opening week.
A major UK hospital was days away from opening, with patients, staff and equipment about to move in, when testing of the ventilation found a serious problem. Some critical care rooms had been designed for 4 air changes an hour, where 10 were recommended. The opening was postponed, the hospital did not fully open for more than 20 months, and the financial cost of the delay was reported to be £16.8m, according to the public inquiry’s interim report.
The cause was not exotic. It was a transcription error in the environmental matrix, the spreadsheet used to capture environmental data for every room in the hospital. The inquiry found that, had that error not been made, the problems with the ventilation system were unlikely to have arisen.
What makes the case uncomfortable reading is not the mistake. Mistakes happen on every project. It is that the error travelled through design, construction and completion before anyone saw it. Responding to the findings, the client accepted that opportunities to detect and put right errors had been missed by every party over the course of the project, as coverage of the inquiry’s findings reported. We worked through the arithmetic of how easily an error like this hides in a large matrix in an earlier piece on design errors.
Why a findings list only speaks for what it opened.
The same report found that the client’s requirements for the ventilation system had not been set out with enough clarity, and the spreadsheet came to be treated as the brief itself. It also found a lack of clarity at board level about what assurance could be taken from the client’s technical advisers. Any review working from that spreadsheet could only compare the design with what it was given, and what it was given was wrong.
That is the built-in limit of every design review. A findings list reports on what the reviewer opened. It cannot report on what they never opened, and an unexamined requirement reads exactly like a satisfied one when the report comes back clean.
A clean report can mislead in two ways. Sometimes a requirement was never captured, so nothing was ever reviewed against it. Sometimes the requirement was known and the package was reviewed, but never against that requirement. Either way the gap is invisible at sign-off, and it only shows itself later, when someone asks what was actually reviewed.
The three findings at the top are the easy part. The two rows underneath are the ones that matter, and most review reports have no way of showing them at all.
What is review coverage, and how do you measure it?
Definition
Review coverage is the share of a scheme’s requirements that have actually been reviewed. It is measured one requirement at a time, so the gaps are named rather than assumed away.
Coverage turns the silence of a findings list into something you can see. Every requirement on the scheme carries one of four statuses.
- Met. Reviewed, and the design satisfies it, with the evidence linked.
- Not met. Reviewed, and the design falls short. This is a finding, and it needs an owner.
- Not yet reviewable. The information needed to judge it has not arrived, so the gap is known and waiting.
- Never reviewed. Nothing has been looked at against it, on any revision. This is the blind spot.
A traditional design review produces the first two. The last two are what it leaves out, and the last one is where the exposure hides. An honest “not yet” is information a team can plan around, and it is far safer than a false all-clear. A clean report that skipped a requirement without saying so is not.
In this example, about two thirds of the 3,400 requirements have been reviewed, and 696 have had nothing reviewed against them at all. That is not a failure. It is a position, and a position you can see is one you can improve.
Start with a register, not a report.
Coverage can only be measured against something, so the starting point is a register of every requirement the scheme has to satisfy. That means more than the Approved Documents. It means everything that defines quality on the job.
- Statutory duties and the Approved Documents
- The client brief and the Employer’s Requirements
- Company standards and technical guidance
- Consultant requirements and information requirements
- Commitments made in meeting minutes and correspondence
The last item is the one most registers miss. A promise made in a design team meeting is still a requirement, even if nobody ever typed it into a spreadsheet.
Once the register exists, requirements with nothing reviewed against them stop being something you discover afterwards and become an output you can act on. They come out as a ranked list, ordered by what rests on each one, so the critical gap is not buried beneath 40 trivial ones.
The register solves a second problem too. Compliance review, coordination review and submittal review each produce their own findings, and held separately, none of them tells you where the scheme stands. Risk that sits between two review types belongs to nobody. Pulling every review into one position, against one register, is how that risk becomes visible. It is also how we approach risk and review coverage at Tektome.
What insurers and Principal Designers now expect.
The case for coverage is not only about quality. It is increasingly about what a firm can prove.
On professional indemnity insurance for architects, a 2025 review of the PI market expects insurers to place increasing emphasis on how firms show awareness of the Building Safety Act and put robust risk management in place. It adds that a proactive approach to compliance and documentation will shape how insurers assess a firm’s risk. A findings list is thin evidence of that. A coverage record is far stronger.
For the Principal Designer, the duty is explicit. Under building regulations in England, the Principal Designer must plan, manage, monitor and coordinate the design work, and take reasonable steps to make sure all designers comply with their duties under building regulations, as the regulator’s guidance on dutyholders sets out. Monitoring the design is hard to evidence without a record of what has, and has not, been reviewed.
The record also has to last. The limitation period under the Defective Premises Act is now 30 years for homes completed before 28 June 2022, and 15 years for homes completed since. In 2025, a Supreme Court judgment confirmed that the longer period also reaches related negligence and contribution claims, as the RICS summary of the ruling explains, and its author’s view is that consultants in design roles are now more exposed to claims. The question of what you reviewed can arrive long after the project team has moved on.
What holds up in that conversation is a record in which every requirement is linked to its source, and every review, decision and sign-off is logged with who made it and when, including what was left to human judgement. That is the difference between a record and a recollection.
Key takeaway
A clean findings list tells you what went wrong in the parts you opened. A coverage record tells you, and anyone who asks years later, what was reviewed, what was not, and why.
Review coverage in practice
A 30-minute session on a scheme we have prepared, showing coverage across every requirement, the blind spots ranked by what rests on them and the record behind each one. Nothing to set up, no project data needed.
Book a demo