Skip to content

Guiding questions — Value creation services#

Fork notice. The questions below are reproduced from the iSHARE Data Space Template page Value creation services → 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: Value creation services.

Building block V3 · owner(s) Nunsys + LogiNex + HyEnSys + University of the Aegean · 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.

1. General#

  • What types of value-creation services are most relevant for the sector (e.g., carbon reporting, energy monitoring, predictive maintenance)?
  • Should horizontal (cross-sector) or vertical (domain-specific) services be prioritised?
  • How to balance commercial vs. non-profit services?

LDT answer DRAFTED · owner: Nunsys + LogiNex + HyEnSys + University of the Aegean · due 26 Sep 2026

Decided The service classes relevant to the LDT are already identified on the block page: CO₂ and emission analytics and reporting (LogiNex), CO₂ tokenisation and behavioural rewards (Nunsys + LogiNex), scenario simulation (ESSIM/DEMkit for PED balances, LEZ what-ifs), AI agents and the observer chatbot (iSHARE + iLabs), and citizen-engagement tooling (Aegean + HyEnSys).

Proposed Horizontal before vertical, for a specific reason rather than on principle: the LDT's four twins span mobility, energy, aviation and logistics, so a vertical service serves one site while a horizontal one serves all four. Emission analytics and scenario simulation are horizontal in this network — every site needs them — and they are also what makes cross-site benchmarking possible, which is the LDT's reason to exist. Vertical services follow once a site has a need no horizontal service meets.

Proposed Commercial versus non-profit: the split is already drawn in Organisational form question 1.3 — the trust layer is non-commercial, the service layer is openly commercial. A value-creation service may be commercial; it may not become a condition of participating in the data space, because that would make the trust layer commercial by the back door.

2. Governance and Participation#

Rules are needed to define which services can operate within the data space, how they are accredited, and how participants can trust them.

  • Who governs service acceptance (central authority, sector councils, accreditation body)?
  • What criteria should services meet (technical compliance, ethics, sustainability)?
  • Should service accreditation tiers exist (basic vs. certified)?

LDT answer DRAFTED · owner: Nunsys + LogiNex + HyEnSys + University of the Aegean · due 26 Sep 2026

Decided The admission rule is already drafted on the block page and is the right one: a service is admitted when its description is policy-complete, its data access runs through the scheme's enforcement layer, and — where it makes claims — its methodology is documented and auditable.

Proposed Who governs acceptance: TIPS, on the WP4 lead's assessment, with the operator of the Marketplace of the EU LDT Toolbox applying the rules rather than setting them. No accreditation body is created; the LDT has neither the volume nor the mandate for one.

Proposed Criteria beyond the admission rule: technical compliance (ITB-S conformance for exchange paths), ethics and AI Act posture for agent services, and — for anything producing a sustainability figure — the method reference. "Sustainability" as an admission criterion for services generally is too vague to apply and should not be claimed.

Proposed Accreditation tiers: two, and they already exist in substance — a listed service meets the admission rule; a certified service additionally holds current ITB-S conformance evidence, which is what the marketplace badge reflects. Inventing further tiers would imply assessment capacity the scheme does not have.

Needs owner iSHARE + iLabs: the AI-agent credential policy, which the agent profile marks _TODO_ and which gates admission of agent services.

3. Interoperability and Standards#

Services must integrate smoothly with shared data, registries, and other technical building blocks while ensuring FAIR principles.

  • Which interoperability standards (APIs, formats, ontologies) should services follow?
  • How to ensure compatibility across domains?
  • How should provenance, traceability, and usage policies be embedded?
  • Will services expose discoverable APIs with lifecycle metadata and versioning?

LDT answer DRAFTED · owner: Nunsys + LogiNex + HyEnSys + University of the Aegean · due 26 Sep 2026

Decided Services follow the same standards as everything else in the scheme — this is the point of having a scheme: DCAT-AP service descriptions, ODRL policies, JSON-LD, credential-gated access over OpenID4VC, EDC with the iSHARE extension for data access, and the domain models in Data models.

Decided Provenance, traceability and usage policies are embedded rather than bolted on: a service's data access is a policy decision like any other and leaves an audit entry; a service producing a derived figure records its lineage in PROV-O with the method reference attached to the activity (Provenance section 2).

Proposed Compatibility across domains comes from services consuming the boundary models rather than each twin's internals — the scope rule from Data models section 1. A service written against a site's internal model is a site integration, not a data-space service, and should not be listed as one.

Proposed Services expose discoverable APIs with lifecycle metadata and versioning, on the same terms as data offerings: semantic versioning, a stated deprecation window with a successor reference, and persistent identifiers. A service that changes its output contract silently breaks every claim computed from it.

Needs owner Nunsys + iLabs: whether service descriptions share the dataset SHACL shapes or need their own.

4. Access and Fairness#

Value creation services should be accessible to all participants, not only large organizations with resources.

  • Should shared infrastructure be provided to SMEs/NGOs?
  • How can we avoid vendor lock-in or over-dependence on a few large providers?
  • What pricing or licensing models (open access, subscription, pay-per-use, hybrid) would ensure fairness and sustainability?

