Three pictures: how a document becomes a served store, how a question becomes an answer, and
how many users read one store without ever sharing a file.
1. The factory: from a document to a served build
A baseline build ingests every tier; an additive build ingests only what the ledger says is
new or changed, then rebuilds the indexes over the cumulative store. A build that fails a
gate is never registered. The build id is a canonical hash of the output, and a rebuild from
the same input reproduces it byte for byte, which is how “the same dataset” is proven rather
than asserted. Shipping is a pointer swap validated by re-opening the live store; if the
validation fails, the previous build is re-activated before the failure is reported.1
2. The query path: from a question to a cited answer
The knowledge is never inside the model. The model reasons over a small, sparse context that
was retrieved and can be inspected; every node carries the document it came from, so an
answer is traceable to source and a wrong node can be corrected, retired or re-minted without
touching a weight. Bench figures for this path are on Stages, measured.2
3. Many readers, one store: the layered stack
Every layer is physically its own directory in the same on-disk format, stacked into one read
view at query time. That is what makes isolation cheap: offboarding a tenant, honouring a
deletion request, or backing up one organisation is “remove or snapshot the directory”, never
“compact a shared store”. A domain base, a data-pack and a customer overlay are the same type
of thing, a store root in the stack, which is why one mechanism serves all three. The
admission-control work that keeps one slow tenant from stalling the others is measured on
Stages, measured, stage 9.3
Sources
Numbers on this page are quoted from the lab's own records. The records are private; each note gives the record's date.