The Space Program & Area Statement

Start from the agreed brief, not from scratch. If the brief lists the spaces the client wants, Claude can turn that list into a structured programme by adding the dimensions of practice: how many of each space, a reasonable area for each, who occupies it, and how it all sums. The key is to give Claude the rules you want it to use rather than letting it reach for its own averages, which may come from a different country, climate or code entirely.

A strong first prompt supplies the room list, states the area basis, and demands a specific format:

Build a space program table from this brief. Columns: Space,
Quantity, Area per unit (sq m), Subtotal (sq m), Occupancy.
Use these planning areas as a starting point unless I've given
a size: [list any known sizes]. Add a circulation allowance of
15% as its own line. Give a NET/CARPET total. Show your
assumptions for every area you chose, in a list below the table,
so I can check them.

Brief spaces: [paste the spaces from the brief]

The instruction to "show your assumptions" is the single most valuable habit in this whole lesson. It converts an opaque table into an auditable one: instead of a bare "24 sq m" for the master bedroom, you see "master bedroom 24 sq m assumes a 4x4 sleeping zone plus wardrobe and a small seating corner", which you can accept, correct or challenge. Without it, you are trusting numbers whose origin you cannot see - the definition of unchecked risk.

Be explicit, too, about which area you mean. "Area" is dangerously ambiguous: carpet area, built-up area, super built-up and the FAR-countable area can differ by twenty per cent or more, and they are governed by definitions in your local development control rules, not by Claude. Decide the basis yourself and tell Claude to work in it consistently. If you let the term float, you will get a table that silently mixes bases - a classic source of a programme that looks right and is wrong by a fifth.

A programme is more than a sum of room sizes; it encodes how many people use the building and how much of it is not rooms at all. Both are places Claude can help and both are places it can quietly mislead.

Occupancy matters because it drives things that matter: sanitation provision, egress width, ventilation, parking, and in many building types the code's own area requirements. Ask Claude to add a realistic occupancy to each space and to total it, and it will - but the totals feed code-driven calculations (how many toilets, how wide the stair, how many car parks) where being wrong is not a rounding error but a compliance failure. So treat the occupancy column as a first pass to verify against the actual code for your building type and jurisdiction, exactly as Module 2.2 insisted: Claude points you to the calculation, it does not perform the ruling.

Ratios are the other reality check. Circulation - corridors, stairs, lobbies, the space between the rooms - typically runs from around 10% in an efficient house to 30% or more in a complex public building, and it is easy to under- or over-count. Efficiency ratios (net usable area over gross area) are a fast way to smell-test a programme: if Claude's numbers imply a 95% efficient hospital, something is wrong. You can even ask Claude to compute these ratios for you and comment on whether they look typical for the building type - a useful prompt precisely because it invites the model to critique its own table:

For this programme, calculate: net-to-gross efficiency, circulation
as a % of net, and area per person. Tell me whether each figure is
typical for this building type, and flag any that look off.

Read the answer as a prompt for your own scrutiny, not a verdict. Claude's sense of "typical" is a plausible average, not your local benchmark, and it does not know that your site's narrow frontage forces generous circulation. But it is very good at catching the gross error - the misplaced decimal, the room counted twice, the circulation line quietly dropped - which is exactly the kind of mistake a tired human makes at 11pm and a fresh set of eyes catches instantly. Used as that second set of eyes, on numbers you then own, it earns its place.

Here is the hard truth this lesson is built around: language models can get arithmetic wrong, and they do so with total confidence. They are trained to produce plausible text, and a plausible-looking sum is not the same as a correct one. Newer models are markedly better at maths, and asking Claude to work step by step (or to use a calculation tool where available) improves reliability - but "better" is not "guaranteed", and a space program is precisely the kind of load-bearing arithmetic where you cannot afford a silent error. The professional stance is simple: you are the quantity surveyor of your own programme.

That does not mean redoing everything by hand - it means checking with intent. Three checks catch the overwhelming majority of problems, as the figure opposite lays out. First, spot-check the totals: add a couple of columns yourself, or paste them into a spreadsheet, and confirm Claude's subtotals and grand total actually sum. Second, check the basis is consistent: is every area the same type (carpet, built-up), and does the circulation percentage apply to the right base? Third, check it against the world: does the total fit the plot at the permitted FAR, with setbacks, in a realistic number of floors? A programme that needs more area than the plot can legally hold is not a programme, however neat the table.

A reliable pattern is to have Claude set up the calculation and you confirm the result. For instance, ask it to write the arithmetic out explicitly - "master 24 + 2 bedrooms at 16 = 32 + living 32 + ... = X, plus 15% circulation = Y" - so you can follow and check each step, rather than accepting a single final figure. This plays to Claude's strength (structuring the calculation clearly and fast) while keeping the verification, which is cheap once the working is visible, firmly with you. For anything that will drive a real decision - a fee, a cost plan, a planning submission - back the check with a genuine tool: a spreadsheet formula, or one of Studio Matrx's own area and FAR calculators, where the maths is deterministic and auditable.

The mindset to internalise: Claude's table is a fast, well-organised first draft of a calculation, not a calculated result. It has done the tedious layout; you do the sums that carry your seal. Scrutiny scales with stakes, and a space program that everything else depends on sits near the top of the scale.

A space program is not a one-time artefact you produce and file; it is a working instrument that changes as the design does, and its value depends on staying current and staying trusted. Two practices keep it honest.

The first is version discipline. When a room grows, a space is cut, or the client adds a guest suite, update the programme immediately and note what changed and why - "guest suite added at client's request, 2 Aug, +18 sq m; total now over plot capacity, flagged." Claude makes this cheap: paste the current table, describe the change in plain English, and ask for the revised table plus a one-line changelog. Because the update is fast, you actually do it, and the programme remains the single source of truth instead of drifting out of date while decisions are made against a stale version. But re-check the affected totals every time - an edit is a new calculation, and a new calculation is a new chance for a silent error.

The second is turning the programme into a communication tool. A bare table is for you; the client needs to understand what it means for their budget and their building. Ask Claude to translate the programme into plain language - "this is roughly a 1,400 square foot home, of which about a seventh is circulation, comfortably within your plot's limits" - or into a simple comparison of options: a lean version and a generous version, side by side, with the area and rough cost implication of each. This is where the speed compounds: exploring three programme scenarios used to be a week's work and is now an afternoon, which means the client makes an informed choice early, when changing it is cheap.

Through all of it, the division of labour holds. Claude assembles, tallies, revises and explains at a speed no human can match, and it never tires of another iteration. You decide what spaces the project needs, which area basis governs, whether the numbers are true, and whether the whole thing fits the plot, the code and the budget. The programme that goes out under your name is one you have audited line by line - fast, because Claude did the assembly, but yours, because you did the checking. That is the discipline that turns a seductive table of numbers into a trustworthy foundation for everything downstream.