ADR-047: Promotion is audited in small persisted batches, ranked by expected yield, with decisions recorded apart from status changes

Context

The promotion audit of 2026-10-19 (curation entries of that date, PR #165) found a mismatch in a few entries it happened to look at. Their proved cores were Proposed, because their promotion conditions bundled a proof with a broader claim. The audit was not a systematic search. The backlog it drew on is large: the pending-decisions report counts 843 undecided documents. An earlier session had also lost progress to a timeout, so work kept only in a conversation is at risk.

The owner proposed an incremental procedure the same day, and asked for it to start in a new pull request. The owner then asked for “some kind of persistent file on the PR to represent, track, and version the queue”, so that progress can be handed off if a session is interrupted.

Decision

Three levels of effort. Triage ranks 20 to 30 candidates from metadata only. An evidence audit reads at most five candidates in full, with the records they rest on. A promotion pull request changes at most three entries.

The rubric orders work and decides nothing. Each candidate is scored out of 20: evidence already in the record (5), how clear the promotable scope is (4), downstream reliance (4), how cheap verification is (4), and how low the risk from known objections is (3). A high score earns an early review, not a promotion.

Waves. Demonstrated CLAIMs still Proposed come first. Then come THEORYs with verified mathematical cores, then source-backed THEORYs, then dependency unlocks (entries resting on something just promoted), and last broad interpretive claims. The order adapts: each batch records its yield, and a wave whose yield falls drops in priority.

Six dispositions. promote, narrow-and-promote, split, retain-proposed, needs-correction and defer. Every disposition other than promotion names a specific blocker. “Needs more evidence” is not a blocker; naming the missing result is.

Persistence.

• record/promotion-audit/queue.yaml is the queue. It is versioned: each change bumps version, appends to history, and records the record revision it was taken against. Its handoff block names the batch in progress, the candidate under review, and the next step, so that a fresh session can resume from the file alone.
• decisions/<CODE>.yaml is one file per reviewed candidate, with its reviewed_revision. A review that is older than the entry’s last change is stale.
• batches/batch-NNN.yaml is one file per batch: what it reviewed and its yield.
• check.py fails if the queue and the decision files disagree: a candidate marked decided with no decision file, or a decision file whose disposition the queue does not show.

Transactions. A batch selects and persists its candidates, reviews no more than five, writes each decision as soon as it is reached, updates the queue, runs the check, commits, and stops. If an interruption comes, the queue’s hand-off block and the decisions already committed are the checkpoint. A candidate gets at most two rounds of supporting retrieval per pass before it is deferred with its blocker.

Review is not promotion. A decision file changes no status. Promotions follow in their own pull requests, each citing the decision it carries out.

Alternatives considered

• One large audit in a conversation. It loses everything when the session is lost, which is the failure this decision exists to prevent.
• A queue derived from the decision files alone. This is DP-2’s preferred remedy, and it was the first design. It cannot record what is in progress or what to do next, which is what a hand-off needs, and the owner asked for the queue as a file. The decision files stay the record of outcomes, and check.py guards the property that the two agree. That is DP-2’s second remedy.
• The curation journal. Its entries are dated and never rewritten, which suits a narrative and not a queue whose states change. Each batch stays one file, as a journal entry would be.
• Reviewing and promoting in one step. It mixes the evidence decision with the edit. A batch can succeed with no status changed.

What a re-derivation counts for

Added 2026-10-19, at the owner’s decision on batch 007’s question. Some promotion conditions ask for a proof the record does not hold: an independent proof, a reading of the original, or a second source. A checked, step-by-step re-derivation recorded in the decision file meets such a condition, and the THEORY is promoted, with the derivation cited in its history note. That is what THEORY-004’s promotion did. The rejected alternatives were to file the derivation only as a demonstrated CLAIM and leave the THEORY Proposed, and to hold the entry until the source is read. The re-derivation must be in the decision file, step by step. A summary that says it was checked is not enough.

What one study counts for

Added 2026-10-19, at the owner’s decision on batch 011’s question (THEORY-191, THEORY-192). An empirical THEORY can be promoted on one study, with no replication, when all three of these hold:

• its title claims no more than that study measured, with the study’s own hedges kept (for example, “has the signature of X, not of Y”, not “is X”);
• the NOTE on that study read it in full;
• nothing in the record contradicts it.

If its promote_when asks for a replication or a second study, that request moves unchanged to a new QUESTION, as other out-of-scope promote_when clauses do. A title that generalises past the study, to other systems, scales or trained models, is narrowed to what was measured first, or else stays Proposed. The rejected alternatives were to require the replication that the promote_when asks for, and to put each case to the owner.

Where a narrowing’s dropped claims go

Added 2026-10-20, at the owner’s decision. Narrowing decides what an Active entry may say. It does not decide that the rest is worthless, and until now nothing said where the rest goes. The default had become to drop it. Every clause a narrow-and-promote removes from a title, or moves to “What this does not say”, is now routed to one of four places, and the decision file says which, clause by clause:

1. A generalization the source or the literature asserts becomes a new Proposed THEORY. It keeps the old wide wording and the same source, and it extends the narrowed Active entry, which is its evidence. It inherits the old promote_when. Example: a general law of neural collapse, beside the Active entry for the runs that measured it.
2. The record’s own extrapolation or gloss becomes a Proposed CLAIM with an interpretive warrant (ADR-032, ADR-043), whose grounds name the narrowed entry.
3. A mis-statement or a clause shown false gets a dated note only. A wide form that was imprecise, or that the source’s own results contradict, is not a proposal worth keeping.
4. Open scope that nobody asserts becomes a QUESTION, as before.

When a clause could be read as either kind 1 or kind 3, the decision file says why it chose. A narrowing PR files its kind-1 and kind-2 entries in the same PR, within the limit of three status changes. A new Proposed entry is not a status change.

The retroactive sweep. Every earlier narrow-and-promote, and as a lower-priority check every promote, is sorted by this rule in triage-008 (record/promotion-audit/triage-008.yaml). The kind-1 and kind-2 entries are then filed in batches of five. The Active entries are left as they are: the sweep adds Proposed entries beside them and re-reviews nothing.

The rejected alternatives were to restore the wide titles and demote the narrowed entries, which would undo correct reviews; to leave the dropped claims in the narrowed entry’s body, where nothing can confirm or reject them as theses; and to file every dropped clause as a QUESTION, which asks without proposing.

Consequences

• Any session can resume an interrupted audit from queue.yaml, without the conversation that started it.
• The queue is hand-maintained, so it can drift. check.py is the guard. Per DP-4 it was fired once against a deliberately broken queue before being relied on (record/promotion-audit/README.md says how).
• Decision files cite codes. Codes in YAML are not linked or upgraded by luria repair, so the ledger uses concretized codes, and a temporary code is recorded together with the entry’s file name.
• Promotion pull requests take longer to arrive, since review and edit are separate. In exchange, each one is small enough to check.