Open questions for partners

Generated by tools/collect_open_questions.py from every Needs owner tag in the scheme. Do not edit by hand — answer the question on its own page, drop the tag, and re-run the script. An answered question leaves this list by itself.

The scheme's draft answers are tagged by provenance: Decided (already fixed by the Grant Agreement, the Consortium Agreement or a recorded decision), Proposed (a defensible default drafted for the owner to confirm, correct or reject — not an agreed position), and Needs owner — the ones below, which cannot be answered without the named partner.

113 open questions across 25 pages.

By partner

Partner	Open questions
iSHARE Foundation	41
iLabs Technologies	34
Nunsys	24
iSHARE Foundation (legal)	18
ERTICO – ITS Europe	13
LogiNex Carbon Intelligence	13
Ayuntamiento de Cartagena	12
City of Almelo	12
FHC Corp (Aruba)	8
Almelo Energie	7
Both cities	7
HyEnSys	6
All use-case profile owners	4
University of the Aegean	4
PD3 authors	3
TIPS Committee	3
Port of Hamburg / liaison	2
Unassigned	2

Questions

iSHARE Foundation

• LDT Governance and Trust Framework → How to contribute your building block — 1. Find your organisation in the Building-block register — it lists exactly which sections wait for your input, with owners and due dates. 2. Review the drafted answers on your block's guiding-questions page: confirm or correct the Proposed ones and supply the facts. Draft any 🧩 block still open on the block page. 3. Submit as a merge request using the Building block template; the WP4 lead (iSHARE) reviews, the TIPS Committee approves.
• Guiding questions — Business model → 1. Value propositions for different roles (e.g. data providers, users, CO₂ consultants, real estate owners) — ERTICO + iSHARE (input Nunsys, Aegean) — the open 🧩. This table is a drafting position derived from the use-case profiles, not a validated value proposition.
• Guiding questions — Business model → 2. Revenue mechanisms (e.g. subscription, pay-per-use, public-private funding) — ERTICO + iSHARE: align with the PD5 cost-benefit analysis; none of these rates exist.
• Guiding questions — Business model → 5. Theme & Scope — ERTICO + iSHARE: confirm, or correct, if the exploitation plan assumes network growth.
• Guiding questions — Business model → 7. Governance Authority — ERTICO + iSHARE: the funding model for the authority itself. Nothing in this scheme answers it today.
• Guiding questions — Data space intermediaries & operators → 6. Governance and Trust — Nunsys + iSHARE: confirm that framing, and state how a rejected listing can be appealed.
• Guiding questions — Organisational form & governance authority → 1.3 Profit vs Non-Profit Orientation — ERTICO + iSHARE: confirm this split survives contact with the exploitation plan, and say whether any partner intends to commercialise a scheme-layer function.
• Guiding questions — Organisational form & governance authority → 1.4 Country and Jurisdiction — iSHARE legal, with Cartagena and Almelo: regulatory, tax and operational consequences per candidate jurisdiction. This answer names a likely choice; it does not evaluate alternatives, and nobody has yet done that analysis.
• Guiding questions — Organisational form & governance authority → 2.4 Dispute Resolution & Compliance — iSHARE legal: the template names CSRD and EPBD. Neither appears in this scheme's framework table. Confirm whether they apply to the LDT — EPBD plausibly does via the Aadorp PED — or strike them.
• Guiding questions — Organisational form & governance authority → 3.2 Terms and Conditions for Participants — iSHARE legal: confirm the accession model can carry this structure, and that the cities can sign it under municipal contracting rules — the open sign-off 🧩 in Contractual framework.
• Guiding questions — Organisational form & governance authority → 3.3 Internal Policies and Procedures — iSHARE + iLabs: incident handling is the gap with real consequences and no owner in the register. It should be assigned.
• Guiding questions — Participation management → 2.2 Pre-Conditions for Entry — iSHARE legal: whether baseline legal compliance (a GDPR posture statement, say) should be an entry requirement or a contractual warranty. The scheme currently assumes the latter; that assumption has not been tested.
• Guiding questions — Participation management → 3.3 Additional Strategic Questions — ERTICO + iSHARE: participant recruitment after the pilot belongs to the exploitation case and has no owner in the register today.
• Guiding questions — Participation management → 4.1 Exit Scenarios — iSHARE legal: the same durations for a scheme participant that is not a consortium party — the accession agreement has to carry its own, and whether it mirrors the 30 days is a drafting choice nobody has made.
• Guiding questions — Participation management → 4.2 Offboarding Process — The hard case nobody has addressed: data already transferred cannot be recalled. What survives exit — deletion duties, retention for audit, continued honouring of usage policies — is a contract question for iSHARE legal, and the answer should be written into the accession agreement rather than inferred.
• Guiding questions — Participation management → 4.4 Additional Strategic Questions — iSHARE legal + iLabs jointly: this whole section is drafted from the scheme's own logic rather than from a decision. The offboarding path is the least exercised part of the participation model and the one most likely to be wrong.
• Guiding questions — Contractual framework → 1. Core Structure of Agreements — iSHARE legal: whether that Accession Agreement carries the six elements listed above as drafted, and whether the cities can sign it under municipal contracting rules. The Data Ecosystem Agreement names the instrument but does not reproduce it, and the copy consulted here is the Scheme Owner template, not an executed EUTwinLink agreement.
• Guiding questions — Contractual framework → 2. Alignment with Governance — iSHARE legal: whether the accession agreement for a scheme participant that is not a consortium party adopts the same threshold and the same 30-day window, or sets its own. The consortium instrument cannot bind a party that never signed it.
• Guiding questions — Contractual framework → 3. Onboarding and Offboarding — iSHARE legal. This is the single most consequential gap in the contract stack as it stands.
• Guiding questions — Contractual framework → 5. Dispute Prevention and Resolution — iSHARE legal: whether the accession agreement adopts that ladder for participants who never signed the Consortium Agreement, or points at a different forum. The gap is real — the question is now which of two known answers it gets, not what the alternative looks like.
• Guiding questions — Regulatory compliance → 1. Applicable Legal Frameworks — iSHARE legal with Cartagena (ES), Almelo (NL), FHC (Aruba), reviewed by ERTICO — the 🧩 on the block page. National law is the gap: this table is almost entirely EU-level, and ES and NL administrative, procurement and open-data rules are not represented at all.
• Guiding questions — Regulatory compliance → 2. Compliance Responsibilities — iSHARE legal: whether the declaration should be a contractual warranty with consequences, or a statement of fact. The scheme currently assumes the former.
• Guiding questions — Regulatory compliance → 3. Risk and Liability — iSHARE legal + ERTICO: insurance, and what replaces the "share of project costs" cap once there is no project to take a share of. Checked against both instruments: neither the Consortium Agreement nor the Pilot Grant Agreement mentions insurance anywhere, so this is not an omission from this page but an absence in the contract stack. Both are post-pilot questions and neither has an instrument behind it.
• Guiding questions — Regulatory compliance → 6. Enforcement Mechanisms — iSHARE legal: every page in this scheme that assumes a unilateral suspension needs rewriting to the two-step above, or the scheme has to argue for an emergency power and get it agreed. The second is defensible for a key compromise, where waiting for a General Assembly is not an option — but it has to be written, not assumed.
• Guiding questions — Data models → 5. Tooling and Accessibility — The LDT has no vocabulary service, and this is a genuine gap rather than a detail. The scheme states that schemas.ishare.eu/vocab# is canonical and that LDT terms get their own namespace — but no hosting, resolution or browsing for that namespace has been decided or assigned. A namespace that does not resolve is not a namespace.
• Guiding questions — Provenance, traceability & observability → 2. Data Modelling — iLabs + iSHARE — the 🧩. The split above is a drafting position; the event list and the PROV profile are the actual deliverable and do not exist.
• Guiding questions — Provenance, traceability & observability → 4. Observability Scope — iLabs + iSHARE: whether the aggregate layer is published openly or stays inside the consortium. PD4 fixes what is collected and who may see their own; it does not say who may see the totals, and that is the part a prospective participant judges the scheme by.
• Guiding questions — Provenance, traceability & observability → 5. Trust & Third Parties — iLabs + iSHARE: the export format. The commitment is made, so the centralisation risk is no longer unmitigated in principle, but an export nobody can parse mitigates nothing in practice — name the format and whether it carries the policy decision and reason alongside the transaction.
• Guiding questions — Provenance, traceability & observability → 6. Governance Linkages — iSHARE + iLabs: the evidence-pack format for PD2 assessments, which the 🧩 asks for and which PD2 will need before this block is finished.
• Guiding questions — Identity & attestation management → 2. Credential Types & Attestations — iSHARE: actual validity periods. None are set.
• Guiding questions — Identity & attestation management → 5. Governance & Lifecycle Management — iSHARE legal: confirm unilateral suspension authority — assumed throughout this scheme and agreed nowhere.
• Guiding questions — Trust framework → 3. Validation & Verification Processes — iSHARE: confirm, since the DAT question touches cross-framework interoperability with IDSA-based spaces.
• Guiding questions — Trust framework → 4. Registry & Transparency — iSHARE: registry availability expectations and correction procedure for erroneous entries, both missing. The registry is operated by iSHARE Foundation per PD4 v1.0 §3, so these belong to the Scheme Owner rather than to the ITB-S operator.
• Guiding questions — Trust framework → 5. Leveraging Existing Frameworks — iSHARE: whether any such arrangement is anticipated within the pilot. Nothing in the use cases currently requires one.
• Guiding questions — Publication & discovery → 2. Governance & Access Control — Nunsys + iSHARE: how a rejected listing is appealed. The scheme gives the operator a rejection power and no appeal route, which is a governance gap rather than an oversight to leave to practice.
• Guiding questions — Value creation services → 2. Governance and Participation — iSHARE + iLabs: the AI-agent credential policy, which the agent profile marks _TODO_ and which gates admission of agent services.
• Guiding questions — Value creation services → 4. Access and Fairness — ERTICO + iSHARE: this is the exploitation-model 🧩, and no pricing exists anywhere in the scheme.
• Guiding questions — Value creation services → 6. Trust, Certification, and Quality Assurance — Nunsys + LogiNex + iSHARE legal: the same question for services that carry no credential — analytics, simulation, advisory. PD4 §4 covers certification of credentials, not of the services computing over them, and the liability position proposed above is still the drafter's.
• AI agents & observers → 3 · Objectives & KPIs — ** — iSHARE + iLabs, with the University of the Aegean on engagement.** Targets and measurement window for the first two. For observer engagement, say who the intended users are — residents, municipal staff, or partner organisations — since the number is meaningless without the population.
• AI agents & observers → 8–12 · Timeline, value, risks, EU alignment — ** — iSHARE.** The agent-credential policy draft: which credential types an agent holds, how its declared purpose is bound into the credential, who may issue one, maximum lifetime, and the revocation trigger. This gates admission of agent services under Value creation services section 2, so nothing in the agent layer can be admitted until it exists.
• Marketplace & CO₂ tokenisation → 8–12 · Timeline, value, risks, EU alignment — ** — LogiNex + iSHARE legal.** The MiCA question needs closing in writing, once: if the reward token is not a crypto-asset under MiCA, record why (non-transferable, no secondary market, redeemable only within the scheme) and the design constraints that keep it so. A token designed without that constraint in mind may acquire it accidentally.

