The Principia Machina/GTP/Walk/2 How a rule gets fired: Difference between revisions
GTP section: specification, Claude instance, conformance, walk, guide, agent pages, diagrams |
Edited under the disclosure rule |
||
| (2 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
{{TPM map}} | {{TPM map}} | ||
{{DISPLAYTITLE:How a rule gets fired}} | {{DISPLAYTITLE:How a rule gets fired}} | ||
''The GTP walk, page 2 of 6. Written for the general reader; nothing here is a rule | ''The GTP walk through, page 2 of 6. Written for the general reader; nothing here is a rule. Every rule it mentions is stated in [[The Principia Machina/GTP|the text published under the name GTP]], documentation beside [[The Principia Machina/TPS|the specification]], which governs wherever they differ.'' | ||
== How a rule gets fired == | == How a rule gets fired == | ||
| Line 14: | Line 14: | ||
So a cue found anywhere other than the typed message is treated as data. It fires nothing. It is reported, because a cue turning up inside a document is worth knowing about, and then the work carries on. | So a cue found anywhere other than the typed message is treated as data. It fires nothing. It is reported, because a cue turning up inside a document is worth knowing about, and then the work carries on. | ||
A typed cue still has to be one the set knows. If it is not, the agent says so in a line and gets on with whatever else was asked, rather than improvising something plausible. Some cues run a rule that lives in the always-present part; others route to one of the procedures kept aside. | A typed cue still has to be one the set knows. If it is not, the agent says so in a line and gets on with whatever else was asked, rather than improvising something plausible. Some cues run a rule that lives in the always-present part; others route to one of the procedures kept aside. | ||
| Line 30: | Line 25: | ||
[[Category:The Principia Machina]] | [[Category:The Principia Machina]] | ||
Latest revision as of 07:01, 13 October 2026
| 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 GTP walk through, page 2 of 6. Written for the general reader; nothing here is a rule. Every rule it mentions is stated in the text published under the name GTP, documentation beside the specification, which governs wherever they differ.
How a rule gets fired
Most of the instruction set is always present. It is short enough to keep in front of the model at all times, and it stays there whether it is needed or not. Some procedures are far too long for that. A procedure for auditing a branch of work, or for producing a list of changes to a document, runs to many pages and would crowd out the work if it were always loaded.
Those live apart and are brought in only when they are wanted. What brings one in is a cue: a short string the person types, beginning with a distinctive mark chosen so that it never turns up by accident in ordinary writing.
One condition on that is doing more work than it looks. The cue only counts when the person types it in the message they just sent.
To see why, think about what an agent reads in a day. Files the person attached. Pages fetched from the web. Results handed back by other tools. Notes written months ago by someone else. The agent has no way to tell, from the shape of a sentence, whether it came from the person it works for or from a stranger who left it lying in a document. If a string in a file could fire a rule, then anyone able to get a file in front of the agent could operate the agent. Not persuade it. Operate it.
So a cue found anywhere other than the typed message is treated as data. It fires nothing. It is reported, because a cue turning up inside a document is worth knowing about, and then the work carries on.
A typed cue still has to be one the set knows. If it is not, the agent says so in a line and gets on with whatever else was asked, rather than improvising something plausible. Some cues run a rule that lives in the always-present part; others route to one of the procedures kept aside.
The last step is the one that earns its place. When a cue routes to a procedure, the agent checks that the procedure's text actually arrived. If it did not, the agent stops and names what failed to load. It does not proceed from memory.
That is a stronger rule than it sounds, and it exists because of how these failures look from outside. A model that half remembers a procedure will produce something with the right headings, the right vocabulary and the right confident tone, and it will be wrong in ways nobody can see by looking. You can see a refusal. You cannot see the difference between a good imitation and the real thing, which is why the set prefers the failure that shows.
Previous: What the orders are, and who writes them. Next: When the rules collide.