For the complete documentation index, see llms.txt. This page is also available as Markdown.

Capabilities and Requirements

Here it is, formatted in the same style:


Capabilities and Requirements

C1: Provide access to datasets used within the LDT, including static, real-time, and simulation data and calculation models

This capability relies on MIM0 (Accessing Data) for generic data access.

Requirements:

R1.1 The LDT shall provide access to simulation outputs and calculation-model inputs where these are needed as part of LDT workflows.

R1.2 The LDT should distinguish clearly between raw source data, transformed workflow-ready data, model inputs, and model outputs.

C2: Exchange data with external systems and other LDTs using interoperable interfaces

This capability relies on MIM3 (Exchanging Data) for data exchange.

C3: Reuse deterministic or AI models across different domains, communities, use cases, and/or LDTs

Requirements:

R3.1 The model should provide standard model metadata, including a description of its methods and parameters, and data-parameters (either by value or by reference). To this end common metadata standards should be used.

R3.2 The model shall expose or be callable through a documented interface, preferably using a known standardised API. The dataset that forms the outcome of the model shall be described (at data-level).

R3.3 Trustworthy, reliable, and ethical use of innovative methods (LLMs, agentic AI, etc.) should be safeguarded. Bias should minimised where applicable. The methods used to guarantee this, should be described.

R3.4 The model must be able to access data on behalf of the end-user or organisation. See MIM3

R3.5 For data to be used in AI models, provenance and trust should be guaranteed. In some cases, an authoratitive sourc, such as a government agency must be listed.

C4: Coordinate and manage data, models, and processing workflows within an LDT (intra-LDT) and across LDTs (inter-LDT)

Requirements:

R4.1 The LDT supports workflows that connect data sources, data transformations, model execution, simulation processes, and outputs.

R4.2 The LDT chains workflow steps, where the output of one step can be used as the input for another.

R4.3 The LDT monitors workflow execution status, including completed, failed, and interrupted processes.

R4.4 The LDT records workflow provenance, including datasets used (including version, timestamped), models executed, parameters selected, and outputs generated.

C5: Provide multiple visualisations of data and results (e.g. 2D, 3D, dashboards) from common underlying data and models for interaction and comparison

Definitions Scenario: A scenario describes the external factors, not influencable by the DT-user, such as ligth, modest or heavy climatechange. Variant: A variant describes the potential options (solutions) the DT-user models in order to respond to a challenge, e.g different environmental designs for an area.

Requirements:

R5.1 The LDT provides metadata explaining what is visualised, including timestamp, spatial scope, data source, and scenario- and variant-assumptions where relevant.

R5.2 The LDT supports different interactive visualisation types, such as 2D maps, 3D scenes, dashboards, reports, or public-facing views.

C6: Ensure that data exchanged (and simulation outputs) within and between LDTs can be interpreted consistently through shared or mapped semantics and clear provenance

This capability relies on MIM2 (Representing Data) for semantic interoperability and on MIM7 for interoperability of geospatial data.

Requirements:

R6.1 The LDT should document unresolved semantic gaps, assumptions, or mappings that may affect the interpretation, reuse, or comparison of results.

Last updated