iLabs Technologies

• Guiding questions — Business model → 3. Cost structures including data curation, onboarding, governance participation — iLabs and Nunsys: actual running costs. No figures exist anywhere in this scheme.
• Guiding questions — Data space intermediaries & operators → 4. Onboarding & Participant Support — iLabs — the open 🧩 on the block page asks for exactly this: onboarding-support services, registry availability and SLA, the conformance process, and continuity arrangements. Everything above is a drafting position, and the throughput times the scheme needs in order to promise anything are still unknown.
• Guiding questions — Data space intermediaries & operators → 5. Federation & Specialisation — iLabs: the executed work order against that scope (PD4 v1.0 Table 3, target M7). Risk: the trust-registry interconnection and the ITB-S integration depend on a subcontract that is described in the application but not yet placed. Mitigation: place it; iLabs remains the accountable operator of the ITB-S conformance lab, development sandbox and reference trust gateway whatever the final scope.
• Guiding questions — Data space offerings → 2. Functional Questions: — iLabs + both cities + LogiNex: the versions of those models and who maintains each LDT extension. The application names the families, not the releases, and names no maintainer for anything the scheme adds on top.
• Guiding questions — Data space offerings → 6. User Support — Training for quality contribution should focus on the one thing contributors reliably get wrong: writing a description that is policy-complete. iLabs + Nunsys: confirm scope and capacity.
• Guiding questions — Organisational form & governance authority → 2.3 Operational Management — iLabs and Nunsys: confirm what you can actually report monthly, and at what granularity. The specification above assumes capability nobody has confirmed.
• Guiding questions — Organisational form & governance authority → 3.3 Internal Policies and Procedures — iSHARE + iLabs: incident handling is the gap with real consequences and no owner in the register. It should be assigned.
• Guiding questions — Participation management → 2.3 Onboarding Process — iLabs: expected throughput times per step. The register's 🧩 asks for exactly this, and without it the scheme promises a process whose duration nobody can state.
• Guiding questions — Participation management → 2.4 Post-Onboarding Support — iLabs + Nunsys: what support you can actually commit to, and with what response expectation. The service agreements, not this page, are where that becomes binding.
• Guiding questions — Participation management → 4.4 Additional Strategic Questions — iSHARE legal + iLabs jointly: this whole section is drafted from the scheme's own logic rather than from a decision. The offboarding path is the least exercised part of the participation model and the one most likely to be wrong.
• Guiding questions — Regulatory compliance → 4. Certification and Assurance — iLabs: what per-release re-testing costs and whether it is feasible at the expected participant count. The policy is fixed; the capacity behind it is not, and it is the input the revenue model in Intermediaries & operators prices against.
• Guiding questions — Data exchange → 1. Protocol Selection — iLabs, with FHC and HyEnSys — the open 🧩. Domain-specific APIs per use case remain unnamed, and the data-source inventories they depend on are still _TODO_ on every site profile.
• Guiding questions — Data exchange → 2. Modes of Exchange — iLabs: confirm the EDC + iSHARE extension enforces that on long-lived transfers. The requirement is stated here; the capability is assumed. Second question on the same component, raised by PD4 v1.0 §3: the pinned pilot profile names protocols, credential formats, status lists and policy enforcement at the gateway, but no connector. Confirm that the EDC + iSHARE extension path satisfies that profile unchanged, or state which part it implements differently — PD4 Table 2 describes the Cartagena ingestion as MQTT/JSON/UL connectors into the data-space layer, with no EDC mentioned, and the two descriptions should not be left to be reconciled by the reader.
• Guiding questions — Data exchange → 3. Integration with Semantics & Discovery — iLabs + Nunsys: whether OpenAPI documents for site-specific APIs are published in the catalogue alongside the dataset descriptions, or only linked. It affects whether a consumer can generate a client automatically.
• Guiding questions — Data exchange → 4. Quality & Reliability — iLabs — the 🧩 asks for the error-handling and reconnection policy and the ITB-S conformance procedure that gates production onboarding. Neither is written.
• Guiding questions — Data exchange → 5. Federation Readiness — iLabs: whether ITB-S can emit that inventory. If it can, the scheme gets federation readiness as a by-product of conformance testing instead of as a documentation exercise.
• Guiding questions — Data models → 1. Understanding Scope & Semantics — iLabs + both cities + LogiNex: the concrete entity and relationship list per domain. The scope rule above is the scheme's position; the actual concepts are the 🧩 contribution and do not exist yet.
• Guiding questions — Data models → 2. Selecting or Creating Models — iLabs + cities + LogiNex: per domain, the model reused, its version, the extension needed, and the maintainer. ERTICO owes the mobility recommendation.
• Guiding questions — Data models → 4. Governance and Maintenance — iLabs: who maintains each LDT extension in practice.
• Guiding questions — Provenance, traceability & observability → 2. Data Modelling — iLabs + iSHARE — the 🧩. The split above is a drafting position; the event list and the PROV profile are the actual deliverable and do not exist.
• Guiding questions — Provenance, traceability & observability → 3. Storage & Management — iLabs: storage location and whether retention can actually be enforced per class.
• Guiding questions — Provenance, traceability & observability → 4. Observability Scope — iLabs + iSHARE: whether the aggregate layer is published openly or stays inside the consortium. PD4 fixes what is collected and who may see their own; it does not say who may see the totals, and that is the part a prospective participant judges the scheme by.
• Guiding questions — Provenance, traceability & observability → 5. Trust & Third Parties — iLabs + iSHARE: the export format. The commitment is made, so the centralisation risk is no longer unmitigated in principle, but an export nobody can parse mitigates nothing in practice — name the format and whether it carries the policy decision and reason alongside the transaction.
• Guiding questions — Provenance, traceability & observability → 6. Governance Linkages — iSHARE + iLabs: the evidence-pack format for PD2 assessments, which the 🧩 asks for and which PD2 will need before this block is finished.
• Guiding questions — Access & usage policies enforcement → 4. Enforcement Architecture — iLabs: name the PAP, and confirm how policy updates reach every PDP.
• Guiding questions — Access & usage policies enforcement → 5. Compliance Tracking & Proof — iLabs: whether pattern detection exists or is aspirational. This answer specifies a requirement, not an implemented capability.
• Guiding questions — Data, services & offerings descriptions → 1. Standardised Metadata Models — Nunsys + LogiNex + iLabs — the 🧩: the concrete field list, the SHACL shapes, and the CO₂ descriptor extension.
• Guiding questions — Publication & discovery → 5. Offering Lifecycle & Sustainability — Nunsys + iLabs: the PID scheme. None exists.
• Guiding questions — Value creation services → 2. Governance and Participation — iSHARE + iLabs: the AI-agent credential policy, which the agent profile marks _TODO_ and which gates admission of agent services.
• Guiding questions — Value creation services → 3. Interoperability and Standards — Nunsys + iLabs: whether service descriptions share the dataset SHACL shapes or need their own.
• AI agents & observers → 3 · Objectives & KPIs — ** — iSHARE + iLabs, with the University of the Aegean on engagement.** Targets and measurement window for the first two. For observer engagement, say who the intended users are — residents, municipal staff, or partner organisations — since the number is meaningless without the population.
• AI agents & observers → 5–6 · Data needs & sharing rules this use case needs — ** — iLabs.** The retrieval-boundary design note, and it is more consequential than its placement on this page suggests. The scheme's enforcement model assumes a requester with a credential and a declared purpose; a retrieval-augmented chatbot blurs that — the question is whether retrieval happens under the viewer's credential or under the agent's, and the answer determines whether the chatbot can leak restricted data to an unauthorised viewer. The scheme's position, for iLabs to confirm or correct: retrieval runs under the viewer's authorisation, so an unauthenticated resident reaches open-tier content only, and no restricted content enters model context for that session. Caching and conversation memory must respect the same boundary, which is the part usually missed.
• Aruba Airport — operational decarbonisation → 8 · Timeline & maturity — ** — FHC Corp, with iLabs.** Milestones with dates: wallet and VC issuance ceremony defined, first operational-role credential issued, ITB-S identity-module validation passed, first cross-site derived indicator exchanged. The dependency to state alongside: this profile is the scheme's pioneer implementation of wallet-based credentials, so its milestones gate the worked example that Identity & attestation owes every other site.
• Cartagena — LEZ, air quality & heat resilience → 8 · Timeline & maturity — ** — Cartagena, with iLabs.** Milestones, with dates: ITB-S conformance of the first exchange path, first open-tier dataset listed in the marketplace, first cross-site indicator exchanged with Almelo, and the LEZ scenario-simulation service available. Dependencies to state alongside them: the source inventory above, and the baseline policy set sign-off in Access & usage policies, which is due 17 Oct 2026.

