Concept 12 min read

How a review actually runs in Scout — from PDF package to signed finding

When people hear “AI reviews your files,” they usually picture something vague: documents go in, a chatbot reads them, answers come out. That picture is wrong in almost every detail that matters — and the details are where trust lives.

This article walks the real path a review takes inside Scout, stage by stage, the way the software actually does it. Nothing here is a simplification of a black box. Every mechanism described below is a specific, inspectable piece of the pipeline. If you only remember one thing, make it this: at no point does your file get uploaded to a service, stored in a cloud, or held by anyone. The review happens on the machine the file is sitting on.

Let’s follow one document package all the way through.

Stage 1: A document package arrives

A “document package” is what bankers actually deal with: one big scanned PDF holding a whole file — a loan with its application, note, title work, insurance binder, and disclosures; a new account with its signature cards and identity documents; an investigation with its statements and case records — sometimes hundreds of pages, stapled together by a scanner years ago with no bookmarks and no labels.

The first thing Scout does is refuse to treat that as one document, because it isn’t one document. It’s a stack.

Sizing up the file

Scout starts by profiling every page: which pages have real, selectable text, and which are just pictures of text — flat scans. Pages with a usable text layer cost nothing extra. Pages that are only images get run through a local text-recognition pass, right on the machine, at high resolution. A package that’s fully digital skips this entirely; a package that’s fully scanned gets the full treatment. The pipeline pays for exactly as much recovery as the file needs.

There’s a small, telling step here. If a scanned package is too large — the working limit is 24 megabytes — the AI can’t be shown the actual pages, only a text summary of them. That limit isn’t arbitrary. The usual industry shortcut is to upload your file to the AI provider’s storage and reference it from there — but a stored file is retained data, which is exactly what zero data retention forbids. So Scout never uploads; every page travels inside the request itself, and a single request tops out at 32 megabytes. (Stage 5 walks through the full arithmetic.) Text summaries of scans are a worse way to review a document. So before giving up, Scout rewrites the PDF in grayscale to shrink it, specifically so the model gets to see the real pages instead of a degraded stand-in. It’s the kind of unglamorous engineering that never shows up in a demo but decides whether the review is looking at the document or at a shadow of it.

Finding the seams

Next, Scout figures out where one document ends and the next begins. It slides through the package in overlapping 100-page windows and asks a vision model — one that looks at the pages themselves, not just their text — to mark the boundaries and name each document: this is the promissory note, this is the title application, this is the insurance binder. The windows overlap so a document that straddles a boundary can’t be missed at the seam.

Anything that arrives already alone — a single photographed page, a one-page PDF — gets its own classification pass, with a built-in escalation: if the first attempt can’t place it confidently, a stronger model takes a second look. And if the model still can’t place it, Scout keeps the honest answer — unclassified — rather than forcing a guess. A wrong label that looks confident is worse than a blank one.

Each identified document is then split out with its own page range, its own recovered text, and its label. What went in as one 240-page blob comes out as a set of named documents Scout can reason about individually.

Three ways to read a page

Every document ends up with exactly one primary representation, chosen in a strict order of fidelity:

The pages themselves. If the document fits within size limits, the model reads it visually — layout, stamps, signatures, checkboxes and all. This is the best way to read a document, and it’s the default.
A structured transcription. If the document is too large for that, Scout transcribes it into structured text — tables kept as tables, page breaks marked, signatures and stamps noted in place.
The flat text layer, as a last resort.

The rule is one representation per document, best available first. That ordering matters later, when a finding needs to be traced back to what the reviewer actually saw.

Stage 2: One file, not a database in the sky

Everything from the previous stage lands in a notebook — and a notebook is not an account, a workspace, or a cloud project. It is literally a single file on the machine.

Inside that one file lives everything about the review: the original document package, each split-out document, the recovered text, every extracted value, every finding, and — this is the part most systems don’t have — a complete ledger of every AI call that was ever made against it: which model, how many tokens, how long it took, what it was for.

Scout even configures the file’s internal storage so it never spawns companion files. There are no sidecars, no hidden caches, no “sync state” living somewhere else. If you copy the notebook file to a USB stick, you have copied the entire review — evidence, results, and audit trail. If you delete it, it’s gone. That one boring technical choice encodes the whole product’s thesis: your review is a thing you hold, not a thing you’re granted access to.

