diff --git a/docs/re/captures/ob-arrival-timing-confirmed.png b/docs/re/captures/ob-arrival-timing-confirmed.png
new file mode 100644
index 0000000..61d6b91
Binary files /dev/null and b/docs/re/captures/ob-arrival-timing-confirmed.png differ
diff --git a/docs/re/ob-counts-marked-attackers.md b/docs/re/ob-counts-marked-attackers.md
index a1fd0f0..c6cb409 100644
--- a/docs/re/ob-counts-marked-attackers.md
+++ b/docs/re/ob-counts-marked-attackers.md
@@ -1,7 +1,9 @@
 # 🟡 What `REMAINING OB` counts — the marked attackers, four per arriving squadron
 
-**Status: 🟡 HYPOTHESIS, assembled from existing measurements, NOT itself
-measured.** It is recorded because it is the first reading that fits *every*
+**Status: ✅ CONFIRMED for the counter's RISES — the `A`-route arrival times
+predict every step to the second (measured 2026-08-27, see below). 🟡 the
+DECREMENT half is still untested: no run has yet killed a marked attacker under
+observation.** It is recorded because it is the first reading that fits *every*
 number this corpus has taken, and because it makes sharp predictions that one
 run can kill.
 
@@ -224,3 +226,50 @@ unless the poll covers more than the objective. Unresolved here.
 * It does not explain the mechanism, only the arithmetic. The counter itself is
   the **HUD widget's value** ([`structures/mission-objective-counter.md`](structures/mission-objective-counter.md));
   where the mission keeps its own tally is still ❔.
+
+---
+
+# ✅ MEASURED — the arrival times predict the counter's steps exactly
+
+Stage 02, guarded route, stage asserted, mission clock sampled beside the counter
+throughout ([capture](captures/ob-arrival-timing-confirmed.png)).
+
+The prediction, made from the disc alone before this run: the three `A`-route
+squadrons `ADT102` / `ADT107` / `ADT113`, each `n = 4`, arrive at **t = 0 / 120 /
+210**, so the counter should read `004`, step to `008` at **t = 120** and to
+`012` at **t = 210**, and go no higher in phase 1.
+
+Observed:
+
+| mission `TIME` | `REMAINING OB` | |
+|---|---|---|
+| 00:12.33 → 01:45.44 | `004` | six samples |
+| **02:00.87** | **`008`** | step bracketed in **(105.4 s, 120.9 s]** |
+| 02:16.59 → 03:17.55 | `008` | five samples |
+| **03:30.66** | **`012`** | step bracketed in **(197.6 s, 210.7 s]** |
+| 03:47.19 → 04:36.95 | `012` | four samples, **no `016`** |
+
+**Both steps land on the predicted second.** 120 lies inside the first bracket
+and 210 inside the second, and the ceiling holds at `012` for a further 86 s of
+mission time.
+
+Three independent features — the starting value, the two step *times*, and the
+ceiling — were all derived from `Route_S02.tbl` and `UnitGroup_S02.tbl` with
+nothing fitted to the runtime data. ✅ The counter's rises **are** the `A`-route
+attacker squadrons arriving.
+
+(The digits render highlighted on exactly the two samples where they change,
+which is the game flashing the counter on update — a free extra confirmation that
+those two frames are the transitions.)
+
+## 🟡 What is still not measured: the decrement
+
+Everything above concerns the counter going **up**. That the counter goes *down*
+by one per marked attacker killed remains untested — the single observed
+decrement (`12 → 11`) came from a run whose pilot killed attackers, which is
+suggestive but is one sample, and this run killed nothing.
+
+The kill test is unchanged and is now the only open half:
+
+1. Kill ONE `e010` and nothing else → the counter must fall by exactly **1**.
+2. Kill a turret → it must not move.