How the library works.

The library

Three parts. All three are the product.

Two honest modes

What the data says. Or what can be derived, labelled as derived.

When the data has the answer, the librarian says what the data says. When the direct path does not serve, it analyzes: correlates, contrasts, clusters or derives a workable answer from the sources it holds, and labels it as derived, naming the technique and the evidence. What it never does is produce an answer it cannot trace.

SUM AMOUNT OF INVOICES
  WHERE VENDOR "Acme" AND MONTH "2026-10"
→ 14,210.00 · 12 of 14 invoices carry an amount · epoch 41

DERIVE GET VENDOR FOR FILE "inv-0923.pdf"
→ Acme Corp · derived
  method: letterhead extraction + vendor list match
  evidence: section 1, 3 prior invoices · confidence .91

Security

The boundary is the product’s shape, not a feature on it.

No client holds a source credential. The librarian holds the connections, reads the rows, joins and derives inside, and only governed results cross out. Each identity, a person, an agent or an application, is granted a scope when it is admitted, declared alongside the library’s purpose; every change the team proposes is graded against those scopes before it ships.

Refusal is structured, never silent. An agent that asks beyond its scope gets scope_denied with what it may ask instead; a result narrowed by scope says so in its envelope. Agents declare their intent with the request (IN CONTEXT) rather than having it sensed from headers or location, which the specification prohibits. The same grammar that forces an agent to commit to meaning is the grammar that bounds what it can reach.

Your manba team

Who keeps the library alive, and how.

The team is organized by what it keeps true: meaning, the model, the sources and the plant, change and its proof, signals and governance. The desk is the service as consumers meet it. Every role acts through the language, as a proposal; every proposal is graded by the benchmark; every step is an entry in one open ledger, which is also the only channel the roles have to each other and to you. Roles run at one of three autonomy tiers, self-publish, review or approve, set per library, and anything beyond a role’s tier becomes an action item for the owner.

The benchmark grades against ground truth the library did not write: the figures a publisher printed, the examples the owner confirmed, the difference between two versions. Cases the engine authored for itself never count toward its own score. Every version is deterministic: same question, same version, same answer; and a version is a self-contained bundle that can be copied, served elsewhere or carried offline and still pass its own benchmark.

Lenses

A lens is a playbook.

A substrate is raw material mounted once: a Drive, a database, an archive. A lens is a declared interest over it: what to extract, what the words mean here, which entities and fields matter, what to expect to be asked, what counts as proof, and who stewards it. Many lenses sit over one substrate, added at any time, each with its own benchmark. “Tell it you care about invoices” is adding a lens.

Because a lens is a procedure and not a description, it travels: an invoices lens written over one Drive runs over another with its declared facts swapped. And because the model is the artifact, a version of a library travels too: replicated near the people who ask, embedded in another application, or carried fully offline, an almanac on a phone in a field with no signal, answering from the model with every answer carrying its source and vintage. designed; the first offline bundle is in build

Future-proof

Smarter models make the librarian cheaper, not unnecessary.

The question comes up: once models are smart enough, why a librarian? Because capability does not dissolve access. A smarter agent still does not hold your credentials, your scope, your consent or your contracts, and it still does not get to declare what your words mean. The more capable the agent, the more the boundary matters. Meaning still needs an owner, and what was asked and answered still needs a record. None of these are model-capability problems, so better models do not remove them.

The librarian is also built to be the layer itself: no large model on the retrieval path, small task experts pinned per version and able to run where the data is, a compiled fast path for answers and a slow path for analysis, everything deterministic at a version. The thought experiment we hold ourselves to: could this replace the upper half of a modern file system, over a durable store, with lenses and native agent support as the bonus? The answer is yes, and it is testable at demo scale.