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.

PC-1 — ceiling on the cap-explained book (owner policy; now with a measured consequence)

status: open · migrated 2026-08-21 · consequence: the meanrev runaway-guard freeze of 08-19/20

⚠ EXPIRED · NOW WITH A MEASURED CONSEQUENCE · PC-1 — pin a ceiling on the "turnover cap" escape (owner judgement)

Raised panel 2026-08-06 · measured 2026-08-07 while amending PR #88.

health._check_position_count excuses any book-size excess when the last selection's turnover hit its cap. That escape currently has no ceiling, so a permanently-throttled sleeve stays "explained" at any size.

Why it is not a code decision. The bound was pinned at 2x target FIRST, as the panel required, then measured: meanrev holds 129 against a 52-name target (2.5x) — its cap binds every day, so exits defer indefinitely. So:

  • 2x reds the negative control every day → alert fatigue, the class this shop keeps paying for;
  • 3x clears 2.5x — but choosing it because it clears the observed value is the bound being fitted to the behaviour it polices, which is the exact failure PC-1 was raised to prevent;
  • unbounded (today) leaves the hole the panel found.

There is no defensible way for an agent to break that tie: every option is either an alarm you will learn to ignore or a number fitted to data. It needs a policy call — is a 2.5x book acceptable for a never-promotable control?

Options: (a) pin a ceiling on principle and accept meanrev reds until its book converges; (b) exempt the control sleeve explicitly and record why; (c) treat meanrev's book size as a known-degraded state and pin the ceiling for weights sleeves that are NOT the control.

Kill criterion: if after pinning, the ceiling neither fires in 6 months nor changes any decision, it is decoration — remove it and record that the unbounded escape was acceptable all along.

Effort 0.25 pd once the policy is chosen. Horizon no expiry, but it sits in live alerting code, so the longer it stays undocumented-by-default the more it reads as considered.

Triage note — 2026-08-24 (annotation only; the body above is untouched)

Its 08-31 dismissal-by-default is triage's own, and this run withdraws the evidentiary basis for it. Triage run 2 (2026-08-17) recorded: "Unless decided by 2026-08-31, triage run 5 will recommend moving it to ## Dismissed with the unbounded escape recorded as accepted by default." Panel run 11 already flagged that this rested on pre-halt evidence. That evidence has since been falsified in the direction that STRENGTHENS the item:

  • The unbounded escape's cost stopped being hypothetical. The book grew until meanrev's legitimate daily batch crossed the runaway guard, and the control sleeve fail-closed for two consecutive trading days (2026-08-19 and 08-20, n_submitted 0 against 209 and 161 targets). Clearing it took an owner config change (955db93, max_orders_per_run 150→300).
  • The ratio the policy call was framed around has moved against the do-nothing option. PC-1 was written at 129 held against a 52-name target (2.5x). As of 2026-08-24 the book is 219 held against 73 targeted (3.0x) and still climbing (173→185→196→196→196→219 since 08-17). A 3x ceiling — one of the three options the item lays out — would already be breached by the observed value.

Consequence for the default: triage run 4/5 should NOT complete a dismissal-by-default that was reasoned from 2.5x and no measured consequence. The item's premise holds more strongly than when the default was set. The decision is still the owner's and still a policy call — but "accepted by default" is no longer the honest resolution of silence here, and this run says so rather than letting a stale default run to completion.

Recorded because a default that outlives its evidence is the exact rot the default was invented to prevent.

Triage note — 2026-08-31 (annotation only; the body above is untouched)

Two things happen to this row today, and they point opposite ways. Both are recorded rather than netted, because the honest state is "the escape is still unbounded, and the alarm case for it is weaker than last week said".

1. Its dismissal-by-default deadline arrives today, and triage is not executing it. Triage run 2 (2026-08-17) wrote: "Unless decided by 2026-08-31, triage run 5 will recommend moving it to Dismissed with the unbounded escape recorded as accepted by default." The 08-24 run withdrew the evidentiary basis for that default. That withdrawal stands, on the leg that has not moved: health._check_position_count still returns True for any book size whenever the last selection hit its turnover cap (src/thales/execution/health.py:104-110, re-verified at HEAD 528793d), and the two fail-closed meanrev sessions of 2026-08-19/20 really happened and really needed an owner config change (955db93) to clear. A live alerting escape with no ceiling is not "accepted" by anyone having failed to answer an email. The default is not executed, and it is now retired rather than re-dated — a default that has been withdrawn once should not be left standing to fire on a later run.

2. The escalation the 08-24 note used is FALSIFIED, and must not be quoted forward. That note said the meanrev book was "219 held against 73 targeted (3.0x) and still climbing". Verified against data/state/meanrev/portfolio_snapshots.jsonl at HEAD: 08-24 219 → 08-25 203 → 08-26 207 → 08-27 206 → 08-28 203. The book plateaued and turned down; the ratio is ~2.7x, not 3.0x, and "still climbing" is false. The turn is attributable to RWG-1 leg 1's resolution, not to convergence of the book.

Consequence for the decision. The three options the body lays out are unchanged and the tie is still the owner's to break — but the observed value is back inside the range where a 3x ceiling would NOT be breached today, which materially changes what option (a) costs. Whoever answers this should answer it against 2.7x-and-falling, not 3.0x-and-climbing.

One piece of rot found while verifying: the in-code comment at health.py:94-103 points the reader at research/RESEARCH_QUEUE.md — the frozen pre-migration archive — rather than at this file. Cosmetic, but it is the pointer a future maintainer follows.

Triage note — 2026-09-07 (annotation only; the body above is untouched)

Correcting last week's correction: the book did not keep falling. It climbed 47 names in two sessions, peaked at 250, and is now 239. The 08-31 note told whoever answers this to "answer against 2.7x-and-falling". Re-measured this run from data/state/meanrev/portfolio_snapshots.jsonl:

08-28  203  →  08-31  233  →  09-01  250  →  09-02  248  →  09-03  243  →  09-04  239

Against the sleeve's own targets in data/state/meanrev/order_log.jsonl (09-04: 101 targeted), the current ratio is 239 / 101 = 2.4x. So the honest framing is neither "2.7x and falling" (08-31) nor "3.0x and climbing" (08-24) but oscillating between roughly 2.4x and 3.0x with no trend — which is itself the answer to the question the row asks. A book that has spent a month between 2.4x and 3.0x is not converging toward its target; the escape is doing exactly the load-bearing work the row said it was.

A 3x ceiling would not fire today (239 < 3 x 101 = 303), and would have fired on 08-24 (219 vs 3 x 73 = 219). Whoever answers this should know the observed value has already crossed and re-crossed the candidate bound — which strengthens the row's own objection to choosing 3x, since the bound would be fitted to a quantity that moves.

The escape itself is unchanged at HEAD (e25f80b): src/thales/execution/health.py:104-110 still returns True for any book size when the last selection hit its turnover cap. Still the owner's policy call; still ~15 minutes to answer and ~0.25 pd to build.

The in-code rot the 08-31 note found is also unchanged: health.py:100-101 still points a future maintainer at research/RESEARCH_QUEUE.md, the frozen pre-migration archive, rather than at this file.