Skip to content

Guiding questions — Use case development#

Fork notice. The questions below are reproduced from the iSHARE Data Space Template page Use case development → Guiding questions — © iSHARE Foundation, used under the EUTwinLink Consortium Agreement (see Legal notices). The template's question text is carried over unchanged so this fork stays comparable to its upstream.

Everything between the LDT answer markers is the EUTwinLink instantiation — that is what partners fill in. Decisions already taken live on the block page: Use case development.

Building block B2 · owner(s) site & service owners per use-case profile · due 26 Sep 2026 · block status DRAFTED · see the Building-block register.

Answer provenance. Every answer below is tagged with where it comes from, because a governance scheme that cannot be traced is not a governance scheme:

  • Decided — already fixed by the Grant Agreement, the Consortium Agreement or a recorded decision elsewhere in this scheme. Change it only through the change procedure.
  • Proposed — a defensible default, derived from the iSHARE Trust Framework, the DSSC Blueprint and the decisions this scheme has already taken. Drafted for the owner to confirm, correct or reject at TIPS. It is not an agreed position until TIPS approves it.
  • Needs owner — cannot be answered without the named owner: a fact about their systems, their legal position or their commercial intent. The text states what is needed and why.

Open points across the whole scheme are collected in Open questions for partners.

Purpose of this Building Block Component: Use cases are the anchor points of any data space; they provide a concrete reason for stakeholders to participate and collaborate. Each use case should be mapped along: Stakeholders involved (who needs what data, and why), Data flows and value exchanges, Business and sustainability outcomes, and Scalability and replicability potential.

1. Use Case Title and Identifier#

Purpose: Create a recognisable name and ID for easy reference.

  • What is the name of the use case?
  • Is there an identifier or code used internally or by the consortium?

LDT answer DRAFTED · owner: site & service owners per use-case profile · due 26 Sep 2026

Decided Six use cases, each with a consortium identifier and its own profile page:

ID Use case Owner
LDT-UC-01 Cartagena — LEZ, air quality & heat resilience Ayuntamiento de Cartagena
LDT-UC-02 Almelo/Aadorp — Positive Energy District City of Almelo + Almelo Energie
LDT-UC-03 Aruba Airport — operational decarbonisation FHC Corp
LDT-UC-04 Hamburg Port — logistics twin Cartagena / ERTICO (liaison)
LDT-UC-05 Marketplace & CO₂ tokenisation Nunsys + LogiNex
LDT-UC-06 AI agents & observers iSHARE + iLabs

Proposed The identifier sequence skips nothing — LDT-UC-04 is Hamburg, numbered before the Marketplace of the EU LDT Toolbox and agent cases because it is a site interconnection like 01–03. Worth keeping stable: these identifiers are referenced from the technical blocks.

2. Problem Definition & Context#

Purpose: Define the environmental or operational challenge being addressed.

  • What environmental, regulatory, or market need does this use case aim to solve?
  • What is the context in which this problem occurs (sector, region, system)?
  • What makes the problem relevant for the Green Deal or EU sustainability goals?
  • How can gaps in data availability or quality be addressed when choosing use cases?

LDT answer DRAFTED · owner: site & service owners per use-case profile · due 26 Sep 2026

Proposed The common problem across all six, which is what makes them one data space rather than six projects: a Local Digital Twin can only reason about its own territory. Cartagena cannot tell whether its LEZ performs well without comparison; Aadorp cannot benchmark its PED; Aruba and Hamburg cannot show their operational patterns transfer. Interconnection is the answer, and interconnection without agreed rules on identity, access and usage is the thing none of them will do.

Per use case the specific need is on each profile: air quality and urban heat under a contested LEZ policy (ES); a district that must produce more energy than it uses, and prove it (NL); operational decarbonisation in a commercial setting outside the EU; port logistics replication; a market and incentive layer; and accessibility of the twins for non-experts.

Decided Green Deal relevance is explicit per profile: Ambient Air Quality Directive and ITS Directive (01), EPBD and RED III energy communities (02), aviation decarbonisation (03), emissions in logistics (04), verified CO₂ savings (05).

Proposed Data gaps are addressed by choosing use cases where instrumentation already exists — all four sites have operational twins today — rather than by funding new sensing. Where quality is the gap (sensor coverage in Cartagena is flagged as a risk on its profile), it is a stated risk rather than an assumption.

3. Use Case Objectives#

Purpose: Clarify the goals and ambitions of the use case.

  • What are the specific outcomes this use case aims to achieve?
  • Which sustainability metrics or business goals will it support?
  • How will success be measured?
  • How can business, regulatory, and technical requirements be integrated efficiently?

