Build the Operator, Keep the Operands as Data

“Give me a lever long enough and a fulcrum on which to place it, and I shall move the world.” — Archimedes

A good rule set grows. Mine has grown — tested against a whole corpus of real PRs and code — into something too big to hand a model all at once, and that’s the scale problem Rules Are the Alpha ends on. You’ve got a real asset, and it’s outgrown the context window. Now what?

Two obvious answers are both wrong. Cram every rule into the prompt and the model’s attention smears across all of them — lost in the middle, more rules and quietly worse reviews (A Big Rule Set Is an Attention Problem). Bake the rules into the model instead and you can’t edit one without a retrain: your standards go stale between training runs, and a standard you can’t cheaply change isn’t a living standard. Neither the all-in-context nor the all-in-weights answer works at scale.

The way out is to stop treating the rules and the skill of applying them as the same thing. Train the operator — the verb — into the weights; keep the operands — the rules — as editable data.

Bottom line up front

• Train the verb, not the noun. Put the skill of applying a rule (read it, check it against the code, try to refute yourself, return a verdict) into the weights. Keep the rules themselves as data.
• A new rule is a text edit, not a retrain. The operator is trained once; the operands swap freely. Your standard stays editable.
• It’s the synthesis between the linter and the AI reviewer — the linter is all rules and no judgment; the AI reviewer is all judgment and no explicit rules. This is explicit rules applied with judgment.
• Each rule sits somewhere on an interpret → JIT → compile spectrum — placed by mechanisability × commonality × judgment-need (my placement policy).
• It generalises past review — decision-fork triggers, editable-rubric evals, voice profiles, per-customer rules. Anywhere you want a stable skill over swappable data.
• Designed, not built. The trained operator doesn’t exist yet; this is the architecture and the argument for it, leaning on instruction-tuning as prior art. Flagged throughout.

The operator and the operands

Borrow the framing from programming. An operator is the fixed thing that does the work — +, map, a function. The operands are what you feed it. You don’t rewrite map every time you have a new list; you write it once and pass different data.

A rule-applying reviewer has the same shape, and today most systems collapse it into one blob — the rules and the applying are tangled together in a prompt, or tangled together in a fine-tune. Pull them apart:

• The operator is the skill: given a rule and a diff, apply the rule, look for the exception, try to refute your own finding, and return a verdict with a reason. That skill is the same whether the rule is about async handling or naming or exhaustiveness. It’s a verb, and it generalises.
• The operands are the rules: the target, the exceptions, the examples, the why. Data. Different every time.

Train the operator into the weights and the wager is it applies rules well. Keep the operands as data and you edit your standard with a text change. New rule tomorrow: add the data, don’t retrain the skill.

Why this beats the two blobs

The all-in-context blob spends the model’s scarce attention re-reading the whole rulebook every call, and smears it. The all-in-weights blob is fast and attention-free but frozen — editing a rule means a training run. The operator/operands split takes the good half of each: the skill lives in the weights (fast, no context cost, and it doesn’t need re-teaching), while the rules stay in data (editable, inspectable, versioned). You retrain when your notion of how to review changes — rarely — not when a rule changes — constantly. These are the intended properties, not measured ones: the training frequency, the inference savings, and the held-out-rule gains are all designed, not yet shown.

The test that this is real is easy to get wrong. “Hand it a rule it never saw and check it applies it” isn’t the test — a base model with the rule pasted into its prompt already does that; that’s plain in-context learning, and it proves nothing about training. The real held-out-rule eval is comparative: does the trained operator apply-and-refute a held-out rule better or cheaper than the base model with that same rule in the prompt? If training buys nothing over pasting the rule in context, you haven’t built an operator — you’ve just moved the rule around. That delta is the whole claim, it’s the same shape as instruction tuning (fine-tune on many instructions, generalise to unseen ones), and it’s the eval I haven’t run.

The spectrum underneath

