Verification items: running all 12 MCP tools over stdio, checking documentation against actual behaviour, visual review of SVG output, and reviewing what the npm package includes.
Roadmap
This is Koyu's development roadmap. It lists the work planned to realize Koyu's vision. Select a card to see details.
Last updated · July 2026
01
Core foundation
The ledger currently exists only inside the implementation. A machine-readable export lets external tools share the same validation rules without re-implementing them.
Walls, slabs, stairs, door positions and the connection graph are already derived, but currently only accessible through the TypeScript API. This adds output that simulators and viewers can read directly.
02
Generation and simulation
Every current way of getting training buildings has a problem. Hand-modelling in BIM is far too slow, synthetic generators produce layouts that look like buildings but do not hold together as plans, and real floor plans carry rights issues and no labels.
In koyu, which room has which use, which door can be passed, and which boundary is fire-rated are written facts rather than values inferred from geometry — so the ground truth cannot be wrong. check rejects what does not hold together, and validate scores whether it works as architecture.
Output goes straight into the format the simulator reads, with no general-purpose exchange format in between.
Done when1,000 buildings generated with all passing check, at least 80% with no validate violations, an external route computation running on the generated graph, and the same .muro reproducing the same geometry.
The connection graph and the door data are already in the model. What is missing is shaping them for one specific engine.
No general-purpose exchange format in between. Pick the first consumer, write what it reads, and only generalise once a second one appears.
Done whenA real evacuation simulator reads koyu's output as-is and computes routes and egress times.
The subdivisions are not added to the source; they are produced at export time.
03
Geodetic reference and regulatory calculation
This is for koyu's own calculations, not for export. Shadow and setback limits are questions a designer has to answer today, and neither can be computed without knowing which way is north.
The coordinate system is named by EPSG code; in Japan that means a plane rectangular system, which sits more naturally under a millimetre Cartesian grid than latitude and longitude do.
It is written as namespaced carried attributes on the site zone. Core never needs to interpret geodetic coordinates — only judgement and drawing read them — so neither the language version nor the attribute ledger moves. An incomplete reference is reported by validate.
Done whenShadow results for a site with a declared true north match a hand calculation, and validate reports an incomplete geodetic reference.
This is not an export for someone else, it is an answer to what the user is stuck on today. Getting the answer during scheme design means the form can still be changed cheaply.
The core computes numbers only; the pass/fail thresholds live in validate. Adding a judgement does not move the language version.
Done whenShadow results match a hand calculation, and the setback judgement returns sound results on existing designs.
CityJSON has object types for storeys and rooms that koyu's space model maps onto directly. It depends on the geodetic reference.
But 'connecting to city data' is not by itself a reason to build it. This waits until there is a question that requires being in the city's coordinate system.
04
IoT and digital twin integration
Time-series data is not stored in .muro. An external database joins records to spaces by path (or uid).
Will be designed as explicit membership separate from the path hierarchy, when BMS integration requires it. Not started.
05
Export to external formats
BOT, IndoorGML and CityJSON are all formats for the receiving side, and each assumes someone is waiting for koyu's data. As far as could be established, nobody is yet.
Every unused export widens the surface that has to be maintained. A whole building fitting in an LLM context, and a diff being readable by a person, both depend on there being little to read. Losing that breaks the purpose.
So the order is reversed: settle the question to be answered and the software that answers it, then write that software's input format. Generalise only when a second consumer appears.
A koyu boundary has the same structure as bot:Interface, the interface between two zones. No other vocabulary maps this cleanly.
But BOT is a community group draft, not a W3C Recommendation, and it is not used in building management or digital twin practice. The 2026 systematic comparison of building ontologies evaluates Brick, RealEstateCore, Haystack and Google Digital Buildings — BOT is not among them.
That same paper finds all four weak at spatial topology and recommends reusing BOT for it. So BOT is not a competitor but the designated owner of the topology those ontologies lack. That makes it worth supporting eventually, but it is not a digital twin initiative. Work starts when something actually asks for BOT.
Done whenSPARQL answers the same route questions as the doors command.
No new vocabulary is added to koyu itself. Mapping tables are managed as .muro layers.
IndoorGML is a full OGC Standard whose core is indoor topology and a navigation network. The koyu space graph is that dual graph already, so the mapping is natural.
But almost no production use of it could be found. The research literature describes it as hard to produce and effectively unavailable for lack of practical tools, while indoor mapping in practice runs on IMDF — Apple's GeoJSON-based format, an OGC Community Standard.
If the goal is route computation or evacuation simulation, writing the format that engine reads is faster, and there is no reason to pass through IndoorGML on the way. It only pays off when a consumer names IndoorGML specifically.
Done whenRoute calculations for the same building agree between koyu and the IndoorGML model.
Round-tripping (IFC → koyu → IFC) is out of scope. Import covers spatial structure, boundaries and attributes; geometry representation is not imported.
06
Not planned
Geometry is derived from grid references and boundary relations. This keeps the source separate from geometry that scanning and point clouds can provide.
.muro holds spatial structure, relations and identifiers.
The source file is the single original; all edits are made to .muro.
koyu covers spatial composition at the early design stage. Detailed design remains the domain of BIM tools.