Where does a decision live?

Tuesday's dinner is rejected because it needs too much active work for a busy evening. The team investigates and finds that the system prompt mentions busy days, the interface has a quick-meals toggle, and retrieval boosts recipes tagged weeknight. Each one influenced the result. None owns it.

This is not merely an observability problem. A decision without a primary home cannot be evaluated, corrected, or defended as a decision. The team can change many things and perhaps reduce complaints, but it cannot establish what was wrong, why the fix worked, or what has been learned. Decision locality is the discipline of giving a meaningful judgment an architectural address.

Helpful context: One cognitive unit, one open decision turns locality into a contract rule. Evaluation as engineering shows how a local decision becomes a testable object, and separate, then assign gives the practical decomposition move.

Runtime judgments naturally spread

Closed decisions usually have obvious locations. The allergy validator enforces the allergy, and the portion calculator calculates portions. Because their inputs and procedures are explicit, their failures point to a function or rule.

Runtime judgments are formed from an arrangement of influences: instructions, household knowledge, retrieved candidates, conversation history, model behavior, and the order in which the system operates. Changing any of these may change the answer.

Unless the architecture gathers those influences beneath a declared boundary, the judgment ends up smeared across every layer that happened to shape it.

That is why a model diagram is inadequate. The model is one influence, not the location of the decision. The location must be an architectural commitment the team has made.

The central architectural question is no longer only what the software does. It is where the judgment lives.

Introduction to Thoughtware · Ch. 2

A home is a declared boundary

A decision's home need not be one model call. It can contain multiple internal steps. What makes it a home is that it declares its purpose, permitted evidence, result, uncertainty behavior, and quality standard.

AssessMealPracticality is a home in this sense. It receives a candidate meal and an interpreted evening; it returns a practicality verdict with grounds; it can state that the evidence is insufficient; and it has a suite of cases that tests whether its judgments are adequate. The implementation may change inside that boundary without forcing every caller to rediscover what “practicality” means.

The primary home should match the nature of the work:

Kind of work	Primary home
Bounded open judgment	Cognitive unit
Coordination across several judgments	Agent strategy
Settled rule or transformation	Deterministic code
Irreversible or unauthorised consequence	Human or granted authority

The error in the opening example is not that a decision used prompt text, interface state, and retrieval. Any of these may be legitimate inputs. The error is that all three silently became competing owners of the same judgment.

Locality creates a vocabulary for failure

When a system has locality, an incident becomes a sequence of concrete questions: did InterpretWeek misunderstand “busy,” did retrieval provide stale household knowledge, did AssessMealPracticality apply the wrong standard, did the planning agent skip a necessary critique, or did deterministic code execute an action that should have required approval?

Each question has a different test and a different repair. That is the actual benefit of locality: it makes cognitive behavior amenable to engineering.

The aim is not to make every borderline judgment deterministic, but to know which component produced the judgment, measure it against a clear standard, and control what happens next.

Evaluation depends on this same address. A product-wide score for “assistant quality” has nowhere useful to attach its findings, whereas a failing practicality suite does. It identifies the unit whose contract, evidence, model, or evaluator needs attention.

Locality is usually lost by accumulation

Teams often begin with one broad instruction because it is the fastest way to learn whether a product idea is viable. Problems begin when that prototype becomes the permanent design.

New constraints are added to the prompt, UI defaults begin to carry policy, retrieval filters shape which options are ever considered, and memory changes later results. Eventually a change made to improve one behavior changes three others.

The warning sign is non-local improvement: a tweak intended to improve meal planning alters tone, factuality, or another unrelated decision. That is evidence that several judgments share a boundary they should not share.

The repair is not to remove context or force every decision into a tiny component. It is to name the decision, choose its primary home, and turn every other influence into a declared input or a separate owner. Once that boundary exists, changes become testable rather than superstitious.

A quick audit

Take one bad output and list everything that could have changed it: prompts, UI defaults, retrieval, memory, tools, post-processing, and human approval. Then ask which items are supposed to own the same decision. If there is more than one primary owner—or none—you have found a locality failure.

The next step is to separate the decision from its influences and give it one address. That is the condition for responsible evaluation, reuse, and improvement.

Read next: Meaning, knowledge, and authority separates three categories that locality failures often collapse together.

Locality also protects change

A local decision can evolve without forcing unrelated behavior to move with it. The team may change how practicality is evaluated, replace the model inside the unit, or add a new evidence source while preserving the contract callers depend on. That is the same benefit interfaces give conventional software: a controlled place to improve without rediscovering every dependency.

Without locality, every change is a system-wide experiment. A prompt adjustment intended to fix Tuesday can alter the explanation, the retrieval choice, and an unrelated recommendation. The more a product learns, the more expensive that uncertainty becomes. Locality is therefore not only how failures are diagnosed; it is how improvement remains safe.