> For the complete documentation index, see [llms.txt](https://mims.oascities.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://mims.oascities.org/mims-specification-v9.0/citiverse/mim9-citiverse/interoperability-guidance.md).

# Interoperability Guidance

#### Interoperability guidance

1. Separate authoring from delivery. Keep the master world in OpenUSD layers and publish it as glTF or 3D Tiles. Preserve object identifiers across every conversion.
2. Never bake live data into geometry. Bind values at runtime through identifiers (M2), so the 3D content and the data can be updated by different owners.
3. Default to client-side streaming for public-facing worlds and reserve pixel streaming for high-fidelity or thin-device cases. Offer a fallback between the two (R5.4).
4. Treat the Virtual World as a consumer of MIM8. LDT simulation outputs reach the world through MIM8 C5 and M5, with scenario and variant metadata.
5. Combine reality capture and modelled content in one georeferenced scene. Gaussian splats and meshes can now share a scene in both glTF and OpenUSD.
6. Publish every world and every delivery endpoint in a DCAT-AP catalogue (MIM3), so other cities and vendors can discover and reuse them.

#### Conformance levels

Conformance follows the maturity levels in the Objectives. A service declares the highest level it meets.

| Level       | Required capabilities                     | Typical example from the pilots                  |
| ----------- | ----------------------------------------- | ------------------------------------------------ |
| 1 Viewable  | C1; C4 (R4.1, R4.3); C5 (R5.1, R5.5)      | Kiel historical reconstruction                   |
| 2 Live      | Level 1 plus C2                           | Cartagena traffic and pollution in 3D            |
| 3 Shared    | Level 2 plus C3 and the rest of C4 and C5 | AccessCity with AI avatars and multiple visitors |
| 4 Federated | Level 3 plus C6                           | Not yet observed in the pilots                   |

#### Compliance testing

* Format validation with existing validators: Khronos glTF Validator, 3D Tiles Validator, buildingSMART IFC validation service, and the OpenUSD compliance tests that AOUSD is building on Core Specification 1.0.
* Engine portability test: load the same world in two different engines and compare object count, identifiers and georeferencing (R4.1).
* Delivery test: check the declared delivery modes and endpoints against the catalogue entry, and measure latency and frame rate on a reference device and network (R5.1, R5.6).
* Self-assessment: vendors declare level, capabilities and mechanisms in the planned mims.yml file, so their Virtual World components appear in the OASC catalogue.
* Application profiles: following the ETSI STF 704 approach, concrete profiles fix one mechanism per requirement so implementations become verifiable. Candidate profiles are a public-event profile (AccessCity) and a planning-scenario profile (Cartagena, Flanders).

#### Relation to other MIMs

| MIM                      | What MIM9 reuses                                        |
| ------------------------ | ------------------------------------------------------- |
| MIM0 Accessing Data      | APIs for live and historical data bound to the world    |
| MIM1 Interlinking Data   | Persistent identifiers of scene objects                 |
| MIM2 Representing Data   | Data models and semantics of linked data                |
| MIM3 Exchanging Data     | Catalogue entries for worlds and endpoints; usage terms |
| MIM6 Securing Data       | Identity and access of users and agents                 |
| MIM7 Geospatial Data     | CRS, georeferencing, CityGML and CityJSON               |
| MIM8 Local Digital Twins | Simulation outputs, scenarios, model services           |

### Open issues and next steps

**Open issues**

* Live scene synchronisation: no open standard covers real-time multi-user sync between engines. Candidates are OpenUSD live layers, IEEE 2874 HSTP and Media over QUIC. Which one should M3 recommend?
* Minimum viable citiverse: SENSE asked for a definition. Should MIM9 adopt the ITU CitiVerse definition and add the four levels, or define its own?
* Scope of C6 (federation): keep it in MIM9 v1 or defer to a later version?
* Streaming cost: MIM9 lacks figures on cost per user for pixel streaming versus client-side streaming. The pilots could supply them.
* Standards in flux: glTF 2.1, 3D Tiles 2.0 and KHR\_gaussian\_splatting are not yet final. Entries marked "not re-checked" need verification.
* AI in the world: how far should MIM9 go on AI avatars and agents beyond R3.6, given MIM8 R3.3 on trustworthy AI?


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://mims.oascities.org/mims-specification-v9.0/citiverse/mim9-citiverse/interoperability-guidance.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
