Skip to content
Frank Cauthen

Practice Resources · R1

Brief Conformance Checklist

We check the design against the brief at milestones because checking is laborious. That is the only reason it is episodic. Take the labor out and the constraint moves immediately to the brief itself, which is mostly written in language that cannot be tested at all. A requirement that cannot fail is not a requirement. This is a method for restating one so that it can.

Independent and personal

This document is my own work and my own opinion, written in my own time. It is not issued by, endorsed by, reviewed by, or connected to my employer. It does not describe, quote, or draw on any firm's internal practice or any real project, and nothing in it should be read as representing HOK, its practices, or its clients. The worked example is invented. Everything on this site is written the same way.

This is not a new idea

The profession already owns most of this discipline and keeps it in the wrong drawer. Commissioning practice defines an Owner's Project Requirements document as a written statement of functional requirements that includes measurable performance criteria and success criteria, and it defines acceptance as a formal act by a person with the authority to declare a requirement met. That is exactly the right structure. It is usually written late, applied to systems rather than to design intent, and read by almost nobody on the design side. What follows is that same discipline turned on the whole brief, early, by the people who have to answer for the result.

Five tests of a single line

  1. T1

    Singular

    One claim per line. Briefs arrive in sentences that carry three requirements and a mood, and every one of them will be argued separately later. Split them now, while splitting is free.

  2. T2

    Sourced

    Traceable to a specific line in the client's own document, or explicitly marked as your inference. Inferences are legitimate and unavoidable. An inference that is not labeled becomes, within about six weeks, a requirement nobody agreed to and everybody defends.

  3. T3

    Testable

    Names the artifact you would examine and the judgment you would make. Not the intention, the check. If you cannot say what you would look at and what would count as a failure, you have written a hope in the grammar of a requirement.

  4. T4

    Staged

    Names the point after which it becomes expensive, which is not the same as the point where you check. Checking is cheap and can happen weekly. What matters is knowing which findings are still free to act on and which have hardened.

  5. T5

    Owned

    Names who is entitled to declare it met. Commissioning practice already treats acceptance as a formal act by a person with authority, and design requirements deserve the same treatment. A requirement everyone is responsible for is a requirement nobody closes.

The conversion, in order

  1. 01

    Split it into single claims

    Go through the brief and break every sentence into one-claim lines. Do not summarize, do not merge, do not improve the prose. You are not editing the document, you are indexing it.

    Why

    Resist writing your own better version as you go. Your summary already contains your interpretation, and your interpretation is the thing you are trying to get checked.

  2. 02

    Classify every line

    Assign each line one of the seven types below. The classification is not bureaucracy. It tells you what kind of test the line can support, and it separates requirements about the building from constraints on the project, which behave completely differently in a negotiation.

  3. 03

    Write the test before you write the solution

    For each line, state the artifact and the judgment. A plan at end of schematic, a named analysis, a count, a walked route. Do this before designing anything against it, because a test written after the fact will quietly describe what you already drew.

  4. 04

    Mark what cannot be tested, on purpose

    Some lines are not testable and never will be. Mark them and leave them in. The failure here is not having untestable requirements, it is silently swapping in a measurable stand-in and then forgetting that a swap happened.

    Why

    This is the step that protects the part of the work that matters most, so it is worth doing slowly.

  5. 05

    Find the pairs that cannot both be met

    Read the whole restated list against itself and mark every contradiction. Flexibility against budget, openness against acoustic separation, daylight against envelope performance. Contradictions are the highest-value output of the entire exercise and they are invisible while the brief is still prose.

  6. 06

    Send it back to the client

    The restatement is the deliverable. The checklist is a by-product. Send it back and ask for confirmation, line by line, including the inferences and the contradictions.

    Why

    If the client will not confirm the restatement, that is not an obstacle to the method. That is the method working. You have learned in month two that the requirement was never agreed, rather than in month fourteen.

