Judgment chains

The plan comes back with a forty-minute braise on Thursday evening. The household is annoyed, so the team goes looking for the component that failed. AssessMealPracticality scored well on its suite that morning, allergy validation passed, and the portion arithmetic was exact to the gram.

Nothing was broken. The braise is there because InterpretWeek recorded Thursday as an ordinary evening, and everything after that point was correct about a week that was not the household's week. That situation is what this page is about, and it is not a component quality problem. Once decisions run in an order, each one answers a question about what the previous one produced, so a link can be entirely accurate and entirely wrong at the same time. A chain's reliability is therefore decided by what passes between its links rather than by how good the links are.

Helpful context: Most decisions are several decisions performs the cut that produces the links, and this page starts after the cut. Where does a decision live? gives each link one home, and how decisions close traces what happens to a link as cases accumulate. Who should lead each judgment (next in this track) allocates leadership link by link.

What a link actually receives

A chain is more than an ordering, because the ordering only says which link runs next. The relation underneath it is inheritance, and every link runs on material it did not produce and usually cannot check. Some of that inheritance is structural and obvious once stated, since assessing variety across a week is impossible until a complete provisional plan exists to be assessed, and portions cannot be calculated until a household count has been accepted. The inheritance that causes trouble is the kind nobody wrote down: repairing one evening depends on knowing which meals the household already accepted, and a repair that does not receive that list will quietly discard them.

Read that way, each link has two faces. Facing backward it consumes assumptions, because AssessMealPracticality takes it as given that the evening it is judging really is a constrained one and has no way to establish that for itself. Facing forward it produces assumptions that something downstream will rely on without re-deriving them. The contract between two adjacent links is therefore part of the architecture rather than an implementation detail, and it is the part most often left implicit.

Link	What it inherits	What it hands forward
InterpretWeek	request, calendar, endorsed knowledge	a week representation with busy evenings marked
AssessMealPracticality	the marked week, one candidate, effort budget	a verdict on one evening
ComposeWeek	per-evening verdicts, accepted meals, constraints	a provisional plan version
CritiquePlan	the complete plan version	named material weaknesses, or none
Purchase	a validated list and an approval	an executed order

Every entry in the middle column is a claim that something earlier established, and nothing in the right column carries a record of whether that claim was true. The links also sit on different ground, since one planning run moves from strongly patterned evening fit through composition with several defensible answers to an unfamiliar restriction the planner may not interpret at all. Established, mixed, and frontier regions works out what each of those readings permits. What matters here is that the reading belongs to the link, so a single run crosses several of them.

Why accurate links produce wrong outcomes

Inheritance is what makes per-link accuracy a misleading number. A suite for AssessMealPracticality feeds it evenings that are correctly marked, because that is what a suite for one bounded judgment ought to do, so it measures the component under the assumption that its inheritance was sound. The figure it returns is real and it is not a prediction about the chain. When Thursday arrived marked as ordinary, the component was asked a well-formed question about the wrong evening and answered it well.

Error therefore propagates rather than averages. Two links at ninety-five percent do not compose into a chain at ninety, because the second link's failures are not independent of the first's: once interpretation is wrong, every assessment below it is wrong about the same thing, in the same direction, at once. That is why the household's complaint is never proportionate to any component's error rate, and why a team that responds by improving its strongest-looking suspect can spend a quarter without moving the outcome. Finding the weak decision is about locating the link actually carrying the failure.

Inheritance also explains a failure with no component to blame. If ComposeWeek begins treating busy as any evening with a calendar entry while AssessMealPracticality still applies the endorsed twenty-five-minute active-effort rule, both behave exactly as specified and the plan is still wrong. The break sits in the contract between them, so reading either component will not find it. Drift of that kind is why week state deserves a version and a published schema rather than a shared understanding.

Chain failure and local repair are not the same repair

Once you know that a fault enters at one link and travels downward, the depth of a repair stops being a matter of taste. InterpretWeek misreading the busy evenings is a chain failure, because everything below it started from the wrong week, so substituting Thursday's meal produces a plan that is wrong in a new way. The repair belongs at interpretation, or at a checkpoint that settles week state before composition spends anything.

One meal failing practicality on Wednesday is the other case. The week was read correctly, the allergy held, six evenings were accepted, and exactly one link produced a weak result. RecommendMealSubstitution proposes a replacement and code applies it as a transactional patch against a plan version, so the accepted meals survive the repair. A local patch is legitimate because it asserts something specific, which is that the chain was sound everywhere except here.

Teams confuse the two because the household reports the same thing either way, that the plan was wrong. The consequence of confusing them is asymmetric. Treating a local weakness as chain failure wastes a full re-run and some goodwill. Treating chain failure as a local weakness produces the pattern where every week needs one more manual fix and nothing ever stabilises, since each patch repairs a symptom of an assumption that is still wrong upstream.

Where a chain should be interrupted

If a fault is cheapest to remove where it entered, then checkpoints belong inside the chain rather than at its end. In weekly planning the natural place is immediately after interpretation, because week state is the assumption the largest number of downstream links depend on and it is the one that can be put to the household in a sentence. Confirming that Thursday is busy costs one question. Discovering it after composition, critique, portion arithmetic, and a shopping list costs the run.

Approval at the end of a chain looks like oversight and rarely is. A person handed a finished plan sees the conclusion of nine links and none of the assumptions any of them relied on, so the only thing they can meaningfully approve is whether the output looks reasonable, which is the check the chain was supposed to have already performed. Oversight has to attach to the link whose consequence the person actually owns, which in the Meal Companion means purchase, medical interpretation, and durable preference rather than the plan as a whole.

A human placed at the end of an opaque workflow does not provide meaningful oversight.

Introduction to Thoughtware · Ch. 30

Closure is the last thing inheritance implies, and it changes what a checkpoint is for. While a link is open, what it hands forward is a verdict that could be wrong, so downstream work has to survive being wrong. Once a link has closed into code, as allergy enforcement does after the household confirms the restriction, what it hands forward is a guarantee, and the checkpoint that used to verify it becomes redundant. How decisions close traces that migration. Its consequence here is that a chain's checkpoints should thin out as the system ages, so a chain still carrying every one of them after two years is a sign that nothing in it has closed.

What to do next

The chain for one feature can be drawn in an afternoon, and the drawing is not the output. The output is two links the drawing identifies: the one whose failure would poison everything below it, which is where a checkpoint belongs, and the one whose failure stays local, which is where a bounded repair is worth building. A team that cannot name those two has a diagram rather than a chain.

The chain is also what makes leadership assignable, because a link is the smallest thing a person or a component can actually own. Who should lead each judgment allocates that ownership link by link, which is a question nobody can answer about a whole product.

Read next: Who should lead each judgment.