INSIEME — Pilot & CEEDS Implementation Progress Dashboard

Common European Energy Data Space · WP4 Deployments · Grant Agreement 101194952 · Sources: D4.1 (M12), Grant Agreement (DoA), TNO Vector (Feb 2026) · Current as of May 2026
20 Deployments 6 Objectives · 6 EOs 7 Use Cases 11 Project KPIs (Table 1) 8 Meta-Services + DCI 11 Reference Models M36 · Apr 2028

Overall Progress

Project months elapsed (M0 = Apr 2025)
14 / 36 ≈ 39% of timeline

Pilots Live

Currently in operation phase
0 / 20 First pilots start by M18 (Oct 2026)

Reference Models

Of estimated 15+ to be developed
11 Published on architecture.insieme.energy

Cross-border Pilots

Planned cross-MS data exchange per §3.x.3
12 / 20 8 explicit "no/limited" · 4 already in transnational DS

Project Objectives, Expected Outcomes & Use Cases

From the Grant Agreement (DoA Annex 1). Each pilot's contribution traces back to these. EO = Expected Outcomes from the DIGITAL-2024-CLOUD-AI-06 call topic (legal commitments). I-OB = INSIEME's own Objectives. I-UC = the seven use case domains driving WP3+WP4.
I-OB · 6 Objectives
EO · 6 Expected Outcomes (call)
I-UC · 7 Use Cases

Project-Level KPIs (Grant Agreement Table 1)

The 11 measurable project KPIs from Table 1 of the Grant Agreement (DoA §1.1.2). These are the canonical success criteria against which INSIEME will be evaluated by HaDEA. Each KPI is linked to one or more I-OBs and is driven by one or more WP4 pilots. Click any KPI for the linked pilots that contribute evidence.
Click any KPI row to see the linked I-OBs and the pilots that contribute evidence toward it.

Project Timeline & D4.1 Submission Milestones

D4.1 is updated bi-annually. Each milestone marks a new version of the deliverable and a maturity gate for the pilots and CEEDS services. Click any milestone for details.
Click a milestone above to see deliverables, expected pilot states and policy dependencies.

Deployment Gantt — 20 Pilots Across the 36-Month Timeline

Phases: Preparation → Development → Pilot Operation → Demonstration. Click a deployment name for its description, S-service dependencies and cross-border scope.
All deployments
Customer-facing
Energy Communities (EC_Scale)
Flexibility & FCA
Grid / DSO planning
e-Mobility
Sector coupling
Preparation / RM alignment Development & integration Pilot operation Demonstration & dissemination
Click a deployment name for details.

Deployment × CEEDS Meta-Service Matrix

From Table 1 of D4.1, extended to a 0–5 maturity scale per service (instead of binary X). Score reflects how far each deployment has progressed in adopting that service. DCI = Digital Customer Interface.
Maturity score (0–5)
Binary (D4.1 Table 1)
0 — Not in scope 1 — Identified 2 — Planned 3 — In development 4 — Integration testing 5 — Pilot operational
Click any header (S1–S8 / DCI) or cell for definition and dependent pilots.

External Policy & Standards Dependencies

CEEDS does not exist in isolation. INSIEME's design and roadmap are gated by parallel EU policy and technical bodies. Updates from these affect what D4.1 will report next.
D4E — Data for Energy Expert Group
DG ENER + DG CNECT expert group defining the federation model & meta-services. CEEDS S1–S8 terminology is aligned with D4E outcomes.
  • Governance & operating model recommendations
  • CEEDS Common Information Model alignment
  • Reference architecture endorsement
CEEDS Operational Entity
The governance entity to operate the federated dataspace. INSIEME prototype must hand off to this entity for sustainability post-2028.
  • National Data Space Facilitator alignment
  • SIMPL Open Toolset & DSSC compatibility
  • Eclipse Marketplace evaluation (S8)
DG ENER
Energy regulation gates: Network Codes, CIR 2023/1162 (metering data), Demand Response and Electricity Balancing Guidelines, Flexible Connection Agreements.
  • CIR (EU) 2023/1162 → S3, S7, DCI
  • Network Code on Demand Response → T4-4 procedures
  • FCA legal basis → T4.4 (ARE, flexgrid, PVflex)
DG CNECT
Digital Europe Programme co-funder. Sets dataspace interoperability requirements, Common European Data Spaces framework, and eIDAS rules.
  • Data Act / Data Governance Act compliance
  • eIDAS for participant identity (S1)
  • Common Data Spaces interoperability
Why these matter for D4.1 updates: The bi-annual D4.1 versions (M12 → M18 → M24 → M30 → M36) must report alignment with any new D4E, DSSC or Network Code outputs published in the preceding six months. Slippage in any external dependency forces re-scoping of WP3 development and may delay pilot operation gates.

Cross-Border Test Matrix — Which Pilots Exchange Data With Which

