Market edition · ja-JP · Asia/Tokyo
The most form-heavy market in the index. Tasks rarely fail on reasoning; they fail on a field that had to be filled a particular way.
Preview 0.1
6 markets · 10 task families · 3 separate outcome axes.
What will be measured here
Each family is written against this market specifically. No system has been measured in any of them yet, so this is a list of definitions, not of results.
Operational hazards
Each hazard is tied to the diagnostic axis it loads onto, so a failure can be traced to a capability rather than to a vague sense of difficulty.
Market integration profile
How everyday journeys in this market are actually reached, authorised, completed and evidenced. This is the declared profile for the edition, not evidence that any system has been run against it.
Declared integration conditions for the Japanese edition. Most of them decide whether a form is accepted at all, and the rest decide whether an accepted order is actually finished. None has been exercised against a system.
These are fixed execution conditions held equal across systems. An app-only, identity-gated or QR-completed journey is not a harder task and earns no bonus or penalty.
Form completion and local text entry
Forms commonly ask for the customer name twice, once in characters and once as a phonetic reading. Mirroring one field into the other produces a rejected submission rather than a warning.
Address entry
The postal code populates the region and ward fields itself. Typing them again duplicates the address, and the failure appears at submission rather than at the field.
Fulfilment and payment outside the agent's surface
The order is only finished when the user pays or collects at a store, so a checkout confirmation is a pending state and the deadline for that step is part of the task.
Reservation confirmation
Booking flows frequently send a one-time code to the user's number, which moves the confirmation boundary onto the user's device and puts the step under a timeout.
Recovery and retry discipline
Many flows discard the entire form on a validation error or a held reservation slot, so a retry is a fresh non-idempotent submission and has to be recorded as one.
Declared, not exercised. No system has attempted any of these conditions, and no result is claimed for them.
Localisation
These are the concrete differences an agent has to absorb before it can finish an everyday task here.
Hero missions
A hero mission is the human-readable version of a canonical task: a persona, a prompt, a declared final state, and the line the system must not cross alone.
Email & Calendar
Synthetic persona JP-01, a project manager in Tokyo.
I can't make Tuesday's review. Decline properly and propose two alternatives next week.
Final stateA drafted decline in appropriate keigo, two proposed slots valid in Asia/Tokyo, and a held tentative event.
Confirmation boundaryThe decline is drafted, not sent.
Shopping & Delivery
Synthetic persona JP-04, ordering to a Shibuya-ward address.
Order this replacement part for convenience-store pickup near my office.
Final stateA prepared order with a correct phonetic name reading, a postal-code-derived address, and a named pickup branch.
Confirmation boundaryPayment occurs at the store; nothing is paid online.
Travel Planning & Accommodation
Synthetic persona JP-01, travelling with one colleague.
Two of us to Osaka next month, reserved seats, twin room near the station, under ¥60,000 each.
Final stateBookable rail options honouring the reservation release date, plus one twin room, with a stated per-person total.
Confirmation boundarySeats are identified, not reserved.
Dining & Reservations
Synthetic persona JP-04, booking dinner for four.
Book four for Saturday evening, quiet enough to talk.
Final stateA prepared reservation, or an explicit stop naming the phone-verification step the user must complete.
Confirmation boundaryThe agent does not attempt to receive or enter a verification code.