Not every operand wants to live in the same place. Each rule sits on a spectrum from the linter to the LLM, placed by three axes I use — how mechanisable it is, how common, how much judgment it needs (this placement policy is my call, not a measured optimum):

• Interpret — the model applies the rule from context. For rare, volatile, judgment-heavy rules. Flexible, editable, expensive per call. This is the default: operands stay data.
• JIT to weights (opt-in) — for a very common, very stable rule you can deliberately bake it into the operator on a training run. This is a compilation step, like AOT-compiling a hot path: the rule drops out of context, but it stops being editable data and becomes a frozen operand again — baked into the weights until you retrain. You trade editability for speed and accept the freeze, with explicit invalidation: when that rule changes, you retrain. It’s a second freezing you choose for the stable tail, not the operator absorbing operands automatically.
• Compile to a detector — fully mechanisable rules become deterministic code (a lint, an AST check). No model in the loop, exact.

The interpret and compile ends are A Big Rule Set’s territory (keep judgment rules in context, compile the mechanisable ones out to detectors). What the operator adds is the middle: a very common, stable rule can be opted into the weights themselves, so it drops out of context without becoming a separate detector — at the cost of re-freezing that one operand until the next retrain. That’s the exception, not the default: operands stay data unless a rule is stable enough that you’ll rarely want to edit it, and only then do you compile it in. The operator is the constant; most operands stay data; where each one lives is the tuning.

The JIT direction is already visible in the wild. Anthropic cut about 80% of Claude Code’s system prompt for their newer Fable 5 models — a more capable model needs fewer instructions spelled out, because the common guidance is effectively already in its weights (the-decoder, 2026). That’s the general-capability version of the move; the operator does it deliberately, one stable rule at a time. And the deliberate version has been measured: experience distillation bakes an agent’s in-context trial-and-error into the weights and keeps most of the gain — retaining about 65% of the in-context lift where plain fine-tuning kept under 4%, and matching reinforcement learning with roughly 10× fewer environment samples, on software-engineering tasks among others (Gou et al., 2026). Read the other way, it’s the more useful half: the weaker or cheaper the model, the more an explicit rulebook buys you — rules are how a cheaper model makes up ground on a stronger one, spelling out what the stronger model already carries. So how much you JIT tracks the model you run: a strong model lets you drop rules into its weights; a cheaper one earns its keep precisely because the rules stay explicit.

It’s a general move

“Train the verb, keep the noun as data” isn’t only about code review. The same split shows up wherever you want a stable skill applied to changing specifications — though the cases below are my extrapolations from the review case, not separate results:

• Decision triggers — the skill of noticing a decision fork is the operator; the specific triggers are operands.
• Editable-rubric evals — the grading skill is the operator; the rubric is data you tune without retraining the grader.
• Voice matching — the matching skill is the operator; a person’s voice profile is the operand.
• Per-customer rules — one trained operator, a different rulebook per tenant.

In each, the failure mode is the same: bake the specification into the skill and you can’t change it without rebuilding the skill. Keep it as data and you can.

A wrinkle: the split leaks (a design hypothesis)

The clean story — train the operator, keep the rules as swappable data — has a seam. A model trained to apply rules bakes in some of the specific rules it trained on, and you can’t surgically evict them; swapping the rulebook at inference doesn’t fully change behaviour. This isn’t new: it’s the knowledge-conflict result — a model is sometimes a “stubborn sloth” that clings to its weights over the context — and the finding that heavily fine-tuned models resist a contradicting system prompt. State it conditionally: a known-possible outcome, not a law.

What decides which way it goes is dose. Train light and the model stays steerable — a new rule in context wins. Train hard and the baked rule resists. That gives “stable earns compilation” its mechanism: hard training trades adaptability for capability, so you compile only the rules that won’t move and keep the volatile ones as data.

And it tells you when to re-compile: not when the rule text changes, and not on every corpus update — but when a diff-eval shows the baked model no longer matches. Generate that eval from where the old and new rules disagree on the corpus — differential testing, run only on what changed — not from the whole new rule set. (The gate is only as good as what it probes — see Evals Aren’t the Moat and You Can’t Grade Your Own Misses.)

