The Cell, in plain words

What are we doing here.

§Start from a question you would hand to someone else

Say you are studying a press release and one of your four questions is: "which of these numbers are events that happened, and which are plans?" You could try to answer it yourself, right there in the main document. Or you could do what an analyst normally does with a well-defined sub-question — write it down, hand it with the material to a reader, and wait for a written answer you can check before you use it.

A Cell is the second option, built into the machine. It is a separate, walled-off pocket of the same log: its own tiny set of listeners and doers, its own rules about what it may hear and what it may do, and exactly one door out. Nothing that happens inside it is visible to the rest of the study until that door opens — and the door only opens once a person has looked at what came out and said "yes, use this."

§What a Cell is not

It is not a different kind of machine. Everything said in Part 1 about the log, listeners and doers is still true inside a Cell — a Cell has its own knots (listeners) and binds (doers), built from the exact same two ingredients as everything else in the machine. It is not a sandbox in the security sense either — there is no attempt here to stop a hostile actor; it is a sandbox in the editorial sense — a place where a delegated finding stays a draft until someone accepts it.

§The four moments this part covers

1. How one comes to exist. A Cell does not appear because someone clicked "new Cell". It is admitted, through a fixed, written ceremony: someone proposes a brief (a Charter — a title, a purpose, the question, and the criteria it will be judged against), the machine turns that brief plus a small inner design into a sealed package, and only a package that passes a long list of checks is allowed to open. A rejected proposal leaves no trace at all — nothing half-opens.
2. How it works while open. Inside, the Cell's one listener waits for everything it needs (a question, some material, the word to proceed); once it has all three, its one doer asks the world (a language model, in the sessions this book draws on) and gets back a structured answer — a list of findings, each tagged with a status.
3. How it is confirmed or refused. The answer is not trusted just because it arrived. An independent check grades it against the Charter's own criteria. Only after that grading does a person get to decide: Attest (accept it — the Cell seals, its finding is exported) or Archive (keep it as history, but never use it).
4. Where the results go. Accepting a Cell releases its finding through exactly one route back into the study — the same slot that asked the question in the first place. Nothing about a Cell's inner workings — its charter, its budget, its raw exchanges with the world — becomes part of the study directly; only that one accepted finding does, and it carries its own provenance wherever it goes.

§Why bother with all this ceremony for one question

Because the alternative — letting any sub-task write straight into the study's shared results — is exactly how a study loses track of what it actually knows versus what it merely asked a model. Fencing the sub-task off, writing down its brief, grading its output against that brief, and requiring a human decision before anything leaves is the cost of being able to say, afterwards, precisely where a claim in the final report came from and who signed off on it. The next file argues this is not a NestVM eccentricity — it is standard practice for handling any delegated piece of work, made mechanical.