Ask a Building Regulations Principal Designer how they are running the appointment and the answer is almost always the same. There is a spreadsheet. It has a row for each requirement, a column for the responsible designer, a status column, and a colour scale that runs red to amber to green. Sometimes it has a tab per RIBA stage. Often it is a version of the tracker RIBA publishes, adapted by whoever set it up first and then copied sideways into every project the practice runs.
This is not a failure of professionalism. A statutory role arrived in October 2023 with a duty to plan, manage, monitor and coordinate design work, and with no prescribed format for showing that you did. A spreadsheet costs nothing, opens on any machine, needs no procurement approval, and produces something you can put in front of a client on day one. Of course that is what practices reached for.
RIBA published a set of downloadable templates alongside its Principal Designer Guide, and one of them is a Building Regulations Relevant Requirements Tracker, issued as an Excel file. It is a serious document. It gives a structure for recording the decisions that show a design meets the relevant requirements, and it is framed as something that can support change control and be shown to a building control body.
Those relevant requirements are defined in regulation 11Q(1), the interpretation provision for Part 2A. To the extent relevant to the work in question, they are regulations 4, 6, 7, 8, 22, 23, 25B, 26, 26A, 28, 36, 41(2)(a), 42(2)(a), 43(2)(a), 44A, 44ZA, 44ZC and 44D to 44I, together with Schedule 1.
RIBA is clear that the templates are models to be adapted to the project, its procedures and its processes. That instruction has largely been ignored. What has actually happened is that the file has been copied, forked, rebadged and passed between practices, consultancies and design and build contractors until a recognisable family of trackers exists across the industry, all sharing the same bones and none of them adapted much beyond a logo swap and a few extra columns.
So when people say they use "the RIBA tracker", they usually mean a descendant of it, several generations removed, whose provenance nobody in the room can now describe.
Three things, and they are not small.
It forces the requirement list to be written down. Before the tracker exists, the set of applicable requirements lives in the heads of four different consultants who have never compared notes. Writing it out is the first genuinely useful act of the appointment, and the spreadsheet is what forces it.
It puts a name against each line. Regulation 11M is about coordination, and coordination starts with knowing who owns what. A tracker with an owner column does more work than most people give it credit for.
It is legible to the client. The client has duties too, and a one-page grid is something a client will actually read. Compared with a design team email chain, that is a real gain in transparency.
RIBA's original is also better than the thing it usually gets reduced to, because it was never designed as a colour-coded status board. Each requirement row carries a route to compliance, the design guidance followed, the design strategy or solution adopted, notes and links to evidence, the stage at which the requirement bites, and the date the row was last touched. Somebody thought carefully about what a defensible record looks like. Open your own copy and count how many of those columns are still there, and how many of the survivors have anything written in them. What happens to the file downstream is a different matter.
If you have a tracker and it is current, you are ahead of the practices that have neither.
The problems begin downstream, when the columns that hold the reasoning fall away in copying and what is left stops being a summary of the record and becomes the record.
A tracker starts life with a fixed list of Parts down the left-hand side, inherited from whichever project it was first built for. That list is jurisdictional and it is dated. Part N, glazing safety, was withdrawn in England in April 2013 and folded into Part K, but it still applies in Wales. Part T, toilet accommodation, was inserted for England from 1 October 2024. From 1 July 2026 Wales runs its own dutyholder regime under a new Part 2B of the Building Regulations 2010, with a different higher-risk building test and the local authority rather than the Building Safety Regulator as building control authority.
RIBA's own file records this happening to it. The version control tab notes that version 1 shipped with the relevant requirements current at launch while awaiting Part T detail, and that version 2 added requirement T1. The template had to be reissued to keep up with the statute. A copy taken from a pre-October-2024 project has no T1 row and no version tab to explain the absence. The workbook carries no Part N sheet either, which is correct for England and wrong from the moment the file is used on a Welsh scheme.
That version tab is the kind of thing that does not survive a rebadge, and without it a spreadsheet has no view on whether its own row headings are still correct. Nobody re-derives the list at the start of each job, because re-deriving is the slow part and copying is the fast part. Inherit a tracker and you inherit a set of assumptions about jurisdiction and date that nobody wrote down.
Colour is the most persuasive and least informative thing in the file, and it is the part that always gets filled in. The status ladder runs from not started through design in progress and ready for submission to granted approval, which tracks the passage of a submission rather than the weight of an evidence base, and it sits two columns along from the notes and links to evidence field that carries the actual proof. Green tells you that at some point someone believed a line had moved. It does not tell you what they read, which drawing revision they were looking at, whether the consultant had issued anything at all, or whether the judgement was made by the individual designated under regulation 11G. The columns that would answer those questions exist in the original. They are also the ones that take real work to fill in.
Two rows from a stripped-down descendant, with the route to compliance and evidence columns gone. Nothing left records which document was reviewed, at which revision, by whom, or on what basis the line was closed. Six months on, only the person who typed it can reconstruct any of that, and only from memory and an inbox.
Design changes. Somebody types over the cell. RIBA's sheet gives each row a "row last updated" column, which is a date, and a date tells you when a value moved without telling you what it moved from or why anyone moved it. The previous state is gone unless a copy was saved, which is why every practice has a folder holding tracker_v7_FINAL_revC_JM_comments.xlsx next to two files with almost the same name and different modification dates. Regulation 11M is a duty carried out across the design phase, and regulation 11Q(1) defines that phase as any period during which design work is carried out for a project, which may continue during the construction phase. A record that cannot show its own history cannot show how a change was assessed, and a design that has clearly evolved with nothing behind the evolution is exactly the gap section 05 is about.
The statutory test is that all reasonable steps were taken to secure a design that would comply if built. Steps, not states. A grid of percentages describes where the work got to; it says nothing about what was done to get it there, which is the thing the duty is actually about. Two projects can show identical trackers and have wildly different amounts of work behind them, and the file cannot tell them apart.
When the appointment ends, regulation 11M requires the principal designer to give the client, within 28 days, a document explaining the arrangements it put in place to fulfil its duties. That is a description of how the role was run. It is not a status export, and nobody has yet produced one from a colour-coded grid without writing it from scratch, from memory, under time pressure, months after the decisions were made.
One appointment, one file, fine. A practice carrying twelve BRPD appointments has twelve files with twelve column sets, twelve interpretations of what "complete" means, and no way to answer a simple question across all of them, such as which projects have an open Part B line with no issued fire strategy. Local authorities and housing associations commissioning at programme scale hit this immediately.
On higher-risk work the tracker eventually meets the Building Safety Regulator, and the regulator now publishes enough data to show the standard being applied. In the twelve weeks to 28 June 2026 it made 368 Gateway 2 decisions across all categories and approved 77 per cent of them, which sounds like a system settling down until you look at the applications that never reached a decision at all. In internal refurbishment work on higher-risk buildings, now the largest category the regulator handles, 237 applications were decided in the period while 299 were invalidated or withdrawn. On new builds, where the figures are split, invalidations outnumbered withdrawals eleven to six, and rejected applications were determined at a median of six weeks against twenty-two for approvals. An application that fails in six weeks has not been beaten on the engineering; it has been turned away at the door, usually on completeness.
The regulator has started saying so itself. In June 2026 it published guidance on the level of detail expected in applications and the shortfalls it keeps seeing, and its commentary on transitional cases, projects that reverted to the BSR when their original building control body ceased trading, makes the point about records better than any vendor could: much of the evidence now expected at Gateway 2 simply is not available. Those projects were run under the old regime, by competent people, almost certainly with a tracker. What they were not run with was a record that could be handed to a different authority and still stand up.
A spreadsheet did not cause any of that. But a spreadsheet is also the wrong instrument for catching it, because it records the conclusion each discipline reached without holding the material that would let anyone test whether the conclusions fit together.
If you are staying in Excel this year, and plenty of good practices will, seven changes carry most of the value. None of them need a licence.
Do those seven and the spreadsheet stops being a status board and starts being a record. It will still be manual, and it will still depend on one person keeping it current, but it will hold up.
There is no threshold in the regulations, and anyone telling you a spreadsheet is non-compliant is selling something. The practical signals are these: more than two or three live appointments at once, a higher-risk scheme heading for building control approval, an appointment that will outlive the person maintaining the file, or the moment when nobody can answer "why is this line green" without opening an inbox.
The last one is the real test. If the reasoning behind a closed requirement lives only in somebody's memory and an email thread, the record is already reconstructed rather than kept, and reconstruction is what fails under scrutiny.
COMP³ starts where the tracker's first column is a guess. You give it the project, and it derives which requirements apply and why, rather than inheriting a row list from a previous job. Each duty carries its source, each requirement carries the evidence it needs, and the record accumulates as the design work happens rather than being assembled at the end. Change is a first-class event with a reason attached, not an overwritten cell.
We are direct about the limits. The product is pre-launch, the regulatory model is being checked before the production release, and the duty to discharge the role stays with the appointed BRPD whatever tool sits underneath. You can see how the reasoning works on the features page, how the model is verified on the verification page, and if the role itself is the question rather than the tooling, start with what a Building Regulations Principal Designer actually is.
This article is general information about how the role is being run in practice. It is not legal advice, and it is not a statement of your obligations on a specific project. Nothing here replaces professional judgement, and the duty to discharge the role stays with the appointed BRPD.
A working record of which Building Regulations requirements apply to a project, who is responsible for each, and what evidence shows the design meets them. There is no prescribed format. Most are spreadsheets, and most descend from the Relevant Requirements Tracker RIBA publishes with its Principal Designer Guide.
Nothing in the Building Regulations 2010 requires or forbids a particular tool. A spreadsheet can hold a defensible record if it captures reasoning as well as status, logs changes with reasons, references documents by number and revision, and sits under real version control. A status grid alone records opinions.
It was written for the English regime. Wales runs a separate dutyholder regime from 1 July 2026 under a new Part 2B of the Building Regulations 2010, with a different higher-risk building test and the local authority as building control authority. The applicable Parts differ too, Part N being the obvious example.
Under regulation 11M, within 28 days of the appointment ending, a document explaining the arrangements the principal designer put in place to fulfil its duties under paragraphs (1) to (3) of that regulation. It describes how the role was run, not where the design got to.
Written by the COMP³ team. If your tracker does something clever that this article misses, or if you think we have a detail wrong, tell us at info@comp3.co.uk and we will update the piece.