The schema is the product

Every field in the principle template is load-bearing. Not stylistic. Load-bearing. serves: is not organization, it is the input to a graph walk that catches orphans. last_reviewed: is not metadata, it is the input to the staleness check. supersedes: is not a link, it is the audit trail that keeps the record honest. Take any one of them out and a review mechanism downstream stops working. Put them all in and you did not build features. You built a schema, and the features fell out.

That is the claim this post defends: a life operating system is not a list of features. It is a schema decision, made once, early, and everything that later feels like a good product move was already implied by it.

Life in Spec Files made the case for keeping a life in version-controlled files at all. Last week's post described what happened when three repos disagreed about what those files contain, and the CI check that now fails when they drift. This one is about why the schema deserved that defense in the first place.

The orphan a chat log cannot catch#

Here is what a schema catches that prose never will. The example is illustrative rather than lifted from my corpus, but it is structurally exact.

A Sunday review session opens with the coherence report, before any writing. The report flags an orphan: a project with a serves: list pointing at a goal that does not exist. Not a goal that failed. A goal that was retired two months ago, in a file whose status: changed and whose dependents never got re-pointed. The project had been absorbing hours every week in service of nothing.

I have kept journals that would never have surfaced that. A chat log with an AI assistant would not have surfaced it either, because the conversation has no structure a graph walk can traverse. The orphan was caught because serves: is a typed reference, the reference had a dangling target, and a script walks those references on a schedule. Drift became a diff. That is the whole trick.

Ten fields, each one buying a mechanism#

The template ships ten frontmatter fields, and the schema file is canonical for all of them; templates/principle.md points at it rather than restating it, for exactly the reasons last week's post laid out.

Field	The mechanism it buys
title	The principle as one actionable sentence, not a category
status	The lifecycle walk: draft, active, contested, retired
kind	The revealed/aspirational split, and the falsification clause below
domain	A closed enum, so a coverage check can see which domains are starved
confidence	An honesty dial the review interrogates rather than a badge
serves	The upward graph edge; the orphan check traverses it
created	The age of the claim
last_reviewed	The staleness check; unreviewed principles surface on schedule
ended_on	Terminal states get a date, so retirement is a fact, not a fade
supersedes	The audit trail; a replaced principle stays in history

There is no id field. The filename is the id, which sounds like a shortcut and is actually a position: identity lives in the filesystem, where git can see renames, not in a database column the corpus cannot inspect.

The kit's steering doc states the design goal in four words I will quote rather than improve: engineering artifacts are "written down, dated, diffable, and revisited." Lives deserve the same rigor. Each of the ten fields exists to make one of those four words mechanical.

The falsification clause is the whole game#

The field that earns its place most is kind:. The kit's methodology doc defines the split: a principle is either revealed, backed by evidence of how I have actually behaved, or aspirational, a rule I want to live by and cannot yet demonstrate. The template forces the question with a ## Falsification section: what evidence would force this principle's retirement?

The clause is machine-checked. The kit's validator, scripts/validate.py, fails a revealed principle that carries no evidence references. A revealed claim with no evidence is a lie the schema catches before a reviewer ever reads it. An aspirational principle that accumulates behavioral evidence has earned promotion, and the promotion is a visible edit to kind:, in a diff, with a date. Both transitions leave history. Neither happens silently.

Compare that to every notes system I have abandoned. They all held claims about who I am. None of them could hold the claim to a standard of proof, because a standard of proof needs structure: a place evidence attaches, a type that demands it, a check that fails without it.

What the schema costs, and why the cost is the point#

A loose note takes five seconds. A schema'd principle takes ten minutes, and most of those minutes go to the questions I would rather skip. What does this actually serve? What would falsify it? Is this revealed or am I flattering myself with the word?

Ten minutes of friction per principle is the price, and the purchase deserves precision, because this is the center of the argument. Each awkward question maps to a field, each field feeds a check, and each check runs without me. Discipline I have to remember is discipline I will eventually skip; I wrote a whole post about recall being the exact faculty that fails. The schema moves the discipline into structure, where forgetting is not an option. The schema is the product. The Sunday report, the staleness sweep, the audit trail, the promotion rule: those are consequences.

The same shape shows up in context architecture: the pile of documents was worth little until structure let each task load a curated slice. A corpus without a schema is a pile. The pile feels productive to grow. Only the schema makes it consultable, checkable, and honest.

The contract the self implements#

Spec-driven development works because the spec is a contract and the code implements it. When the code drifts, tests fail; the contract, not the memory of the author, is what holds. SpecSelf is that idea moved one altitude up. The schema is the contract, and the self implements it: behavior supplies the evidence, reviews audit the claims, and the corpus refuses to let a flattering assertion sit unexamined next to a falsifiable one.

If you take one move from this post, take the smallest version of it. Before adding a single feature to whatever system holds your own record, decide the fields, and make each one buy a mechanical check. Without a schema it is a diary. With one it is a spec, and specs can fail loudly, which is the only reason to trust them when they pass. The Starter ships the ten fields and the validator so you can start from a schema instead of a pile.