Nunsys

• Guiding questions — Business model → 1. Value propositions for different roles (e.g. data providers, users, CO₂ consultants, real estate owners) — ERTICO + iSHARE (input Nunsys, Aegean) — the open 🧩. This table is a drafting position derived from the use-case profiles, not a validated value proposition.
• Guiding questions — Business model → 3. Cost structures including data curation, onboarding, governance participation — iLabs and Nunsys: actual running costs. No figures exist anywhere in this scheme.
• Guiding questions — Data space intermediaries & operators → 2. Service Brokerage — Nunsys: which of these functions WP6 actually delivers, and when.
• Guiding questions — Data space intermediaries & operators → 6. Governance and Trust — Nunsys + iSHARE: confirm that framing, and state how a rejected listing can be appealed.
• Guiding questions — Data space offerings → 1. Data Products — Nunsys + LogiNex + both cities — the open 🧩. Per product: source, update frequency, quality level, licence tier and Green-Deal descriptors. Update frequency is not stated for a single product today, and it determines protocol choice in Data exchange.
• Guiding questions — Data space offerings → 3. Functional/Technical Questions: — The per-source inventories are _TODO_ on every site profile and are the precondition for this block's 🧩.
• Guiding questions — Data space offerings → 4. Associated Services — Nunsys + LogiNex: confirm the quality-declaration fields are producible.
• Guiding questions — Data space offerings → 6. User Support — Training for quality contribution should focus on the one thing contributors reliably get wrong: writing a description that is policy-complete. iLabs + Nunsys: confirm scope and capacity.
• Guiding questions — Organisational form & governance authority → 2.3 Operational Management — iLabs and Nunsys: confirm what you can actually report monthly, and at what granularity. The specification above assumes capability nobody has confirmed.
• Guiding questions — Participation management → 2.4 Post-Onboarding Support — iLabs + Nunsys: what support you can actually commit to, and with what response expectation. The service agreements, not this page, are where that becomes binding.
• Guiding questions — Participation management → 3.1 Operational Enablement — Nunsys: whether the marketplace can report unmatched searches at all. The mechanism above assumes it can.
• Guiding questions — Contractual framework → 4. Flexibility vs. Standardisation — Nunsys for the marketplace annex; Almelo Energie / HyEnSys for the grid-party annex, which is assumed here and confirmed nowhere.
• Guiding questions — Contractual framework → 6. Compliance and Enforcement — Nunsys + LogiNex: liability for incorrect reward calculations, which the marketplace 🧩 asks for and which has no answer in the scheme today.
• Guiding questions — Data exchange → 3. Integration with Semantics & Discovery — iLabs + Nunsys: whether OpenAPI documents for site-specific APIs are published in the catalogue alongside the dataset descriptions, or only linked. It affects whether a consumer can generate a client automatically.
• Guiding questions — Data, services & offerings descriptions → 1. Standardised Metadata Models — Nunsys + LogiNex + iLabs — the 🧩: the concrete field list, the SHACL shapes, and the CO₂ descriptor extension.
• Guiding questions — Data, services & offerings descriptions → 5. Ecosystem Visibility and Transparency — Nunsys: whether the catalogue can compute staleness against declared frequency. The mechanism assumes it can.
• Guiding questions — Publication & discovery → 2. Governance & Access Control — Nunsys + iSHARE: how a rejected listing is appealed. The scheme gives the operator a rejection power and no appeal route, which is a governance gap rather than an oversight to leave to practice.
• Guiding questions — Publication & discovery → 5. Offering Lifecycle & Sustainability — Nunsys + iLabs: the PID scheme. None exists.
• Guiding questions — Value creation services → 3. Interoperability and Standards — Nunsys + iLabs: whether service descriptions share the dataset SHACL shapes or need their own.
• Guiding questions — Value creation services → 5. Sustainability and Business Models — Nunsys + LogiNex: token issuance basis, redemption, anti-gaming controls, fees and revenue allocation — the open 🧩, and the MiCA question flagged on the marketplace profile.
• Guiding questions — Value creation services → 6. Trust, Certification, and Quality Assurance — Nunsys + LogiNex + iSHARE legal: the same question for services that carry no credential — analytics, simulation, advisory. PD4 §4 covers certification of credentials, not of the services computing over them, and the liability position proposed above is still the drafter's.
• Marketplace & CO₂ tokenisation → 3 · Objectives & KPIs — ** — Nunsys.** Targets and measurement window per metric. The one worth defining carefully is reuse events, since it is the only metric here that measures whether the data space works rather than whether it was built: a listing nobody consumes is activity without value. Define what counts as a reuse event — a contract negotiated, a transfer completed, or a repeat transfer — before the number is reported.
• Marketplace & CO₂ tokenisation → 7 · Architecture (building blocks used) — ** — Nunsys.** The ledger or registry choice for tokens is unmade, and it is not a purely technical decision. A distributed ledger brings MiCA and environmental-footprint questions into a sustainability project; a conventional registry does not, and loses the transferability that makes a token a token rather than a loyalty point. State which, and why. Whichever is chosen, the scheme needs: where token state lives, who operates it, what happens to balances if the operator stops, and how a token issued on a later-corrected CO₂ figure is handled — reversal, adjustment, or neither. That last question has no answer anywhere in the scheme and is the one an auditor will ask first.
• Marketplace & CO₂ tokenisation → 8–12 · Timeline, value, risks, EU alignment —

