Concept 6 min read

Recipes: why deterministic code makes the decisions

Ask any examiner, auditor, or QC manager what worries them about AI review, and it’s rarely “can the model read the document?” Models read documents well. The worry is the other half: will it reach the same conclusion tomorrow that it reached today? Ask a language model the same question twice and you can get two differently-worded answers — that’s what it’s built to do. Wonderful in conversation. Disqualifying in compliance.

Scout resolves that tension with one architectural rule, and everything else in this article follows from it:

The model reads. Code decides.

The AI is used for the one thing it’s uniquely good at — reading messy, scanned, inconsistent real-world documents and pulling out specific facts. Every decision made about those facts — does the APR exceed the ceiling, does the lien-holder match, is the insurance dated before funding — is made by ordinary program logic. Same facts in, same verdicts out, every single time. There is no judgment call, no mood, no phrasing lottery anywhere in the decision path.

A review is a program, not a prompt

Inside Scout, a review is performed by a recipe — and a recipe is not a prompt, a template, or a “custom GPT.” It is a small program: real code, with steps that run in a fixed order, arithmetic that computes the same result every time, and rules written as plain logical expressions anyone technical can read.

That distinction sounds academic until you see what it buys.

A prompt says: “Check whether this loan complies with our policy.” What happens next depends on how the model feels about the wording that day.

A recipe says: extract these eleven facts, from these specific document types. Then evaluate these rules, in this order: amount_financed <= approved_amount, apr <= ceiling, insurance_effective_date <= funding_date. Report every result.

The model participates in the first half — the reading. It is nowhere in the second half. The rules aren’t suggestions the AI weighs; they’re code that executes. If the same facts go in, the same findings come out, whether the recipe runs today, next quarter, or in front of an examiner asking you to reproduce a result from March.

Even the arithmetic is done the boring, correct way. Dollar amounts are converted to whole cents and compared as integers, because adding money as decimals accumulates tiny rounding errors — and a compliance check that’s off by a cent has already lost the argument. Dates are normalized to one canonical format before any comparison. None of this is left to the model’s judgment. It’s the deterministic scaffolding the model works inside.

Code — but fenced in

“The review logic is code” raises a fair follow-up: code can do anything. Isn’t that a risk?

General-purpose code can do anything. Recipe code deliberately can’t.

Recipes are written in a restricted language that runs inside a sealed box. A recipe cannot touch the computer it runs on — it can’t read or write files on the workstation, can’t see the operating system, can’t reach into other applications. It can’t open network connections wherever it likes; there is exactly one controlled door to the outside, and the institution’s configuration decides what, if anything, is on the other side of it. It can’t loop forever, and it can’t smuggle in outside software.

What it can do is exactly the job: read the documents in the notebook being reviewed, ask the model to extract facts from them, evaluate rules, and write results back into that same notebook.

This is the opposite trade from most automation platforms, which start with a general-purpose scripting environment and try to bolt security on afterward. A recipe starts with nothing and is granted only the capabilities a document review needs. The guardrails aren’t a policy document — they’re what the language physically cannot express.

Sealed, fingerprinted, versioned

There’s one more property that separates a recipe from a prompt: you can prove which one ran.

Every recipe is bundled — the program, plus the exact checklist of facts it extracts and rules it enforces — and sealed with a cryptographic fingerprint, a hash of its exact bytes. Before Scout runs a single line, it recomputes that fingerprint and compares. A bundle that has been altered, corrupted, or is missing its seal does not run. There is no warn-and-continue.

When a run finishes, the notebook’s ledger records the fingerprint and version of the bundle that produced it. Months later, “exactly which logic generated this finding?” is answered with a hash, not a recollection. Try asking that question about a prompt someone pasted into a chatbot last spring.

Where recipes come from — and why buyers should care

So far this describes how a recipe runs. The other half of the story is how one gets written, approved, and delivered — because that’s where most institutions expect the catch. “Custom logic per institution” usually translates to “statement of work, professional services, six weeks.”

Scout treats authoring and delivery as part of the product.

Authoring is a conversation. Inside Scout, you describe the review you need in plain language — the documents involved, the facts that matter, the policy rules — and an authoring assistant drafts the recipe with you: the extraction checklist, the rules, the report. You can read back every fact and every rule it proposes, in plain terms, before anything is sealed. The assistant writes the code; you approve the checklist. What gets sealed is what you reviewed.

Delivery is central, and controlled. Published recipes live in Scout HQ — the institution’s management hub — and sync down to every workstation from there. That one arrangement carries most of the operational value:

Change without releases. A new regulation, a revised policy ceiling, a new product’s checklist — that’s a new recipe version published to HQ, not a software upgrade rolled out to every machine. The application doesn’t change; the logic it faithfully executes does.
Scoped to fit. A recipe can apply to every client, to one institution, to one product, or to one institution’s one product — and the most specific version wins. A baseline indirect-lending review can serve everyone while your institution runs its own tightened variant, without forking anything.
One version of the truth. Every workstation pulls from the same source. Nobody is running the checklist from an email attachment two revisions old — the seal and version travel with the bundle, and the run ledger records which one executed.
Versioned like the regulated artifact it is. Recipes carry versions and fingerprints end to end, from HQ to the workstation to the ledger line in the finished notebook. When policy changes, the old version’s runs still say exactly what logic they ran under.

This is the piece that turns recipes from a technical nicety into an operating model. The institution owns its review logic the way it owns its policy manual — written in plain-language collaboration, sealed on approval, distributed centrally, and auditable forever after.

The quiet argument

There’s a version of AI review where the pitch is the model: bigger, newer, smarter. Scout’s argument is quieter. The model is an excellent reader, and it is only the reader. The decisions belong to code — code that is fenced in so it can’t wander, sealed so it can’t drift, versioned so it can’t be misremembered, and delivered centrally so everyone runs the same one.

Same documents in, same findings out. That’s not a limitation of the system.

That’s the product.