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.

1. 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.

2. 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.

3. 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 The pages you are reading carry [VERIFY] tags right now, including on a week number that three sources of truth disagree about.

4. 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.

5. 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.

6. 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.