Hard rules and soft constraints

The product spec says: "Respect allergies and keep Tuesday light." One sentence, and the two halves of it are made of different material.

Ship it as a single prompt and a capable model will honour neither dependably. The allergy never reaches deterministic enforcement, so a fluent violation remains available on any run. The practicality trade-off never acquires an owner or a suite, so nobody can say whether Tuesday fit is improving. When either one breaks, the diagnosis available to the team is that the AI was wrong.

The instinct most teams reach for is importance, and it fails immediately. Ranked by importance the allergy comes first and Tuesday becomes a nice-to-have, yet a plan that satisfies every allergy and no preference is a plan the household will not use. The question that actually separates the two is what may legitimately happen when the requirement loses. A hard rule may never lose. A soft constraint has to be able to, because a goal that cannot yield to another goal was never a constraint in the first place.

Helpful context: Open, closed, and closing sorts decisions by kind, and this page sorts the requirements that describe them. Closed decisions belong in code covers what happens to a rule once it qualifies for deterministic enforcement. The Weekly Meal Companion, the household dinner planner from the books, runs throughout. Most decisions are several decisions (next in this track) takes the same spec sentence apart link by link.

Importance is not the difference

Ranking requirements by importance produces one ordered list, and a list is the wrong shape for the problem. A ranking answers which requirement wins when two of them conflict, which is a useful thing to know about variety and effort and a meaningless thing to say about an allergy, because the allergy does not enter the competition at all. The two requirements differ in kind, and a difference in kind cannot be expressed as a difference in position.

Collapsing the kinds fails in both directions, and the two failures look nothing like each other. A hard rule filed as a strong preference acquires a tone of politeness and no enforcement anywhere: "try to avoid allergens" reads as considerate and ships as a suggestion the model weighs against everything else in its context. A soft constraint filed as a hard rule acquires a threshold instead, so "must keep Tuesday under twenty minutes" arrives written like a compliance clause and then collects exceptions for traybakes, for leftovers, for the week the spinach has to go, until nobody can say why the number was twenty.

Because the two failures need opposite repairs, the label has to be assigned before either requirement is built. That is why the rest of this page treats the two materials one at a time, since where each one is enforced and what a violation of it means have nothing in common.

What makes a hard rule hard

A rule is not hard because a requirements document said "must". It becomes hard when the fact behind it has been endorsed, meaning approved for use with a scope and a provenance rather than inferred from something a household member typed once, and knowledge is endorsed, not retrieved owns that mechanism. Before endorsement, "Leena has a confirmed cashew allergy" and "I think Leena reacted to something once" are the same kind of sentence to the system, and only one of them can support a refusal.

Once endorsed, the rule leaves cognition entirely, which is the placement closed decisions belong in code works out in full. What matters here is the behaviour that placement produces. Enforcement runs before any candidate plan is shown rather than as a review afterwards, and the check is never weighed against how confident the model feels about a particular ingredient, because an exception purchasable with confidence is not a rule.

The model's confidence cannot bypass the threshold.

Introduction to Thoughtware · Ch. 21

In conduct, that hardness shows up as licensed refusal. Under cognitive posture the system declines a request that would violate a hard rule and says so plainly, rather than returning a softened plan that technically complies. Ambiguity in the rule itself is the case that catches teams out: a reported reaction nobody confirmed is not a weaker allergy, it is a missing endorsement, so the honest response is to report the restriction as unconfirmed and ask the household to settle it rather than closing the gap by inference.

Authority takes the same shape, which is what shows that hard rules are wider than safety. Grocery purchase requiring approval is a hard rule about who may act rather than a strongly held preference about caution, and no amount of competence at assembling shopping lists converts spending authority into a parameter the system may weigh. Authority is granted develops why capability never supplies permission.

What makes a soft constraint soft

A soft constraint is a goal held against other goals, so how far it is satisfied is always relative to what else the week is demanding. Variety pulls against effort, and clearing the vegetables that will spoil pulls against what people will actually enjoy eating midweek. Neither pair has a fixed rate of exchange, which is why a soft constraint cannot be satisfied absolutely and can only be traded well or badly. Code can hold a trade-off only by freezing the rate in advance, and where rules stop working follows what happens to a threshold set that way.

