The price of closed work left open

Closed work has a correct answer that does not require judgment: arithmetic, exact policy thresholds, schema validity, known exclusions. Put that work inside a cognitive unit and you have done something expensive twice over. You pay tokens and latency to reproduce a rule you already know. You add variance where exact execution was available. The system becomes less reliable and more expensive at the same time, which is a combination that should not survive naming.

Helpful context: Closed decisions belong in code states the rule. Mistakes both ways warns against pushing open judgment into brittle rules. Cost per decision makes the ongoing bill visible. Decision cost falls with history shows the ROI when closure happens. This page closes the Economics track by quantifying the waste when it does not.

That is simultaneously a reliability claim and an economic one. The Economics track began with two budgets. It ends here: closed work left open burns both budgets every run.

One compelling number

Paying per call to re-derive portion math every Meal Companion run produces a cost that is small per case and large over time. About $0.008 per ComposeWeek call times 2 iterations times 52 weeks equals about $0.83 per year for one household. At ten thousand households, that is about $8,300 per year on arithmetic a deterministic function would run once, correctly, for free.

Allergy exclusion left inside GenerateCandidates adds variance on top: the model might miss cashew once. The guard would not. Five years of probabilistic allergy checking becomes reliable work made unreliable at scale. The token cost is real but the trust cost compounds faster, because one violation after months of correct behaviour can collapse household confidence in the system's safety promises.

In code

Exact, fast, cheap at scale

In cognition

Variable, slow, paid per token

Closed work belongs in deterministic code unless the class is not yet closed.

Eval noise from faux judgment

When closed work stays inside a cognitive unit, teams evaluate fuzzy behaviour on exact questions. Suites show eighty-five percent on portion sizing. The correct response is "this should be code," not "tune the prompt." Eval effort goes to noise because the team is measuring something that has a known correct answer as though it were a matter of judgment.

The exact lane of evaluation as engineering reads one hundred percent or blocks release. Grader scores on work that should be deterministic confuse operators and hide the extraction win. A team that spends three sprints tuning a template to improve portion accuracy from eighty-five to ninety-two percent has invested engineering time in making cognition less bad at arithmetic rather than removing arithmetic from cognition entirely.

Spotting closed work still left in cognition is often the fastest economic win after naming.

The cognitive unit, Ch. 14

Fast win after naming

Once judgments have names, closed work becomes findable on the decision map from framing. The pattern is recognizable: evaluation at one hundred percent on a class that should be exact, or arithmetic failures with always-the-same-shape reasoning applied to different values. Extracting the rule into deterministic code while keeping the cognitive unit as fallback where needed produces a feature cost drop at the high-volume edge of the funnel, where money actually sits.

Leaving closed work unnamed keeps it invisible on the provider bill. The bill is real. The attribution is not. Feature cost versus decision cost exposes the line item once the map exists, which is why naming precedes optimization in the economics sequence.

Guards at the front

Deterministic guards before cognition stop paying the price on every case. Allergy exclusion, permission denial, and amount thresholds are exact. Leaving them inside a cognitive unit reproduces a rule you already know, more slowly and less reliably. The funnel design from deterministic guards is the operational fix. This page is the economic justification for doing it early rather than waiting until the bill is painful enough to motivate action.

Tie back to Decisions

The Decisions section named the sorting question: open versus closed versus closing. Economics makes the ongoing price of ignoring that sort visible. Mistakes both ways warns against pushing open judgment into brittle rules. The win is separation: closed work in code, open work in named cognitive units, closing classes over time so decision cost falls with history. Neither direction of error is costless, but the price of leaving closed work open is measurable in tokens while the price of premature closure is measurable in incidents.

Trust erosion has a cost

Variance on closed work teaches households the system might agree with itself tomorrow or might not. One missed allergy after months of correct plans can collapse trust faster than a year of creative variety delighted. The economic cost of trust erosion appears in churn, support load, and manual override rate even when token spend looks stable. Households that stop trusting the system's safety properties start checking every output manually, which means the product has externalized reliability cost to its users.

Closing work is therefore a retention investment alongside an inference optimization. The token line matters. The trust line matters more at scale because churn compounds while token cost is linear.

Organizational habit

Teams accustomed to prompt tuning resist extraction because prompts feel faster than pull requests. One sprint to move portion math into code pays back every week thereafter. Making extraction a standard outcome of eval review creates the habit: when exact lane hits one hundred percent on a class that should be exact, an extraction ticket opens before the next tuning meeting.

Pairing extraction wins in engineering review spreads the habit across teams. The fastest economic win after naming is often boring code replacing expensive cognition. The emotional resistance comes from a culture that values model interaction over deterministic correctness, but the economics do not share that preference.

What this looks like in practice

An audit of Meal Companion ComposeWeek before closure reveals the pattern. Portion math inside the template costs about $0.008 per call, 2 iterations, 52 weeks, 10 thousand households, producing about $8,300 per year in illustrative token spend on arithmetic. One deterministic function with tests carries engineering cost once and near-zero marginal cost with zero variance thereafter. Allergy inside GenerateCandidates produced rare violations with high trust cost. Moving it to a guard produced zero violations in six months of production.

Product review uses one comparison: five-year token cost of probabilistic arithmetic versus one sprint to close. The win does not require a new model. It requires an honest assessment of which edges carry closed work and what that work costs across the system's lifetime.

Clerk and household time

Closed work left open also wastes human time. Clerks re-check arithmetic the system should have enforced. Households manually verify portions after every plan because the product taught them not to trust math. Those minutes rarely appear on provider bills. They appear in support load and churn. When leadership asks for ROI on extraction, human minutes saved on high-volume exact predicates belong on the same page as token lines, because the combined cost is what the organisation actually pays.

Closing the Economics track

This page ends the Economics section that began with two budgets. The progression has moved through budgets, guards, per-edge prices, feature totals, wrapping, reliability spend, falling marginal cost, and now the price of leaving closed work open. The through-line is that once cognitive units have names, economics becomes arithmetic. And once economics is arithmetic, architectural decisions become arguable with evidence rather than with preference.

Building begins with framing: the decision map as primary artifact. Economics answered how much judgment costs and where spend belongs. Building asks where to start designing, and the answer is decisions before models, outcomes before features.

The extraction decision itself has economics

Moving open judgments into deterministic code has upfront cost: analysis, tests, migration, eval realignment. Leaving them open has ongoing cost: wrappers, incidents, and trust erosion. Pricing the closure decision explicitly in roadmaps means comparing incident frequency and decision cost before and after closure on the same terrain. Closed work still needs maintenance when policy changes, so budgeting that maintenance prevents closed rules from silently drifting back into fluent guesses when the underlying policy shifts.

What to do next

Running one audit to list checks inside cognitive units that pass the closed checklist from closed decisions belong in code reveals the extraction opportunities. Extracting one closed check to code with tests in a single sprint produces the first concrete savings. Recomputing cost per decision on the affected edge after guard placement confirms the return. Adding exact-lane eval that blocks promotion if closed work regresses into cognition prevents the habit from unwinding.

See deterministic guards, decision cost falls with history, and how decisions close.

Read next: Start from decisions, not from models opens the Building track.