Intelligence Over Rules

TL;DR: When a Hussh agent has been asked a question, a deterministic rule may inform its answer but may not replace it. Three failure shapes are named and forbidden: deciding instead of the model, discarding what it returned, and skipping it while reporting as though it ran.

Status as of 2026-09-11: see body.

Relations

• One ADK - the runtime this doctrine governs
• World Model - the store the structuring agents write into
• Engineering bar - the verification discipline this depends on

Status as of 2026-09-11: Adopted as a binding principle in the repository's operating kernel, with a long-form boundary reference and enforcing tests. Applied so far to the personal-knowledge structuring chain and the agent chat action path; older surfaces have not all been swept.

What it is

A specialist agent is expensive. Writing its instructions, constraining its output to a schema, calling it, and paying for the call are all costs already incurred by the time it answers. A deterministic rule that then overrules that answer does not save any of that cost. It only discards the result.

The rule this names is narrow and testable. Where a model has been asked, its answer stands. Where a rule encodes something the model should know, that knowledge belongs in the system instructions, not in a branch downstream of the call.

The point is not that rules are bad. It is that a rule placed after a model call is invisible: it changes the product's behaviour without changing anything a reader of the prompt would see, so the prompt can never be debugged against what the system actually does.

The three shapes

A boundary between a model and a rule gets crossed in exactly three ways. Naming them makes each one findable in review.

1. Decides instead. The rule computes its own answer and uses that, ignoring what the model said. The tell is a condition whose trigger is disagreement with the model, resolved in the rule's favour. A rule of that shape can never lose, so its error rate is unobservable.

2. Discards. The model is asked for a set of fields, returns them under a schema that rejects a response missing any, and the code then rebuilds those fields from something else. The tell is a required output field that no caller ever reads.

3. Skips. The stage is routed around entirely, and the result is reported in a shape indistinguishable from a stage that ran and answered. The tell is a fallback marker that reads the same whether the model failed or was never called.

The two exceptions

Both are narrow, and both must be stated at the point they apply rather than assumed.

1. The model failed. If the call errored, timed out, or returned nothing usable, a deterministic fallback is not substituting for a judgement. It is the only judgement that exists, and it is correct. What is not permitted is letting that fallback look identical to a successful answer.

2. A safety or integrity guard. A guard preventing an unrecoverable, one-directional loss sits outside this doctrine, the same way a security check does.

The working example is an explicit correction cue. When someone says "actually, I live in X now" and the model shrugs, the correction must still land, because a dropped correction leaves a person's own record wrong and nothing tells them it did not take.

Such a guard is legitimate only when all three hold:

• it prevents a loss that cannot be undone;
• it fires on an explicit signal rather than an interpretation;
• it records that it fired.

The obligation that makes it real

A rule that is suppressed must say so. A rule that wins silently and a rule that loses silently are equally unmeasurable, and the disagreement rate between the rule and the model is the only number that answers the question that actually matters: does the prompt need work, or has the rule earned its place back?

This is what converts the doctrine from a preference into an engineering loop. Every suppression is recorded. When the recorded rate for a given guard reaches zero, the guard can be deleted, because the instructions have absorbed it.

Why it matters, measured

The doctrine was not adopted on taste. It was adopted after a measurement: on one classification task, changing nothing but the wording of the instruction moved a desired behaviour from zero occurrences in ten trials to eight in ten, on identical input. The restrictive phrasing had been added to make the agent safer. What it actually did was suppress the behaviour entirely and route records into a neighbouring category, where they were harder to find and wrong.

The rule downstream of that call had been compensating for the prompt. Removing the rule without fixing the prompt would have been reckless; fixing the prompt made the rule unnecessary. That sequence, in that order, is the method.

What this is not

• It is not an argument for removing validation. Output still gets checked against its schema, and an invalid value is still refused.
• It is not an argument against determinism in general. Deterministic derivation from data the model never saw remains correct, and is often the only honest source, such as a description of a record after later processing steps have changed it.
• It does not apply to security controls. Those are not judgements and are not in scope.

Sources

• Repository operating kernel, principle on model and rule boundaries.
• Internal backend semantic-boundary reference, long form with the measured evidence.
• Enforcing test suites covering the structuring and intent stages.