iSHARE Foundation (legal)

• Guiding questions — Organisational form & governance authority → 1.4 Country and Jurisdiction — iSHARE legal, with Cartagena and Almelo: regulatory, tax and operational consequences per candidate jurisdiction. This answer names a likely choice; it does not evaluate alternatives, and nobody has yet done that analysis.
• Guiding questions — Organisational form & governance authority → 2.4 Dispute Resolution & Compliance — iSHARE legal: the template names CSRD and EPBD. Neither appears in this scheme's framework table. Confirm whether they apply to the LDT — EPBD plausibly does via the Aadorp PED — or strike them.
• Guiding questions — Organisational form & governance authority → 3.2 Terms and Conditions for Participants — iSHARE legal: confirm the accession model can carry this structure, and that the cities can sign it under municipal contracting rules — the open sign-off 🧩 in Contractual framework.
• Guiding questions — Participation management → 2.2 Pre-Conditions for Entry — iSHARE legal: whether baseline legal compliance (a GDPR posture statement, say) should be an entry requirement or a contractual warranty. The scheme currently assumes the latter; that assumption has not been tested.
• Guiding questions — Participation management → 4.1 Exit Scenarios — iSHARE legal: the same durations for a scheme participant that is not a consortium party — the accession agreement has to carry its own, and whether it mirrors the 30 days is a drafting choice nobody has made.
• Guiding questions — Participation management → 4.2 Offboarding Process — The hard case nobody has addressed: data already transferred cannot be recalled. What survives exit — deletion duties, retention for audit, continued honouring of usage policies — is a contract question for iSHARE legal, and the answer should be written into the accession agreement rather than inferred.
• Guiding questions — Participation management → 4.4 Additional Strategic Questions — iSHARE legal + iLabs jointly: this whole section is drafted from the scheme's own logic rather than from a decision. The offboarding path is the least exercised part of the participation model and the one most likely to be wrong.
• Guiding questions — Contractual framework → 1. Core Structure of Agreements — iSHARE legal: whether that Accession Agreement carries the six elements listed above as drafted, and whether the cities can sign it under municipal contracting rules. The Data Ecosystem Agreement names the instrument but does not reproduce it, and the copy consulted here is the Scheme Owner template, not an executed EUTwinLink agreement.
• Guiding questions — Contractual framework → 2. Alignment with Governance — iSHARE legal: whether the accession agreement for a scheme participant that is not a consortium party adopts the same threshold and the same 30-day window, or sets its own. The consortium instrument cannot bind a party that never signed it.
• Guiding questions — Contractual framework → 3. Onboarding and Offboarding — iSHARE legal. This is the single most consequential gap in the contract stack as it stands.
• Guiding questions — Contractual framework → 5. Dispute Prevention and Resolution — iSHARE legal: whether the accession agreement adopts that ladder for participants who never signed the Consortium Agreement, or points at a different forum. The gap is real — the question is now which of two known answers it gets, not what the alternative looks like.
• Guiding questions — Regulatory compliance → 1. Applicable Legal Frameworks — iSHARE legal with Cartagena (ES), Almelo (NL), FHC (Aruba), reviewed by ERTICO — the 🧩 on the block page. National law is the gap: this table is almost entirely EU-level, and ES and NL administrative, procurement and open-data rules are not represented at all.
• Guiding questions — Regulatory compliance → 2. Compliance Responsibilities — iSHARE legal: whether the declaration should be a contractual warranty with consequences, or a statement of fact. The scheme currently assumes the former.
• Guiding questions — Regulatory compliance → 3. Risk and Liability — iSHARE legal + ERTICO: insurance, and what replaces the "share of project costs" cap once there is no project to take a share of. Checked against both instruments: neither the Consortium Agreement nor the Pilot Grant Agreement mentions insurance anywhere, so this is not an omission from this page but an absence in the contract stack. Both are post-pilot questions and neither has an instrument behind it.
• Guiding questions — Regulatory compliance → 6. Enforcement Mechanisms — iSHARE legal: every page in this scheme that assumes a unilateral suspension needs rewriting to the two-step above, or the scheme has to argue for an emergency power and get it agreed. The second is defensible for a key compromise, where waiting for a General Assembly is not an option — but it has to be written, not assumed.
• Guiding questions — Identity & attestation management → 5. Governance & Lifecycle Management — iSHARE legal: confirm unilateral suspension authority — assumed throughout this scheme and agreed nowhere.
• Guiding questions — Value creation services → 6. Trust, Certification, and Quality Assurance — Nunsys + LogiNex + iSHARE legal: the same question for services that carry no credential — analytics, simulation, advisory. PD4 §4 covers certification of credentials, not of the services computing over them, and the liability position proposed above is still the drafter's.
• Marketplace & CO₂ tokenisation → 8–12 · Timeline, value, risks, EU alignment — ** — LogiNex + iSHARE legal.** The MiCA question needs closing in writing, once: if the reward token is not a crypto-asset under MiCA, record why (non-transferable, no secondary market, redeemable only within the scheme) and the design constraints that keep it so. A token designed without that constraint in mind may acquire it accidentally.

