Deterministic guards before cognition

Not every case should reach every cognitive unit. Closed decisions belong in code and should run first. That is reliability discipline and it is how two budgets (cost and time) stay attached to genuinely open work rather than paying for comparison operators dressed as inference.

Without guards, every request pays for every cognitive unit on the full population. Cost and latency follow volume you never chose. The cognitive unit nobody discusses in standup often dominates the bill because it runs on every case while prestige judges get the tuning budget. A system that routes everything through cognition before checking whether the request is even well-formed has confused capability with placement.

Helpful context: Deterministic code owns exact work. Two budgets frame money and latency constraints. Cost per decision prices edges after guards shrink population. This page is the pattern note connecting closed-work discipline to economics.

Population reduction

Guards shrink the population that reaches expensive judgment. Volume is highest at the front of a funnel where work is comparatively mechanical. Each guard stage produces a measurable clearance rate: some percentage of cases that never proceed to the next expense. Residual volume after all guards is the true input to open cognition.

Stage	Typical work	Architecture role
Front	Schema, permissions, hard thresholds	Deterministic guards
Middle	Comparison, classification at edges	Named cognitive units, often mid-tier models
Back	Consequential judgment	Measured cognitive unit, wrappers if consequence justifies

In the Meal Companion, rejecting malformed plan JSON before any judge cognitive unit runs, or short-circuiting on confirmed cashew allergy before candidate generation, are guards. They are not judgments dressed as prompts. They are exact operations with defined inputs, defined outputs, and zero-token cost.

1. 01Schema and permissionsExact front guards
2. 02Hard thresholdsAuto-clear closed cases
3. 03Named open judgmentsRun on the remainder only

Each stage shrinks the population before the next expense.

Exact before fuzzy

Guards are not a substitute for open judgment. They remove work that should never have been fuzzy in the first place. Allergy exclusion once endorsed, permission denial, and arithmetic thresholds are exact. Leaving them inside a cognitive unit spends money and reliability to reproduce a rule you already know. The spend is visible on the cost per decision spreadsheet as a line item that should read zero but does not.

Closed decisions belong in code and should run first.

The cognitive unit, Ch. 12

Teams sometimes resist guards because moving checks to code feels less "AI-native." The resistance confuses capability with placement. Models can check allergies. That does not mean allergy checks should live in GenerateCandidates. A model that can do arithmetic does not mean arithmetic belongs in a template. The placement question is architectural, not about what the model can handle.

Designing the funnel

The funnel is designed rather than discovered in the provider bill six months later. Naming makes guards findable: amount thresholds before tolerance negotiation, schema validity before extraction, permission denial before recommendation. Each check has a defined position and a measurable clearance rate that proves population shrink.

The sequence for one funnel starts with listing closed checks that must never be fuzzy for this path. Those checks move into deterministic code before the first expensive cognitive unit. Clearance rate and residual volume per stage become the metrics that prove the funnel works. Wrappers and reliability spend then concentrate only on the open remainder where consequence justifies them.

Feature cost versus decision cost shows whether guard improvements dwarf token shaving on a rare prestige edge. Usually they do, because guards operate on the highest-volume portion of the funnel while prestige tuning operates on the tail.

What this looks like in the household planner

A household submits a weekly plan request. Before GenerateCandidates runs, four checks complete in milliseconds at zero token cost. The schema guard confirms request JSON is valid, required fields are present, and the household identifier resolves. The allergy guard applies confirmed allergens from endorsed knowledge so no candidate may include cashew if Leena's allergy is on record. The permission guard blocks purchase actions until a human approval node has recorded consent. The busy-evening flag classifies calendar gaps deterministically where rules exist, tagging the remainder for AssessMealPracticality.

Only the residual case set reaches a cognitive unit for busy-evening fit, variety, and local repair. AssessMealPracticality runs on evenings that passed guards, not on cases already settled or malformed. The population shrink is measurable: if forty percent of evenings clear through deterministic classification, forty percent of candidate generation cost disappears without any model change.

Measuring before and after tells the full story: calls to GenerateCandidates per accepted plan, median latency to first usable plan, allergy violation rate. Guard placement should move all three numbers in the same direction.

Guards and evaluation

Exact guards belong in the exact lane of evaluation as engineering. They pass one hundred percent on closed predicates or block release. Model graders on downstream open judgment do not substitute for skipped guards, because a grader that scores eighty-five percent on a question that has one correct answer is measuring the wrong thing.

When a guard fails open (allows a case that should have blocked), the failure is a bug with a deterministic fix, not a tuning problem. That distinction matters because it tells the team which tool to reach for: a code patch with a test, not a prompt edit with a regression hope.

