# 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.

---