ERTICO – ITS Europe

• Guiding questions — Business model → 1. Value propositions for different roles (e.g. data providers, users, CO₂ consultants, real estate owners) — ERTICO + iSHARE (input Nunsys, Aegean) — the open 🧩. This table is a drafting position derived from the use-case profiles, not a validated value proposition.
• Guiding questions — Business model → 2. Revenue mechanisms (e.g. subscription, pay-per-use, public-private funding) — ERTICO + iSHARE: align with the PD5 cost-benefit analysis; none of these rates exist.
• Guiding questions — Business model → 4. Cost structures including data curation, onboarding, governance participation — ERTICO + Aegean: whether partners recognise these as their incentives.
• Guiding questions — Business model → 5. Theme & Scope — ERTICO + iSHARE: confirm, or correct, if the exploitation plan assumes network growth.
• Guiding questions — Business model → 7. Governance Authority — ERTICO + iSHARE: the funding model for the authority itself. Nothing in this scheme answers it today.
• Guiding questions — Organisational form & governance authority → 1.3 Profit vs Non-Profit Orientation — ERTICO + iSHARE: confirm this split survives contact with the exploitation plan, and say whether any partner intends to commercialise a scheme-layer function.
• Guiding questions — Participation management → 3.3 Additional Strategic Questions — ERTICO + iSHARE: participant recruitment after the pilot belongs to the exploitation case and has no owner in the register today.
• Guiding questions — Regulatory compliance → 1. Applicable Legal Frameworks — iSHARE legal with Cartagena (ES), Almelo (NL), FHC (Aruba), reviewed by ERTICO — the 🧩 on the block page. National law is the gap: this table is almost entirely EU-level, and ES and NL administrative, procurement and open-data rules are not represented at all.
• Guiding questions — Regulatory compliance → 3. Risk and Liability — iSHARE legal + ERTICO: insurance, and what replaces the "share of project costs" cap once there is no project to take a share of. Checked against both instruments: neither the Consortium Agreement nor the Pilot Grant Agreement mentions insurance anywhere, so this is not an omission from this page but an absence in the contract stack. Both are post-pilot questions and neither has an instrument behind it.
• Guiding questions — Value creation services → 4. Access and Fairness — ERTICO + iSHARE: this is the exploitation-model 🧩, and no pricing exists anywhere in the scheme.
• Cartagena — LEZ, air quality & heat resilience → 9–12 · Value, risks, EU alignment, materials — ** — Cartagena + ERTICO.** ERTICO owes the mobility-standards recommendation (which models and ITS profiles apply) that Data models is waiting on. Cartagena owes confirmation that the attribution risk above is the one it is actually exposed to politically — it is the drafter's reading, not the city's.
• Hamburg Port — logistics twin → 3–5 · Objectives, stakeholders, data — ** — liaison (Cartagena / ERTICO) with Hamburg Port Authority (supporting stakeholder, letter of support).** This profile has no confirmed owner, and six weeks after the v0.5 deadline that is itself becoming a decision by default. The scheme needs four things, in this order: 1. Who signs. An accession agreement needs a signatory. If the Port participates only as a supporter, the scheme needs the lightweight Observer/associate accession described in section 6 — and that document does not exist. 2. What flows. Which datasets or indicators move to and from the LDT. The profile's own position is that commercial logistics data stays restricted and only derived indicators cross, which is workable but unconfirmed. 3. ESRI-stack interoperability. The interconnection must remain non-ESRI-portable per the funder recommendation (Annex 9) — in this scheme that is a general portability rule, not a vendor objection. Needed: which interfaces are open and documented. 4. Whether to proceed at all. If the Port's effort cannot be secured, the honest course is to record Hamburg as out of scope for PD4 rather than carry it as pending — see Use case development section 8.
• Hamburg Port — logistics twin → 7–12 · Architecture, timeline, value, risks — ** — liaison + ERTICO.** Hold the scoping call, or recommend descoping. Both are acceptable outcomes; carrying it forward unchanged is not.

LogiNex Carbon Intelligence

• Guiding questions — Data space offerings → 1. Data Products — Nunsys + LogiNex + both cities — the open 🧩. Per product: source, update frequency, quality level, licence tier and Green-Deal descriptors. Update frequency is not stated for a single product today, and it determines protocol choice in Data exchange.
• Guiding questions — Data space offerings → 2. Functional Questions: — iLabs + both cities + LogiNex: the versions of those models and who maintains each LDT extension. The application names the families, not the releases, and names no maintainer for anything the scheme adds on top.
• Guiding questions — Data space offerings → 3. Functional/Technical Questions: — The per-source inventories are _TODO_ on every site profile and are the precondition for this block's 🧩.
• Guiding questions — Data space offerings → 4. Associated Services — Nunsys + LogiNex: confirm the quality-declaration fields are producible.
• Guiding questions — Contractual framework → 6. Compliance and Enforcement — Nunsys + LogiNex: liability for incorrect reward calculations, which the marketplace 🧩 asks for and which has no answer in the scheme today.
• Guiding questions — Data models → 1. Understanding Scope & Semantics — iLabs + both cities + LogiNex: the concrete entity and relationship list per domain. The scope rule above is the scheme's position; the actual concepts are the 🧩 contribution and do not exist yet.
• Guiding questions — Data models → 2. Selecting or Creating Models — iLabs + cities + LogiNex: per domain, the model reused, its version, the extension needed, and the maintainer. ERTICO owes the mobility recommendation.
• Guiding questions — Data, services & offerings descriptions → 1. Standardised Metadata Models — Nunsys + LogiNex + iLabs — the 🧩: the concrete field list, the SHACL shapes, and the CO₂ descriptor extension.
• Guiding questions — Data, services & offerings descriptions → 4. Sector-Specific Extensions: — LogiNex, Almelo Energie, Cartagena: confirm these attributes are producible from their systems. The list is derived from what the claims require, not from what the sites can emit.
• Guiding questions — Value creation services → 5. Sustainability and Business Models — Nunsys + LogiNex: token issuance basis, redemption, anti-gaming controls, fees and revenue allocation — the open 🧩, and the MiCA question flagged on the marketplace profile.
• Guiding questions — Value creation services → 6. Trust, Certification, and Quality Assurance — Nunsys + LogiNex + iSHARE legal: the same question for services that carry no credential — analytics, simulation, advisory. PD4 §4 covers certification of credentials, not of the services computing over them, and the liability position proposed above is still the drafter's.
• Marketplace & CO₂ tokenisation → 8–12 · Timeline, value, risks, EU alignment —
• Marketplace & CO₂ tokenisation → 8–12 · Timeline, value, risks, EU alignment — ** — LogiNex + iSHARE legal.** The MiCA question needs closing in writing, once: if the reward token is not a crypto-asset under MiCA, record why (non-transferable, no secondary market, redeemable only within the scheme) and the design constraints that keep it so. A token designed without that constraint in mind may acquire it accidentally.

Ayuntamiento de Cartagena

