Principle 01 7 min read

The model reads. Code decides.

Every AI product claims a philosophy. Most philosophies live in the marketing deck, which means they last exactly as long as the next deadline. This one lives somewhere harder to erase: in the type system of the code itself.

The principle is five words — the model reads, code decides — and it splits every review Scout performs into two territories. In the first, a language model does the one thing it’s genuinely better at than any software ever written: reading messy, scanned, inconsistent real-world documents and reporting what’s printed on them. In the second, ordinary program logic takes those reported facts and decides what they mean — does the amount financed exceed the approval, is the insurance dated before funding, does this loan pass or fail. The model is never in the second territory. Not discouraged from it. Not in it.

This article is about where exactly that border sits, how it’s enforced, and — because honesty is the point — where the model is allowed to get closest to it, and what fences it in there.


A border you can’t cross by accident

Rules that depend on developers remembering them get broken by developers in a hurry. So Scout doesn’t ask anyone to remember this one.

In the engine’s source, the model is quarantined behind its own interface — the code calls it the oracle, the one non-deterministic thing in the system. A step that needs the model must declare that need explicitly in its type; a pure computation step doesn’t, and the code’s own comment states the consequence: a compute step is “compiler-guaranteed unable to call it.” Not forbidden by policy. Unable. A developer who tried to sneak a model call into decision logic wouldn’t get a stern code review — they’d get a program that doesn’t compile.

Look at the list of operations a review program can invoke and the border is visible in the roster itself. Three operations involve the model, and all three are forms of reading: extract printed values, transcribe or summarize, gather documents. Everything else — evaluating rules, doing arithmetic, parsing dates, assembling reports, writing results — is deterministic code, incapable of consulting the model even if it wanted to.

What “deciding” looks like without a model

So what actually happens in the deciding territory? Plain, inspectable, slightly boring code — boring in the way a vault door is boring.

A real Scout review recipe for a lender’s funding checklist contains a function about seventy lines long that renders every verdict on the loan. It reads like policy, because it is policy: if the amount at this line is zero, pass; if it’s a readable number that isn’t zero, fail, and print the amount; if the trade-in year doesn’t precede the loan year, fail. No model is consulted anywhere in those seventy lines. The report it produces ends with a sentence generated by an if statement, not an opinion: “required checks failing — do not fund.”

The arithmetic underneath is done the pedantic, correct way. Dollar amounts are converted to whole cents and handled as integers, because the code’s authors noticed what every bank programmer eventually notices — that 0.29 × 100 on a computer is not quite 29, and a compliance check that drifts by a cent has already lost the argument. Dates are parsed into a canonical form before any comparison, because “04/02/2026” and “April 2, 2026” are the same day and a string comparison doesn’t know that. Account numbers, VINs, and Social Security numbers are never treated as numbers at all, because leading zeros are meaningful and arithmetic would destroy them.

None of these choices is glamorous. All of them are the kind of thing you can only get from code — because a model, however smart, cannot promise you it will round the same direction every time.

The verdict the model is never offered

Here’s the detail that does the most work, and it’s small enough to miss.

A check in Scout doesn’t have two outcomes. It has four: pass, fail, needs review, and not applicable. And the code reaches for the third one every time a precondition for deciding isn’t met. The amount on the page was unreadable? Needs review. The loan date wouldn’t parse, so the prior-year test can’t be anchored? Needs review. The checklist item is a human directive — “verify the member was called” — that no document can prove? Needs review, with whatever corroborating evidence Scout could gather attached. Even an unrecognized check type falls through to needs review, never to a silent pass.

The code is allowed to say: “I can’t decide this. A person must.”

That’s the property a chatbot can’t give you. Ask a language model a question it can’t reliably answer and it answers anyway — fluently, confidently, in well-formed prose. Ask Scout’s decision code the same question and it returns the honest fourth answer, because someone wrote an if branch for honesty and the branch always executes.

Even the reading isn’t taken on faith

Saying “the model reads” undersells how suspiciously the reading is treated. Every value the model reports passes through a gauntlet of deterministic checks before any rule sees it — sanitation, format, type, and finally corroboration: a plain text search, no AI involved, confirming the value literally appears in an independent transcription of the page. A value that fails is held back exactly like a value that was never found, with the reason recorded. When two documents disagree about the same fact, neither wins — the fact is withheld and a conflict finding is raised, because, in the code’s own words, picking one and reporting it as fact is the failure mode being fixed.

There’s even a second model turn that adjudicates doubtful values — and the epistemics of that turn are stricter than most courtrooms. The adjudicator is deliberately not told what the text search concluded, so it can’t just agree with a verdict it was handed. Anything it claims to see on the page is quarantined in a field that, per the code, “nothing downstream reads as data.” And to catch an adjudicator that agrees rather than reads, Scout’s test harness can plant known-wrong values — a shifted decimal, a plausible fabrication — and measure whether they get caught. The model participates in perception. It is never allowed to certify perception.

Where the model gets closest — and the fence there

An honest account has to include the closest approach. Some review steps do ask a model for a per-requirement status — is this stipulation cleared, or still pending? That is verdict-shaped work, and Scout treats it like handling something radioactive:

  • The model may only choose from a fixed menu of statuses baked into the request’s output format — and the menu is incomplete on purpose. The status “missing” isn’t on it. Only deterministic code can declare a document missing, after checking that ingest actually ran, the vocabulary actually synced, and the search actually happened — so “absent” can never mean “we didn’t look.”
  • The model reports only the status and the source document. The requirement’s identity — its name, ID, and category — is reconstructed by code from the checklist, so the model can’t drift the record even accidentally.
  • If the preconditions for a trustworthy run aren’t met, the code refuses to claim any result at all: not assessed, in so many words, rather than a guess dressed as a finding.

The pattern is the principle applied at its own edge: wherever the model’s judgment is used, code decides what the judgment is about, what answers are even expressible, and whether the run was fit to produce an answer in the first place.


Why this is the principle that comes first

Everything else in this series — sealed recipes, one vocabulary, versioned updates, a file you can hold — assumes this split. Determinism is only worth versioning if the thing being versioned is actually deterministic. An audit trail is only an audit trail if the logic it points to would do the same thing again.

The model is a rented, brilliant, occasionally erratic reader, and Scout uses it as exactly that. The decisions — the part your examiner asks about, the part your policy manual governs, the part that has to be the same next March as it was this March — belong to code. Not because we distrust AI in general, but because decide the same way every time is a promise only code can make, and it’s the promise the whole product is built to keep.