# DISMISSED — capture bid/ask/sizes/quote-timestamp at order-submit time as a new forward stream

status: dismissed · scout evaluation, panel run 13 (2026-08-24) · frontier SCOUT half

---

**Killed because:** it fails the un-backfillable bar *as a capture stream*, and
no pinned decision currently needs it.

**What was evaluated.** At order-submit time the live path fetches the NBBO
twice — arrival mids in `src/thales/execution/daily.py:~1673-1681` and the
marketable-limit price in `src/thales/execution/pipeline.py:~304-319` — but
persists only the derived **mid** (`arrival_price`) and the derived
`limit_price`. Verified against live `data/processed/tca_log.jsonl`: records
carry {date, symbol, side, shares, decision/arrival/fill price, three bps
stats} — no bid, no ask, no sizes, no quote timestamp, not even a time-of-day.
So the spread-at-submit and quote state are discarded every day. The question
was whether to start capturing them as a new stream.

**Why it does not clear the four bars.**
- **Un-backfillable — FAILS.** Consolidated NBBO history is purchasable
  (TAQ / Polygon / Alpaca SIP), so the spread at a known timestamp can be
  bought later. The moat test is "own what cannot be backfilled"; this can be.
  The only genuinely un-backfillable residue is the exact tuple we acted on
  plus our own submit timestamp — a completeness gap in an *existing*
  registration, not a new stream.
- **Mechanism / consumer — no live consumer.** Both pinned TCA consumers run on
  slippage-vs-arrival-mid, which IS already captured: `timing_drag`
  (`tca.py:~210-244`) and the slippage report both use `arrival_price`.
  Bid/ask would only *decompose* that number into spread-paid vs impact —
  diagnostic, not decision-changing. `CAPTURES.md`'s `tca_fills` registration
  already claims the decision-time tuple, so this is a completeness defect of
  an existing registration, not an uncaptured stream.

**Recorded as a zero-cost fold-in, not a row.** On the next touch of
`pipeline.py` / `tca.py`, persist the already-in-memory `(bid, ask, sizes,
quote_ts)` plus a submit timestamp into the existing `tca_fills` / order_log
records. This amends the existing registration at ~zero marginal cost and is a
natural companion to the EXQ-1 fix (same files). It is not urgent because
nothing consumes it yet.

**Reopens if:** a pinned decision ever needs the spread-vs-impact decomposition
that arrival-mid slippage cannot provide — concretely, (a) a re-evaluation of
the `order_type` TCA gate, or (b) a December go-live-gate TCA dispute where the
50 bps median is contested and the question is "how much was spread vs impact."
Either makes the un-backfillable as-acted-on tuple decision-grade, at which
point the fold-in should already have been capturing it — so the fold-in is the
cheap hedge that makes the reopen answerable.