• Guiding questions — Organisational form & governance authority → 1.4 Country and Jurisdiction — iSHARE legal, with Cartagena and Almelo: regulatory, tax and operational consequences per candidate jurisdiction. This answer names a likely choice; it does not evaluate alternatives, and nobody has yet done that analysis.
• Guiding questions — Organisational form & governance authority → 4. Additional Strategic Questions for Co-Creation — These are the co-creation questions for the 🧩 contribution on the block page — City of Almelo and Ayuntamiento de Cartagena, from the public-authority perspective. They are the questions this scheme most needs answered by someone other than its drafter, and the draft below is a starting position to react to, not an answer.
• Guiding questions — Regulatory compliance → 1. Applicable Legal Frameworks — iSHARE legal with Cartagena (ES), Almelo (NL), FHC (Aruba), reviewed by ERTICO — the 🧩 on the block page. National law is the gap: this table is almost entirely EU-level, and ES and NL administrative, procurement and open-data rules are not represented at all.
• Guiding questions — Regulatory compliance → 5. Sector-Specific Rules — Cartagena, Almelo and FHC respectively. Each knows its sector; the scheme does not.
• Guiding questions — Data, services & offerings descriptions → 4. Sector-Specific Extensions: — LogiNex, Almelo Energie, Cartagena: confirm these attributes are producible from their systems. The list is derived from what the claims require, not from what the sites can emit.
• Cartagena — LEZ, air quality & heat resilience → 3 · Objectives & KPIs — ** — Ayuntamiento de Cartagena.** Per metric the scheme needs four things, and has none of them: the baseline value and the period it was measured over, the target, the measurement window, and the spatial scope (which corridors). A metric without a baseline cannot evidence improvement, and these feed the PD2 and PD5 KPI sets directly. Where a target is politically sensitive, state a measurement commitment instead of a number — that is still usable; silence is not.
• Cartagena — LEZ, air quality & heat resilience → 4 · Stakeholders — ** — Cartagena.** Confirm the regional and national authorities involved (Región de Murcia; any air-quality or transport competence held above municipal level) and state for each whether it is a data provider, a data recipient, or a regulator with a right of access. The distinction decides whether it appears in the scheme as a participant with an accession agreement or as a recipient under a legal obligation, and the two carry different obligations entirely.
• Cartagena — LEZ, air quality & heat resilience → 5 · Data needs & sources — ** — Cartagena.** The source inventory is the precondition for Data models and Data exchange, and neither block can be completed without it. Per source: format, update frequency, quality or coverage level, level of detail, whether it already exposes NGSI-LD / MIM2, and whether it contains personal data. The LEZ camera and enforcement feed is the one to answer first. It is the only source in this profile that is both personal data and held under an enforcement power, which means its lawful basis is not consent and the Commons model does not reach it. Until Cartagena states what it is and under which power it is processed, the scheme cannot write a defensible policy for it.
• Cartagena — LEZ, air quality & heat resilience → 7 · Architecture (building blocks used) — ** — Cartagena + PD3 authors.** Cross-reference the PD3 architecture diagram here rather than redrawing it. This profile should name the blocks and the conditions; PD3 owns the architecture.
• Cartagena — LEZ, air quality & heat resilience → 8 · Timeline & maturity — ** — Cartagena, with iLabs.** Milestones, with dates: ITB-S conformance of the first exchange path, first open-tier dataset listed in the marketplace, first cross-site indicator exchanged with Almelo, and the LEZ scenario-simulation service available. Dependencies to state alongside them: the source inventory above, and the baseline policy set sign-off in Access & usage policies, which is due 17 Oct 2026.
• Cartagena — LEZ, air quality & heat resilience → 9–12 · Value, risks, EU alignment, materials — ** — Cartagena + ERTICO.** ERTICO owes the mobility-standards recommendation (which models and ITS profiles apply) that Data models is waiting on. Cartagena owes confirmation that the attribution risk above is the one it is actually exposed to politically — it is the drafter's reading, not the city's.
• Hamburg Port — logistics twin → 3–5 · Objectives, stakeholders, data — ** — liaison (Cartagena / ERTICO) with Hamburg Port Authority (supporting stakeholder, letter of support).** This profile has no confirmed owner, and six weeks after the v0.5 deadline that is itself becoming a decision by default. The scheme needs four things, in this order: 1. Who signs. An accession agreement needs a signatory. If the Port participates only as a supporter, the scheme needs the lightweight Observer/associate accession described in section 6 — and that document does not exist. 2. What flows. Which datasets or indicators move to and from the LDT. The profile's own position is that commercial logistics data stays restricted and only derived indicators cross, which is workable but unconfirmed. 3. ESRI-stack interoperability. The interconnection must remain non-ESRI-portable per the funder recommendation (Annex 9) — in this scheme that is a general portability rule, not a vendor objection. Needed: which interfaces are open and documented. 4. Whether to proceed at all. If the Port's effort cannot be secured, the honest course is to record Hamburg as out of scope for PD4 rather than carry it as pending — see Use case development section 8.

City of Almelo

• Guiding questions — Organisational form & governance authority → 1.4 Country and Jurisdiction — iSHARE legal, with Cartagena and Almelo: regulatory, tax and operational consequences per candidate jurisdiction. This answer names a likely choice; it does not evaluate alternatives, and nobody has yet done that analysis.
• Guiding questions — Organisational form & governance authority → 4. Additional Strategic Questions for Co-Creation — These are the co-creation questions for the 🧩 contribution on the block page — City of Almelo and Ayuntamiento de Cartagena, from the public-authority perspective. They are the questions this scheme most needs answered by someone other than its drafter, and the draft below is a starting position to react to, not an answer.
• Guiding questions — Participation management → 1.3 Additional: Strategic Questions — HyEnSys + Almelo Energie + Aegean: how community representatives are mandated, and how a Commons decision maps onto a scheme role. This is the open 🧩 on the block page and the main unanswered question in this block.
• Guiding questions — Contractual framework → 4. Flexibility vs. Standardisation — Nunsys for the marketplace annex; Almelo Energie / HyEnSys for the grid-party annex, which is assumed here and confirmed nowhere.
• Guiding questions — Regulatory compliance → 1. Applicable Legal Frameworks — iSHARE legal with Cartagena (ES), Almelo (NL), FHC (Aruba), reviewed by ERTICO — the 🧩 on the block page. National law is the gap: this table is almost entirely EU-level, and ES and NL administrative, procurement and open-data rules are not represented at all.
• Guiding questions — Regulatory compliance → 5. Sector-Specific Rules — Cartagena, Almelo and FHC respectively. Each knows its sector; the scheme does not.
• Guiding questions — Data, services & offerings descriptions → 4. Sector-Specific Extensions: — LogiNex, Almelo Energie, Cartagena: confirm these attributes are producible from their systems. The list is derived from what the claims require, not from what the sites can emit.
• Almelo/Aadorp — Positive Energy District → 3 · Objectives & KPIs — ** — Almelo Energie, with the City of Almelo.** Baseline, target and measurement window per metric, as for every profile. Two PED-specific points the scheme needs stated explicitly: whether each figure is measured or modelled (ESSIM/DEMkit outputs are modelled, and conflating the two is the error that discredits PED claims — see Descriptions section 4), and the measurement boundary — building, block or district — since "positive energy" is only meaningful against a stated boundary.
• Almelo/Aadorp — Positive Energy District → 4 · Stakeholders — ** — City of Almelo + Almelo Energie.** The DSO is the open question with the largest consequences in this profile. Flexibility and balance data flowing to grid parties is already foreseen under a bilateral annex to the standard data-sharing terms, but no grid operator is confirmed as a participant. Three things are needed: whether the DSO participates at all; if so, whether as a full participant with an accession agreement or as a counterparty under a bilateral annex only; and whether NL energy-market rules constrain what may be shared with it. Until this is settled the annex in Contractual framework is drafting against an unknown counterparty.
• Almelo/Aadorp — Positive Energy District → 5 · Data needs & sources — ** — Almelo Energie.** Source inventory: format, frequency, resolution, quality, and personal-data status per source, as the precondition for Data models and Data exchange. The resolution of the household meter data is the critical figure. It determines the aggregation floor the scheme must enforce: high-resolution household consumption reveals occupancy and behaviour, and the ODRL constraint protecting it cannot be written until the resolution and the intended aggregation level are known. Also needed: whether telemetry frequency justifies streaming (MQTT) rather than the scheme's default request/response — see Data exchange section 1.
• Almelo/Aadorp — Positive Energy District → 8 · Timeline & maturity — ** — City of Almelo + Almelo Energie.** Milestones with dates: Commons consent mechanism operational, first aggregated district indicator published, DSO exchange established (dependent on the open question in section 4), and ITB-S conformance of the exchange path. Dependencies: the Commons specification above, and the source inventory.
• Almelo/Aadorp — Positive Energy District → 9–12 · Value, risks, EU alignment, materials — ** — City of Almelo + HyEnSys.** The last risk is the drafter's addition and needs a judgement from people who know Dutch cooperative and data-protection law: is a cooperative mandate a sound basis for household data delegation, and what happens to flows if it is challenged?