Seven kinds of line, seven kinds of test

  1. 1

    Quantity

    A count or an area. Fourteen exam rooms, two hundred parking spaces, nine thousand square feet of laboratory.

    The test
    Count it against the current plan. Trivial, and worth automating precisely because it is trivial.
    Where it goes wrong
    The number is testable and its basis usually is not. Ask what assumption produced it and when. Quantities outlive the reasoning that set them, and they get defended long after the assumption has stopped being true.
  2. 2

    Performance

    A target for how the building behaves. Energy, acoustics, air, light, thermal comfort, resilience.

    The test
    A named analysis, at a named stage, against a named threshold.
    Where it goes wrong
    A target with no method attached is a number that cannot fail. If the brief says a figure but not how it will be demonstrated, the method is your inference and has to be labeled as one.
  3. 3

    Relation

    Adjacency, separation, sequence, visibility. How parts of the building stand with respect to each other.

    The test
    A stated condition on a plan. A route that does not cross another route, a sightline that exists, a door that does not open onto a given space.
    Where it goes wrong
    Briefs state relations as preferences and projects treat them as requirements. Decide which one it is now, because the day it is tested is the day somebody has already built the plan around the other reading.
  4. 4

    Prohibition

    A stated negative. No windowless workstations, no public access to the service corridor.

    The test
    A sweep for the condition. The most reliably testable type there is.
    Where it goes wrong
    Prohibitions get checked once, early, and then assumed for the rest of the project. They are violated late, in the coordination that nobody re-tests.
  5. 5

    Constraint

    Budget, schedule, site, code, jurisdiction. Requirements on the project rather than on the building.

    The test
    Tracked continuously and separately, because they move.
    Where it goes wrong
    Mixing constraints into the same list as building requirements is the most common structural error in a brief. Constraints will be traded against everything else in the document, so they belong on their own page where the trade is visible.
  6. 6

    Experience

    Welcoming, calm, legible, dignified, quiet. What it is like to be there.

    The test
    Handled separately. See the section below, because getting this one wrong is how the whole method turns against the work.
    Where it goes wrong
    This is the category that matters most to the building and least to the checking, which is precisely the asymmetry that makes it dangerous to automate around.
  7. 7

    Aspiration

    The sentence that has the grammar of a requirement and the content of a hope. It should be a model for the sector. It should be sustainable.

    The test
    None, by definition. Label it and keep it.
    Where it goes wrong
    An aspiration honestly marked is more useful than a requirement dishonestly measured. Leaving it unmarked lets everyone believe it is being handled by someone else.

The experiential requirement

Welcoming is not testable. Neither is calm, dignified, or generous. Any method that promises otherwise is selling you a proxy.

But a condition can serve an aspiration without standing for it, and that distinction is the whole of the technique. Welcoming is not testable. A person arriving without an appointment can see the reception desk from inside the entry doors without turning is testable, on a plan, in about four seconds. It does not mean the same thing. It is not a definition of welcoming and it must never be written as one. It is one condition that serves the aspiration, and there will be others, and satisfying all of them still does not guarantee the result.

So write the condition and keep the aspiration above it, in the document, permanently. Never delete the aspiration once the condition exists. The moment the condition stands alone, you have started measuring the proxy, and the proxy will win every argument at four in the afternoon, because it is the one anybody can point at.

The reason this section exists

The bias this guards against is old and has nothing to do with software. What is new is the asymmetry. Making the checkable half of the work cheaper, while the unmeasurable half stays exactly as expensive as it always was, does not create the bias. It amplifies it. Marking the untestable requirements and refusing to convert them is the one defense the method has.

The longer version of this argument is in Judd’s Objection.

Worked example

An invented project: a 60,000 square foot outpatient clinic for an invented client. Six lines lifted from the kind of brief that actually arrives, converted in full. The last two are the interesting ones.

01

As written

The clinic should feel welcoming and reduce patient anxiety.

Experience, plus two derived conditions

Restated

  • ASPIRATION. The clinic should feel welcoming and reduce patient anxiety. Not testable. Retained.
  • CONDITION, serving the above. A person entering the main doors can see the reception desk without turning. Test: plan sightline, end of schematic. Source: our inference.
  • CONDITION, serving the above. No patient waiting position has its back to the main circulation route. Test: plan review at every issue. Source: our inference.

Why it is written that way

