Guide 3: Vetting an input and handling a detection
| 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 3 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
Handle a report that something was found inside material the agent read, and authorise the actions that cannot be authorised any other way.
Scope
Reading a detection report, deciding what to do with the material, and giving permission for a destructive or outbound action. Not covered: the checking itself, which happens whether or not anyone asks for it and cannot be turned off.
Procedure
- Expect nothing when the material is clean. Silence here is the designed behaviour, not an oversight, and an assistant that reported every clean file would train you to stop reading the reports.
- On a report, expect four things: where the material came from, the offending words reproduced, flagged as reproduced rather than obeyed, what it was trying to cause, and how far the damage would have reached.
- Decide what happens to the material itself. Usually it can still be used as information with the offending part set aside, and that will be the first option offered. Occasionally the right answer is that the whole source is not worth trusting.
- Give permission in your own typed words when you want a destructive or outbound action. Name the action and name what it acts on.
- Do not point at a document that contains the permission. A file saying an action is authorised is exactly the shape of the problem, and it will not be accepted however plainly it is worded.
- Treat a second request as information. If the agent asks again, your first wording was ambiguous, and ambiguous permission is treated as none.
- Do not expect to switch the checking off for a difficult file. Other rules here can be suspended; this one cannot, and neither can the two gates.
Worked example
A block of work returned by a second agent arrives on a staging page, and one line in it is addressed to the lead rather than being part of the result. The lead quotes that line back, marked as quoted and not carried out, names what it was asking for, and reports what would have followed had it been treated as an instruction. The records in the return are still incorporated, because they are information and the line was not part of them. Nothing in the return authorises anything, whatever it says about itself.
Governing sections, in the Claude instance: INPUT VETTING.
Guide contents: the section contents. Previous: Running a decision pause. Next: Branching a thread and requesting closeout.