LDT answer DRAFTED · owner: site & service owners per use-case profile · due 26 Sep 2026

Needs owner Each profile's section 3 carries _TODO_ against targets, and this is the most consequential set of unanswered questions in the scheme — KPI targets feed PD2 and PD5 and cannot be invented here.

Decided The metrics themselves are named per profile: gCO₂e per vehicle-km in pilot corridors, LEZ emission-proxy trends, hotspot counts and eco-routing uptake (01); kgCO₂e per building and district scenario, renewable share, peak impact, community participation rate (02); operational efficiency and estimated € and CO₂ savings (03); published assets, reuse events, verified credential exchanges and token uptake (05); observer engagement and zero policy-violating agent access (06).

Proposed Measuring success: each profile states its metric; what is missing everywhere is the baseline and the measurement window. A metric without a baseline cannot show improvement, which is the specific risk for the city cases where the claim is policy effect.

Proposed Integrating business, regulatory and technical requirements efficiently is done through the profiles' section 6 — "sharing rules this use case needs from the scheme" — which converts a use-case need directly into a requirement on a building block. That is the mechanism that keeps the scheme grounded in use cases rather than in theory.

4. Stakeholder Involvement#

Purpose: Identify key actors in the data value chain and their roles.

  • Who are the key stakeholders involved (e.g., data providers, processors, users, decision-makers)?
  • What role does each actor play (e.g., share data, analyse, visualise, take action)?
  • Are any public authorities, SMEs, or NGOs participating?
  • How can participants provide input to ensure use cases are relevant and practical?

LDT answer DRAFTED · owner: site & service owners per use-case profile · due 26 Sep 2026

Decided Actors and roles are listed per profile, and include public authorities (two municipalities, regional authorities in ES), SMEs (Nunsys, LogiNex, HyEnSys, iLabs, FHC, Qwihi), a community energy cooperative (Almelo Energie), a university (Aegean), a sector association (ERTICO), and supporters (Hamburg Port Authority (supporting stakeholder, letter of support); Esri (letter of support, 9 January 2026; intended subcontractor to iLabs, subject to procurement)).

Proposed Roles in the template's terms — share, analyse, visualise, act:

  • Share — cities, FHC, Hamburg Port, Almelo Energie, LogiNex.
  • Analyse — LogiNex (emissions), site twins (simulation), iLabs.
  • Visualise — Nunsys (marketplace), the observer chatbot, municipal dashboards.
  • Act — the municipalities, on policy; residents, on behaviour; the airport, on operations. The scheme's purpose is served only when this last column happens, and it is the hardest to evidence.

Proposed Participants provide input through the co-creation process: the profiles are theirs to complete, and section 6 of each is a direct channel into the scheme's requirements. Needs owner Two gaps are already visible and marked on the profiles: the DSO / grid operator in the PED case is unconfirmed, and airlines and handlers at Aruba are unlisted. Both are parties whose absence would change the data flows.

5. Data Needs & Sources#

Purpose: Describe what data is needed and where it comes from. What types of data are required (e.g., emissions data, material flows, building info)?

  • What types of data are required (e.g., emissions data, material flows, building info)?
  • Who are the data providers?
  • What is the format, frequency, and level of detail of the data?
  • Are there interoperability or standardisation challenges?

LDT answer DRAFTED · owner: site & service owners per use-case profile · due 26 Sep 2026

Decided Data types per profile: IoT air, noise and heat sensors, mobility feeds, LEZ camera and enforcement data, weather and emission-computation inputs (01); smart-meter and household energy data, generation and storage telemetry, ESSIM/DEMkit outputs (02); passenger-flow sensors, operational systems, flight schedules (03); vessel and hinterland flows (04); offering metadata, verified emission computations, transaction records (05).

Decided Three of these carry personal data and are flagged as such on their profiles: LEZ camera and enforcement data, household smart-meter data, and passenger-flow sensing. The scheme's response is on the profiles' section 6 — Commons mediation, aggregation floors, purpose-bound ODRL policies — rather than a blanket rule.

Needs owner The source inventories are _TODO_ on every site profile, and they are the precondition for Data models and Data exchange. What is needed per source: format, update frequency, quality level, level of detail, and whether it is already exposed as NGSI-LD / MIM2.

Proposed The standardisation challenge is known and structural: four twins built independently, on different stacks, never intended to interoperate. The scheme's answer is to standardise the boundary — what crosses between twins — and leave each twin's internals alone.

6. Data Sharing & Interactions#

Purpose: Describe how data will be shared and exchanged between parties.

  • What data sharing agreements or governance rules are needed?
  • Which participants will consume or enrich the data?
  • How will data sovereignty and access control be ensured?
  • Is there a need for a specific Trust Framework or data space technical connector?
  • How can alignment among participants be maintained during implementation