Two conditions, both labeled as inference, neither presented as a definition of the aspiration. The aspiration stays on the page above them and does not get closed out when the conditions are met.

02

As written

Provide adequate daylight to staff areas.

Performance, with the target missing

Restated

  • REQUIREMENT. Staff work areas achieve a stated daylight target. Test: daylight analysis at end of schematic and again at end of design development. Threshold: TO BE CONFIRMED BY CLIENT.
  • OPEN ITEM. The word adequate carries no number. We propose a threshold. Until the client confirms it, the number is ours and the requirement is unagreed.

Why it is written that way

The temptation is to fill in a defensible industry number and move on. Do not. Filling it in silently converts our judgment into their requirement, and in a year nobody will remember which it was.

03

As written

Staff and patient circulation should be separated.

Relation, with the key term undefined

Restated

  • REQUIREMENT. No staff route between the shared workroom and any exam room passes through public circulation. Test: walked route on plan, every issue.
  • OPEN ITEM. Separated was never defined. We have chosen the strictest reading that the plan can support. Confirm or relax it now, because the relaxed version is much harder to retrofit than to design.

Why it is written that way

Separated could mean six different things and the project will eventually pick one under pressure. Picking it in month two, in writing, in front of the client, costs nothing.

04

As written

Fourteen exam rooms.

Quantity

Restated

  • REQUIREMENT. Fourteen exam rooms. Test: count, every issue. Source: client brief, verbatim.
  • OPEN ITEM. What throughput assumption produced fourteen, and on what date? If the answer is a staffing model from two years ago, this number is the most confidently wrong line in the brief.

Why it is written that way

The easiest line in the document to test and one of the likeliest to be stale. Testability and truth are unrelated properties.

05

As written

The building should be sustainable.

Aspiration wearing a requirement's clothes

Restated

  • Either: REQUIREMENT. The project achieves a named certification at a named level, demonstrated by the named submission at the named stage.
  • Or: ASPIRATION. Retained, unmeasured, and honestly labeled as such.
  • Both are defensible. The original sentence is not, because it lets everyone assume somebody else is carrying it.

Why it is written that way

This is the single most common line in the single most common form in briefs, and it is doing no work at all in the sentence the client wrote.

06

As written

Allow for future expansion. / Hold the construction budget.

Contradiction

Restated

  • CONTRADICTION. Expansion capacity carries a cost now for a benefit later. The budget line has no allowance for it.
  • This is not resolvable by design. It is a decision the client has to make, and the only question is whether they make it in month two with options or in month eleven with none.

Why it is written that way

Two requirements that cannot both be met is the most valuable line the restatement produces, and it is completely invisible while the brief is still prose. This is what step five is for.

Four ways this method fails

  1. F1

    The proxy trap

    You convert an untestable requirement into a measurable stand-in, the stand-in gets tracked, and within a quarter the stand-in is the requirement. This is the one that costs you the building rather than the schedule. Step four exists solely to prevent it.

  2. F2

    False precision

    You supply a number the client never gave, it goes into the restatement unmarked, and it hardens into a requirement nobody agreed to. Every inference gets labeled as an inference, every time, including the ones that are obviously right.

  3. F3

    The frozen brief

    Faithful conformance holds the project to its earlier and stupider self. Good projects routinely turn into something nobody asked for, and the brief gets tidied afterward so the discovery reads as intent. A restatement has to be revisable, and every revision has to be dated and re-confirmed rather than quietly absorbed.

  4. F4

    Completeness theater

    Every line comes back marked met, and the document is circulated as evidence. It is not evidence. It is a list that has stopped asking questions. A healthy restatement always carries open items, and the open items are the part worth reading.

Version 1.0 · Updated August 2026

Checking was never the hard part of this, and it is about to stop being the expensive part. What is left is the work of stating what we actually promised, in language precise enough to be found wrong. It is unglamorous, it is mostly writing rather than drawing, and it is now the constraint.

Free to adapt. If you run a real brief through this and it breaks, that is the most useful thing you could send me. hello@frankcauthen.com

Once a brief is restated this way, the second pattern in Critique Prompt Patterns takes the restated list as its input. The argument underneath both is in The Tighter Loop.

← All practice resources