Because there is no fixed rate to enforce, the constraint needs somewhere its answers can be graded rather than somewhere they can be checked. AssessMealPracticality owns busy-evening fit, which gives the trade-off an address, a suite of scenarios, and a version. That is what makes a defensible loss distinguishable from a defect: mushroom dislike losing to a week where the only sensible use of what is already in the fridge is a risotto is correct behaviour, and the suite is how anyone can tell.

The constraint also needs a route for corrections, or it decays into a guess the system makes fresh each week. When the household rejects Tuesday's suggestion as too heavy, that correction attaches to the component that owns the judgment. If it lands in chat history instead, it influenced exactly one run, and the household experiences a product that has to be told the same thing every Sunday.

All of which produces a different conduct. A soft constraint licenses challenge rather than refusal, so the system may point out that this week's constraints are jointly impractical and propose which one to relax, and that is the behaviour separating a collaborator from a component that silently picks. Violation handling follows: an allergy breach is blocked, refused, and recorded with nothing to negotiate, while a heavy Tuesday is critiqued, substituted, or asked about, and the household may accept it when the week leaves no better option. Treating both as preferences the model respects removes the only behaviour that keeps hard rules hard.

What this looks like in practice

"Respect allergies and keep Tuesday light" becomes two entries with different homes, different enforcement positions, and different evidence that they are working.

Link in the work	Kind	Where it is enforced	What a violation is
Identify confirmed allergies	Hard once endorsed	Deterministic validation, before candidates exist	A blocked plan and an audit entry
Judge whether a meal suits a busy evening	Soft	AssessMealPracticality, with household corrections	A graded miss in the suite

Position is where the translation usually fails, because a hard rule enforced late is decoration. An allergy check that runs once the week has already been written out has allowed the offending plan to exist, and a spending gate that opens after the cart is on screen presents the purchase as settled. Soft constraints have no equivalent deadline, since their output is a graded judgment rather than a gate, and that difference in timing is a direct consequence of the difference in kind.

The spec sentence also carries something that is neither material, and that is the label teams most often get wrong. "Tuesday is busy this week" is true for this run and expires with it, where "busy evenings stay under twenty-five minutes of active effort" is endorsed knowledge about every busy evening. Promoting the first into the second without an explicit act is how a system accumulates beliefs the household never confirmed, and trust breaks at the moment behaviour depends on one of them.

One sentence is rarely only two entries, either. The originating household request carries hard rules, soft constraints, and run context together, and most decisions are several decisions walks that request through the monolithic version and the separated one. What this page contributes to the exercise is the labels, because a request cannot be cut into components until somebody has said which parts are allowed to lose.

Traffic runs one way

A soft constraint that returns the same verdict across hundreds of weeks has begun to close. The twenty-five-minute limit on active effort started as a preference, stabilised under household correction, was endorsed as knowledge, and now sits in code as a check, which is the lifecycle how decisions close traces. The constraint changed material rather than changing importance, and it was evidence that moved it.

Nothing travels the other way. An allergy does not earn demotion to a preference because the household grew tired of refusals, and an approval gate does not soften because approval is inconvenient. Hard rules do change, and they change by re-endorsement rather than by erosion: a household can retire a restriction that turned out not to be real, which is a governance act with a record attached, and it is a different thing from a threshold quietly relaxed because override requests kept arriving.

That asymmetry is what keeps hard rules hard in operation rather than only in the document. A system that can be argued into an exception has soft constraints throughout, whatever its specification calls them, and the household finds out which kind it bought on the one week it matters most.

What to do next

The useful test on an existing requirement is not how important it is but what the honest behaviour would be on the week it cannot be satisfied. If the answer is a refusal with an explanation, the requirement is hard, and the trace has to run to an endorsed fact and an enforcement point ahead of the work it constrains. If the answer is a worse plan the household might reasonably accept, it is soft, and it needs a named owner, a suite of scenarios, and a place for corrections to land.

A third answer shows up often enough to be worth naming. If the honest behaviour depends on which household member is asking, the requirement has not been decided at all, so it is neither material and belongs with whoever holds the authority to settle it, as contested decisions develops. Sorting a spec into those three answers is the work that makes the next step possible, which is cutting the request itself apart.

Read next: Most decisions are several decisions.