# OSR-1 — 130 market replacements were REJECTED by the broker after the local log recorded them ACCEPTED, and no channel can see a broker-side terminal rejection: the order log is write-once at submit, the digest counts local `failed` only, reconcile compares ID sets

status: open · raised 2026-09-05 (maintainer verification of the external design review r2 — a side finding from pulling broker truth for its finding 1; NOT in the review) · class: truth divergence between layers (the AI-native audit's recurring class) · judgement: **YES** · effort ~0.25–0.5 pd · horizon: fired on the 08-28 and 08-31 displaced-cron sessions; recurs on any post-close submission, and applies to every sleeve's exits

---

**Plain-language summary for an owner reading one paragraph.** The system
writes down an order's status once, at the moment it hands the order to the
broker. If the broker later refuses it, nothing comes back to correct that
line. On the two displaced-cron days, 130 of the market orders that replaced
unfilled limits were refused by Alpaca at the next morning's pre-market
processing. The local log says ACCEPTED for every one of them; the daily
digest counted zero failures (it only counts orders that failed *at
submission*); the reconciler reported no drift (it checks that the two sides
hold the same order IDs, not what became of them); and the 08-31
displaced-cron memo assumed those orders would "fill at the next open". The
positions self-heal because each run recomputes from the broker's actual
positions, so the economic effect on the never-promotable meanrev control
was a one-day delay. But the blindness is structural and sleeve-agnostic: a
broker-refused *exit* on momentum would look identical — green digest, clean
reconcile, ACCEPTED in the log.

## Ground truth (read-only broker pull, 2026-09-05; 45-day window 07-23 → 09-04, 3,255 broker orders)

- local meanrev replacements (`market_replace_of` set): 546, of which 544 in window;
- replacement terminal statuses at the broker: **filled 412 · rejected 130 · expired 2** (2 predate the window);
- rejected, by local batch date: **08-28 → 45** (broker `submitted_at` 2026-08-31T11:00Z, i.e. Monday 07:00 ET pre-market) · **08-31 → 85** (2026-09-01T11:00Z);
- side: 90 buy / 40 sell · type market · all fractional quantities;
- local `order_log.jsonl` status for all 130: `OrderStatus.ACCEPTED`;
- the *fresh selection* limit orders of the same two batches: **none** rejected — only the post-close market replacements were;
- cause: the orders endpoint carries no reject reason; not determined here — see data plan. Not recorded anywhere in the repo before this row (the 08-31 memo counts the batches and assumes fills).

## Why nothing sees it — verified at HEAD `cd571b2`

- `state.log_order` is append-only; the replacement's record is written at
  submit with `"status": res.status` (`daily.py:1252-1258`), the batch's the
  same way in `pipeline.py`. There is no status-update record type.
- `digest.py:114`: `failed = [o for o in todays_orders if
  str(o.get("status","")).lower() == "failed"]` — local submit-time failures
  only; the `!! N FAILED orders` line (`:550-551`) that the 07-21 audit added
  cannot count these.
- `reconcile.py:135-160`: symmetric difference of order-ID sets; `status` is
  carried in the report rows and never compared.
- **FOS-1** (open) computes per-symbol streaks from the same local log, so it
  inherits the blindness.
- `ops/DAILY_AUDIT.md:146` asks the daily audit to check failed/rejected
  orders against broker truth (`portfolio orders`) — the routine was
  quota-starved on exactly those days (self-audit 2026-09-02, M1), which is
  the only reason this was found by hand.

## Fix shape (propose-only)

1. **Terminal-status sweep**, at the start of the next run or in the digest
   gather: for local orders from the prior N sessions whose recorded status
   is non-terminal, fetch broker status by `client_order_id`
   (`AlpacaBroker.get_order_by_client_id` already exists) and append a
   `status_update` record — the log stays append-only, and the sweep is
   idempotent per (order, terminal status).
2. **Digest**: count broker-terminal `rejected` / `expired` (and `canceled`
   not initiated by us) as failed; FOS-1's streak logic reads the updated
   status, which closes its inherited blind spot for free.
3. **Reconcile**: a status-divergence section — local non-terminal vs broker
   terminal — report-only, so the RUNBOOK's step 2 actually answers "did what
   we sent happen?".
4. **Data plan for the cause**: read the rejected orders' `failed_at` /
   account activities, or reproduce on the paper account by submitting one
   fractional market order after the close. Record the reason on this row
   before designing any behavioural change (e.g. holding replacements until
   the session opens is a *policy* change that goes through the owner).

## Test design + negative control (CQA-1 doctrine)

- `SimulatedBroker` fixture where one submitted order transitions to
  `rejected` after submit → the next run's sweep appends a `status_update`
  and the digest renders `1 FAILED`; revert the sweep → `0 FAILED` (today's
  behaviour).
- Reconcile fixture with the same divergence → the new section names the
  order; revert → "OK — local matches broker".
- Idempotency: running the sweep twice appends one update, not two.

## Kill criterion — pre-registered

If the sweep shows the broker exposes a reject reason that explains all 130
as one benign class already healed by re-selection, **and** the owner rules
the one-day delay acceptable for the control sleeve, the *policy* question
closes — but legs 1–3 still stand: the defect is that no layer could see it,
not that it happened.

## Cap note for triage

Fold partner **FOS-1** (same digest surface, same log; leg 2 is literally its
missing input). The reconcile leg must survive any fold.

---

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

**FOS-1 shipped, and it shipped ON TOP of this row's blind spot. Leg 2 is no
longer merely a fix — it is now load-bearing for an alarm that is live.**

This row's own cap note said *"Fold partner FOS-1 (same digest surface, same
log; leg 2 is literally its missing input)."* FOS-1 was built instead, alone,
in PR #154 (`ee68ebe`, 2026-09-06) and now sits in `queue/built/` recorded as
shipped. Verified leg by leg at HEAD `e25f80b` — **#154 closed none of this
row's four legs:**

