How Scout works, written out.

We publish the mechanism rather than describing the benefit. Each piece stands on its own; read them in any order.

Core concepts

start here
Concept What a harness is — and why the model alone isn’t a product The gap between a capable model and something a bank can put in front of an examiner, and the named parts that close it. 8 min read Concept How a review actually runs in Scout — from PDF package to signed finding The whole pipeline, stage by stage — splitting a scanned package, extracting facts in attention-sized batches, and the four answers a rule can give. 12 min read Concept Taxonomies: one vocabulary for every document Why “Checking” and “DDA” have to be one concept before anything downstream can be trusted. 5 min read Concept Recipes: why deterministic code makes the decisions The model reads the page. A recipe decides what the reading means — the same way, every run. 6 min read Concept The notebook is a file — and your data never leaves it What a .scoutnb holds, where it lives, and who owns it. 5 min read Security What the control plane can see — and what it never can HQ ships configuration out and takes nothing back. What crosses the wire, and what structurally cannot. 6 min read Concept How one change reaches every Scout instance Versioned, hash-signed configuration, and why every finding names the exact version that produced it. 5 min read

Four principles

one lesson each
Principle 01 The model reads. Code decides. Perception is the only place Scout calls a model. Everything downstream is formal. 7 min read Principle 02 We integrate. We don’t replace. Scout connects to the core, the LOS, and the imaging system. It is not a system of record. 7 min read Principle 03 PII stays in the field. Borrower data rests in a notebook, on hardware the institution already owns and secures. 7 min read Principle 04 One engine, centrally managed. The same Rust core on a banker’s desk and headless inside a partner product. 7 min read