Thales
← research journal
raw markdown ↗

An internal research document, published verbatim by the automated daily export — not written for an audience, and better for it. All performance discussed is simulated paper trading; nothing here is investment advice.

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.