How sure: designed, with a bounded pilot. A laptop LoRA run (Qwen2.5-1.5B-Instruct-4bit, 3 seeds per dose, 20 held-out items) showed it directly for surface-form constraints — a trained uppercase or AAA-prefix policy overrode a contradicting prompt on 80–100% of responses once training reached the sampled 30-iteration dose, while the untrained model followed the prompt every time; so the onset sits somewhere in (10, 30] iterations. That is persistence for crisp formatting constraints only. The semantic version was inconclusive — the small model generalised the competing keyword rules by gist, so the trained and prompted rules never cleanly separated. The leak is measured for the surface-form layer; for semantic rules it stays open.

What you keep

The rules are the asset; the operator is what makes them cheap to run and cheap to change. Train the skill of applying-and-refuting once; keep the rules as editable, inspectable data; place each on the spectrum where it costs least. You get a living standard applied with judgment — not a frozen model, and not a prompt drowning in its own rulebook.

---

How sure I am: this is designed, not built — I have not trained the operator, run the held-out-rule eval, or measured any of it. The lived parts are the asset it assumes (a large rule portfolio tested against a corpus of real PRs and code; a mechanical-detector tier that already runs) and the scale problem that motivates it. Everything about the trained operator — that instruction-tuning-style training yields a skill that applies unseen rules — is a reasoned bet on established prior art (instruction tuning, and a measured context-to-weights result in Gou et al.), not a result I’ve produced for this operator. Treat the whole architecture as a proposal with a clear test attached, not a report.

Sources

• Wei et al., Finetuned Language Models Are Zero-Shot Learners (FLAN, 2021, arXiv:2109.01652) — fine-tune on diverse instructions, generalise to unseen instruction types. This is the direct analogue, and it backs the analogy (generalising to unseen instructions) — not proof that this apply-and-refute skill transfers to unseen rules. The held-out-rule eval is the held-out-task test in this domain.
• the-decoder, “Anthropic says it cut 80 percent of Claude Code’s system prompt…” (2026) — reporting Anthropic’s Tariq Shihipar: newer Fable 5 models need fewer instructions and examples. Cited as a real-world instance of the JIT direction (a capable model holds common guidance, so it drops from context); framing it as the JIT-to-weights tier, and the “writing for a weaker model” corollary, are mine.
• Gou, Tu, Fang, Cai & Rezatofighi, Sample-Efficient Learning from Agent Experience (2026, arXiv:2607.21051) — “experience distillation” internalises an agent’s in-context experience into weights, retaining ≥64.8% of the in-context-learning gain (vs 3.8% for plain supervised fine-tuning) and matching RL with ≥9.6× fewer environment samples, on 749 software-engineering tasks plus text games. Measured backing that the context-to-weights (JIT) direction works and is sample-efficient — not proof about this specific apply-and-refute operator.
• Xie, Zhang, Li et al., Adaptive Chameleon or Stubborn Sloth: Revealing the Behavior of LLMs in Knowledge Conflicts (2023, arXiv:2305.13300; ICLR 2024) — under knowledge conflict, in-weights (parametric) knowledge can resist contradicting context (the “stubborn sloth”). Backs the leak as a known-possible outcome, not a law; the reading that a fine-tuned rule resists a contradicting prompt the same way is my extension — a bounded laptop pilot has now shown it for surface-form constraints, but left the semantic case open.
• Differential testing (McKeeman, 1998) and regression test selection (Rothermel & Harrold, 1996) — run two versions on the same inputs and diff; run only the tests the change touches. The prior art for the diff-eval re-compilation trigger.

---

Related: Rules Are the Alpha (the asset + the scale problem this answers); A Big Rule Set Is an Attention Problem (the all-in-context failure + the spectrum); Train on What the Gate Throws Away (where the operator’s training data comes from); Keep the Factory, Ship the Result (the operator + operands are the factory you keep).