One engine, centrally managed.

Software vendors love the word “platform,” and it usually means: we built the same feature three times — once for the desktop app, once for the API, once for the partner integration — and we’re hoping the three copies agree. They drift, of course. The desktop app validates a field the API doesn’t. The integration rounds differently than the app. Nobody decided this; three codebases just aged three ways.

Scout’s fourth principle is a refusal to let that happen: there is one engine, and everything you can point at — the app a lending officer uses, the command line a technologist scripts, the library a partner embeds inside their own product — is a thin skin over that single engine. Not a compatible reimplementation. The same compiled Rust core, running the same review, the same way, everywhere it runs.

---

One core, several faces

At the center of Scout’s codebase sits a single Rust component that owns everything that matters: notebooks and their lifecycle, document ingestion, review execution, artifact storage, sync with HQ, and the rules for when a model may be called. Its own documentation is blunt about the arrangement — every consumer binds to it, and anyone tempted to add product logic to a frontend is told, in the source, that the logic “almost certainly belongs” in the core.

The faces on that core are deliberately boring:

• The desktop app — what most users mean by “Scout” — is a windowed shell over the core.
• The command line wraps the core directly: no server, no middle layer, and — this is the telling part — the same data directory, catalog, and settings as the desktop app. Open a notebook in one and the other sees it, because there is no “CLI version” of a notebook. There’s a notebook.
• The partner library — shipped as a standard .NET package — is the same core compiled into a native library that a partner’s own product loads directly into its process. A loan-origination vendor can run a Scout review inside their software with no Scout window ever appearing.

And here’s the detail that makes “same engine” checkable rather than rhetorical: every one of those faces speaks to the core in the identical vocabulary. The desktop app asking for a review and a partner’s C# code asking for a review send the same method name with the same JSON shape — the source states, as an invariant, that the two bindings “stay wire-compatible.” There is no desktop dialect and no embedded dialect. There’s the engine’s language, spoken through different microphones.

One deliberate asymmetry is worth knowing about, because it’s a feature: the library handed to partners is built with Scout’s conversational chat stripped out entirely — not switched off, absent from the binary — so Scout’s prompts and internal tooling can’t be extracted from a file sitting on someone else’s server. Capability differences between the faces exist only where someone chose them, in writing, for a reason.

“Centrally managed” is the other half

One engine everywhere creates the next problem: a thousand copies of the same engine can still be running a thousand different configurations. This is where Scout HQ — the control plane covered elsewhere in this series — earns the second half of the principle.

Every instance, whatever its face, pulls its working material from HQ: the review recipes the institution has enabled, the document vocabulary, the written policies. Each workstation receives a package scoped to its own institution — its recipes plus VisionFI’s shared catalog tier, and structurally nothing belonging to anyone else. When more than one version of a recipe could apply, precedence is three lines of arithmetic, not a judgment call: a recipe published for your institution outranks the general one; one published for your specific product outranks that. The most specific wins, and a tie at the same level is an error, never a coin flip.

The part an auditor will care about: the resolution logic lives in the core, below every face. The desktop app, the command line, and the partner’s embedded copy don’t each implement “which recipe applies” — they all ask the same function, so the same loan under the same configuration resolves to the same sealed recipe, byte-for-byte, wherever the question is asked. And every run writes that answer down: the recipe version and fingerprint, plus the version and fingerprint of the institution configuration it ran under, stamped into the notebook’s ledger. Two runs on two machines that record the same fingerprints ran the same logic. That’s not an assurance; it’s two hashes you can compare.

The version number that refuses to lie

Managing one engine centrally also means knowing, precisely, which engine anyone is running — and here the codebase carries a scar worth showing.

Early on, a partner package was built one day before an important fix landed in the core. The C# code compiled fine. Every call succeeded. And recipes silently never synced — because the native engine inside the package predated the fix, and nothing on the surface said so. The failure wasn’t a crash; it was a mismatch that looked healthy.

The fix was to make lying impossible. The partner package’s version now is the engine version — engine 0.1.56 produces package 0.1.56, so “which engine am I running?” is answered by the version string with no lookup. Beyond that, every build stamps its exact provenance — the engine tag, the source commit, the release channel — into the assembly itself, readable at runtime by one call:

VisionFI.Scout 0.1.56 (stable; scout-agent v0.1.56 @ 0d2b0c5)

The same discipline runs through the rest of the distribution machinery this series has already covered: recipes hash-verified before every run on every host, published assistants signature-checked against a key baked into the app, configuration fingerprints that only advance after a successful install. HQ and the download pipes are treated as dumb and untrusted on purpose — the content proves itself, so it proves itself identically whether it landed on a teller-line workstation or inside a partner’s data center.

Why institutions should want this

The one-engine arrangement sounds like an internal engineering preference. It’s actually a set of promises with your name on them:

A finding means the same thing everywhere. A review run headlessly inside your LOS vendor’s product and a review run by an analyst at a desk executed the same sealed logic under the same configuration — and both wrote down the fingerprints to prove it. There is no “the integration behaves a little differently” asterisk, because there is no integration codebase to behave differently.

A fix lands once. When the engine improves, the desktop app, the CLI, and the partner package don’t each wait their turn in three roadmaps. They’re the same core; the improvement is theirs the moment they carry the new version — and the version string says whether they do.

Your exam scales down. Evaluating Scout means evaluating one engine, one distribution mechanism, one ledger format. The alternative — vet the app, then separately vet the API, then separately vet whatever the partner embedded — is three reviews of three things pretending to be one.

The quiet test of the principle is a question you can put to any vendor: when your product runs inside someone else’s, is it the same code? For Scout the answer isn’t “functionally equivalent.” It’s the same compiled engine, resolving the same recipe by the same rule, stamping the same fingerprints into the same file format — on a banker’s desk, in a script, or inside a product that never shows Scout’s name at all.