principles
Rules with origin stories
Every one of these is a constraint the code actually enforces, not a value statement. Where a rule exists because something went wrong, the thing that went wrong is written down next to it.
[DRAFT] These pages have not had a voice pass yet, see design/brand.md. The rules are settled; the prose isn't.
- 01
A human approves everything that leaves the system
No timer publishes. Every outbound post passes a person first, and the switch that would change that ships defaulted off.
why The autonomous-posting switch exists. It is called AUTO_POST, it defaults to false, and in the entire history of this platform it has never been turned on.
- 02
One writer per table
A single command-line tool owns the content lifecycle. The publishing tool and the client-facing workspace are projections of it, never sources of truth.
why Two surfaces showed a piece of content in two different states, and there was no principled way to say which one was right. There is now.
- 03
An unverified number gets a label, not a guess
If a figure isn't in the config, it ships marked [VERIFY]. A plausible number is worse than a missing one, because nobody checks it.
why A week number on this site's own landing page was flagged [VERIFY] for days because three sources of truth disagreed about it. The flag came down when the vault was fixed, not when someone picked the flattering number.
- 04
Redact by allowlist, and fail closed
Everything published here is built field-by-field from a literal, scanned before it is written, and the scanner aborts the whole export on a single hit.
why A goal line in a config file contained a colon, so it parsed as a map instead of a string, so the scanner was handed the text "[object Object]" and passed it. Found on 2026-08-03, while building this page.
- 05
The log is the product
Every agent action writes an evidence record. The records are hash-chained, so editing history is detectable rather than merely discouraged.
why Anyone can claim an agent did the work. A hash chain is the difference between a claim and a record.
- 06
Code and client data live in different repositories
The engine is one repo. Every install's data is a separate vault the engine reads through an environment variable. They are never mixed.
why A single install can serve several clients. The first time client work lands in the engine repo, you can no longer hand the engine to anyone.
- 07
A tool's description is untrusted input
Everything an external tool publishes about itself is loaded into the model's context before a single call is made. It is data that arrives looking like instructions, so it gets read and graded before adoption, by something that is not the model.
why A live commercial MCP server scored 89.86% on configuration and still graded F, because one tool's 6,290-character description stopped describing the tool somewhere in the middle and started addressing the agent reading it. Graded 2026-09-03, audit b8535ab0.