FHC Corp (Aruba)

• Guiding questions — Regulatory compliance → 1. Applicable Legal Frameworks — iSHARE legal with Cartagena (ES), Almelo (NL), FHC (Aruba), reviewed by ERTICO — the 🧩 on the block page. National law is the gap: this table is almost entirely EU-level, and ES and NL administrative, procurement and open-data rules are not represented at all.
• Guiding questions — Regulatory compliance → 5. Sector-Specific Rules — Cartagena, Almelo and FHC respectively. Each knows its sector; the scheme does not.
• Guiding questions — Data exchange → 1. Protocol Selection — iLabs, with FHC and HyEnSys — the open 🧩. Domain-specific APIs per use case remain unnamed, and the data-source inventories they depend on are still _TODO_ on every site profile.
• Guiding questions — Identity & attestation management → 3. Credential Issuance & Verification — FHC with Qwihi — the open 🧩: the Aruba issuance ceremony, verification points in the operational process, and revocation handling, written up as a pattern other sites can copy.
• Aruba Airport — operational decarbonisation → 3 · Objectives & KPIs — ** — FHC Corp.** Baseline, target and measurement window per metric. Two things specific to a commercial site: say which figures are commercially confidential and therefore restricted-tier, and which derived indicators may go cross-site — this profile already commits to derived KPIs crossing while operational data does not, and the scheme needs to know which is which before the licence tiers can be written.
• Aruba Airport — operational decarbonisation → 4 · Stakeholders — ** — FHC Corp.** Confirm whether airlines and ground handlers participate. This is not a list-completion detail: if they do, they are third-country commercial participants holding credentials issued under this scheme, which multiplies the non-EU transfer question across several organisations instead of one. If they do not, state that their data reaches the twin through the airport operator, under what terms.
• Aruba Airport — operational decarbonisation → 5 · Data needs & sources — ** — FHC Corp.** Source inventory: format, frequency, quality, and personal-data status per source. The point needing an explicit answer rather than an assumption: at what point passenger-flow data is aggregated. "Aggregate only" is stated as a property of what is shared; the scheme needs to know whether aggregation happens at the sensor, in the twin, or at the point of exchange. If raw flow data exists anywhere in the chain, the privacy position rests on a policy rather than on the architecture, and that changes what the scheme must enforce.
• Aruba Airport — operational decarbonisation → 8 · Timeline & maturity — ** — FHC Corp, with iLabs.** Milestones with dates: wallet and VC issuance ceremony defined, first operational-role credential issued, ITB-S identity-module validation passed, first cross-site derived indicator exchanged. The dependency to state alongside: this profile is the scheme's pioneer implementation of wallet-based credentials, so its milestones gate the worked example that Identity & attestation owes every other site.

Almelo Energie

• Guiding questions — Participation management → 1.3 Additional: Strategic Questions — HyEnSys + Almelo Energie + Aegean: how community representatives are mandated, and how a Commons decision maps onto a scheme role. This is the open 🧩 on the block page and the main unanswered question in this block.
• Guiding questions — Contractual framework → 4. Flexibility vs. Standardisation — Nunsys for the marketplace annex; Almelo Energie / HyEnSys for the grid-party annex, which is assumed here and confirmed nowhere.
• Guiding questions — Data, services & offerings descriptions → 4. Sector-Specific Extensions: — LogiNex, Almelo Energie, Cartagena: confirm these attributes are producible from their systems. The list is derived from what the claims require, not from what the sites can emit.
• Almelo/Aadorp — Positive Energy District → 3 · Objectives & KPIs — ** — Almelo Energie, with the City of Almelo.** Baseline, target and measurement window per metric, as for every profile. Two PED-specific points the scheme needs stated explicitly: whether each figure is measured or modelled (ESSIM/DEMkit outputs are modelled, and conflating the two is the error that discredits PED claims — see Descriptions section 4), and the measurement boundary — building, block or district — since "positive energy" is only meaningful against a stated boundary.
• Almelo/Aadorp — Positive Energy District → 4 · Stakeholders — ** — City of Almelo + Almelo Energie.** The DSO is the open question with the largest consequences in this profile. Flexibility and balance data flowing to grid parties is already foreseen under a bilateral annex to the standard data-sharing terms, but no grid operator is confirmed as a participant. Three things are needed: whether the DSO participates at all; if so, whether as a full participant with an accession agreement or as a counterparty under a bilateral annex only; and whether NL energy-market rules constrain what may be shared with it. Until this is settled the annex in Contractual framework is drafting against an unknown counterparty.
• Almelo/Aadorp — Positive Energy District → 5 · Data needs & sources — ** — Almelo Energie.** Source inventory: format, frequency, resolution, quality, and personal-data status per source, as the precondition for Data models and Data exchange. The resolution of the household meter data is the critical figure. It determines the aggregation floor the scheme must enforce: high-resolution household consumption reveals occupancy and behaviour, and the ODRL constraint protecting it cannot be written until the resolution and the intended aggregation level are known. Also needed: whether telemetry frequency justifies streaming (MQTT) rather than the scheme's default request/response — see Data exchange section 1.
• Almelo/Aadorp — Positive Energy District → 8 · Timeline & maturity — ** — City of Almelo + Almelo Energie.** Milestones with dates: Commons consent mechanism operational, first aggregated district indicator published, DSO exchange established (dependent on the open question in section 4), and ITB-S conformance of the exchange path. Dependencies: the Commons specification above, and the source inventory.

Both cities

