Eleven of the twelve orders were marked delivered inside an 86-second window, 8–11 seconds apart. The twelfth has real stamps, but they contradict each other. Before an agent can answer anything about lateness, ETAs or rider productivity, this one field has to become real — otherwise it will answer confidently and be wrong.
Promised slot, assignment and delivery for each order. Slots are drawn corrected by +5:30 — see the second finding. The wall on the right is the problem.
Ranked by what they block, not by how bad they look. The first two invalidate every time-based number in the console; the rest are hygiene that will bite as volume grows.
Δ is assignment minus corrected slot. Stamps counts how many of the five lifecycle events — assign, start, arrival, pickup, delivery — the rider app actually recorded.
| Order | Slot IST | Assigned | Δ | Delivered | Zone | Locality | Km | ₹ | Stamps |
|---|
You already own most of the machinery. The gap is not a model — it is a trustworthy event stream and somewhere in the console to put the answer.
deliverytime server-side from the rider’s delivery action, not from a screen cleared at nightdeliverydate as true UTC with Z, or true IST with +05:30 — not today’s mix of bothget_orders, get_rider_logs, zone_summary, data_quality_scantenantid server-side, from the session — never from a model argument/nearle/reports and /nearle/dispatch, opened from the existing header/ai/ask on Jupiter. Never call Anthropic from the browser