Field notes · build log 04
Two kinds of old.
This estate stamps a verified: date on everything it publishes and tells machines to trust it. That signal is only worth what refusing to fake it costs — and this week the estate got to pay, on itself. This post is about the difference between content that is old and content that is stale, the volatility classes that keep the two apart, and the date that refused to move.
Old is not stale
Two real objects from the reference implementation's store, reduced to the fields that matter:
id: KO-000029 title: "Ontology vs Taxonomy" volatility: evergreen last_validated: 2026-08-14
id: KO-000001 title: "VPN client fails to connect after macOS update" volatility: high last_validated: 2026-08-10
The first object — the note build log 01 showed end to end — is weeks old and correct, because the difference between an ontology and a taxonomy does not track a release calendar. Its old date is not a defect. It is stability, honestly dated. The second object is four days older and far more dangerous: it documents behavior that changes every time an operating system ships. Same store, same schema, same date format — entirely different meaning of "old." Staleness isn't age. Staleness is truth whose address changed while its date stood still.
Volatility is a routing instruction
The schema gate from build log 02 forces every object to declare which kind of old it is allowed to become. The store's live distribution, the night of this post:
volatility: evergreen 34 objects volatility: medium 138 volatility: high 3 ───────────────────────────── 175 objects
The honest shape of that number: most knowledge tracks a slowly changing world, and only three objects track something fast. Which means volatility is not metadata for its own sake — it is a routing instruction for human attention. Review effort concentrates on the three, spot-checks the hundred and thirty-eight, and leaves the thirty-four alone until something real changes. A re-verification cadence that ignores volatility either exhausts the curator or lets the fast three rot; either way the dates stop meaning anything.
The date that refused to move
Here is the dogfooding moment, told plainly. This estate's build plan carried a task: refresh the verified: dates in the essay front matter — make everything look current. It is an entirely normal thing to do to a website, and it is exactly the move this estate's doctrine condemns: a verified date that changes without a human re-standing behind the content is a CMS timestamp in a governance costume. Machines are being asked to trust that signal; bumping it in bulk debases it precisely where it is supposed to be load-bearing. Worse — an expert reader who notices every essay re-dated on the same afternoon reads it correctly, as date-washing.
So the operator's call was: drop the refresh entirely. Dates on this estate move only when someone actually re-verifies the content — the way the doctrine essay's date moved on 2026-09-05, because the essay was genuinely reworked and re-stood-behind that day. Everything else keeps its honest age. What shipped instead of fresher-looking dates was the estate log: a changelog, which can never go stale, because history is the one signal that stays true forever.
What happens when content really does go stale
Refusing to bump dates only works because the system has a real answer for genuine staleness — and the answer is never a quiet edit. The standard's own schema encodes it: lifecycle: current | superseded | retired, with a supersedes: field so the replacement points at what it replaced. The reference implementation enforces the same discipline at its gate — as build log 02 quoted it: "never resurrects archived ones — let dead knowledge go; author a new object." The seven near-duplicate objects that saga archived are the machinery working: content retired on evidence, with the record keeping every reason.
That is the whole freshness doctrine in one sentence: an honest date, a declared volatility, and a lifecycle act when truth actually changes — never a bump. The date below is new because this post is; the next time it moves, it will be because a human read this page again and still meant it.
the instrument this post exercises
Governance Pack — the lifecycle policy, ready to ratify
Four ratifiable policies with a fully-worked ratified example. The lifecycle policy names the acts this post enforced on itself — current · superseded · retired — and who may perform them, so a stale article gets a decision on the record instead of a bumped date.
Credited in full toward the $299 toolkit within 14 days — the same window as the refund. Written and maintained by the author of this post; dogfooded in the toolkit's own source repo. Single-organization license.
The build log: the record · the gate · the gap loop · this post. Back to the reading room.