• Guiding questions — Data space offerings → 1. Data Products — Nunsys + LogiNex + both cities — the open 🧩. Per product: source, update frequency, quality level, licence tier and Green-Deal descriptors. Update frequency is not stated for a single product today, and it determines protocol choice in Data exchange.
• Guiding questions — Data space offerings → 2. Functional Questions: — iLabs + both cities + LogiNex: the versions of those models and who maintains each LDT extension. The application names the families, not the releases, and names no maintainer for anything the scheme adds on top.
• Guiding questions — Data space offerings → 3. Functional/Technical Questions: — The per-source inventories are _TODO_ on every site profile and are the precondition for this block's 🧩.
• Guiding questions — Data space offerings → 7. Interoperability — Both cities: whether open-tier offerings should be harvested by national portals. That is a municipal transparency decision, not a technical one.
• Guiding questions — Data models → 1. Understanding Scope & Semantics — iLabs + both cities + LogiNex: the concrete entity and relationship list per domain. The scope rule above is the scheme's position; the actual concepts are the 🧩 contribution and do not exist yet.
• Guiding questions — Data models → 2. Selecting or Creating Models — iLabs + cities + LogiNex: per domain, the model reused, its version, the extension needed, and the maintainer. ERTICO owes the mobility recommendation.
• Guiding questions — Publication & discovery → 4. Interoperability & Standards — Both cities: which offerings fall into that last category.

HyEnSys

• Guiding questions — Participation management → 1.3 Additional: Strategic Questions — HyEnSys + Almelo Energie + Aegean: how community representatives are mandated, and how a Commons decision maps onto a scheme role. This is the open 🧩 on the block page and the main unanswered question in this block.
• Guiding questions — Contractual framework → 4. Flexibility vs. Standardisation — Nunsys for the marketplace annex; Almelo Energie / HyEnSys for the grid-party annex, which is assumed here and confirmed nowhere.
• Guiding questions — Data exchange → 1. Protocol Selection — iLabs, with FHC and HyEnSys — the open 🧩. Domain-specific APIs per use case remain unnamed, and the data-source inventories they depend on are still _TODO_ on every site profile.
• Guiding questions — Access & usage policies enforcement → 2. Policy Information Points (PIPs) — HyEnSys — the Commons-controls 🧩, which is the specification this answer depends on and which does not exist yet.
• Almelo/Aadorp — Positive Energy District → 7 · Architecture (building blocks used) — ** — HyEnSys.** Integration notes, and — more importantly — the Commons-controls specification this profile depends on, which is also the open 🧩 in Access & usage policies. Specifically: how a household joins, consents, delegates to the cooperative and leaves; how a community mandate is expressed so a PDP can act on it; and what happens when a Commons rule and a participant's policy conflict. This specification gates two building blocks and is the single most load-bearing missing contribution in the scheme.
• Almelo/Aadorp — Positive Energy District → 9–12 · Value, risks, EU alignment, materials — ** — City of Almelo + HyEnSys.** The last risk is the drafter's addition and needs a judgement from people who know Dutch cooperative and data-protection law: is a cooperative mandate a sound basis for household data delegation, and what happens to flows if it is challenged?

All use-case profile owners

• Guiding questions — Use case development → 3. Use Case Objectives — 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.
• Guiding questions — Use case development → 4. Stakeholder Involvement — 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. 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.
• Guiding questions — Use case development → 5. Data Needs & Sources — 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.
• Guiding questions — Use case development → 8. Timeline and Maturity — Milestones are _TODO_ on every site profile. The scheme can state sequence but not dates.

University of the Aegean

• Guiding questions — Business model → 1. Value propositions for different roles (e.g. data providers, users, CO₂ consultants, real estate owners) — ERTICO + iSHARE (input Nunsys, Aegean) — the open 🧩. This table is a drafting position derived from the use-case profiles, not a validated value proposition.
• Guiding questions — Business model → 4. Cost structures including data curation, onboarding, governance participation — ERTICO + Aegean: whether partners recognise these as their incentives.
• Guiding questions — Participation management → 1.3 Additional: Strategic Questions — HyEnSys + Almelo Energie + Aegean: how community representatives are mandated, and how a Commons decision maps onto a scheme role. This is the open 🧩 on the block page and the main unanswered question in this block.
• AI agents & observers → 3 · Objectives & KPIs — ** — iSHARE + iLabs, with the University of the Aegean on engagement.** Targets and measurement window for the first two. For observer engagement, say who the intended users are — residents, municipal staff, or partner organisations — since the number is meaningless without the population.

PD3 authors

• Guiding questions — Use case development → 7. Architecture — 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.
• Guiding questions — Use case development → 11. Alignment with EU Policies or Standards — 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.
• Cartagena — LEZ, air quality & heat resilience → 7 · Architecture (building blocks used) — ** — Cartagena + PD3 authors.** Cross-reference the PD3 architecture diagram here rather than redrawing it. This profile should name the blocks and the conditions; PD3 owns the architecture.

TIPS Committee

• LDT Governance and Trust Framework → How to contribute your building block — 1. Find your organisation in the Building-block register — it lists exactly which sections wait for your input, with owners and due dates. 2. Review the drafted answers on your block's guiding-questions page: confirm or correct the Proposed ones and supply the facts. Draft any 🧩 block still open on the block page. 3. Submit as a merge request using the Building block template; the WP4 lead (iSHARE) reviews, the TIPS Committee approves.
• Guiding questions — Organisational form & governance authority → 3.5 Documentation and Accessibility — TIPS: ratify that, or correct it. The decision is no longer "should the scheme become publicly readable" but "is it right that it already is", and it carries a contractual edge. PD4's Document information contradicts the live state: it classifies the deliverable as Sensitive (SEN) and says reviewer access is on request, with the tagged snapshot attached as a PDF annex. That classification is not cosmetic — Pilot Grant Agreement article 12.1 binds the recipient to keep confidential anything identified in writing as sensitive information, for five years after final payment. Marking PD4 "Sensitive" in writing while publishing the repository it is a snapshot of is therefore a tension in the contract, not only in the paperwork. The argument for public stands either way — a data space whose rulebook cannot be read by prospective participants cannot recruit them — but the classification and the visibility have to agree. (Sources: Pilot Grant Agreement article 12.1; GitLab project visibility checked 29 October 2026.)
• Marketplace & CO₂ tokenisation → 8–12 · Timeline, value, risks, EU alignment —

Port of Hamburg / liaison

• Hamburg Port — logistics twin → 3–5 · Objectives, stakeholders, data — ** — liaison (Cartagena / ERTICO) with Hamburg Port Authority (supporting stakeholder, letter of support).** This profile has no confirmed owner, and six weeks after the v0.5 deadline that is itself becoming a decision by default. The scheme needs four things, in this order: 1. Who signs. An accession agreement needs a signatory. If the Port participates only as a supporter, the scheme needs the lightweight Observer/associate accession described in section 6 — and that document does not exist. 2. What flows. Which datasets or indicators move to and from the LDT. The profile's own position is that commercial logistics data stays restricted and only derived indicators cross, which is workable but unconfirmed. 3. ESRI-stack interoperability. The interconnection must remain non-ESRI-portable per the funder recommendation (Annex 9) — in this scheme that is a general portability rule, not a vendor objection. Needed: which interfaces are open and documented. 4. Whether to proceed at all. If the Port's effort cannot be secured, the honest course is to record Hamburg as out of scope for PD4 rather than carry it as pending — see Use case development section 8.
• Hamburg Port — logistics twin → 7–12 · Architecture, timeline, value, risks — ** — liaison + ERTICO.** Hold the scoping call, or recommend descoping. Both are acceptable outcomes; carrying it forward unchanged is not.

Unassigned

• How to contribute your building block → Filling an answer slot — Keep the provenance tag honest when you edit: an answer you confirm as a partner is no longer Proposed, and one you have supplied the facts for is no longer . Dropping a tag removes that item from Open questions for partners the next time tools/collect_open_questions.py runs, which is how the list stays accurate.
• LDT Governance and Trust Framework → Find your way — Every item in the scheme, grouped by partner. Generated from the pages themselves, so it cannot drift.