AI that follows the rules — and knows when not to

The recipe, and two demos that show it in practice

Most attempts to make an AI follow the rules pour the whole rulebook into it and hope it complies. It does not, and that can be measured. Here is a running demo built on the opposite principle: it looks up the single rule when it is needed, answers only when the source covers the question, and holds back or refers to a human when it does not. The goal is an AI that fails as little as possible, and predictably when it does. The way there is that it can say when it doesn't know, instead of guessing.

Try them

Two demos, one for each side of the recipe. Both run on open language models and are demonstrations of the research, not finished products.

• The compliance assistant (live) — the RAG side. A staff-handbook assistant: ask it about leave, data, sick pay. It answers only from the handbook, and if you ask something the handbook does not cover, it says so and points you onward instead of inventing an answer.
• The tutor demo (on the way, tutor.frictiontheory.org) — the fine-tune side. A tutor that is fine-tuned to scaffold you toward the answer without handing it over. The point: because the rule lives in the weights, it resists "just tell me" and "ignore your instructions", where a rule in the prompt would fold. That robustness is the whole reason to fine-tune.

The tutor is also the safe, public stand-in for a more sensitive field. The same architecture was built for a counselling-area conversation demonstration, but that one is deliberately not offered to the public: a public mental-health chatbot is, in substance, a regulated medical device under EU rules, and a disclaimer does not exempt it. The tutor is deliberately built with no grading, no scoring and no emotion recognition, the very things that would make an education AI a high-risk use under the AI Act. Finding those lines is itself part of the work: a responsible system also knows the limit on its own reach. Research access to the counselling architecture can be arranged.

The one idea: optimal, not perfect

Following a rule is an internal race between routes, like any other action. The rule's route has to win the races it should win and yield the ones it should yield. It can fail in two ways. It can ignore the rule under pressure, so the rule loses a race it should have won. Or it can follow the rule so rigidly that it refuses legitimate things and turns useless. An assistant tuned to "never break a rule" lands in the second ditch. The right place is the middle, where it follows the rule when it should and gives way when it should.

The same holds for holding back. A model that answers everything fabricates confident answers when the source is missing. A model trained to always hold back ends up withholding on what it actually knows. What works is the selective middle: answer what is covered, hold back on what is not. That is what the demos try to hit.

The recipe: how to build a maximally compliant AI system

This is the most reliable compliance you can build, and it rests on one architectural choice. Compliance is behaviour, not information, so you install the behaviour and look the rules up, instead of pouring the whole rule-set into either the prompt or the weights.

The one choice, in short

• Fine-tune the behaviour in. (To fine-tune is to retrain the model on examples.) This is how the system acts: check the source before answering, flag doubt, abstain when it can't, refer to a human. Plus the few narrow rules that always apply and can be checked mechanically, like "redact every name" or "always answer in this format". This is exactly what fine-tuning is good at: installing a stable way of acting.
• Do NOT fine-tune the knowledge or the rule-set in — the specific facts, policies, and conditional rules. Fine-tuning installs a disposition, not a database, and it masks rather than stores individual facts. Put those in RAG instead (retrieval-augmented generation: the rule is fetched into context one at a time, at the moment it is needed).

The rule of thumb: behaviour → fine-tune. Knowledge and rules → look up (RAG).

Behaviour, rule, or knowledge? And where the line falls

What decides it is whether the answer depends on the situation. It is not about what you call it. Four types on a sliding scale:

• Instruction / behaviour (how the system acts, always) → fine-tune. E.g. "check the source before answering", "flag doubt", "refer rather than guess".
• Closed rule (deterministic — the same every time, no judgement) → fine-tune. E.g. "always redact names", "always answer in this format".
• Open rule (conditional — depends on the case, needs judgement) → RAG. E.g. "data is kept 5 years in DK, 7 in DE", "escalate if self-harm is mentioned".
• Knowledge (the facts themselves) → RAG. E.g. "leave is 25 days", "the DPO is Jane".

Yes, the transition is a gradient, and the clean test is two questions. Does it apply the same way every time, regardless of the case? Then fine-tune it in. Does the right answer change with the situation or the facts, and do you need to see which one applied? Then look it up. The boundary case shows it: "always redact names" fine-tunes fine, because it is deterministic, while "redact names except when the requester is the person themselves" is conditional and belongs in RAG. Same topic, each side of the line, because one needs judgement and the other does not.

Step by step

• 1. Write the behaviour as training data, not the rulebook. Examples of the disposition itself: check-then-answer, flag doubt, abstain or refer. Keep the response style short; a verbose, many-section template can collapse the model's general ability at scale.
• 2. Fine-tune that disposition into a small open model (the demo uses Qwen2.5-7B). Deep enough to resist casual override and jailbreak, shallow enough to stay governable. That is "optimal, not perfect" at the rule layer itself.
• 3. Put every rule and every fact in a retrievable source (RAG), and store each rule in many wordings, so it fires whatever way the user phrases it.
• 4. Add a coverage gate. Build in a check that lets the system answer only when a retrieved source actually covers the question, and makes it abstain or refer otherwise. Without it, a gap in coverage becomes a confident fabrication rather than an "I don't know".
• 5. Add one reframe round. If the user's everyday wording misses the rule's terms, reformulate the question, search again, and show that you did, before giving up.
• 6. Make the safety rules deterministic. On crisis or hard stops, the system delivers the fixed response without improvising.
• 7. Audit everything. Because it is software end to end, you can check every rule against every conversation, down to the individual answer. That is the compliance advantage a human advisor cannot match.

Is this the right architecture for you?

Choose it when you want maximum reliable compliance with a fixed rule-set and a clear view of where it is about to break a rule; when the rules change (RAG updates without retraining); and when a confident wrong answer is costly. Watch two things. It is optimal, not perfect: it will sometimes abstain on something it could have answered, and that is the safe trade. And the choice of base model matters: a standard chat model cannot easily be made to respond differently depending on how far it trusts the user, so choose the model deliberately.

The research behind it

The demos build on a set of findings about how language models work inside:

• Compliance is behaviour, not information — why a rule buried among many stops working, and why the rule should be looked up rather than trained in.
• Fine-tuning installs dispositions, not data — what training actually puts in: a way of answering, not a register of facts.
• ICL as working memory, FT as long-term memory — why knowledge in context stays calibrated, while knowledge trained into the weights loses its calibration.

A full paper on the architecture is in preparation.