michiyomi Development History
A record of when this data platform was built and what it was built from. 2026-08-23 edition.
Origin
michiyomi was created as an entry for the Governor of Tokyo Open Data Hackathon 2026. Work began on July 16, 2026, and ran for 38 days through the August 22 submission. The first verbalization entered the database on day one. The name “michiyomi” was chosen eleven days before the deadline, and the michiyomi.dev domain was registered the day before submission.
Before those 38 days, only the raw material—citizen-published Mapillary imagery captured from 2003 through 2026, 99.95% from 2014 onward—the desk hardware, and a general-purpose provenance CLI already existed. The verbalization pipeline, databases, API, MCP server, interfaces, name, and domain were all produced during the project.
Dates and counts come from work logs and SQLite database aggregates as of 2026-08-23.
Timeline
| Date (2026) | Event |
|---|---|
| Jul 16 | Project starts. Mapillary metadata is aggregated into 3.64 million scenes; model selection and the first roughly 2 KB prompt are completed. The first Setagaya L1 verbalization is recorded that day. |
| Jul 17 | The prompt is comprehensively rewritten into the v3 family—four versions in one day—yielding three to five times the information of the first version. |
| Jul 22 | Hackathon entry submitted. Prompt v3.4 introduces direction rules: no compass words; left/right are camera-relative. |
| Jul 27–28 | Setagaya pilot completes: L1 at 29,764 points, L2 over 3,048 segments, and L3 over 152 groups. The project reframes itself from a “school-route risk map” to a visual verbalization data platform. |
| Jul 31–Aug 1 | Expansion to Shibuya and Shinjuku (35,010 L1 points). The REST API skeleton runs locally on Cloudflare Workers and D1. |
| Aug 4 | Expansion to Chuo, including Ginza (13,043 L1 points). |
| Aug 9 | The verbalization engine moves from cloud inference to a Qwen-family local VLM on one home GPU. Generation-based provenance is added to the API at the same time. |
| Aug 10–11 | All 23 wards are divided into 94,232 road chunks; longitudinal-change detection completes for 6,197 groups. |
| Aug 11–12 | All 5,798 change claims undergo falsification-oriented adjudication in separate, context-isolated sessions. |
| Aug 12 | A human-facing “karte” interface is built and retired the same day. The product is redefined as infrastructure for AI to read physical reality and rebuilt around MCP. The name “michiyomi” is chosen. |
| Aug 14 | Verbalization of the priority area completes at 135,594 scenes. |
| Aug 15–22 | Remaining wards run continuously through five coverage-prioritized batches. The engine upgrades to the Qwen3.8 family and reaches 2,667 images per hour. |
| Aug 21 | michiyomi.dev is registered and release 2026-08-21-r1 enters production. |
| Aug 22 | Release 2026-08-22-r1, containing all 588,220 processed scenes, is published and submitted to the hackathon. |
Processing of remaining wards continued after submission, targeting full 23-ward coverage by the end of August. See current coverage notes.
What was rebuilt
Much of the 38 days consisted of building, measuring, and discarding. The largest redesigns are preserved here.
- The L1 prompt had 12 versions (2,061 bytes initially, 13,026 finally), and L2 had six. Some apparently promising versions were rejected after testing. A v3.5b proposal that injected map context was discarded to preserve the image-only principle; a lightweight schema was discarded when its predicted 1.5× speedup measured only 1.06×.
- Output rules grew through failure. “Right” means camera-right, not east; momentary object counts are excluded; and absent, unknown, and outside the frame must be distinguished. None of these rules existed in the first version.
- The first database preserved a design mistake. It lacked a prompt-version column, forcing provenance to be inferred from run dates. That failure led to row-level model, prompt, and timestamp provenance in the second database, then the three-tier row/generation/release model.
- The product changed form repeatedly. School-route risk map → visual verbalization data platform → human-facing karte UI → AI-facing MCP platform. The karte UI was retired on the day it was completed.
- Some analyses were withdrawn. A utility-pole comparison confounded by elevated roads, a rejected year-gap hypothesis, and an erroneous cost calculation remain marked as retractions in the work record.
Compute used
| System | Workload | Scale |
|---|---|---|
| Cloud VLM GPT-5.6 family via Codex CLI | 77,676 first-generation L1 scenes; 15,666 L2 segments; detection over 6,197 change groups; adjudication of 5,798 claims. | About 3 billion tokens (estimated from work-log averages) |
| Local VLM Qwen family × one home GPU | All 588,220 L1 scenes from Aug 9 through Aug 21. | 4.95 billion tokens (database-measured) |
| Supporting models Gemini, Claude, and others | 48-image model bake-off, visual review of demo candidates, implementation, and review. | Not aggregated |
The total is about eight billion tokens. Even using inexpensive metered cloud models, buying the same volume would cost hundreds of thousands of yen. In practice the project ran against fixed-subscription weekly limits, sometimes purchasing additional credits after reaching them, then moved to one home GPU on August 9 to make full-volume processing feasible.
The overlap between cloud and local generations reflects this history and directly supports regression comparison. See Design principle 3.3.
How to verify
The record can be checked from outside the project in several ways.
- Generation provenance: Every scene response includes its model and generation. GET /v1/generations reports generation counts and prompt-version distributions; GET /v1/provenance returns the release provenance chain.
- Capture dates: Each scene links to its source Mapillary image, where capture time can be independently inspected.
- Publication history: The
snapshotin every API response identifies the queried release. The first public release was2026-08-21-r1. - Machine-readable contract: The current English API definition is available as OpenAPI 3.1 YAML.