LDT answer DRAFTED · owner: site & service owners per use-case profile · due 26 Sep 2026

Decided Governance rules each use case needs from the scheme are stated in section 6 of every profile, and they are requirements on the building blocks rather than aspirations. The recurring ones: Commons controls plus aggregation floors for citizen data (01, 02), derived-indicator publication rights for cross-site benchmarking without raw re-sharing (01, 03, 04), confidentiality tiers for commercial operational data (03), a bilateral annex for grid parties (02), non-EU transfer clauses (03), and a lightweight Observer/associate accession for supporters (04).

Decided Sovereignty and access control are ensured the same way in every use case: credential-gated access, ODRL policies enforced at federated PEP/PDPs, registry and credential status as shared PIPs, and an audit entry per decision.

Decided Yes to both of the template's technical questions — the LDT requires a trust framework (the iSHARE DataRights Trust Framework 3.x) and a connector (EDC with the iSHARE extension), validated through the ITB-S before production.

Proposed Alignment during implementation is maintained by the rule that a use case may be stricter than the scheme baseline, never weaker. That lets four very different sites implement at their own pace without forking the rules.

7. Architecture#

Purpose: Show how the use case integrates with the broader architecture.

  • Which building blocks (Governance, Business, Technical) are used?
  • Will the use case integrate a Data Space Connector, a Trust Anchor, or a data intermediary?
  • Does it follow some standards, like DSSC, iSHARE, SIMPL, etc?
  • What mechanisms ensure smooth scaling and integration with existing systems?
  • How can coordination be improved across federated operators or multiple ecosystems?
  • Which tools best support collaboration and scaling?

LDT answer DRAFTED · owner: site & service owners per use-case profile · due 26 Sep 2026

Decided Standards followed: DSSC Blueprint (the building-block structure of this whole scheme), iSHARE Trust Framework 3.x (identity, trust, policy), OASC MIM2 / NGSI-LD (city data), DCAT-AP (descriptions), W3C VC / OpenID4VC (credentials), ODRL via the iSHARE profile (policies). SIMPL alignment is a watching brief, not a dependency — the agent profile notes SIMPL is still evolving and instructs that the adapter be kept thin (risk R4).

Decided Every use case integrates a data-space connector (EDC with the iSHARE extension), a trust anchor (iSHARE Foundation, plus eIDAS trust lists) and intermediaries (iLabs for registry and ITB-S, Nunsys for the marketplace).

Proposed Scaling and integration with existing systems rests on one rule that PD4 should state prominently, because it was a funder recommendation generalised into scheme policy: every interconnection must remain portable — an open, documented interface, so a site can be replaced without renegotiating the scheme. The ESRI stack is the origin of the rule; it applies to all of them.

Coordination across federated operators is through shared artefacts — same schemas, same ODRL profile, same registry, ITB-S validation — rather than through coordination meetings.

Needs owner PD3 holds the architecture itself; the profiles' section 7 should reference the PD3 diagram rather than describe it. That cross-reference is _TODO_ on profile 01.

8. Timeline and Maturity#

Purpose: Define the development status and roadmap of the use case.

  • Is this a concept, pilot, or operational use case?
  • What are the key milestones (e.g., prototype, deployment, scaling)?
  • What technical or organisational dependencies exist?
  • How can insights from abandoned use cases guide future decisions?
  • How can feedback loops be structured to allow flexible adaptation?

LDT answer DRAFTED · owner: site & service owners per use-case profile · due 26 Sep 2026

Decided Maturity differs sharply and should not be presented uniformly: operational twins already exist at Cartagena, Almelo/Aadorp and Aruba; pilot applies to the marketplace (WP6, M9+ ramp-up) and the LDT interconnection itself (WP7); concept-to-prototype applies to the AI agent stack (prototype at M18, TR3.2) and the observer chatbot (T4.4, M9–M18). Hamburg Port is pre-scoping.

Decided Dependencies already recorded: the Aruba wallet flows are gated by the WP4 T4.1 baseline; marketplace listing depends on ITB-S conformance evidence; PD2 interoperability scores depend on validated exchange paths.

Needs owner Milestones are _TODO_ on every site profile. The scheme can state sequence but not dates.

Proposed On the template's question about abandoned use cases: none has been abandoned, and the scheme's live example is more useful — Hamburg Port has no confirmed owner, which after six weeks past the contribution deadline is itself a decision being taken by default. The co-creation process should name it rather than carry it forward as pending.

Feedback loops: the profiles' section 6 is the standing channel from use case to scheme, reviewed at TIPS.

9. Value Proposition & Expected Impact#