Stage 3: The review runs

Reviews in Scout are performed by recipes — and a recipe is worth defining carefully, because it’s the answer to the most common and most fair question about AI review: “how do I know it does the same thing every time?”

A sealed program, not a prompt

A recipe is a small program, written in a deliberately restricted scripting language, bundled together with the exact checklist of facts it extracts and rules it enforces. The whole bundle is sealed with a cryptographic fingerprint — a hash of its exact bytes. Before Scout runs a single line of a recipe, it re-computes that fingerprint and compares. A bundle that’s been altered, corrupted, or is simply missing its seal does not run. No exceptions, no warning-and-continue.

And when a run finishes, the notebook’s ledger records which bundle fingerprint and version produced it. Months later, you can answer “exactly which logic generated this finding?” with a hash, not a shrug.

The recipe language itself is restricted on purpose. A recipe cannot open arbitrary network connections — there is exactly one network door, and the institution’s policy controls what’s on the other side of it. It can’t touch files outside the notebook. And it handles money the way an auditor would insist: dollar amounts are converted to whole cents and summed as integers, because adding money as floating-point decimals accumulates tiny errors, and a compliance engine that’s off by a cent has already lost the argument. Dates get normalized to one canonical format so that comparing them is unambiguous. None of this is left to the AI’s judgment — it’s the deterministic scaffolding the AI operates inside.

Extraction: asking small questions, carefully

The heart of a review is extraction: pulling specific facts — the APR, the amount financed, the VIN, the lien-holder name — out of specific documents.

Scout does not ask the model to “read the file and fill in this giant form.” Live testing showed why: past roughly eight fields per question, models start intermittently dropping answers that are plainly printed on the page — in one test, the APR, the most standardized field on any disclosure, vanished from a twelve-field batch. So Scout asks in small groups, sized to the model’s attention rather than to what’s technically possible.

Each fact is authored against a specific document type — the APR comes from the Truth-in-Lending disclosure, not from wherever it happens to appear — and Scout matches those authored names against the labels assigned at ingest, using the same shared vocabulary on both sides so they can’t drift apart. If a document type matched two physical documents (an insurance binder and its endorsement, say), both are read.

Anything the first pass misses gets asked again, in fresh smaller batches, because extraction misses are intermittent, not fundamental — the same fact found on one run can slip on another, and a retry costs little while recovering it.

Four checks before a value is believed

Every extracted value passes through a gauntlet before it’s accepted:

Sanitation — stray characters and formatting noise removed.
Shape — a VIN has to look like a VIN, money like money, a ZIP like a ZIP. These formats are a fixed, closed set; recipe authors can’t invent loose ones.
Type — a number has to actually parse as a number.
Corroboration — Scout checks, with plain text matching and no AI involved, that the extracted value literally appears in the document’s transcription. This check is deliberately forgiving about spacing and digit grouping — the disagreements that scanning actually produces — because a false “confirmed” is cheap noise, but a false “unconfirmed” sends a human chasing a ghost.

Corroboration is a signal attached to the value, not a gate that discards it. The review reports its confidence; it doesn’t hide its work.

When documents disagree, nobody wins

Here’s a design decision that says a lot about the whole system. Suppose the loan amount appears on two documents, and they don’t match.

Scout does not average them. It does not prefer the “more authoritative” one. It does not let the model pick. It withholds the fact entirely — treating it exactly like a value that couldn’t be found — and attaches both readings to a conflict finding for a human to resolve. Two documents disagreeing about a dollar amount is not a data-cleaning problem. It’s a finding.

Rules with four honest answers

Once the facts are assembled, the rules run — and this part contains no AI at all. Each rule is a plain, inspectable logical expression: the APR must not exceed the ceiling; the lien-holder must match; the insurance effective date must precede funding. Same facts in, same verdicts out, every single time.

Each rule produces one of four outcomes, not two:

Pass — the rule evaluated and the condition held.
Fail — the rule evaluated and the condition failed. This is what surfaces as a finding.
Needs review — the rule could not be evaluated, usually because the document package is missing the fact it needs. A person has to look.
Not applicable — the rule doesn’t govern this loan, so there was nothing to check.

