Move Decider — Japan Mobility Decision Engine

Inspiration

I live in the mountains of Echigo-Yuzawa, Niigata, and work remotely for a company in Tokyo. Four or five times a year I travel down for an on-site week, and every time I lose half a day agonising: drive on toll roads? Save the tolls on national roads? Take the Shinkansen and leave the car behind? Sleep in the car two nights? Navigation apps answer "how do I get there". Nobody answers "which way should I go, on my numbers" — and because these trips are self-funded (no expense account), every wrong choice comes straight out of my own pocket. So I built the accountant I wished existed.

What it does

Move Decider compares every realistic strategy for a trip and prices each one four ways: cash, door-to-door time converted at your personal value of time, comfort/convenience ratings, and seasonal risk. It then recommends one — and shows the break-even points: at what value of time the answer flips, and how much the joy of driving would have to be worth for the car to win honestly. It runs on a calibrated personal profile: my car's real fuel economy (an old Honda N-BOX at ~14 km/L), the 25 minutes down the mountain to the station, the fact that I listen to podcasts while driving (driving hours count at half price), and my rest-stop habits. Three live cases ship with the demo: a real 5-night Tokyo work week replayed from actual bookings, the same trip in snow season (where the risk layer vetoes two strategies), and a day trip to an exam in Maebashi.

How I built it

Three layers, deliberately separated: (1) A deterministic costing engine (Python) — generalized cost from transport economics (Becker 1965), the attribute structure of random-utility / discrete-choice models (McFadden 1974), and segment-based time accounting in which different kinds of travel time carry different prices. (2) A region data pack — prices as structured data with source, date, and confidence (verified receipt vs. labelled estimate). Corridors are packs: Tokyo ships now, Maebashi is a preview pack, flights and Europe are future packs on the same engine. (3) An explanation layer (NVIDIA Nemotron on Nebius Token Factory) — the LLM receives only the engine's computed table and may explain, compare, and flag unknowns. It is architecturally forbidden from inventing numbers: fixed output schema, every figure traced to the engine, estimates labelled, unknowns listed rather than smoothed over. The demo's signature interaction: drag the "enjoyment value of driving" slider. Below ¥4,250 the Shinkansen wins; above it, the model flips its recommendation to driving the national road and sleeping in the car — not as a gimmick, but because travel-time research (Mokhtarian & Salomon, 2001) shows travel itself carries positive utility. Other tools silently assume your time on the road is pure loss. Mine asks what it's worth to you, and prices it.

Challenges

Keeping the LLM honest is a design problem, not a prompting problem: numbers had to come from code, with the model confined to language. Real prices are messy: ETC discount windows, advance-purchase Shinkansen fares, a parking lot that is free 8 months a year. The pack format (source/date/confidence) exists because a single wrong "verified" price destroys the whole premise. My own assumptions kept being wrong in interesting ways (fuel, rest stops, the car waiting at the station) — the profile system exists so the model can be corrected by living, which is also the product's moat.

What's next

Flight module (baggage fees, airport access, check-in buffers — the LCC total-cost trap), a Tokyo⇄Europe sample pack, and opening the pack format so multi-base remote workers can calibrate their own corridors.

Built With

• html
• javascript
• nebius-token-factory
• nvidia-nemotron
• python