DISMISSED — AUTO-APPROVE — pre-register which classes the machine may approve without the owner

status: dismissed by TRIAGE 2026-08-31 · OVERTAKEN by the queue-as-directory migration (47e8e73, 2026-08-21) · raised 2026-08-10 · body verbatim below

Resolution — the mechanism it specifies can no longer be built

Killed because its premise was falsified by a change this shop shipped after it was written. The item specifies an evaluator that "reads each Open item and moves any that satisfies every criterion into the approved section mechanically." Since 2026-08-21 the approval gate is not a section, it is a PATH, and scripts/automerge_guard.py:189 denies every agent write to research/queue/approved/ — added, modified, renamed-in, any git status. No agent-executed evaluator can perform the move the item describes. Verified at HEAD 528793d: zero auto_approve references in config/, src/ or ops/, and the guard's approved-path denial reproduces against the real classify().

Two further facts recorded so the reopen is cheap:

The 8-week dry-run clock never started. The item pre-registered "if 8 weeks of dry-run would have approved fewer than 2 items, drop the idea." No dry-run was ever run, so that criterion has accrued nothing and must not be read as having lapsed.
This dismissal removes the pre-committed decide-item for kill-counter (a). ops/QUEUE_TRIAGE.md:103-105 commits that at 8 weeks with no owner move into approved/, AUTO-APPROVE is re-surfaced as decide item #1. That counter stands at 4/8 today. Whoever re-surfaces it at 8 must rewrite the mechanism first — the old one is unbuildable — and this file is where the owner's own risk-tolerance values (max_effort_days: 0.5, require_kill_criterion, the allowed/forbidden class lists, max_per_week: 2) are preserved verbatim for that rewrite.

Reopen condition. Reopen the moment EITHER (a) the mechanism is rewritten against the directory gate — the plausible shapes are a guard carve-out for a signed evaluator, or the owner's own credential executing the move, and both are governance changes the item's own forbidden-class list arguably excludes; OR (b) kill-counter (a) reaches 8 weeks, whichever comes first. On (b) it reopens as decide item #1 by pre-commitment, rewrite or no rewrite.

Triage note: this is a dismissal of a mechanism, not of the idea. The owner's question behind it — "what would it take to get fully out of the loop?" — is unanswered and is worth more than the answer this row proposed.

Body as filed (verbatim, untouched)

AUTO-APPROVE — pre-register which classes the machine may approve without the owner

status: open · migrated 2026-08-21 from RESEARCH_QUEUE.md (verbatim below)

AUTO-APPROVE — pre-register which classes the machine may approve without you (owner policy)

14. AUTO-APPROVE — pre-register which classes the machine may approve without you. · judgement: YES · effort 0.5 pd · horizon: no expiry, but it compounds — number 14 assigned by triage 2026-08-17. It was the only Open item carrying no **N. row, which made it invisible to the fleet digest's item counter and uncitable by number in every report since 08-10. Identifier only — the text below is the owner's own, unedited.

Raised 2026-08-10, answering the owner's "what would it take to get fully out of the loop?"

Phase 1 (records-only auto-merge) removed mechanical CLICKS. This is phase 2, which removes JUDGEMENT — and therefore cannot be written by an agent. The mechanism is easy; the risk tolerance encoded in it is the owner's.

Mechanism. A research.auto_approve block; an evaluator reads each Open item and moves any that satisfies every criterion into the approved section mechanically. Same shape as the December go-live gate: decide ONCE, in advance, in writing, and the machine executes that rule instead of asking weekly. Nothing is delegated that the owner did not write.

Proposed values, to accept or amend (deliberately tight — loosening later is cheap, tightening after something slipped through is not):

enabled: false — nothing moves until the owner sets it true
max_effort_days: 0.5
require_kill_criterion: true
allowed classes: loudness, instrument-calibration, hygiene
forbidden classes: strategy, capture-activation, governance
max_per_week: 2 — a cap, so a bad week cannot flood the pipeline

Dry-run first. Ships disabled; triage reports "these N items would have been auto-approved under your rule" for a few weeks. The rule is observed before it acts.

Why the forbidden classes are permanently forbidden: strategy work may only enter via a fired pre-registered activation (charter §4 P1); capture-activation spends money or commits to a data stream; governance items ARE the owner's appetite. None is delegable by any rule.

Kill criterion: if an auto-approved item ever yields a PR the owner would not have approved, the rule was drawn wrong — disable, record which criterion failed to exclude it, and do not re-enable without changing that criterion. Conversely, if 8 weeks of dry-run would have approved fewer than 2 items, the machinery is not worth it — drop the idea.

Effort 0.5 pd. Horizon no expiry, but it compounds: every week it is off is a week of decisions made by hand that were already decided in principle.

Append 2026-10-07 (panel run 36) — reopen leg (b) HAS FIRED, twice. This file still says 4/8.

Leg (b) is "kill-counter (a) reaches 8 weeks". It reached 8 at the 2026-09-28 triage and stands at 9 of 8 as of 2026-10-05. Triage #218's own counters block states it: "(a) 9 of 8 — FIRED, second week." The 2026-10-05 triage email's subject line carries it to the owner (GATE UNUSED 9 WEEKS), and the 09-28 one before it (GATE UNUSED 8 WEEKS); both re-surfaced AUTO-APPROVE as decide item #1, which is exactly the pre-committed action at :23-30. So the pre-commitment was honoured — nothing was skipped.

What was not honoured is the record. :26-27 still reads "That counter stands at 4/8 today", an 2026-08-31 figure. The firing exists only in the two outbox emails (origin/outbox/triage, b84593c and 0413ef5) — a branch no routine reads in the ordinary course.

Verified independently this run, from the full history (the cloud checkout arrives as a depth-50 shallow clone, which makes this arithmetic unreadable without git fetch --unshallow — noted because it silently truncates any counter a routine computes from git log):

git log -- research/queue/approved/ returns exactly one commit in the directory's entire existence: 47e8e73, 2026-08-21, which created README.md — not an item.
research/queue/approved/ holds 0 items today, 47 days on.
Corroborated by research audit #196 ("the approval gate is 0 of 13").

Why this is worth an append rather than nothing. The queue-as-directory migration's whole memory guarantee is that ls research/queue/dismissed/ plus a grep shows every adjudication with its tripwire attached. A future panel or the monthly research audit greps this file, reads 4/8 against a reopen condition of 8, concludes NOT-FIRED, and either skips a live tripwire or "discovers" it fresh and mints a row — relitigating a question already put to the owner twice. That is the ERN-1 failure class (a conditional kill reachable only through an artifact the panel cannot find), and ERN-1 was migrated for it.

State of the two options at :32-37, so the owner's choice is current. Option (a) — "the mechanism is rewritten against the directory gate" — has not happened. Option (b) is the live one, and its standing remedy is already on the table: PR #197 item 1(b), open since 2026-10-01 and untouched, which offers the owner the choice of granting triage the dismissed→open move. Nothing here asks for a new decision; it asks that this file stop asserting a number that would hide the one already pending.

This append changes no verdict. AUTO-APPROVE stays dismissed; the dismissal was of a mechanism, not of the idea, and that is unchanged. Only the counter is corrected.