The last two states are the ones most checklist software throws away. A rule that couldn’t run just… doesn’t appear, and absence reads as a pass. Scout records both out loud in the results — because “we verified this,” “we couldn’t verify this,” and “this didn’t apply here” are three different claims, and a review that blurs them isn’t a review.

The results include every rule in order, with the exact expression that ran — the audit record — plus the findings and the items needing review broken out for the human who has to act on them.

Stage 4: What comes out the other end

A finished run leaves three kinds of things in the notebook.

The report. Findings bucketed by severity, with a summary a person can act on: “FAIL — 1 critical, 0 warning findings across 5 rules.” Recipes can render this as a formatted PDF, a spreadsheet, or an interactive report, all generated locally.

The evidence chain. Every extracted value, its verifications, its corroboration status, and any document conflicts — linked back to the documents they came from.

The ledger. Every model call the run made: which model, what it was asked to do, token counts, timing — plus the fingerprint of the exact recipe bundle that ran. If anyone ever asks “what did the AI actually do to reach this conclusion?”, the answer is rows in a table, not a reconstruction from memory. The ledger is written call-by-call as the run proceeds, so even a run that dies mid-flight leaves an honest record of everything it did before it stopped.

And one small human touch: when a run finishes, Scout sends a desktop notification — unless the run took less than ten seconds (you were still watching) or the app window is focused (you’re looking right at it). Even the notification logic is designed not to waste your attention.

Stage 5: What never left the machine

Now the part everyone in a regulated institution should ask about first.

Throughout everything above — the splitting, the reading, the extraction — the document file itself never left the workstation. When the AI needs to read pages, those pages are included inline in the request, read in the moment under a zero-data-retention agreement with a single AI provider, and never stored on the other end. There is no upload step, no cloud document store, no third-party processing service. Every size limit mentioned in this article exists precisely because Scout refuses to use file-upload services that would hold copies.

Why 24 megabytes? The arithmetic of never uploading

Stage 1 gave the short version of why the size limit exists; here’s the full accounting, because it’s the zero-data-retention promise made visible.

The standard way AI products handle large documents is a file-upload service: send the file to the provider once, store it there, reference it forever after. It’s convenient, and it’s exactly what zero data retention forbids — a stored file is retained data. With that door closed, every page the model reads has to travel inside the request itself, and a single request to the AI tops out at 32 megabytes. Binary data inflates by a third when packaged for transmission, so 24 megabytes of actual PDF is precisely what fits: 24 × 4/3 = 32.

Everything Scout does about document size — the grayscale shrink, the tiered fallback from pages to transcription to text, the windowed transcription of oversized files — is machinery for living inside that budget instead of opening a storage door. A system that quietly uploaded your files would need none of it. The limit is the receipt.

This posture isn’t a checkbox — it has teeth, and it has costs Scout has chosen to pay. Spreadsheet and Word-document processing happen entirely on-device rather than through a converter service. Semantic “search by meaning” over notebooks was ruled out entirely because no embedding provider offered acceptable retention terms — so Scout ships deterministic search instead. Feature decisions lose to the boundary, not the other way around.

The shipped promise, stated in the product itself, is five points:

Your documents stay on your device. VisionFI never receives copies of your files.
Zero data retention. Pages are read in the moment and never stored by the AI.
US inference. Model calls are contracted to run in the United States.
No training. Nothing you review is used to train any model.
Credentials stay local. Connection secrets live in your device’s keychain, not on our servers.

Why the details are the point

Strip away the specifics and every AI review tool tells the same story: documents in, findings out. The specifics are the product.

A document package that gets split into named documents instead of read as a blob. A shrink step that exists so the model sees real pages. Facts asked for in attention-sized groups, retried when missed, corroborated against the literal text, and withheld when documents disagree. Rules that are deterministic, inspectable, and honest enough to say “needs review” instead of silently passing. A sealed, fingerprinted recipe that either runs exactly as published or not at all. And a single portable file holding the evidence, the verdicts, and a call-by-call ledger of everything the AI did — sitting on your machine, because it never went anywhere else.

That’s how a review actually runs in Scout. Not magic. A pipeline — one you’re allowed to inspect.