Where rules stop working

The first version of “avoid repetition” blocks dinners eaten in the last seven days. Then come exceptions: leftovers are fine, similar cuisines sometimes count, a demanding week changes the value of familiar food. Months later the feature has dozens of branches and no one can explain why the latest threshold is correct.

This is not a failure to write enough rules. A rule stops being adequate when the question changes with context, when several goals must be traded off, or when a wrong answer is costly to reverse. Beyond that boundary, each new branch preserves a case while leaving the underlying judgment unnamed.

Helpful context: What is judgment gives the operational test for the open work that remains. The ladder of cognitive work distinguishes recommendation from calculation, while open, closed, and closing turns the classification into a repeatable workflow.

Difficulty is not the issue

Tax calculation can be immensely complicated and still belong in code, because the rules determine one answer from the facts. A correct implementation agrees with another correct implementation, and a wrong result is demonstrably a bug.

The repetition feature fails for a different reason. “Is this meal too repetitive?” means something different on an exhausting Wednesday, after a holiday, or in a week with no time to cook. The branch list grows because the decision has no stable form for the branches to converge on.

Three conditions make rules brittle

Context breaks a rule when identical inputs carry different practical meaning. A ten-minute delay can be trivial for one traveller and intolerable for a family with tired children. The number stays the same; what matters does not.

Trade-offs break a rule when the team must exchange one good for another: variety against effort, freshness against preference, ambition against reliability. A threshold can record a trade-off that someone once made, but it cannot explain or revisit that trade-off when circumstances change.

Low reversibility changes the standard even for familiar decisions. A writing assistant can experiment and revise, whereas a system denying a claim or spending money cannot rely on the same tolerance for error. Consequence can therefore move a decision out of automatic rule territory on its own.

The boundary becomes clearer when the team compares what the condition asks the system to do.

Question in the product	Why a rule works or fails	Better home
Does this ingredient contain cashew?	The endorsed allergy and ingredient list settle the answer	Deterministic validation
How many portions are needed for four people?	The calculation has one intended result	Deterministic code
Is this dinner too close to what we ate last week?	Similarity depends on household tolerance, effort, and the rest of the week	Bounded judgment
Should the system buy these groceries now?	The decision changes money and authority, not only plan quality	Approval boundary

The table is not a hierarchy where rules are primitive and judgment is sophisticated. It is a placement device. Rules are better whenever the answer is closed enough to test exactly, and judgment is better when pretending the answer is closed would only hide the trade-off.

The code usually reports the problem first

Watch for branches added one complaint at a time, thresholds nobody can justify, and users saying the system “doesn't understand my case.” These are not merely product frustrations. They are evidence that a rule is standing in for interpretation or judgment.

The repair is not to discard rules. Preserve the closed part—dates, allergens, arithmetic—in deterministic code. Then name the open part, give it a standard and evaluation, and let the product ask or abstain when the case does not supply enough grounds.

Move the boundary without abandoning control

Promoting a rule to judgment does not mean replacing it with an unbounded prompt. It means separating the exact constraints from the trade-off they do not settle. The Meal Companion should always reject a confirmed allergen and always honour an ingredient deadline. Those checks create a safe field in which AssessMealPracticality can decide whether a candidate meal actually suits a difficult evening.

The cognitive unit then needs a contract: what inputs it may use, what verdict it returns, which grounds it exposes, and when it should abstain. Its evaluation cases should include ordinary successes and the edge cases that previously produced the branch chain. This turns each complaint into evidence for a bounded decision rather than another exception in a global rule.

It also permits a decision to close again. If repeated review establishes that a condition is genuinely stable—for example, a confirmed allergy or an explicit effort ceiling—the finding can be promoted into deterministic validation. How decisions close traces that movement. The point is not to maximize cognition, but to keep the boundary honest as knowledge improves.

Read incidents as design evidence

When users complain that the product “doesn't understand,” do not immediately translate that into a model-capability problem. First ask whether the feature was trying to answer a question whose meaning varies by situation. Then ask whether the complaint identifies a missing trade-off, a missing piece of endorsed knowledge, or an action whose consequences made the tolerance for error too low.

These questions change the repair. A missing fact may need a targeted question. A persistent trade-off may need a named judgment and grader. A high-consequence action may need human approval even if the underlying recommendation is excellent. Abstention as a result is important here: declining to force a rule across an underspecified case is often the most dependable behavior.

A rule can become a judgment, and back again

The boundary is not a referendum on rules. It is a way to keep the rule honest. When a decision contains a stable, explicit condition, move that condition into code and test it. When a condition keeps changing its meaning with the household, the surrounding week, or the consequence of failure, give the open part an owner and an evaluation rather than another exception.

This also means the boundary can move in the other direction. Repeated cases may reveal that a previously open distinction has become clear enough to encode. How decisions close follows that path. Good architecture therefore does not choose rules or cognition once. It continually places each part of the work where its evidence can support it.

Read next: Language is the abstraction above thinking explains why this kind of work must be made explicit in the words a team uses.