# PIT-1 — the pit snapshotter greens while producing nothing (or garbage that permanently occupies its slot): three silent shapes, bleeding under the displaced-cron regime

status: open · raised panel run 16 (2026-09-01), executing the 2026-08-31
daily-audit memo's detector hand-off (item c), change-review verified and
adversarially narrowed · class: moat / loudness (capture path — the P0 shape:
a green step with an empty product) · judgement: **YES** · effort ~0.5 pd ·
horizon: live now — bleeds on any momentum run displaced past Tiingo's EOD
publication; two of the last four trading days already bled permanently

---

**Plain-language summary for an owner reading one paragraph.** The
point-in-time signal snapshotter — one of the forward-capture streams the
charter calls irreplaceable — can finish green while writing nothing, and can
write a nearly-empty file that then *blocks its own repair forever*. Last
week's displaced crons exercised all of it: 08-26 is missing outright, 08-27
and 08-28 hold 123 and 58 rows against a ~890 median and can never be healed
(write-once), and 08-31's run wrote nothing at all behind a green
"Point-in-time snapshot" step. The proposed fix makes the writer loud and
self-protecting: refuse thin writes (so the slot stays open for a
same-day retry), and make "nothing was written" a visibly non-green outcome —
without ever letting a capture failure fail-close trading.

## Mechanism — three shapes, all verified at HEAD `29c6f23`

1. **Exit-1 swallowed green.** The no-data paths exit 1
   (`src/thales/cli.py:4700-4702`, `:4725-4727`) but the workflow step is
   `continue-on-error: true` (`.github/workflows/paper-trading.yml`,
   deliberately, so a capture failure can never fail-close trading — that
   design choice is correct and this row must preserve it), so the job shows
   green with nothing produced.
2. **Stale-date idempotent skip.** `cli.py:4706` defaults the snapshot date
   to `prices["date"].max()`. A displaced run that fires before Tiingo
   publishes today's EOD sees *yesterday* as max; yesterday's snapshot
   already exists → write-once skip (`src/thales/data/pit_snapshot.py:106-108`)
   → exit 0, honestly green, nothing written. This is what happened 08-31
   (run commit `bca9ae3` contains no pit file).
3. **Thin write permanently occupies the slot.** `build_snapshot` has no row
   floor, so a very-late run persists whatever partial EOD rows the vendor
   has published (08-27 = 123 rows, 08-28 = 58 vs ~890 median), and
   write-once idempotency then blocks any heal — pit has no heal path
   (skew has one, `options_skew.py:433-448`).

**Honesty note:** the thin writes were not fully silent — capture-qa's
existing 50%-of-trailing-median floor caught 08-28, which is the repeat 🔴
mail. The true claim is: green **workflow**, permanent **slot consumption**,
and misattributed alerting (the alert-naming half is CQA-2's row).

**Boundary vs the STAMP family (state it so triage doesn't merge them):**
STAMP-1/2 are defects of `date.today()` — the runner's UTC wall clock used as
stamp and idempotency key. PIT-1's date comes from `prices["date"].max()`, a
**data-lag-derived** date; the STAMP fixes (ET normalization, trading-day
guard) never touch `cli.py:4706` and would not stop this bleed. Distinct
mechanism, distinct fix site. GAP-1's `capture_gaps` detects interior holes
after the fact and deliberately stops at the stream's own latest capture, so
it cannot prevent (or even promptly see) a trailing hole; SAC-1 is
trading-path persist sites. No overlap.

## Fix shape (propose-only; narrowed by adversarial review)

1. **Row floor at the writer**: refuse to persist a snapshot below the SAME
   50%-of-trailing-median convention `capture_qa` already commits to for this
   stream (`src/thales/data/captures.py:819-826`) — reuse that
   function/threshold, introduce **no second tunable number**. A refused thin
   write leaves the slot open for a later-same-day retry (heal-lite for
   free).
2. **"Nothing written" becomes a distinct non-green outcome** surfaced on the
   observability channel (a separate failing step after the trading steps, or
   a QA/digest condition naming `pit_snapshots`) — while the trading job
   still completes.
3. ~~A heal path modeled on skew's~~ — **struck by review** as a second
   mechanism/new surface; parked as a separate owner decision if the retry
   window proves insufficient in practice.

## Test design + kill criterion (pre-registered, negative-controlled)

- **No-quote fixture** → the observability channel reds naming
  `pit_snapshots`, AND a co-registered negative control asserts the trading
  job still completes on the same fixture. (Without that clause the fix's
  laziest implementation — deleting `continue-on-error` — passes its own
  test while violating the never-fail-close-trading doctrine.)
- **Thin fixture** (rows < the reused floor) → write refused loudly, file
  absent, slot still writable; revert the floor → only its test reds.
- **Stale-date fixture** (prices max < today on a trading day) → distinct
  "nothing written for <today>" outcome, not a silent green skip.
- **Falsifier:** if the reused floor rejects a legitimately small day
  (real universe shrink) within 20 shadow trading days, the floor convention
  is wrong — record it and re-derive from history; do not tune the threshold
  after seeing the failure. Since the floor is capture-qa's own, such a
  failure indicts a convention the QA layer already committed to, which is
  the honest outcome either way.

## Data plan

None — owned committed state (`data/pit_snapshots/`, workflow logs, git
history) plus static code. No external source, no cost.

## Urgency, stated honestly

The 08-31 hole was healable only if the 09-01 run fired before ~23:30Z; the
panel is propose-only and cannot act on that. Under Monday's ~5.7h delay mode
the defect is a benign one-day lag; under the ~9h mode it bleeds a permanent
day each session. Which mode this week runs in is not knowable from here —
the row's case is that the writer should not depend on the scheduler's mood.