Guide 4: Branching a thread and requesting closeout
| The Principia Machina: map |
|---|
| Reading the diagrams Structure key Process key Definition of terms Roles |
| Reading by audience Start here: the walk through The operator's guide Tutorial: create a UUID Workspace Container (UWC) Public Recorder inputs Sponsors: your first agent |
| The specification Contents: parts, tables, diagrams TPS 0.5.0 (declared 2026-10-03, revision 8; machine-optimized text) Decisions (the foundations record, one line each) |
The operator's guide, page 4 of 4. It assumes the walk through. Each page states its purpose and scope, gives the procedure, works one example, and links what governs it. The worked examples are drawn from the Claude instance; the rules they follow are GTP's, which governs wherever this guide and it differ.
Purpose
Move a body of work into a thread of its own with written terms, and bring it to a proper finish.
Scope
Asking for a charter, starting the new thread, what to expect while it runs, and reviewing the request that ends it. Not covered: the subject matter of any particular branch.
Procedure
- Ask for a charter, naming the topic. What comes back is a single block: the terms of the work, what is in and out of scope, what is already established, what is still open, and the obligations on offer.
- Read the scope before you paste anything. The charter is the only place the boundaries get set cheaply; changing them later costs a round.
- Paste it whole as the first message of a new thread, and attach every document it names. A charter that arrives without its documents will halt, correctly, at its own first check.
- Expect the checks to be answered one by one before any work begins, and a path declared. A halt here is the charter doing its job.
- Expect one obligation per turn, and each in two parts: what will be done and how it could fail, written down first, then the doing. If the first part is missing, the second is not worth reading.
- Expect the branch never to declare itself finished. What it produces at the end is a request, listing every obligation and how it ended, every question raised and who owns it, every value produced and how it was arrived at, and every edit it owes another round.
- Answer that request one of three ways: approve it, return it with a list of repairs and reopen the branch to that extent only, or record that the work is sound but has not yet reached the holdings, which is a different job's problem.
- Check the docket for anything left without an owner. A question with no one responsible for it is the thing that quietly disappears.
Worked example
This branch began from a charter pasted into an empty thread with two export files attached. Its first check failed: the pattern document the charter named was not present, and the charter's own routing said to halt rather than reconstruct it from memory. Rather than abandoning the work, an alternative was selected, the already-published section on this wiki standing in for the missing pattern, with every house rule read from it marked as read rather than given. The obligations then ran one per turn, and two of them stopped partway when a decision was owed.
Governing sections, in the Claude instance: its branch and review procedures, MRG.
Guide contents: the section contents. Previous: Vetting an input and handling a detection. Next: the section contents.