The other half of the judgement stack

Every major BIM platform is now shipping an AI assistant. The more useful question is what advantage is left once every practice has the same features and rents the same models, because that answer will not arrive in a software release.

The argument we would not argue with.

Martyn Day has given that question its sharpest airing yet. His AEC Magazine feature, Dawn of the Judgement Stack, takes ALPA’s open-source Skills for Architects repository as its starting point and draws a line most of the industry has not yet drawn. Vendor AI will keep improving, and firms should use it. But a software company can only ship what generalises across thousands of customers, and the moment it encodes one firm’s healthcare methodology or planning interpretation it becomes wrong for everyone else. What is left over, the reasoning a practice wraps around whatever model it happens to be renting, is the part no vendor can ship.

He organises this as three layers, borrowing the term judgement stack from Dustin Schafer at Henderson Engineers: vendor features at the base, the practice’s own encoded reasoning above it, and institutional memory above that, where those skills start reasoning over decades of the firm’s own projects. Each layer is harder to copy than the one below it.

The sharpest line in the piece is about where the intellectual property actually sits once every vendor has a capable assistant.

The competitive asset is the thinking that produced the geometry.

Martyn Day, AEC Magazine

That is correct, and it is the whole argument in ten words. We would add four things to it.

There are two judgement stacks, not one.

The article is mostly about design judgement: why the door belongs where it does, which adjacencies are non-negotiable, how circulation should work, when a regulation should be read conservatively. That is real, and it is well made.

A second body of judgement sits alongside it, which the article notes in passing, listing quality reviews and the checks that happen before information leaves the office among the reasoning a firm could codify. We would put considerably more weight on it than a list entry. It is the reasoning a firm applies to decide whether what has been produced actually meets what was required. What your best reviewer opens first. Which clauses they never take on trust. The defect they saw on a scheme in 2019 that they have looked for on every project since. Where the brief reliably drifts, and which discrepancy is worth an email against which one stops an issue leaving the office.

That knowledge is scarcer than design judgement, more expensive to hire, and it leaves faster, because it lives in fewer heads. It is also the half with a statutory clock attached to it.

The judgement stack is not only an architect’s asset.

The piece frames the opportunity around practices, which makes sense for an architecture readership. In our market the same argument applies at least as forcefully one step up the chain, to the organisation commissioning the work.

Mid-tier owner-developers author requirements of their own, and plenty of them. House standards refined over a decade of schemes. Operator standards for power, cooling and uptime, applied across many concurrent builds. Validation requirements written around a named occupier’s process. They then carry the dutyholder and professional indemnity exposure when the delivered scheme does not meet those requirements.

They have a judgement stack too, and it is usually in worse condition than a design practice’s: scattered across briefs, minutes, an ageing employer’s information requirements document, and one or two people who remember why a particular clause is in there. Turning that into trackable requirements is the first honest step, and it is not a documentation exercise for its own sake. It is the pass line against which everything arriving on the project gets reviewed.

Judgement that cannot be graded is only an assertion.

A skill makes judgement repeatable, reviewable and improvable, as the article says. We would add one more requirement to that list: gradable.

An experienced reviewer does not hand back a pass or a fail. They hand back something more useful. This is fine, and here is the clause it satisfies. This one I want a second opinion on. This I cannot form a view on from the information supplied. And this nobody has looked at at all. Strip the calibration out and you have encoded the reviewer’s conclusions while throwing away the thing that made them worth trusting.

The last case is the one that matters most. A rule-based tool is silent where there is no rule, and silence reads as an all-clear. An honest account of what has not yet been reviewed is worth more before sign-off than a confident report on whichever fraction happened to be encodable.

Do not start with a blank page.

The article’s diagnosis is right. The hard part is not programming, it is getting senior people to articulate how the practice already works. We would put it more bluntly: that is the reason most judgement stacks will never get built. Authoring thirty-nine skills is a documentation project, and documentation projects lose to fee-earning work every time, in every firm, forever.

The way out is to stop treating capture as a separate exercise. Judgement is easiest to record at the moment it is being exercised. Nobody has a spare fortnight to write down how they review a package. Everybody has to review the next package anyway. If the reasoning applied to that review is retained as structured record, the requirement it traced back to, the finding raised, the resolution accepted and why, then the stack accrues as a by-product of work that was happening regardless.

This is also what turns a library into a moat rather than an archive. The article notes that institutional knowledge improves each time it is used, and the mechanism deserves spelling out: every resolved finding narrows the next review, so what accumulates is a record of the firm’s own resolved judgement. A competitor can license the same foundation model and read the same open repository. They cannot download your last two hundred resolutions, because those are your past.

Outside the BIM monolith is not the same as owned.

The strongest passage is the one on dependency: a practice can spend years codifying its judgement and still find itself paying for access to it every time that judgement is queried. Framing this as a toll road rather than as vendor lock-in is a better description of the commercial reality, and worth borrowing.

We would attach one caution to it. Moving intelligence out of the authoring application is necessary, but it is not sufficient. Outside Revit and locked inside another platform’s proprietary structure is the same toll with better scenery.

The feature closes by suggesting that the coming decade may digitise the judgement that produces buildings rather than only the buildings themselves. That is the right note to end on, and it is his, not ours. We would add one thing to it: the judgement under the most immediate pressure is the kind that decides whether a package is ready to leave the office, and across the residential, life sciences and data centre work we see, that pressure is arriving now rather than next decade.