Why we mill knowledge bricks instead of one giant KB.

Note · KBMill · method · human-sized blast radius

The usual answer to “we need a company knowledge base” is one big index: everything in, search forever, hope the model finds the right neighbor. That feels like scale. It is often a trap. We mill knowledge bricks — bounded, portable packages you can update, mute, and leave behind — and compose programs from bricks instead of growing one unbounded pile. Human-sized blast radius, not an infinite company brain.

What goes wrong with the monolith

Even careful conventional KB advice leans toward single-topic units and away from “one giant platform.” The one-big-index trap is not as contrarian as it sounds — searchability dies when everything shares one blast radius.

Wrong era, wrong neighbor

One giant KB mixes domains, years, and trust levels. The 2014 procedure answers the 2024 question. A footer ranks like a heading.

Noise spreads

A bad scan poisons retrieval for everything nearby. Update cost explodes: fix one manual and you are renegotiating the whole index.

Awkward leave-behind

What do you hand a team, a contractor, or an air-gapped box — a slice of a cloud vector DB?

Honesty has nowhere to sit

There is no natural place for a residual board per locus. Junk stays searchable because “cleaning the KB” means boiling the ocean. Bricks are not just tidy — they are the shape that lets honesty scale. That is how local LLM deployments look fine on hardware and fail on corpus fitness.

What a brick is (the elegant unit)

A knowledge brick is a portable ZIP you keep: structured stock for one clear locus, junk muted off the answer path and listed (LIBRARY_CARD and muted chunk flags — the residual board), plus a short craft_brief.md for what it is for and what it is not. Bounded to build. Bounded to update. Bounded to argue with. You point your existing model at that package — RAG the brick if you want; do not RAG the dump.

Human-sized blast radius

Scale is composition, not inflation. Ops manual in one brick, params in another, related by adjacency — not one soup. When a seam is obvious (separate files, volumes, domains), split. When one continuous work is one locus, keep one brick. The worst case you design for is the worst brick, not an infinite company index. Portable units. Honest holes per package.

A question that spans two loci does not require melting them. Compose the relevant bricks at query time — load ops and params (or point retrieval at both) via a small shelf manifest or your existing multi-index tooling. The model sees the bricks you chose for that job; it does not inherit the decade soup. See COMPOSITION_ArduPilot_Plane — Plane ops, Params, and MAVLink as separate bricks. Same split in the HF retrieval eval. The applied SharePoint case — melt vs shelf — is where composition meets a decade dump.

Compared to other processes (same job)

Dump → embed → RAG

Optimizes ingest speed. Fine for demos. Weak when the share is scans, chrome, and mixed years — retrieval will faithfully surface the mess.

Extract → markdown

Optimizes “words out.” Still not a signed leave-behind.

One platform KB

Optimizes central control. Often becomes the monolith above unless someone invents bricks inside it anyway.

Brick manufacture

Optimizes a portable, residual-honest unit you can keep, mute, and hand to your model. Different objective.

Simple at the door

Complexity belongs in the plant — not in a standing data team the end user must join. On the mill you drop files in the bin. You get a ZIP, or no charge. No open-ended “standup our RAG center” project required to try the method on one pile. $10 a brick are manufacture difficulty.

Argue with the package

Public brick shelf · HF retrieval eval. Open a ZIP. Read the card / mute list. Re-run the questions. If your method beats a milled brick on the same questions with clearer trust, show the package. Our bet: a truly better method will still look like a plant that ships honest leave-behinds — not a return to one unmutable company brain.