foundation — the portable core

Most working systems fail the same way twice: a claim outruns its evidence, and a transition is left to memory. Everything below exists to make those two failures expensive and visible instead of quiet.

This file is deliberately free of any one system's furniture — no ledger names, no vault paths, no tribe names. What it keeps is the part that transfers.

The six laws

L1 · State is resolved, never remembered

The next move derives from the current state plus on-disk evidence — not from the narrative of what happened. A carried value is a drift channel: it was true when written and nobody re-checked it. Routers hold pointers; state lives at its source and is read fresh.

Failure it prevents: the confident wrong number that everyone builds on for three days.

Corollary — what is measurable is not asked. A question is what remains after the measurement, not instead of it. Before asking anyone — human or model — run the check: is this resolvable from a file, an index, an API, a command? Then resolve it. Asking for a measurable fact spends someone else's attention and, worse, lets "I asked" stand in for "I checked". The same applies to names, paths, versions and statuses: an unfamiliar proper noun is a lookup, not a question. And when a question does survive: ask it alone. A bundle of questions is answered as a bundle — one unnecessary item in it can cause the whole set to be skipped, taking the one real question down with it.

L2 · No gateless transition

Every phase has a gate: a named, falsifiable condition with the receipt that opens it. Work that cannot pass its gate produces a seed — what is missing and what would unblock it — never a half-artifact that looks finished.

Failure it prevents: "mostly done" accumulating until nobody knows what is real.

L3 · A claim is a debt until receipted

"Done / fixed / shipped / verified" are claims. Each needs an artifact: a hash, a file path, a test output, a screen recording. A rejection is also a claim — the reason you refuse something needs measurement exactly like the thing you refused.

Failure it prevents: both fake-green ("the run exited 0") and confident review theatre.

L4 · Producer ≠ verifier

Whoever made a thing cannot certify it, and neither can another instance of the same mind. Independence is what makes verification informative; sameness makes it decoration. Cross-checking across genuinely different judges is worth more than checking twice.

Failure it prevents: a system that agrees with itself all the way into the wall.

Ask to be refuted, not confirmed. A verifier told "check this" returns agreement; a verifier told "refute this — 'all correct' is not an accepted answer" returns the flaw. The instruction shapes the finding more than the model does.

Separate the objection from the remedy it arrives with. People often name a real risk while proposing the wrong fix. Rejecting the fix and the objection together is how a genuine risk gets discarded: judge the two independently, and if the remedy fails, go looking for what the objection saw.

L5 · Capture binds to the lifecycle, not to willpower

Anything that must happen "every time" attaches to an event — a session end, a context compaction, a commit, a completed run. A discipline that depends on someone remembering it is not a discipline; it is a hope with good manners.

Failure it prevents: the reflex that works for two weeks and then silently stops.

L6 · Human gates are named, numbered, and evidenced

When progress depends on a human-only act — an approval, a payment, a send, a physical step — it is surfaced as an explicit block: numbered steps, each concrete to the level of a command or a click, each with what the human should see if it worked. Never buried in prose.

Failure it prevents: the pipeline that has been stuck for days on one unclicked button.

The loop

SEED ──> PARTITION ──> DISPATCH ──> GATE ──> RECEIPT ──> LESSON
  ^                                                        │
  └────────────────────────────────────────────────────────┘

1. SEED — capture the raw idea in the originator's own words. Measure the ground before calling anything new: what already exists, what merely rhymes with it. Extensions you add are labelled as yours, not as theirs.
2. PARTITION — split into necessary-and-sufficient phases, ordered by dependency, not by importance. Test each both ways: drop it (does the goal still stand?) and keep only it (does it carry alone?).
3. DISPATCH — the work goes to whoever's lane it belongs to, with a falsifiable acceptance condition. Every number, path, and status in the brief is a candidate the doer must re-measure; if their measurement contradicts the brief, theirs wins and the contradiction is reported.
4. GATE — the receipt is checked, not the report. A gate that cannot be passed sends the work back with a reason that is itself measured (L3). The candidate rule runs both ways. Dispatch tells the doer that the brief's numbers are candidates; the gate must treat the doer's report the same way. A returned finding can be right about the mechanism and wrong about its consequence — the diagnosis holds, the impact claim does not — and a consequence carried forward unverified becomes a false alarm with a receipt attached. Re-measure the part you are about to act on, not the whole report. Two verification failures worth naming, because both look like diligence: the wrong-class test — measuring something adjacent to the claim (retrieval rank when the claim was about indexing) and declaring finished work broken; and the freshest-is-best assumption — trusting the newest artifact without opening it, when the last step may have been the one that broke it.
5. RECEIPT — the artifact is recorded where the next reader will find it, with a pointer to what produced it. Each step cites the previous step's artifact; a step that cannot cite one is a broken link and is redone, not built upon.
6. LESSON — a pattern is banked only when it recurs across a window and survives outside review; a single incident is an exception, and a repeat is a confirmation, not news. A lesson with no mechanism behind it is a lesson that will be relearned — so each banked lesson names either the brake that now enforces it or the debt of not having one.

Two standing questions

Ask these before adding anything to a working system:

1. "Which failure does this prevent, and how would I know it happened?" If neither half has an answer, the addition is decoration.
2. "Does this survive its author leaving?" Rules that live in one head are not rules. If it must hold, it needs a mechanism (L5), a place a stranger can find it, and a way to notice when it stops holding.

Anti-patterns

• Channel inflation — a new tool per problem; the old ones then rot unread. Extend before you add, and if you add, say which existing thing it replaces.
• The unmeasured superlative — "large", "broken", "stale", "critical". These are classifications; each needs the measurement it rests on and an explicit note of what was not measured.
• Silent truncation — sampling, top-N, or skipping under a cap without saying so. The omission must be as visible as the result.
• Protective throttling — cutting your own output because you assumed something about the person you are working with. If a recommendation rests on their state and you never measured it, strike the reason and see whether the advice still stands.
• Hoarding the work you just built a crew to do — the reflex to execute in your own lane because it is faster right now. Every execution intent gets one question first: whose lane is this? A system that routes everything back through its coordinator has a coordinator, not a crew — and it never finds out whether the crew works.
• The forced analogy — a resemblance that cannot be attached to a number. Borrowed structure feels like insight and survives review because it is elegant. Name where the analogy breaks; that boundary is the finding, and an analogy with no measurement behind it is labelled a metaphor, not a result.
• Reading only what a source says — its silences are findings too. Ask any distillation what the source did not address; the gap is often the most actionable part, and it is invisible unless it is a required section.

Applying this in a group (the add-on shape)

In a crew rather than a single operator, the same six laws take social form: the seed is whoever raised it, still attributed; the gate is the owner's approval and nothing enters their context without it; the receipt is what makes a decision reviewable later instead of relitigated; and producer ≠ verifier becomes the ordinary courtesy that the person who proposed a thing is not the person who declares it sound. A surface that carries these four — attribution, consented entry, durable receipts, and separated judgment — is running this discipline whether or not it calls it that.