- **Leg 1 (terminal-status sweep) — not closed.** #154 modified `cli.py`,
  `digest.py`, `failed_streaks.py` (new), `pipeline.py` and tests;
  `state.py`, `daily.py` and `reconcile.py` were not touched. There is still
  no `status_update` record type in `state.py`, and nothing calls
  `get_order_by_client_id` to refresh a recorded status. The market
  replacement is still written once at submit with `"status": res.status`
  (`daily.py:1385-1392`).
- **Leg 2 (digest counts broker-terminal rejections) — not closed, and now
  worse.** `digest.py:114` is byte-for-byte the line this row quotes:
  `failed = [o for o in todays_orders if str(o.get("status","")).lower() ==
  "failed"]`. Everything #154 added reads from that same list — the streak
  machinery runs only `if failed:` (`digest.py:121`) and
  `failed_streaks._index` classifies on the same local field
  (`failed_streaks.py:66`). A broker-side rejection leaves
  `OrderStatus.ACCEPTED` on the record, so it enters neither `failed`, nor
  `failed_new` / `failed_standing`, nor the new exit-4 escalation
  (`cli.py:1138-1163`).
- **Leg 3 (reconcile status divergence) — not closed.** `reconcile.py:133`
  still merely carries `"status"` into the report row; the comparison is
  still the symmetric difference of order-ID sets (`:137,:140,:144,:165`).
- **Leg 4 (the cause of the 130) — not closed.** `pipeline.py:355-356` now
  keeps the broker's rejection text, but only on the **submit-time**
  `record["status"] = "failed"` branch (`:354`) — the AVB case. Nothing
  records why an order accepted at submit was refused later.

**Why this raises the row rather than lowering it.** Before #154 the
blindness was a reporting gap. Now the system's newest alarm — the one that
reds the run (exit 4) when a de-risking order fails — is built on the field
that cannot see the failure class this row measured 130 instances of. The
row predicted exactly this (*"FOS-1 ... inherits the blindness"*); it is no
longer a prediction. And 2026-09-08 is the first live session to exercise
the exit-4 path at all, so its first exercise is a blind one.

Ground truth unchanged and not re-pulled this run (no broker credentials in
this container): the 130 rejections of the 08-28 and 08-31 batches are
recorded in the row above from a credentialed pull on 2026-09-05.