Concept 5 min read
Taxonomies: one vocabulary for every document
Ask three people at the same institution what to call the same piece of paper and you’ll get three answers. The teller says “checking account,” the core system says “DDA.” The loan file says “Retail Installment Contract”; the dealer who sent it calls it a “RISC,” the older officer calls it a “RIC,” and somewhere in the stack it’s printed as “LAW 553” — a form number that has quietly become a name. Down the hall in commercial lending, the credit memo references a “UCC-1,” the attorney’s cover letter calls it a “financing statement,” and the tickler system just says “UCC filing” — one lien perfection document, three names before lunch.
None of these people are wrong. But software that takes names at face value ends up believing the same document is several different things — a review looking for “the Retail Installment Contract” walks right past the page titled “LAW 553,” and a collateral check hunting for the “financing statement” never finds the file labeled “UCC-1.”
Scout’s answer is a taxonomy: a single, shared vocabulary in which every document kind is one concept with one canonical name — and every nickname the industry has ever given it is recorded as an alias of that concept. “Checking” and “DDA” aren’t two strings to be matched. They’re one idea with two spellings.
What a term actually is
Inside Scout’s catalog, a document type is a small structured record, not a keyword. The vocabulary runs to hundreds of them — consumer lending, commercial lending, deposit operations, compliance — and each carries four things:
A canonical label. “Retail Installment Contract.” This is the one true name — the one that appears in the notebook, in findings, in reports.
Its aliases. For that same term, eight of them: RISC, RIC, retail installment sale contract, retail installment sales contract, motor vehicle retail installment contract, installment sale contract, retail contract — and yes, LAW 553. Every name the document answers to in the wild.
A category. Lending, collateral, compliance, deposit — so a “Deed of Trust” (aliases: DOT, mortgage, trust deed) files under collateral while a “Credit Score Notice” files under compliance.
The same pattern holds wherever the paper comes from. On the commercial side, a “UCC Filing” answers to UCC-1, UCC-3, and financing statement; a “Guaranty Agreement” answers to guaranty, guarantee, personal guaranty, and corporate guaranty; a “Loan Agreement” is also a credit agreement or a credit facility, depending on who drafted it. On the deposit side the naming gap is famously institutional: what a bank’s core calls a DDA, a credit union calls a share draft account, and the member just calls checking — while a certificate of deposit, a CD, a time deposit, and a share certificate are one product wearing four industry dialects. A taxonomy term absorbs all of that: one concept, every dialect on file.
A description that teaches. This is the underrated part. The description isn’t a definition for a glossary — it’s guidance for the judgment call. The Retail Installment Contract’s description spends four sentences explaining when to choose it over a Promissory Note: pick this one when the seller or dealer is the original creditor and the form assigns the contract to the credit union; a loan the institution originated directly is a Promissory Note, not this. The vocabulary doesn’t just name the concepts — it encodes the expertise for telling them apart.
Where the vocabulary does its work
The taxonomy earns its keep at three moments, and the point of the design is that all three use the same terms.
At the front door. When documents are ingested, Scout’s classifier is handed the full taxonomy — every label, every alias, every description — and given one strict rule, quoted straight from the code: “You MUST use these exact labels (not aliases) in your response.” The AI reads titles, headers, logos, and form numbers; it’s free to recognize a document by any of its nicknames; but it must record it under the canonical name. The messy vocabulary of the real world flows in; one clean vocabulary is written down.
In conversation and in recipes. When an automated review says “find the loan disclosure,” or a QC recipe is authored against “the promissory note,” those names pass through a resolver that maps free text onto the same term-and-alias set the ingest classifier used. The comment at the top of that code states the goal plainly: authoring and selection “speak one vocabulary.” Type “TIL” and you land on the Loan Disclosure Statement. Type “prom note” and you land on the Promissory Note. The person writing the rule and the software classifying the page can use different words and still mean the same thing — because both sets of words resolve to one concept.
With a forgiving ear. The resolver normalizes before it matches: lowercase everything, drop apostrophes, collapse stray spaces. “Buyer’s Order,” “Buyers Order,” and “buyers order” with an accidental double space are all the same name. The tolerance is for typography, never for meaning.
Down to the fields
The naming problem doesn’t stop at the document’s title — it continues inside the document. The number a review needs might be printed as “Amount Financed” on the disclosure, “Principal” on the note, and “Total Loan Amount” on the worksheet. Same value, three labels, three fonts.
Scout’s automated reviews are built from recipes, and a recipe’s extraction spec handles this at two layers.
The document layer is formal. When someone authors a review in conversation — “pull the loan amount from the loan disclosure, or fall back to the loan agreement” — the authoring tool takes each document name they used and snaps it to the canonical taxonomy label, telling the author what it did: the tool’s own message reads that it “normalized document names to canonical taxonomy labels.” Write “TIL” while authoring and the recipe is stored against “Loan Disclosure Statement” — the same term the ingest classifier writes, which is precisely why the recipe finds the document later.
The field layer is expertise, written down. Each fact a recipe extracts carries an instruction the author composed, and real ones read like a reviewer training a new hire: the total amount financed / loan amount, as a dollar figure — the variant names folded right into the ask. When an author says “look for this, and it may be labeled this, that, or the other thing,” that sentence becomes part of the recipe. It’s the same one-concept-many-names principle at finer grain; the difference is that document names live in the shared registry, while field-name variants today travel inside each authored recipe. As those instructions accumulate across institutions, they’re the obvious next stratum for the shared vocabulary to grow into.
When names collide
A shared vocabulary has to survive its own contradictions, and the code is candid about a real one it hit.
In the lending vocabulary, “Consumer Loan Application” once claimed “membership application” as an alias — while “Membership Application” was also a full-fledged term of its own. Handled naively, the alias swallowed the term: anyone asking for a Membership Application was silently handed the wrong document type.
The fix is now a rule with a test guarding it: a term’s own canonical label always outranks another term’s alias. A concept owns its name, no matter who else lists that name as a nickname. And when two terms claim the same alias — two document types both answering to “invoice,” say — neither has the stronger claim, so the system resolves it deterministically and, in the code’s own words, “reports the ambiguity instead of hiding it.”
That’s a small design decision with a large consequence: naming disputes get surfaced to a human who can fix the vocabulary, instead of being papered over differently on every run.
One document, several hats
Real loan files refuse to stay tidy. A Loan Agreement sometimes embeds a Security Agreement; a closing package’s body may contain the Truth-in-Lending disclosure outright. Forcing one label onto a multi-purpose document would make it invisible to every review looking for its other roles.
So classification here is an index, not a gate. Each document gets its single best-fit type, plus a list of additional types it fully serves. The document wears one name tag but is findable under every job it actually does — which is exactly how a good index behaves.
Why a vocabulary, in the end
You could imagine skipping all this and just letting the AI describe each document in its own words. It would even look fine, for a while. But “Deed of Trust” on Tuesday and “mortgage instrument” on Thursday are, to software, unrelated strings — and every rule, every report, every search would inherit that drift.
A taxonomy is the opposite bet: pin the concepts down once, let the names stay plural. The institution’s slang, the vendor’s form numbers, and the regulation’s formal titles all remain speakable — they’re aliases, faithfully kept. But underneath, every page in every notebook is classified against one versioned, reviewable, correctable vocabulary that the classifier, the chat, and the automated reviews all share.
“Checking” equals “DDA” equals “share draft.” One concept, not three strings. Get that right hundreds of times — across lending, commercial, and deposit paper, down into the fields — and the whole system gets to speak your language, while never disagreeing with itself.