How one change reaches every Scout instance

Here’s a problem every multi-branch institution recognizes, even if it’s never been written down. Policy changes on Tuesday. By Thursday, three branches are working from the new checklist, two are working from the old one, and one is working from a PDF someone emailed in the spring. Nobody did anything wrong. The change just had to travel by hand, and hand-carried changes arrive at different times — or not at all.

Scout’s answer is that a change never travels by hand. Your review logic, your document vocabulary, your written policies — all of it lives in one place, Scout HQ, and every workstation pulls from that one place. Publish a change once and every instance picks it up on its next sync. This article is about how that actually works: how a workstation knows something changed, how it proves the bytes are genuine, and how — months later — a finding can name the exact version of the logic that produced it.

---

The conversation is two questions long

When Scout checks in with HQ, the exchange is almost embarrassingly small.

First question: “what’s the current version of my configuration?” HQ answers with a tiny manifest — a version label, a timestamp, and a fingerprint: a cryptographic hash of your institution’s exact configuration bytes. A hash is a short string computed from content, with the useful property that if even one byte of the content changes, the hash changes completely.

Scout compares that fingerprint to the one it recorded last time. If they match, the conversation is over — nothing changed, nothing downloads, and the workstation goes on running exactly what it was running. If they differ, the second question: “send it down.” The whole package arrives at once — recipes, vocabulary, policies — not a trickle of individual edits.

One detail here says a lot about the engineering posture. Version labels would be the obvious thing to compare, and Scout deliberately doesn’t trust them. During development, an upstream system was observed making real content changes without bumping its version number — the label said “nothing new” while the bytes said otherwise. So the code hashes the actual content and treats that as the truth. A comment in the source spells it out: hashing the whole payload means any change forces a re-apply. Labels are for people. Fingerprints are for deciding.

All of it or none of it

Downloading a new configuration and installing it are different things, and the gap between them is where lesser systems create their strangest bugs — a machine caught mid-update, running half of Tuesday’s rules and half of Thursday’s.

Scout closes that gap with a database transaction: the workstation’s local catalog is replaced in a single atomic operation. Until the swap commits, every review runs against the old configuration in full; after it commits, everything runs against the new one in full. There is no observable in-between.

And the fingerprint Scout records for next time only advances after the install succeeds. If a download completes but the install fails, Scout keeps the old fingerprint on purpose — so the next sync sees a mismatch and tries again, rather than believing it’s up to date while running stale logic. The code comments treat that ordering as load-bearing, because it is.

Proving the bytes are real

“The workstation downloads logic from the cloud and runs it” should make any security reviewer sit up. Scout’s design starts from the assumption that the pipe can’t be trusted — so the content has to prove itself.

Review recipes carry their fingerprint inside the bundle. Before a single rule executes, Scout recomputes the hash from the bytes it actually holds and compares it to the one stamped at publish time. A mismatch doesn’t produce a warning; the bundle does not run.

Published assistants go further: each one is encrypted and signed with a private key that exists only at VisionFI. Every Scout installation carries the matching public key inside the application itself — not fetched from anywhere, baked into the binary. Verification runs in a deliberate order: check the download’s hash, check the signature, and only then decrypt. Nothing is opened until the bytes are proven to be the ones VisionFI published. If someone intercepted the download and substituted their own content, the failure is blunt and final:

Signature check failed — these bytes were not published by VisionFI.

The connection isn’t what makes the content trustworthy. The signature is.

The most specific version wins

“Every instance runs the same configuration” needs one refinement, because institutions aren’t identical. A baseline indirect-lending review might serve every client; your institution might run a tightened variant; one of your products might need a variant of that.

Scout resolves this with a simple precedence rule: a recipe can be published for all clients, for one institution, or for one institution’s one product — and when more than one applies, the most specific wins. The general version keeps serving everyone else; your variant shadows it only where it’s meant to. Nothing is forked, and the resolution logic is a few lines of arithmetic, not a judgment call.

The part auditors care about

Everything above is plumbing. Here’s what the plumbing buys.

Because every configuration package is fingerprinted, every recipe versioned, and every published revision kept immutable — old versions are never overwritten, which is also why rollback is just pointing back at an older one — the question “which logic produced this finding?” has a precise answer. When a review runs, the run record written into the notebook names the bundle version and its hash, alongside the institution configuration it ran under.

That turns an uncomfortable exam question into a lookup. “Your policy changed in March. Which reviews ran under the old rule?” — with hand-distributed checklists, that’s an archaeology project through inboxes. With versioned distribution, the answer was written down at the moment each review ran, by the machine that ran it.

One change, published once, verified everywhere, and remembered forever. The alternative isn’t a different architecture. It’s the email attachment — and hoping.