Interrogating the Brief

The most common defect in a brief is not error but omission - the requirement nobody thought to state because it seemed obvious, or because no one in the room owned it. Accessibility, acoustic separation, storage, future-proofing, maintenance, security, services and plant space, statutory requirements: these are the things briefs routinely fall silent on, and silence in a brief becomes an assumption in a design and a dispute on site. Claude, prompted to compare your brief against what a complete brief for this building type usually contains, is a fast and thorough way to surface them.

The prompt is simple and the framing matters:

Act as an experienced architect reviewing a colleague's brief
for [building type] before design starts. Here is the brief.
List every important thing a brief like this should normally
address that this one does not - especially around accessibility,
services, storage, statutory requirements, maintenance and
future needs. For each gap, tell me why it matters. Be thorough
and critical; I would rather hear it now than on site.

Framing Claude as a critical reviewer, and explicitly inviting bad news, matters because a language model's default is to be agreeable - ask it what it thinks of your brief and it will tend to reassure you. You have to give it permission, even instruction, to be harsh, and to point it at the categories where omissions hurt most. The figure opposite shows the shape of what comes back: your brief goes in, Claude probes it, and out come sorted flags - gaps, conflicts, risks and questions.

Read the resulting list as a checklist to work through, not a verdict to accept. Some gaps Claude names will be genuine and important; some will be irrelevant to your project (it does not know the client already owns the furniture, or that the site has no accessibility obligation); and some it will miss, because it does not know your building type as well as you do. Its job is to make sure you consciously decide about each potential requirement - to convert silent assumptions into explicit choices - not to write the requirements for you. Every gap it raises is a small question you now answer on purpose.

Gaps are things missing; conflicts are things present that cannot coexist. These are subtler and often more dangerous, because each individual requirement is reasonable - it is only together that they are impossible. The classic is the tension between budget, scope and quality: the client wants a large programme, high finishes and a tight budget, and any two of those can be had but not all three. There are quieter versions everywhere: 'open and flowing' with 'private and quiet'; 'low maintenance' with 'natural materials'; 'maximise the plot' with the setbacks the byelaw demands; 'ready in six months' with a programme that takes twelve.

Claude is well suited to hunting these because it can hold the whole brief at once and reason about internal consistency without the emotional investment that makes designers explain conflicts away. Ask it directly:

Analyse this brief for internal contradictions - places where two
or more requirements are hard to satisfy together. For each, name
the requirements in tension, explain the conflict, and suggest what
the client might have to trade off. Include budget-vs-scope-vs-
quality and any programme, site or code tensions.

The figure of the hidden-conflict triangle - budget against space program against site-and-code limits - is worth internalising, because most brief conflicts reduce to some version of 'these three do not reconcile'. When Claude surfaces one, it has not solved anything; it has handed you a decision that belongs to the client. And that is the real value: a conflict found in the brief is a conversation with the client ('you can have the fifth bedroom or the double-height living room within this budget, not both'); the same conflict found in design development is an awkward, expensive redesign; found on site, it is a claim. Moving the discovery as far upstream as possible is the whole game.

As always, verify before you act. Claude will sometimes flag a 'conflict' that is not one - it may not know that the budget is flexible, or that the six-month deadline is aspirational. Treat each flagged conflict as a hypothesis, confirm it is real, gauge how much it matters, and only then take it to the client. The skill is not accepting Claude's list; it is using it to make sure no genuine conflict reaches the drawing board undiscovered.

One of the most powerful risk techniques adapts beautifully to working with Claude: the pre-mortem. Instead of asking 'what could go wrong', you imagine the project has already failed - the client is furious, the building does not work, the budget blew - and reason backwards to what caused it. This mental trick defeats the optimism that infects the start of every project, and Claude is a tireless partner for it because it will generate failure modes without the discomfort a human team feels naming them.

Imagine it is two years from now and this project has gone badly
- the client is unhappy and the building underperforms. Working
backwards, give me the ten most likely reasons it failed, based
on this brief. Include design, budget, programme, site,
stakeholder and use-related causes. For each, what early warning
sign in the brief points to it?

What returns is a ranked set of risks tied back to specifics in your brief, which you then triage. Some will be remote, some will be things you have already handled, and some will be the uncomfortable, real ones you were half-avoiding - the stakeholder who has not actually agreed, the budget everyone knows is thin, the programme that assumes a fast approval. Naming them now, on paper, is what lets you design mitigations in from the start rather than firefighting later.

Risk reasoning is also where you must be most careful not to over-trust Claude, in both directions. It can invent risks that do not apply to your context, and - more dangerously - it can miss the risks specific to your site, jurisdiction or client that are not present in the brief text it can see. A pre-mortem with Claude is a powerful supplement to your own experienced judgement and your team's, not a replacement for it. The risks that matter most are often the ones only local, specific knowledge surfaces - the contractor everyone in town knows to avoid, the monsoon that floods that road, the approval authority that is slow this year - and none of that is in Claude's reach. Use it to be thorough about the knowable; stay vigilant about the rest.

All of this interrogation is only worth doing if it changes what you do next, and the output that carries it forward is a single, sharp list: the questions to take back to the client. Gaps, conflicts and risks are internal analysis; the client sees a considered set of questions that make you look rigorous rather than uncertain. Claude is excellent at the last transformation - turning your messy analysis into a clean, prioritised, tactfully-worded set of questions:

From the gaps, conflicts and risks we've identified, draft a
prioritised list of questions to put to the client. Group them,
put the decision-forcing ones first, and phrase them so they
help the client choose rather than feeling interrogated. Note
which ones must be resolved before design can proceed.

The result is the deliverable that closes the front end of a project: a set of questions that convert every silent assumption and hidden conflict into an explicit, client-owned decision. Some questions force a trade-off ('within this budget, which of these three do you most want?'); some fill a gap ('who will maintain the garden, and how often?'); some confirm a risk is understood ('the approval could take longer than six months - is the moving-in date firm?'). Taking these to the client early is the mark of a serious practice, and it protects you: a decision the client made, recorded in your notes, is not a mistake you made.

Step back and see what this module has built. You turned a conversation into a brief (3.1), the brief into a costed programme (3.2), the programme into a plan logic (3.3), and now you have stress-tested the whole thing before committing a single considered line (3.4). At every step Claude did the fast, structured, tireless work - drafting, tabulating, reasoning, probing - and at every step you supplied the truth, the judgement and the decisions, with your scrutiny scaled to the stakes. The brief that emerges is not Claude's. It is yours: heard, structured, quantified, organised and interrogated - and ready, at last, to design against.