Ordering matters

Guard order is architecture. Running an expensive embedding lookup before schema validation wastes both budgets on malformed input. Running permission denial after candidate generation wastes cognition on plans that cannot ship. The funnel design principle is cheapest exact checks first, population shrink at each stage, expensive open judgment last.

The Meal Companion places allergy enforcement before GenerateCandidates because generating candidates that will never surface saves nothing useful. The cost of a wasted generation call is small per case but multiplied across every evening of every household in every planning run, the volume makes misplacement expensive. Ordering is where economics and architecture intersect at the most granular level.

Guards are not prompts

A prompt instruction to "check allergies carefully" is closed work dressed as open judgment. It will fail open under pressure, drift with provider updates, and resist cognitive unit testing. The instruction looks like safety but behaves like a suggestion, because the model treats it as one more thing to consider rather than a hard gate.

Deterministic guards have tests, version control, and audit trails the same way payment authorization does. If the check cannot be written as code with defined inputs and outputs, the decision is not closed yet. That work stays in evaluated cognition until the closing checklist passes. But once the check can be written as code, leaving it in a template is paying for unreliability.

Measuring guard ROI

After placing guards, comparing three numbers over two weeks of production-shaped traffic reveals the return: total cognitive unit calls per accepted outcome, p95 latency to acceptance, and violation rate on exact predicates (allergy, permission). Guard ROI appears when calls and latency drop while violations stay at zero. If calls drop but violations rise, the guard is wrong or incomplete, not successful.

Sharing guard clearance rates in cost review means finance sees population shrink as a first-class savings mechanism, not an engineering detail hidden behind latency numbers. The savings are often larger than any per-call optimisation because they remove entire call chains rather than shaving tokens from individual templates.

Common guard mistakes

The most frequent mistake is placing a guard too late in the funnel. A permission check after plan generation wastes cognition on unshippable output. The system produced a plan the household will never see, burning both budgets on work that had a known blocker before it started.

A close second is implementing guards as prompt instructions. Closed work dressed as open judgment fails open under load because the model treats the instruction as advisory. When traffic spikes, the instruction competes with other context for attention, and the "guard" becomes probabilistic exactly when determinism matters most.

Teams that place guards without clearance metrics cannot prove population shrink after guard placement. The change feels productive but remains anecdotal. And guards without evaluation, where the exact predicate fails occasionally but gets treated as a tuning problem instead of a bug fix, erode the boundary between code and cognition that makes the economics work.

Relationship to closed work

Guards implement closed decisions at the funnel front. Every guard skipped is closed work left inside a cognitive unit downstream, paying tokens and latency on every case. The price of closed work left open quantifies that ongoing bill across the system's lifetime. Guard placement is often the fastest way to stop paying that price because it operates on the highest-volume paths where even small per-case savings compound into meaningful budget reduction.

Guard ownership matters in the same way cognitive unit ownership does. Guards without owners drift when schema changes or knowledge endorsement rules update. An allergy guard that passed six months ago may fail open after a new household profile shape ships unless someone owns regression on the exact lane. Assign one owner per guard funnel and include guard regression in the same review cadence as cognitive unit eval.

Staging guard experiments

Testing guard reordering in staging with production-shaped traffic before moving checks earlier in the funnel protects against two failure modes. A guard placed too early may block legitimate cases that should have reached cognition. A guard placed too late wastes cognition on cases that had deterministic answers. Staging experiments make the funnel design discussable with numbers: clearance rate, residual volume per stage, false positive rate on the guard, and cost delta on the path.

The allergy enforcement pattern before candidate generation serves as the reference guard for teams learning the design. It has the properties that make guards valuable: exact predicate, zero tokens, audit trail, evaluation at one hundred percent on the exact lane. Teams learning guard design benefit from implementing one reference pattern completely before spreading guards across the funnel, because the reference teaches the mechanics of measurement and ownership on a case everyone understands.

What to do next

Every closed part left inside a cognitive unit is reliable work made unreliable, paid for in money and latency. Auditing one production funnel for checks that currently run inside cognitive units but pass the closed checklist is the starting point. Moving one closed check to code with tests (not prompt edits) in a single sprint, then measuring residual volume per stage, makes the economics concrete. Pricing guarded versus unguarded edges with cost per decision reveals whether the investment justifies broader funnel redesign.

That ongoing price of closed work left in cognition is the subject of the price of closed work left open. See also deterministic code, open, closed, and closing, and two budgets.

Read next: Cost per decision.