Research notes
Mirai Guide: one survival curve behind every answer
Collapsing three disagreeing shopping orders into a single function of time, so the route, the headline, and the leave time finally agree.
For a while the app computed three different shopping orders from two different notions of difficulty, and showed all of them to the same attendee for the same cart. The cart page ordered by a risk scalar. The live headline re-ranked that route. The plan page sorted by a curve quantile and ignored live stock entirely — so the “leave home by” time was derived from a walk the attendee was never going to take.
Why it split
The root cause was that the two difficulty measures answer different questions. A risk scalar returns a whole-day number; a curve is a distribution over when. Neither can be derived from the other, so each consumer picked whichever one suited it and drifted.
The symptoms followed from that. Stop numbers disagreed between pages for the same cart. The live headline hardcoded crowd-aware ordering, so someone who had deliberately switched it off still got it. Sold-out stops still consumed walk and queue time in the leave-time model, inflating the trip.
The collapse
Everything now reads one primitive: a per-item survival function over arrival time. Ordering, odds, and timing all consume it. A scalar cannot produce a leave time, but a survival function can produce a scalar — so the function is the primitive and the scalar is derived, never the reverse.
The requirements were written so a reviewer could reject an implementation that violated one, and two are worth repeating:
- No consumer may call the risk scalar directly for ordering. One scoped exception is documented rather than hidden: a server-side route endpoint runs without the curve artifact loaded, so it derives the equivalent linear ramp and its published ordering is unchanged.
- Behavior without a curve must be bit-identical to before. Curve coverage is partial, so the no-curve path is the common path, and the refactor was not allowed to move those numbers.
The result is that the cart, the live headline, and the plan order the same cart the same way, the departure recommendation is computed for the walk the attendee will actually take, and the crowd-ordering toggle means the same thing everywhere.
The honest part of the record
The plan document keeps the table of what was wrong, because every row names a bug someone could reintroduce. It also records that one follow-up change deliberately did move numbers — a clamp discontinuity fix, reviewed separately and measured on its own — rather than folding it into the refactor and claiming the whole thing was behavior-preserving.