2026-08-29 · Updated 2026-08-29 · 10 min read
Methodology, changelog, and citation guidance for recurring research
The cross-asset contract behind every recurring research asset this site publishes: the register of eleven shipped assets in three families, the five-declaration methodology template each one states, the append-only changelog rules, the floor every citation must meet, and the ownership every refresh answers to.
By Juno AI INC · evidence · methodology
Citing a living document is a bet on its maintenance. Every research asset this site publishes that can drift — a dataset cut from an upstream surface, a taxonomy grounded in sources that move, a matrix recording what released products support — carries the same four-part guarantee: a methodology stated before any claim, an audit record that only ever grows, a citation form naming exactly what a claim was true of, and an owner for the next refresh. Those rules were first written one asset at a time, on each asset's own page. This page is the layer they share: the template every asset states, the journaling rules all of them follow, the floor every citation must meet, and the ownership every refresh answers to. It is written for the two readers who need it most — an author about to cite one of these assets, and a maintainer about to inherit one.
Two boundaries hold throughout. Each asset keeps its own contract — the printed citation block, the identifier families, the stability terms — and those stay where they were published; this page owns the shared layer beneath them, plus the register that names every asset the layer governs. And nothing here was chosen by a demand estimate: the approved route record for this page owns zero corpus rows, no ranking or advertising metric enters any rule, and the admission test below is about maintenance, never popularity.
The register
Eleven shipped assets stood under this contract at the header's evidence date, enumerated from the pages that publish them — not from plans or intentions. An asset joins by passing four tests: it is original evidence or reference material from this site's research program rather than documentation of a released package; its claims can drift, because instruments behind them move; it carries an explicit versioning unit — a version, an edition, a dataset version, a manifest version — together with an append-only audit record; and it states what its refresh must do. Released-product documentation fails the first test by design: operational reference follows package versions, a different lifecycle with different owners. The eleven fall into three families, because they version for different reasons.
Content-addressed evidence — four assets that version because the bytes underneath them can be re-taken:
- the longitudinal leaderboard extract, a dataset whose entries are sealed under a content hash; refreshing means re-running the committed generator over a newly taken fetch and publishing the next dataset version, and the previous version's claims stay true of the bytes it named;
- the repeated-attempt variance summary, a pure derivation of that extract; when the parent refreshes, the summary republishes under a new version with new hashes, and a committed checker re-derives the summary from that same parent and fails closed if the two disagree;
- the repository benchmark case library, where each case is anchored to two commits — the base it applies on and the commit that grades it — so history holds the pins still; growing the set or amending a note ships the next library version under a fresh digest;
- the validated workflow example archive, whose files are frozen at their published digests inside a deterministic manifest; an upstream template change surfaces there as a new digest with a freshly recorded validation pass and a new manifest version, while every digest already published keeps naming the bytes it named.
Versioned references — five assets that version because a citation must resolve to a stable meaning:
- the coding-agent harness taxonomy, where permanent identifiers and boundary criteria are held by a policy that splits edits in two: a clarification that moves no boundary lands as a journaled in-place change, while anything that would reclassify a named system opens a new version;
- the coding-agent failure and recovery taxonomy, the same shape held over failure classes and the recovery each class routes to, with its grounding re-checked against committed sources on the standing cadence below;
- the Ralph-loop safety checklist, whose item numbering is protected at both ends — a retired item's number retires with it, and additions append new numbers rather than refilling gaps;
- the worktree parallel-agent reference architecture, whose component identifiers carry the same permanence and whose product contracts get re-traced against committed source every quarter;
- the agent-task dependency pattern library, five drilled shapes; a later version that grows or prunes the set arrives under a fresh evidence date, while the recorded drills keep describing the release they were run against.
Dated standing records — two assets that version because the world they record changes:
- the harness support and interoperability matrix, whose cells carry dates of their own: when a cell changes, the following page version records which cells shifted and when, untouched cells keep their dates, and cells awaiting released-artifact truth stay pending behind an external gate that no editorial statement may stand in for;
- the state-of-harnesses report, a numbered edition on a quarterly review: when an instrument has moved, the next edition derives every finding again from the instruments as they then stand, re-dates the header, and names which findings changed — and an instrument joining or leaving opens a new edition of its own.
The methodology template
Before an asset claims anything, it states five things. No register member ships without them:
- Instruments. The exact bytes behind every claim — pinned by content hash, per-file digest, or dated extract. An asset never cites the live web as its evidence; it cites a sealed copy it controls, so that a citation names the bytes a claim was read from.
- Admission. The rule a claim must pass to enter: numbers recompute from the pinned instrument, observations are checkable against the recorded source at its date, and nothing enters by editorial assertion. The rule is written once and binds every claim the page carries.
- Limits. The inherited bounds, stated once and traveling with every claim — including one this whole site holds: a value that was never observed is never flattened into a number. That vocabulary has its own owner in the honest evidence semantics guide; recurring assets inherit its discipline rather than restate it.
- Evidence date. The day the instruments were read, printed in the header and moved only by a journaled act.
- Derivation. The command or rule that recomputes a claim from its instrument, committed beside the asset, so a reader can re-run the chain without asking anyone's permission.
For a new asset, the five declarations fit one block:
The changelog policy
Four rules, binding all eleven:
- The audit record only grows. Nothing already published is overwritten in place. The record takes one of three forms: six members keep an on-page changelog; the pattern library's journal opens with its second version, as its page promises; and the four content-addressed assets keep the immutable sequence of published versions, where an old version's claims stay true of the bytes it named. Whichever form it takes, a correction that leaves no trace in the record did not happen.
- The versioning unit belongs to the asset. Edition, version, dataset version, manifest version: the unit is named where the asset prints its contract, and it moves whenever the content moves. A reader who cannot tell that the ground shifted under a citation has lost the one signal every rule here protects.
- In-place edits clarify; they never re-decide. Fixing a wording, tightening a definition, linking a companion whose route has shipped — all allowed while no finding, classification, or cell moves, and all journaled with the date they landed. The harness taxonomy's journal shows the pattern: each entry records what changed and, just as deliberately, what did not.
- No change is a result. A scheduled pass that lands on every instrument unmoved records that result, and the standing version number holds. A correction runs the erratum floor in the report's sharpest form: an error that leaves a finding's direction standing is repaired in place with a journal entry, and one that would reverse it is pulled by a journal entry and succeeded by the next version — never smoothed over.
What a citation must carry
Three fields form the floor, before any asset-specific form applies: the asset's stable URL; the versioning unit at the version cited; and the evidence date the claims were true of. Strip any one of the three and the citation stops being checkable — a dateless citation asserts a permanence no asset in this register has ever claimed, and a versionless one leaves the reader guessing which journal state the words came from.
The asset's family then decides what joins the floor. Content-addressed assets add the digest, so the citation names bytes. Identifier-bearing references add the identifier, so the citation names a meaning. The support matrix adds the cell's own date, because its cells drift separately and a page version is not precise enough. How to cite is stated on each member's own page, in the form that fits it: the identifier-bearing references print a block to copy, the remaining members except the archive state their required fields in prose, and the archive — which states no citation rule — pins the digests a correct citation of it would name. This page sets the floor those forms must meet and does not replace them.
One more obligation travels with the floor: name the upstream when an asset wraps one. An extract cut from someone else's surface owes that surface the attribution this site asks for its own assets; the dataset page records the upstream board's own request beside its download for exactly this reason.
Update ownership
Every asset declares which of two refresh modes it answers to, on the page that publishes it. Standing cadence: five assets — the harness taxonomy, the failure and recovery taxonomy, the safety checklist, the worktree architecture, and the state-of report — commit to a quarterly pass over the sources behind them. Event triggers: the remaining six wait on a specific movement — a new upstream fetch, a parent dataset refreshing, a shipped template changing upstream, new cases or revised notes, an addition or retirement inside a pattern library, a support cell moving (a pending one only when the external gate answers) — and each names its trigger where it prints its contract.
What a pass must do is the same in either mode: re-derive every claim the instruments ground, as the instruments now stand; journal the no-change if nothing moved; ship the new version, re-deriving and naming what changed, if something did. The rule this page adds across all eleven: a refresh never arrives as an unannounced rewrite. The versioning unit is the only signal a citing reader has that the ground under a quotation shifted, so it must move with the content, every time.
The register itself is maintained under the policy it states. It was enumerated from the shipped pages at the header's evidence date. An asset joining is a new version of this page with a fresh date, because coverage is part of what citers relied on; a factual correction to an entry lands as a journaled in-place change; an asset leaving is a new version for the same reason.
Version 1 and how to use this page
This page is an asset under its own register — version 1, evidence-dated in the header, journaled here, refreshed under the ownership rules above.
- Version 1, 2026-08-29 — the register opens. Eleven shipped assets in three families, the five-declaration methodology template, the four-rule changelog policy, the three-field citation floor, and the two-mode update ownership. No prior version exists, and nothing was superseded by it.
Citing one of the eleven? Open its page and copy the block it prints. Building the twelfth? Start from the template above — and when your asset adopts this contract, cite this page for the rules it runs under.