Rules, Learning and Hybrid Systems

1Rules versus data

A behaviour can be implemented by writing the policy down or by fitting it from examples, and the two have opposite economics. A rule is cheap to build when the policy is known, free to run, and exactly right about its own policy forever — and helpless when the policy cannot be articulated.

Learning inverts every term: expensive to build well — data collection, labelling, evaluation — approximate by construction, and silently wrong when the world drifts. It is also the only option when nobody can write the mapping down, which is the situation for perception in general: spam, photographs, speech, fraud patterns.

The criterion is articulability. Published tax slabs, a legal transfer limit, an arithmetic consistency check: short, exact, stable policies — write them. What makes an email spam, which pixels make a cat: mappings with no finite statement — learn them from examples.

The trap runs in both directions. Learning an articulable policy buys approximation error, drift exposure and a monitoring bill, and delivers a worse version of a sentence you could have typed. Hand-writing an unarticulable policy grows a rule forest, one branch per edge case, until nobody can predict what the system does — the failure mode that ended classical expert systems.

The lab below makes the asymmetry concrete: on a policy that is literally one line of arithmetic, the written rule scores 100% by construction, while a fitted linear model given the very same rows lands near chance — equality is not a half-space, and no linear boundary can express it.

Figure. Accuracy on the 200-row form-validity task in the lab below (seed 0): the one-line rule is exact by construction, while a logistic regression trained on the same rows cannot represent the equality boundary and lands near chance. Measured by running the lab, not sketched — reproduce it below.

Coding lab. A rule versus a model on an articulable policy runs in the app, with checks on your output.

2Choosing the family: rule, search, or learn

Rules versus learning is really a three-way decision, because classical search is a distinct option: when you can write down the states, the legal moves and the goal — but not the solution — search computes the behaviour from the specification, with no examples and no hand-written policy.

The decision procedure asks about knowledge, in order. Can the policy itself be stated exactly? Write the rule. Can the problem be stated exactly, even though the policy cannot? Search or plan over it — route finding is the canonical case: nobody writes if-then rules for every junction and nothing is learned; the map plus an algorithm is the system.

Only when neither the policy nor a searchable model can be written does learning become necessary rather than fashionable — and then its preconditions bite: representative examples, in quantity, with labels you trust, and an evaluation you will keep running for the life of the system.

Necessary-versus-fashionable is a production distinction, not a style point. A learned component you did not need is not a neutral extravagance; it is an unarticulable dependency in the middle of your stack — undebuggable by reading, retrained on a schedule, monitored forever. Mature AI teams keep boring rules exactly where boring rules suffice.

Figure. Three questions in order, each about what you can write down: the policy itself (rule), the problem's states and moves (search), or neither but examples exist (learn). Falling off the end means the task, not the method, needs work.

The three questions, in order

1. State the policyTry to write it in a paragraph. If you can, a model would only ever approximate your own sentence — write the rule.
2. State the problemIf states, moves and goal are writable, search computes the behaviour from the specification. No data needed.
3. Count your examplesLearning needs representative labelled data and a permanent evaluation. Without both, reframe the task instead.

3Hybrid systems: layering the families

Production systems rarely pick one family; they layer them. The standard stack runs perception by learning — because no rule reads pixels or free text — and constraint enforcement by rules, because a constraint that must never bend cannot be entrusted to a component that is approximate by construction.

The payments example carries the whole idea. A fitted model scores every transaction's fraud risk; thresholds route the ambiguous middle to human review; and a deterministic rule blocks any transfer above the legal limit no matter what the model thinks. The model is an opinion, the rule is law, and the design is knowing which is which.

Modern agent stacks are the same architecture at a different scale: a language model proposes, and around it sit allow-lists for which tools it may call, schema validation on what it emits, spend and rate limits, and irreversibility gates that route side-effect actions through confirmation. The model's competence does not change the need for the cage — the cage is what makes the competence deployable.

The layering discipline in one sentence: hard constraints at the bottom (nothing passes), learned judgment in the middle (ranks and scores), policy thresholds on top deciding what the scores mean operationally. Signals flow up through the stack; authority flows down.