Derived from §3.x.3 of D4.1 ("Current integration with data spaces and cross-border data exchange requirements") and from §3.1's narrative on pilot clusters. Cells show planned data exchange between pairs of pilots. This is the central CEEDS value proposition but is not visualised anywhere in D4.1. Click any cell for the rationale.
Strong — explicit cross-pilot validation planned Medium — shared reference model / common framework Weak — implicit (same cluster, replication potential) No exchange planned
Click any cell to see the rationale, evidence source in D4.1, and CEEDS services that the exchange relies on.
Summary at M14: 5 pilots explicitly do not require cross-border exchange (ARE, Hierarchies, Cuerva LL, Metering Point Effectiveness, PEGNIPO — though PEGNIPO is cross-sectoral within Portugal). Most planned cross-border value is concentrated in the four EC_Scale pilots, the two e-mobility pilots, and the two customer-facing apps. Recommendation: the next D4.1 update should explicitly tabulate this matrix, define test scenarios per cell, and assign owners for each cross-pilot exchange.

Pilots × Use Cases (I-UC-1 to I-UC-7)

The seven Use Case domains defined in the Grant Agreement. This view shows which use case(s) each pilot validates. Coverage is the legal commitment to the funding authority — every I-UC must be evidenced by at least one operational pilot by M36.
Primary — pilot directly validates the use case Secondary — pilot contributes evidence Not in scope
Click any use case header (I-UC-1 to 7) for the description and the pilots that validate it.

WP5 — Business Models, Sustainability & Financing

INSIEME's EO2 and I-OB-4 commit to "suitable business models that ensure the maintenance and upscaling of CEEDS beyond the lifetime of the project". The full TNO report "Bridging the Financing Gap for Data Sharing Initiatives" (TNO 2025 P12826, 1 Dec 2025) provides the most relevant empirical evidence available: 85%+ of data space initiatives stall after the pilot phase because they cannot transition from grant-funded to financially viable operating models. This section applies the TNO findings to WP5.
Overview & insights
3 case studies
6 stepping-stones
3 archetypal routes
Readiness markers (Table 4)
5 pitfalls
Recommendations
INSIEME positioning
Strategic warning from TNO: "Financing alone doesn't make a data space sustainable. It's the combination of governance maturity, tangible value, and shared commitment that keeps an ecosystem alive." For INSIEME, this means WP5 (T5.1–T5.8) and WP4 pilots must converge on visible economic value before grant expiry — not after. M30 (D4.1 v4, Oct 2027) is the practical deadline to demonstrate willingness-to-pay from pilots' commercial partners.

Indicators & KPIs per Work Package (Grant Agreement)

All six work packages, each with its tracked indicators. Provenance: the Grant Agreement defines three explicit KPI tables — Table 1 (11 project-level KPIs, shown separately above), Table 4 (8 Management Indicators, WP1) and Table 6 (14 Dissemination KPIs, WP6). For WP2/3/4/5 the indicators below are derived from the GA's task descriptions, deliverable schedule, and EO commitments — they are real and traceable to the document but were not originally tabulated as "KPIs" inside their own WP. Recommendation: cross-reference each derived indicator with the relevant Table 1 KPI in the D6.5 update at M18.
WP1 — Management
WP2 — Architecture
WP3 — Implementation
WP4 — Deployments
WP5 — Sustainability
WP6 — Dissemination

Reference Models & Procedures Progress

11 reference models published so far. Reference models = structured definitions of roles, procedures, and information objects (per SGAM + HEMRM + IEC CIM). Each procedure is mapped to S1–S8 services in Annex I of D4.1.
T4.2 — Metering & Customer Data
  • Access to historical / near-real-time data
  • Master data access
  • Implicit flexibility signals
  • Customer switching
T4.3 — Energy Communities (CESU)
  • CESU registration & allocation
  • Internal settlement w/wo flexibility
  • Flexibility market participation
  • 16 procedures mapped
T4.4 — Flexibility & FCAs
  • FCA initialisation, onboarding, revocation, termination
  • Activation / limitation events
  • Demand Response (33 procedures)
T4.5 — Electromobility
  • Sector coupling (transport ↔ electricity)
  • OTLL Smart Charging
  • eHDMobility (heavy-duty)
T4.6 — Hierarchies
  • Optimised RES integration
  • Structured data exchange
T4.7 — AI-enabled support
  • AIGridOpt
  • INTERFLEX (GR)

Risk Register (from Grant Agreement, with M14 RAG status)

Eight critical risks from the Grant Agreement (DoA section on Critical risks and risk management strategy), with current (M14) Red/Amber/Green status. Risk #3 (architecture misalignment), #4 (security/privacy) and #5 (interoperability) are the standing technical threats. Risk #7 (sustainability/willingness-to-pay) is rated low/low in the GA but flagged amber here based on TNO Vector evidence (>85% of data spaces fail post-grant). The dashboard owner should refresh RAG status at every D4.1 milestone.