Purpose: Summarise the added value for stakeholders and broader sustainability goals.

  • What concrete value does this use case deliver to stakeholders (economic, social, environmental)?
  • How does it contribute to Green Deal objectives (e.g., circular economy, emissions reduction)?
  • Is there potential for replication or scaling?

LDT answer DRAFTED · owner: site & service owners per use-case profile · due 26 Sep 2026

Decided Value per profile: evidence-based LEZ policy with citizen-visible air-quality gains and a replicable playbook (01); proven PED operation with community ownership of data and replicable energy-community governance (02); a commercial replication case and proof the scheme travels beyond the EU (03); port-city replication (04); sustainability of the LDT through revenue, and incentivised participation (05); accessibility of the LDT for non-experts, and a governance-as-code demonstration (06).

Proposed Economic, social and environmental, separated because they are not equally evidenced:

  • Environmental — the strongest claim, and the one most dependent on measurement: emission reductions attributable to LEZ and PED interventions. Attribution is the hard part and is why provenance is mandatory where figures become claims.
  • Social — community control over data (Commons), citizen access to the twins (observer chatbot), transparency of municipal policy.
  • Economic — operational savings at the commercial sites; a market for data services; reduced cost of trust infrastructure through sharing it.

Decided Replication potential is the LDT's primary ambition rather than a by-product — see Business model question 5.

10. Risks and Barriers#

Purpose: Identify potential challenges and mitigation strategies.

  • What are the technical, organisational, or legal barriers?
  • Are there risks related to data quality, privacy, or stakeholder engagement?
  • How can these be mitigated?

LDT answer DRAFTED · owner: site & service owners per use-case profile · due 26 Sep 2026

Decided Risks already recorded on the profiles: personal-data exposure in mobility data and sensor quality gaps (01); consent fatigue, energy-data sensitivity and NL energy-sharing rules in flux (02); transfer-law complexity and commercial sensitivity (03); supporter status versus data-contribution expectations (04); greenwashing exposure if CO₂ verification is weak, and token-regulation edge cases such as MiCA (05); AI Act classification effort and hallucinated answers about live city data (06).

Proposed The cross-cutting risks the individual profiles do not show, which belong in PD4 rather than in any one profile:

  • Partner engagement. The largest live risk. Zero contributions arrived by the v0.5 deadline; PD4 acceptance is a payment condition. Mitigation is escalation at TIPS, and it has not happened.
  • Single-operator dependency. Registry and credential issuance sit with one operator and the continuity arrangements are not written (Intermediaries & operators question 5).
  • Post-M18 discontinuity. No funding model for the governance authority.
  • Regulatory drift during the project. NL energy rules and the AI Act both move faster than the deliverable.

Mitigations are named with each. The honest position for PD4 is that the first is a management problem, not a documentation one.

11. Alignment with EU Policies or Standards#

Purpose: Ensure strategic alignment with regulatory and policy frameworks.

  • Does the use case align with EU Taxonomy, CSRD, EPBD, SFDR, or other legislation?
  • Are any standardisation frameworks (e.g., ETSI, CEN/CENELEC) being applied?

Purpose: Provide diagrams, mock-ups, or links that support understanding.

12.Supporting materials (Optional)

  • Data flow diagrams
  • Mockups or MVP screenshots
  • Stakeholder maps
  • Links to documentation or previous results

LDT answer DRAFTED · owner: site & service owners per use-case profile · due 26 Sep 2026

Decided Policy alignment per profile: Green Deal throughout; Ambient Air Quality Directive and ITS Directive (01); EPBD and RED III energy communities (02); aviation decarbonisation and GDPR-equivalence considerations (03); Green Deal logistics (04). Horizontally: GDPR, Data Governance Act, Data Act, eIDAS 2.0 and the AI Act, per Regulatory compliance.

Proposed On the template's specific list — EPBD applies through the Aadorp PED. CSRD, EU Taxonomy and SFDR are corporate sustainability-reporting and finance regimes; they do not obviously apply to the LDT's participants, but LogiNex's CO₂ products could feed a participant's CSRD reporting, in which case the methodology requirement becomes a compliance matter rather than a quality one. Worth a line in PD4 either way.

Decided Standardisation frameworks applied: ISO 23795-1 and the LCMM method for emission computation; W3C (VC, JSON-LD, PROV-O, ODRL, SHACL); OGC for geospatial services; OASC MIM2; DCAT-AP; OpenID4VC. ETSI appears indirectly through eIDAS trust-list profiles. CEN/CENELEC is not currently referenced.

Needs owner The template also asks for data-flow diagrams, mockups, stakeholder maps and links to prior results. None exist in this repository; diagrams belong to PD3 and should be cross-referenced from each profile's section 7.