Figure. Signals flow left to right: the learned layer turns raw input into a score, the threshold turns the score into a proposed action (routing the ambiguous middle to review), and the hard rule gate — the highlighted layer — lets the action through only if every invariant holds, whatever the score said.

4Failure ownership and the operating point

A hybrid stack is only as debuggable as its ownership map: every failure the system can produce must have exactly one layer that owns it, decided at design time — because during an incident, 'the system was wrong' is not an actionable sentence.

Ownership follows the layering. A fraud that sailed through under the legal limit with a low score is the model's failure: bad judgment. A transfer above the legal limit that executed is the rule layer's failure — a broken invariant — even if the model also scored it low, because the limit was never supposed to depend on the score. A flood of legitimate transactions sent to review is a threshold failure: a bad operating point, with a model doing exactly its job behind it.

Error costs are asymmetric, and the operating point is a business decision expressed as a threshold: a missed fraud costs the loss; a false alarm costs a review. Choosing the threshold is therefore arithmetic, not taste — the worked example runs it, and the answer is not the threshold that looks tidier on a dashboard.

The incident habit that follows: when behaviour changes, first ask which layer changed. Models drift with the world, thresholds get retuned, rules get edited in code review — three different diffs, three different owners, three different fixes.

Figure. Total cost of each operating point from the worked example, split into review cost and missed-fraud cost. The strict threshold buys fewer reviews at the price of 40 missed frauds, and the asymmetric costs (Rs 50 versus Rs 5,000) make that trade lose by Rs 128,700.

5Guardrails: verifiable constraints around models

A guardrail is a hard constraint wrapped around a learned component: an invariant checked deterministically on the way in or the way out, regardless of what the model believes. Input schema validation, output format checks, allow-listed actions, spend ceilings, rate limits, irreversibility gates — mechanically diverse, logically identical.

The property that makes a guardrail a guardrail is verifiability: you can read it, test it exhaustively or prove it, and its failure is reproducible from its inputs. A learned safety classifier does not have that property — it is another model, with another distribution it was measured on. Useful and widely deployed, but categorically a scorer, not a guarantee; treating statistical protection as an invariant is the category error this concept exists to kill.

Guardrails sit at the actuator edge by design — between decision and side effect — because that is the last point where a bad decision is still recoverable. The tool-using agent lesson drew those edges; this concept is what lives on them.

The lab below is the pattern at its smallest: a scoring function proposes, a three-line gate disposes, and the transfer above the legal limit is blocked even when the score says it looks fine. Write the gate so the final test passes.

On the hybrid-stack figure, this concept is the highlighted gate sitting on the action edge: everything upstream — model, thresholds — may only propose; the gate alone disposes.

Coding lab. A hard gate over a soft score runs in the app, with checks on your output.

6How each family rots

Rules and models both rot, and they rot differently; the total cost of ownership, not the build cost, is what actually decides the family for a long-lived system.

A rule breaks loudly and cheaply. The policy changes — a new tax slab, a raised limit — the rule is now visibly wrong, someone edits a line, and the fix ships through ordinary code review. Its failure is legible, and its maintenance is event-driven: zero cost until the policy moves.

A model breaks silently and expensively. The world drifts away from the training distribution, accuracy decays with no error message, and the fix is a pipeline — re-collect, re-label, re-train, re-evaluate, re-deploy — that must already exist on the day you need it. Its maintenance is continuous: monitoring is not overhead but the only instrument that can observe the failure at all.

Search rots through its model of the world: the map says the road exists, the road is closed, and plans fail in execution rather than in planning. The fix is neither a code edit nor a retrain — it is reconciling the model with reality, which is its own pipeline.

This asymmetry is why the decision procedure defaults to rules and search, and why 'we replaced the rules with a model' should always trigger a budget question: you traded event-driven maintenance for continuous maintenance, and the trade pays only where the rule genuinely could not be written.

The picture worth holding, described rather than drawn because its values would be invented: a rule's correctness over time is a step function — flat until the policy changes, then visibly broken; a model's is a slow slide that only a monitor can see. When the drop happens is unknowable in advance; that it is a step versus a slide is the whole point.