Borrowing the shape, not the box

Retrieval systems all begin the same way: cut the documents into chunks, find the ones that look relevant, answer from those. The early chunks were blunt — fixed-size slices — and the field has spent years making them less blunt, contextual retrieval and the rest. We pushed from the document side: parse a file into its actual structure — sections, summaries — so a chunk is a unit that means something rather than an arbitrary cut. Not for elegance, but because the questions we cared about were precise — what a scholarship pays, who's eligible — and precise answers fall apart on brutal slicing.

Then the general-purpose notebook arrived — NotebookLM, and the shape it made familiar. Point it at your own sources, chat over them, every answer footnoted back to a passage. No project, no onboarding, no one preparing the documents first. The surface for this kind of work had gone general — and the polish kept heading toward turning your documents into something to present. The part we cared about was heading the other way.

A surface going general is the easy thing to admire. The question we found more interesting was the inverse one: not whether the surface could generalize, but whether the depth could — the structure, the entities — without going shallow on the way. Some of it generalized almost for free. Some of it you have to do on purpose.

The footnote is a contract

Trust generalized easily. We have the model emit a small handle — [3] — and let the renderer, not the model, decide what [3] resolves to. The model can be wrong about an answer; it can't be wrong about its own sources, because it never gets to resolve its own citations. And when nothing in your documents supports a claim, the honest output is “I don't have that in your sources” — not a confident guess. That single rule is what lets a small model you can run yourself be trusted at all, and it's the same rule in every domain. Trust didn't need a project.

Where it runs

So did the place it runs. The model, the index — an FTS5 table and a notebook of sources — can stay in the building; none of it has to leave. For some teams that's a preference; for others it's the only reason they can use a thing like this at all. That part you keep simply by not giving it away.

The part you generalize on purpose

The depth was the hard one, and it's the part still worth the work. A notebook that only retrieves can quote, summarize, and stop. But the questions people bring are often structural — how many, which ones qualify, what's missing, does this meet that — and those need the documents turned into something with shape: typed entities you can count and compare, not snippets you can paraphrase.

What made that tractable was keeping two layers apart. The structure we parse out — sections and their summaries — is the stable one; it sits close to the source and doesn't move when the domain's questions change. The typed entities are projected from it — derived, not carved into the documents — so when the first schema turns out wrong, and it always does, you re-project into the new shape instead of re-reading anything. The first pass is rarely right; the point is that the second pass is cheap.

That's what lets the depth generalize instead of staying bespoke. Improve the parsing once — in general, or for a domain that needs it — and a new domain becomes a schema and a handful of examples projected onto structure that's already there. Not a rebuild.

The corner this is from

This is the other corner of the workshop from the last note — that one was about the bench under our chat apps; this is about what runs on it when the work is knowledge. We borrowed the shape gladly; it's a good shape, and we didn't need to reinvent it. The box was the part worth keeping — the trust, the place it runs, and the depth that, unlike the shape, never generalizes itself.