Concept 5 min read
The notebook is a file — and your data never leaves it
Scout is built on an old-fashioned conviction: work you’re accountable for should be a thing you can hold. Ask “where is my review, exactly?” and the answer should be a place you can point to.
So Scout’s answer is a file. When you review a loan package in Scout, everything about that review — the original documents, the recovered text, every extracted value, every finding, every AI call that was ever made — lands in a single file on your machine with the extension .scoutnb. Copy that file to a USB stick and you’ve copied the entire review. Delete it and it’s gone. Email it to a colleague and they double-click it open, the way documents have worked since documents were invented.
This article is about what’s actually inside that file, because the inside is where the design shows.
One file, on purpose
A .scoutnb file is a database — a complete, self-contained one, built on the same kind of battle-tested storage engine that quietly runs inside your phone, your browser, and most of the software you already use. That choice buys something rare: a file that’s simultaneously a portable document and a queryable, structured record.
Databases of this kind normally travel with companions — little sidecar files for in-flight changes and shared state. Scout deliberately configures the notebook so those never exist. The code that makes this choice says why, in a comment: the setting it uses “keeps a notebook a single self-contained file at rest,” because “the portable-document shape is worth more here” than the performance the alternative would buy.
That one unglamorous setting is the product’s thesis in miniature. A notebook has no hidden cache, no sync state living somewhere else, no cloud half. The file is the whole thing.
It also draws a boundary. Inside Scout, a reference can point from a finding back to the page it came from — but the code is explicit that the reach ends at the file’s edge: a notebook is a single file, so nothing inside it can reference, or leak into, anything outside it. Your review can’t accidentally wander.
What’s inside
Open a notebook’s hood and you find a small set of tables, each holding one kind of truth.
The nameplate. A single metadata row: the notebook’s name, its status, how many files and pages it holds, when it was created and last touched. This row is also the bouncer — when Scout imports a .scoutnb, it opens the file and looks for this row first. A file without it is rejected as not-a-notebook, whatever its extension claims.
The evidence. Every object in the review is an artifact: the uploaded PDF, each document split out of it, the recovered text of every scanned page, extracted images, spreadsheet sheets, findings, reports, notes. The actual bytes — the PDFs themselves, not links to them — are stored inside the file. And every artifact is stamped with its lineage: which artifacts it was derived from, forming an unbroken chain from any conclusion back to the source page.
Each artifact also carries one of three provenance labels, and the distinction matters: source (it came in from outside — an uploaded file), derived (the software produced it), or authored (a human wrote it). At a glance, the notebook knows the difference between evidence, analysis, and opinion.
The ledger. This is where the philosophy shows most clearly. Every automated review run is recorded with its status, its token counts, and — critically — the cryptographic fingerprint of the exact recipe version that produced it. Beneath that, every individual AI call: which model, what kind of call, how many tokens in and out, how long it took, whether it errored. The full conversation transcripts of each run are in there too.
If an examiner asks, a year from now, “what did the AI actually do to reach this finding?” — the answer is rows in a table inside the file they’re already holding. Not logs on a server. Not a reconstruction from memory.
Chats too. A conversation with Scout isn’t a different kind of thing — every chat session is itself a .scoutnb file, carrying the transcript, any files you attached, and the token usage of every turn. The same anatomy, the same portability.
To give this some scale: a real four-file, 127-page commercial review — original package, split documents, recovered text, findings, reports, ledger and all — is about 27 megabytes. A seventeen-document loan review with per-document quality findings: about 23. Smaller than the photo roll from one long lunch.
Sharing is just… sharing a file
Because the notebook is an ordinary file, Scout gets to skip an entire genre of engineering. There is no sharing service, no permissions model, no OAuth handshake with your collaboration suite. The design document for the sharing feature reduces the whole problem to one sentence: the only thing the app has to provide is a way to get the file out.
So that’s what it provides. Click a notebook’s copy button and the file lands on your clipboard; paste it into Teams, an email, a chat, a folder. Your institution’s own file-sharing rules — retention, data-loss prevention, access control — apply automatically, because it’s your file moving through your systems. Scout never sees it move.
On the receiving end, .scoutnb is registered with the operating system as Scout’s document type. Double-click one and Scout opens, copies it into your library, and shows you the review — evidence, findings, and audit trail intact, because they were never anywhere else.
One honest caveat, straight from the design notes: a shared notebook carries the whole session — documents included. That’s the intent; full context travels with the file. It also means sharing a notebook is sharing everything in it, so it deserves the same moment of thought as attaching any file full of customer records.
The same container, wearing a different hat
Here’s where the format gets quietly powerful. Because a notebook is a self-describing database, it can carry more than reviews — it can carry capabilities.
VisionFI ships what it calls feature notebooks: a .scoutnb that contains, say, an entire quarter of industry call-report data — dozens of tables, thousands of institutions — plus a manifest describing an assistant that knows how to answer questions about it: its name, its persona, its example prompts, and the strict read-only permission profile it operates under. The design document puts it well: the notebook ships the assistant’s soul, the app ships its body. Updating the assistant means shipping a new file, not a new version of the app.
These published notebooks get an extra layer ordinary ones don’t need: each one is encrypted and cryptographically signed by VisionFI, and the app verifies that signature against a key baked into the app itself — checking, in the code’s words, that the bytes “are proven to be the ones VisionFI published” before a single byte is decrypted. The file can travel over any network, sit in any bucket, and still arrive trustworthy, because the trust is in the math, not the pipe.
Why a file, in the end
The notebook format exists because of that opening conviction: a regulated institution’s most sensitive artifact — a completed review, evidence and verdicts and audit trail together — should be a thing you hold.
A thing you can copy, archive under your own retention policy, hand to an auditor, attach to a case file, or delete with certainty. A thing that works without an account, without a connection, without VisionFI.
One file. Opens on click. That’s not a limitation of the design — it is the design.