> 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/capabilities-and-requirements.md). # Capabilities and Requirements ### Capabilities and Requirements The key words SHALL, SHOULD, MAY and CAN are used as defined in MIM0. C1 to C5 correspond to the four interoperability themes of this MIM; C6 is proposed for discussion. #### C1: Compose a Virtual World from heterogeneous 3D, BIM, geospatial and reality-capture sources This capability relies on MIM7 for geospatial encoding and coordinate reference systems. Requirements: * R1.1 Scene content SHALL be exchanged in at least one open scene-description or 3D format (see M1). * R1.2 A composed world SHOULD reference its constituent assets (layers, external assets) instead of copying them, so each source can be updated by its owner independently. * R1.3 Every asset SHALL declare its coordinate reference system and georeferencing (see MIM7 R5.1). Local engine coordinates SHALL be transformable into that CRS. * R1.4 Units, up-axis, handedness and scale of every asset SHALL be declared. * R1.5 Source, capture date, level of detail and licence of every asset SHALL be described as metadata (see MIM3). * R1.6 Conversions between formats (e.g. IFC to glTF, OpenUSD to 3D Tiles) SHOULD preserve object identifiers and semantics. Information lost in conversion SHALL be documented. #### C2: Link scene objects to raw, real-time and simulated data This capability relies on MIM0 (access), MIM1 (identifiers), MIM2 (data models) and MIM8 C5 (visualisation of LDT results). Requirements: * R2.1 Scene objects that represent real-world entities SHALL carry persistent identifiers that resolve to the same entity in the data ecosystem (see MIM1 and MIM7 C4). * R2.2 Live and historical values SHOULD be bound to scene objects at runtime through a MIM0 interface, not baked into the geometry. * R2.3 Per-object attributes SHOULD be attached with a standard mechanism of the chosen format (see M2). * R2.4 The world SHALL be able to consume LDT simulation outputs together with their scenario, variant, timestamp and spatial scope (see MIM8 R5.1). * R2.5 Dynamic data SHALL be timestamped. The world SHOULD let users navigate time (past, present, scenario). #### C3: Enable multi-user collaboration and shared state This capability relies on MIM6 for identity, authentication and authorisation. Requirements: * R3.1 Changes to the world state (edits, annotations, object states, positions of users and objects) SHALL be exchangeable through a documented protocol or API. * R3.2 Poses of users, devices and objects SHOULD be expressed in a standard geospatial pose format (see M3). * R3.3 Collaborative edits SHOULD be non-destructive (layers, overrides) and keep authorship and version history. * R3.4 Users and AI agents SHALL authenticate with open standards. Permissions SHOULD be definable per layer or object. * R3.5 Issues and annotations on built assets SHOULD be exchangeable with BIM tools. * R3.6 AI agents and AI avatars SHALL be recognisable as such to users. Their access to scene context SHOULD use a documented interface (see MIM8 M3). * R3.7 Presence and tracking data of users is personal data. It SHALL be minimised and processed in line with the GDPR. #### C4: Render the world portably across engines and devices Requirements: * R4.1 The world SHALL be renderable by more than one engine or client from the same source content, without manual re-authoring. * R4.2 Materials SHOULD use physically based material definitions in an interchangeable format. * R4.3 Large worlds SHALL support hierarchical level of detail and spatial partitioning (tiling), so constrained devices can render them. * R4.4 XR devices SHALL be addressed through standard XR runtime APIs. * R4.5 Reality capture (point clouds, Gaussian splats) SHOULD be combinable with meshes in the same scene. * R4.6 User interfaces SHOULD meet EN 301 549. Worlds SHOULD offer a non-immersive alternative (2D view, text or audio description). #### C5: Serve and stream Virtual Worlds over different networks and protocols Requirements: * R5.1 A Virtual World service SHALL describe its delivery modes (download, progressive 3D streaming, pixel streaming, split rendering) and endpoints in machine-readable metadata, published in a catalogue (see MIM3). * R5.2 Public-facing worlds SHOULD offer at least one client-side delivery mode, so that the cost per user does not depend on server GPUs. * R5.3 Server-side and split rendering SHALL use standard real-time transports and codecs. User input and pose SHALL be exchanged in a documented message format. * R5.4 Services SHOULD adapt to device capabilities and network conditions (level of detail, bitrate, fallback between server-side and client-side rendering). * R5.5 Static content SHALL be cacheable with standard HTTP caching and content delivery networks. * R5.6 Quality-of-experience metrics (latency, frame rate, bitrate) SHOULD be monitored and reported. #### C6 (proposed): Discover and connect Virtual Worlds Requirements: * R6.1 Every world SHALL be described in a catalogue with its spatial extent, entry points, delivery modes, supported devices and access conditions (see MIM3). * R6.2 Worlds SHOULD link to each other through resolvable URIs (portals), including an entry pose. * R6.3 Users SHOULD be able to reuse their identity and avatar across worlds. #### **C7: Actuation** Actions taken in the virtual world can be pushed to external API's or applications Requirements: * --- # 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/capabilities-and-requirements.md?ask=&goal= ``` `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.