LDT answer DRAFTED · owner: Nunsys + LogiNex + HyEnSys + University of the Aegean · due 26 Sep 2026

Proposed Shared infrastructure for SMEs and NGOs: the LDT already provides the expensive part as a common good — identity, trust, policy enforcement, registry and the ITB-S sandbox. That is what a small participant would otherwise have to build, and it is the scheme's most effective fairness measure. Beyond that, no shared compute or hosting is offered and none should be promised.

Proposed Avoiding vendor lock-in — the LDT has a specific exposure and a specific rule. The exposure: registry and credential issuance sit with one operator, and the marketplace with another who also sells on it. The rule, generalised from the funder's recommendation on the ESRI stack: every interconnection must remain portable — open, documented interfaces, so a component or a site can be replaced without renegotiating the scheme. Reinforced by the registry and issuer components being iSHARE open source, so the function is transferable.

Proposed Pricing and licensing: hybrid. The trust layer is free at the point of use for all participants, and never metered. Value-creation services set their own models — open, subscription, or pay-per-use — with the fairness constraint that a public body's access to scheme functions can never be conditioned on buying a commercial service.

Needs owner ERTICO + iSHARE: this is the exploitation-model 🧩, and no pricing exists anywhere in the scheme.

5. Sustainability and Business Models#

Services need viable business models, balancing sustainability with impact.

  • Should some services be public goods (funded by EU/national initiatives) while others are market-driven?
  • How to handle revenue-sharing between service, data providers, and users?
  • How can value creation services be aligned with long-term Green Deal objectives (e.g., CO₂ reduction, transparency, circular economy)?
  • Will the marketplace have transaction fees and tracking & tracing of purchases?

LDT answer DRAFTED · owner: Nunsys + LogiNex + HyEnSys + University of the Aegean · due 26 Sep 2026

Proposed Public goods versus market-driven, mapped onto the LDT's actual components: the scheme layer (trust, identity, policy, registry, conformance) is a public good and should be funded as one — through iSHARE scheme governance, follow-on projects or municipal budgets. The service layer (marketplace, tokenisation, analytics) is market-driven. The uncomfortable fact for PD4 chapter 8 is that the public-good layer is the one with no post-M18 funding and the one every commercial service depends on.

Proposed Revenue-sharing between service providers, data providers and users is not specified and should be, because the tokenisation case makes it concrete: a token issued for a verified CO₂ saving is computed from a city's data by LogiNex's method and transacted on Nunsys's marketplace. Three parties contribute; no allocation exists.

Decided Green Deal alignment is the services' purpose rather than a constraint on them — emission reduction evidence, transparency of municipal policy, and incentivised behaviour change.

Decided Marketplace transaction fees and tracking of purchases are foreseen; fees apply to commercial-tier exchange only, never to open or restricted tiers (Business model question 2).

Needs owner Nunsys + LogiNex: token issuance basis, redemption, anti-gaming controls, fees and revenue allocation — the open 🧩, and the MiCA question flagged on the marketplace profile.

6. Trust, Certification, and Quality Assurance#

Trust mechanisms are required to ensure that services deliver accurate, unbiased, and reliable outputs.

  • Should services undergo certification or quality audits?
  • How can transparency in algorithms, data sources, and methodologies be ensured?
  • How should liability be handled if a service provides incorrect or misleading results?

LDT answer DRAFTED · owner: Nunsys + LogiNex + HyEnSys + University of the Aegean · due 26 Sep 2026

Proposed Certification of services: no formal certification regime, for the same reason as elsewhere — the LDT is not a certifying body and iSHARE certification is iSHARE Foundation's to grant. What services undergo is the admission assessment plus ITB-S conformance for their exchange paths, with the certified marketplace badge reflecting current evidence.

Decided Transparency of algorithms, data sources and methodologies is a condition of admission where a service makes claims, not an aspiration: documented, auditable methodology, with the method reference carried in the service's descriptions and in the provenance of every figure it produces. For AI services the AI Act posture adds transparency duties — users know they are talking to an AI, and agent actions are logged like any participant's.

The scheme should be precise about what this does and does not require: it requires the method to be documented and auditable, not the implementation to be open source. A commercial provider can meet it without surrendering its code.

Proposed Liability for incorrect or misleading results is the gap that matters most here, and the marketplace profile already names it. The proposed position: liability sits with the service provider for its own computation, bounded by caps in its terms of use; the scheme is liable for neither, and says so; and a participant relying on a figure for a regulatory purpose does so on its own assessment. Where a token was issued on an incorrect saving, the correction mechanism — reversal, adjustment, or neither — must be stated in the tokenisation terms.

Decided For credential-bearing offerings this is agreed in PD4 §4, which the "nothing here is agreed" above predates. The scheme keeps a register of accredited issuers per credential type and methodology version under TIPS change control; an issuer is listed after a passing ITB-S conformance report and a methodology review, and is suspended or delisted through the same procedure. Every credential states its evidence class (self-declared, measured, third-party verified), and a Marketplace badge states exactly what was verified. Relying parties accept any accredited issuer for the credential type they require, and the Marketplace publishes accepted credential types rather than named issuers. (Source: PD4 v1.0 §4 — text as in PD4 v0.96, 29 Oct 2026.)

Needs owner 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.