Mirai Guide: planning a day backwards from the thing you want

The hardest question at a goods event is not “what do I want” but “what time do I need to get up.” Mirai Guide answers it by computing the whole day backwards from the item most likely to sell out.

The backwards timeline

Every step is derived right-to-left, so the chain terminates in a wake-up time:

• The target entry time for an item is a function of its risk curve and the attendee’s own risk-tolerance dial.
• Through-the-doors target is the earliest target entry time across everything in the cart.
• Venue arrival subtracts the entry-queue wait expected for that arrival offset.
• Leave home subtracts transit duration and the station walk.
• Wake up subtracts a personal preparation buffer.

Two design rules keep it honest. Every output renders as a range with a confidence band, never a single minute, and the interface says plainly that the plan is a 目安 — a guideline. And transit duration is never computed in the app: timetable data is licensed, so the attendee confirms a duration through a prefilled deep link to a transit service and that number is stored locally only.

The corpus that calibrates it

The model learns from an authored historical corpus rather than from whatever the app happens to observe. It is built in the repository, versioned, and uploaded through the admin panel — never seeded straight into the database.

The bundle carries two record kinds. Sellout events are the fact table: official day-of sellout announcements. Observations hold everything else in a tidy long shape — one row per measurement, with an observation kind (queue wait, throughput, growth, booth or item popularity, context constants, calibrated model parameters), an optional scope, a subject, a metric with units and optional low/high bounds, an optional located point in time, and provenance.

Two properties of that shape matter more than the schema itself:

• New covariates go into a free-form features object, never a migration. A future precision model can read the table directly without the schema chasing it.
• The build is deterministic. The same authored sources produce a byte-identical bundle, so diffs are clean and the hash is stable. Applying it is append-only with content-derived IDs, which makes re-applying the same bundle a no-op — re-author one row, rebuild, re-upload, and only that row lands.

Rows carry their source and a review state, and rows whose source time is illegible are surfaced as diagnostics and skipped rather than quietly becoming facts.

Provenance is a design constraint, not a footnote

The historical sellout data is re-derived from the official announcements that are its primary source. A community compilation proves the data exists and is used as a read-only cross-check — not copied — and its author is owed credit before launch. That constraint shaped the ingestion path: the corpus records where every row came from and how confident it is, because a prediction that cannot show its provenance is not something to put in front of someone deciding when to wake up.