Can You Build a Building with a Checklist?

As SENNA has grown, I have spent a surprising amount of time trying to write down what we know.

Not design principles or studio values, but the practical knowledge that sits behind good architectural documentation: the coordination points that repeatedly cause problems, the interfaces that need another look, and the small inconsistencies that seem inconsequential on a drawing but become expensive once they reach site.

We have been developing increasingly comprehensive documentation checklists across the studio as a way of improving consistency and transferring experience as the team grows. What became interesting quite quickly was that the more knowledge I tried to capture, the more obvious it became that architectural knowledge does not sit neatly inside a list.

There is still enormous value in trying. A growing practice should not depend on one or two people remembering everything they have learned over the course of their careers. But there is also a danger in believing that once enough knowledge has been documented, the process itself becomes intelligent.

Trying to write down what experience knows

An experienced architect rarely looks at a drawing in isolation.

Take something relatively small, like a balcony threshold. What appears to be a simple junction may involve waterproofing, drainage, accessibility, structure, façade systems, door frames, floor levels and construction tolerances. A change to one dimension can affect several others, even when those consequences are not obvious on the drawing where the change first appears.

Over time, architects become attuned to those relationships. They recognise patterns because they have seen enough consultant responses, RFIs, shop drawings and site conditions to understand how one decision can ripple through a building.

A checklist is one way of turning that accumulated experience into institutional memory. If something has caused a problem before, the next architect should not need to rediscover it independently.

The limitation is that documenting experience is not the same thing as reproducing it.

The checklist trap

The obvious failure of a checklist is that it is ignored. The more subtle failure is when it is followed so faithfully that the process begins to stand in for judgement.

A drawing set can pass through multiple layers of review, every item can be signed off, and the building can still be poorly resolved.

That is because checking and thinking are not interchangeable.

A checklist can remind someone to review a threshold against waterproofing, structure and façade systems. It cannot necessarily determine which element should move when those requirements conflict, whether an assumed constraint should be challenged, or whether a technically compliant answer is still a poor architectural outcome.

Most difficult architectural decisions are not difficult because information is unavailable. They are difficult because several pieces of information are valid at once.

The challenge is not simply to find the relevant information. It is to weigh it.

Buildings are not repeatable products

Architecture is simultaneously repetitive and highly specific.

We may work repeatedly within the same typology, under the same regulatory framework and using familiar construction systems. There is a great deal that should be standardised.

At the same time, every building rearranges the variables. The site, geometry, structure, façade, consultant inputs, commercial pressures and client priorities are all different.

A detail that worked perfectly on one project may be inappropriate on another because one condition has changed.

This is why experience is not simply a larger library of answers. Its value lies in understanding which precedent applies, which one does not, and when a familiar pattern is creating false confidence.

In that sense, expertise is partly the ability to recognise when the pattern is misleading you.

So why make the checklist at all?

Because good systems make good judgement easier to apply.

If a particular interface needs to be checked on every project, there is no benefit in relying on memory. If a recurring coordination issue has already been encountered, there is no reason for that lesson to disappear with the project team that experienced it.

The purpose of the checklist is not to replace judgement. It is to create more space for it.

We should systemise the things we already know so that our attention can be directed towards the things we do not.

A good architectural system should capture recurring risks, embed lessons learned, create consistency and prompt the right questions. What it should never do is create the impression that following the process is equivalent to resolving the building.

What cannot go on the checklist

The hardest parts of architectural practice are often the least procedural: knowing when a technically correct answer is still the wrong one, when a precedent no longer applies, or when a small decision will create consequences elsewhere in the building. Those judgements depend less on recall than on context, prioritisation and discernment.

As our tools become more capable, that distinction may become increasingly important. If AI becomes exceptionally good at interrogating standards, comparing drawings and retrieving relevant precedent, then architectural expertise may shift further away from simply knowing more things.

Its value may sit increasingly in knowing what matters.

Architecture is full of decisions made with incomplete information, competing priorities and consequences that are not always immediately visible. That is not a weakness in the process. It is the nature of the work.

So no, I do not think you can build a building with a checklist.

But I do think a good checklist can make the architect better at building one.

And if our systems, standards and AI tools continue to improve, perhaps that becomes the real measure of their value: not whether they replace professional judgement, but whether they give us more capacity to apply it well.