Adjacencies & Stacking

An adjacency matrix is the oldest, most useful device in programming: a grid of every space against every other, with each cell scoring how much the two want to be near each other - essential, desirable, neutral, or must-be-separated. It forces you to consider every relationship deliberately rather than only the obvious ones, and it exposes conflicts early, on paper, where they cost nothing to fix. The trouble is that building one by hand for a real programme is tedious, and tedium is where things get skipped. This is precisely the sort of structured, complete, slightly boring task Claude does well.

Give Claude your space list and ask it to draft the matrix, stating the reasoning:

Here are the spaces in a family home: [list]. Build an adjacency
matrix scoring each pair as: ++ (want adjacent), + (desirable),
. (neutral), or x (keep apart). For every ++ and every x, give a
one-line reason. Base it on typical family-home planning and the
brief notes I've given, and tell me where the brief is silent so
I can decide.

What returns is the figure opposite: a complete matrix with reasons, drafted in one pass. Its value is not that it is correct - it is that it is complete and explicit. Every relationship has been considered and justified, which is far more than a hurried human sketch usually achieves, and each reason is something you can agree with or overrule. When Claude scores kitchen-to-master as 'keep apart' because of cooking smells and noise, you might agree; when it scores study-to-living as neutral, you might override it to 'keep apart' because this particular client takes calls all day. That override is the design happening - you reasoning against a complete draft rather than a blank grid.

The deeper benefit is that the matrix makes disagreements visible. If two of the client's stated wishes imply contradictory adjacencies - a private study but also a study open to the family - the matrix will not resolve it, but it will surface it, which sends you back to the brief and the client with a sharp question rather than a vague unease. That is Claude at its best in this phase: not deciding, but ensuring nothing goes unconsidered.

From the matrix emerges zoning - the grouping of spaces into coherent territories: public and private, served and servant, quiet and loud, day and night. Claude can propose these groupings and articulate the logic, which is useful both for testing your own instinct and for explaining the plan later. Ask it to cluster the programme into zones and to describe the circulation that connects them, and you get a reasoned first organisation you can accept, adjust or reject.

The concept worth naming here is the privacy gradient - the idea that a well-planned building moves you from the most public space (the entry, the street edge) through progressively more private ones (living, then family, then bedrooms) rather than jumbling them. Claude reasons about this fluently and can check a proposed arrangement against it: 'does anyone cross a private zone to reach a public one?' is a question it will answer thoughtfully. It can also reason about circulation efficiency - whether your organisation implies long corridors, whether a single core can serve the plan, whether the entry sequence makes sense - all as structured argument you evaluate.

But hold the line on what Claude is doing. It is reasoning about a diagram of relationships, not about a place. It does not know that the site slopes, that the good view is north-west, that the neighbour's window looks straight into your proposed courtyard, or that in this culture the kitchen's relationship to the entry carries social meaning. All of that is your knowledge, and it routinely overrides the abstract logic. The right way to use Claude here is conversational: propose your zoning, ask it to critique it against circulation and privacy principles, let it raise things you had not weighed, and then decide - carrying in the site and cultural knowledge Claude simply does not have.

A useful prompt pattern is to make Claude argue both sides:

Here's my proposed zoning [describe]. Give me the strongest case
FOR this arrangement, then the strongest case AGAINST it, focusing
on circulation, privacy and daylight. Don't conclude - I'll decide.

Asked to argue rather than to conclude, Claude becomes a genuine sparring partner, and you leave the exchange having stress-tested your plan without ever having surrendered it.

On any project over one storey, adjacency becomes three-dimensional, and a new discipline appears: stacking. Which functions go on which floor, how the vertical circulation and services run, how the public-to-private gradient expresses itself in section as well as plan - these decisions shape the building as much as the plan does, and they interact tightly with structure, services and cost.

Claude reasons about stacking well because it is, again, a problem of relationships and rules. Feed it your programme and the number of floors and it will propose a stack: public functions low where they meet the street and take the footfall, private functions high where they gain quiet and light, services and wet areas aligned vertically so plumbing and ducts run straight, a single core serving all levels. The figure opposite shows the archetype - a stilt or ground level for parking and services, public living at entry level, semi-private family floors above, the most private suite highest, with one stair-and-lift core threading them and a clear privacy gradient rising through the section.

The prompt is straightforward, and again you ask for the reasoning:

Stack this programme over [N] floors. For each floor, list the
spaces and explain why they belong there, considering: public-to-
private gradient, aligning wet areas and services vertically,
daylight, and a single circulation core. Flag any space whose
placement is a genuine trade-off.

The trade-off flag is the valuable part. Stacking is full of them - put the kitchen up for the view or down for the garden? the guest room on the public floor for convenience or the private floor for quiet? - and Claude naming them is what turns a bland stack into a set of real decisions for you to make. As always, its stack is a reasoned starting proposition, not an answer. It does not know your local byelaw caps height at three floors, that the water table forbids a basement, that the client's parents cannot manage stairs and need a ground-floor bedroom the abstract logic would put upstairs. You bring those; Claude ensures the rest of the logic is coherent and complete around them.

Everything in this lesson circles one principle: in the move from programme to plan, Claude is the tireless foil and you are the architect who decides. This is a sharper distinction than in the more clerical parts of practice, because here Claude produces things - matrices, zonings, stacks - that look like design decisions. They are not. They are structured reasoning about relationships, offered fast and explained clearly, for you to accept, bend or reject. The risk, and it is a real one, is that their fluency and completeness seduce you into adopting the plan Claude 'suggested' rather than the plan the project needs.

Guard against it with a habit: never let Claude conclude. Ask it to build the matrix, to argue both sides of a zoning, to flag the trade-offs in a stack - but reserve every decision for yourself, made with the site, the client, the culture and the budget in view. The tell that you have slipped is when you find yourself defending an arrangement because 'that's what came out', rather than because it is right for this place. If you cannot say why a plan is good in your own words, you have not designed it; you have transcribed a plausible suggestion.

Used with that discipline, the payoff is large. The slow, error-prone, easily-skipped parts of programming - the complete matrix, the explicit zoning rationale, the coherent stack with its trade-offs named - get done thoroughly and fast, which means you enter the drawing board with your relationships fully thought through rather than half-considered. You will make better plans, more quickly, and you will be able to explain them, because you argued them out against a foil that never got tired of the conversation.

And the plan remains unmistakably yours. Claude never stood on the site, never met the family, never carried the liability for a corridor that does not work. It helped you see the problem whole. You solved it. That is the relationship this whole course teaches, and nowhere is it more important than here, at the exact point where a programme becomes a piece of architecture.