# Introduction to the iSHARE Data Space Template This page provides an overview of the Data Space Template's Building Blocks. This documentation is primarily structured around the bulding blocks defined in the [Data Spaces Blueprint 3.0 by the Data Spaces Support Centre](https://blueprint.dssc.eu/), which is based on the[ Open DEI project](https://design-principles-for-data-spaces.org/). Building blocks are basic units or components that can be implemented and combined with other building blocks to achieve the functionality of a data space.

Figure 1. Overview of DSSC Data Spaces Blueprint v2.0 Building Blocks.

{% hint style="info" %} Data spaces are allowed to publish agreements on topics other than the topics above. iSHARE provides the following extra topics, which are also covered in the iSHARE Trust Framework * [Operational processes](https://framework.ishare.eu/detailed-descriptions/operational/operational-processes) * [Glossary](/glossary) {% endhint %} # Refers to the iSHARE Trust Framework 3.0 This Data Space Template takes the[ iSHARE Trust Framework 3.0](https://framework.ishare.eu/) into account as an importan reference point. The aim is to help understand which parts of this template are already supported by the framework, and where a data space may still need to make its own choices or define additional rules. In general, where this template follows the iSHARE Trust Framework, the framework can be used as supporting guidance. Where this template adds data-space-specific decisions, extra detail, or a different approach, this is made explicit in the relevant pages. #### How updates are handled: Framework and template updates are reviewed step by step: 1. iSHARE Foundation publishes updates to the framework and documents the changes in the [release notes](https://framework.ishare.eu/releases/release-notes). 2. The iSHARE Data Space Template is then reviewed and updated, where needed, to reflect those framework changes. 3. The iSHARE Data Space Template then reviews those updates and also takes into account relevant updates in the DSSC Blueprint. # Glossary The glossary of this Data Space Template is based on the [iSHARE glossary](https://framework.ishare.eu/glossary-and-legal-notices/glossary).
# Legal Notices No part of these specifications may be reproduced in any form by print, photocopy, microfilm or any other means or stored in an electronic retrieval system, without the prior written consent of the iSHARE Foundation, which must never be presumed.
# Business Building Blocks The business building blocks help each data space define how it creates and sustains value within its ecosystem. They provide direction for making strategic choices about purpose, financial sustainability, and the value shared among participants. Whether your initiative serves the public interest, operates in a specific sector, or aims for commercial viability, these building blocks guide you in shaping a model that balances collective benefit with individual incentives. They help you clarify how your data space interacts with its stakeholders, what services and data products are offered, and how participants experience tangible value from collaboration. At the centre of this pillar lies the connection between data space offerings (the data, services, and governance elements that enable participation) and the use cases they support. Together, these define how your ecosystem operates and grows sustainably over time. By approaching the business model as a shared framework rather than a single owner’s plan, each participant can contribute to and benefit from a trustworthy, interoperable, and future-ready data-sharing environment (see Figure 2).

Figure 2.Relationship Between Business Building Block Components.

# Business Model A well-considered business model is key to sustaining a data space, even when profit isn’t the primary objective. While iSHARE does not prescribe a specific business model, we encourage each data space initiative to explore how value can be created, sustained, and fairly distributed among all participants. The DSSC Blueprint 3.0 describes that many data spaces aim to fund strategic initiatives, such as improving interoperability, launching collaborative tools, or offering participant support services, rather than chasing revenue alone. It also places more emphasis on clarifying the value proposition of the data space and on how the business model may evolve as the initiative grows. They suggest that a solid business model makes this possible by providing structure to financial flows, value exchange, and collective benefits.

Figure 3. Business Model as Enabler of Value Creation.

The core value of a data space lies in reducing fragmentation and lowering the costs of connecting systems and organisations. By aligning on shared standards and agreements, data spaces make data sharing more accessible, repeatable, and secure, which in turn supports innovation. This value should also be clear for participants, showing how they can retain full control over their data, while benefiting from simplified, trusted, and reusable data exchange across diverse use cases. Unlike traditional businesses, a data space relies on multiple independent actors working together toward shared goals. This means the business model must support collaborative governance and avoid centralisation of power. The goal is not just sustainability, but mutual benefit, across both data providers and users, as well as service providers. Developing such a model requires thoughtful coordination and should be made in conjunction with decisions about governance, participation, and value creation. It is also important to consider how the model can grow over time. Regular review and adaptation help support sustainability, respond to participants' needs, and identify new value opportunities, including how funding, support, or revenue mechanisms may evolve as the data space reaches broader adoption, for example, through membership services, transaction-based, public funding, or mixed models. Each building block of your data space is interconnected, and designing with that in mind will help the business model become a foundation for long-term success. {% hint style="info" %} The complete DSSC description is available [here](https://blueprint.dssc.eu/?pane=business\&intro=blueprint-in-the-broader-context\&f%5BblueprintVersion%5D=v3.0\&business=business-model#DataSpaceOfferings). {% endhint %} {% hint style="info" %} Business Model connects closely with other building blocks: * **Use Case Development:** Defines participant needs and groups. * **Data Space Offerings:** Shows what data is available and how it can be used. * **Intermediaries and Operators:** Help data providers and recipients engage with the data space. * **Organisational Form and Governance Authority:** Sets rules and coordinates participants. * **Participation Management:** Manages stakeholders and processes across the system. {% endhint %} {% hint style="warning" %} The guiding questions can help in the co-creation process and in defining this building block, so please see the next section. {% endhint %} # Guiding questions {% hint style="success" %} **Purpose of this Building Block Component:** A clear business model defines who benefits, how value is created, and how operations are sustained over time.This means clarifying: {% endhint %} 1. **Value propositions for different roles (e.g. data providers, users, CO₂ consultants, real estate *****o*****wners)** * *How effectively are value propositions tailored to different participant roles in the data space* * *How do participants experience or perceive the benefits of interacting with other participants* * *How actively are participants engaged, and what initiatives motivate their participation?* * *How can engagement be increased for participants that are less active or less involved* 2. **Revenue mechanisms (e.g. subscription, pay-per-use, public-private funding)** * *How can multiple revenue streams be explored while ensuring fair access for all participants?* 3. **Cost structures including data curation, onboarding, governance participation** * *Which operational costs can be optimized without affecting trust or data quality?* 4. **Cost structures including data curation, onboarding, governance participation** * *How can business models better support participants’ individual goals and motivations?* * *Which mechanisms encourage shared objectives and collaboration?* 5. **Theme & Scope** * *What is the data space’s thematic scope?* * *What are its objectives, growth, and profit ambitions?* 6. **Use cases & Services** * *Which use cases are strategic priorities vs future ambition?* * *What benefits do these use cases offer participants?* * *What services are core vs value-added?* * *Who will deliver them?* * *How are they incentivised?* 7. **Governance Authority** * *What are the responsibilities and business model of the authority* * *How is governance reviewed and improved?* # Use Case Development The iSHARE Trust Framework describes[ three primary use cases](https://framework.ishare.eu/detailed-descriptions/functional/primary-use-cases), explaining the basic design and implementation of the Trust Framework: * [Machine-to-machine service provision](https://framework.ishare.eu/detailed-descriptions/functional/primary-use-cases/1.-m2m-service-provision) * [Human-to-machine service provision with identity info at the Service Provider](https://framework.ishare.eu/detailed-descriptions/functional/primary-use-cases/3.-h2m-service-provision-with-identity-info-at-the-ip/without-identity-broker) * [Human-to-machine service provision with identity info at the Identity Provider](https://framework.ishare.eu/detailed-descriptions/functional/primary-use-cases/3.-h2m-service-provision-with-identity-info-at-the-ip/with-identity-broker) The three primary use cases are supported by[ seven secondary use cases](https://framework.ishare.eu/detailed-descriptions/functional/secondary-use-cases). A more practical description of the framework's functionality is provided in[ these four example use cases](https://framework.ishare.eu/use-cases). {% hint style="info" %} These use cases provide a generic overview of the functionality the framework provides. To get a more practical view of the provided functionality by this particular data space, it is suggested to provide real-life examples under this page that resonate with (potential) data space participants, including the relevant data products or services involved. {% endhint %} Similarly, DSSC also encourages you to build on this foundation by showcasing relevant, concrete use cases that resonate with your target ecosystem to make your own data space effective. These don’t need to be overly complex; even a small, well-designed pilot can spark interest and demonstrate the potential of data sharing. Strong use cases should show how they create value, whether economic, social, or environmental. Use case development is an iterative process: (THE WORD "MONITOR" SHOULD BE UPDATED TO "TRACKING" IN IMPROVE CONTINUOUSLY (dssc changed this))

Figure 4. Iterative Process for Use Case Development.

{% hint style="info" %} ### The complete DSSC description is available [here](https://blueprint.dssc.eu/?pane=business\&intro=blueprint-in-the-broader-context\&f%5BblueprintVersion%5D=v3.0\&business=use-case-development#DataSpaceOfferings). {% endhint %} Throughout this process, it is important to track progress and adjust use cases as needed, so they remain relevant and do not become outdated as participant needs, business context, and available offerings evolve. Keeping the principle of the iSHARE Framework at the centre: trust, clarity, and participant autonomy. Also, look for synergies and complementary efforts across the ecosystem. Strong use cases not only add value, but they also inspire others to join and scale the impact of your data space. {% hint style="info" %} Use Case Development connects closely with other building blocks: * **Business Model:** Use cases create value and show how the data space helps participants. * **Data Space Offerings & Value Creation Services:** The available data and tools determine which use cases are possible. * **Intermediaries & Operators:** They coordinate participants and manage use cases. * **Regulatory Compliance:** Use cases must follow the law and regulations. * **Contractual Framework:** Agreements set the rules for sharing data and providing services. * **Data Models:** How data is structured affects which use cases can work. {% endhint %} {% hint style="warning" %} The guiding questions can help in the co-creation process and in defining this building block, so please see the next section. {% endhint %} # Guiding Questions {% hint style="info" %} **Purpose of this Building Block Component:** Use cases are the anchor points of any data space; they provide a concrete reason for stakeholders to participate and collaborate. Each use case should be mapped along: Stakeholders involved (who needs what data, and why), Data flows and value exchanges, Business and sustainability outcomes, and Scalability and replicability potential. {% endhint %} {% hint style="success" %} **Purpose:** Create a recognisable name and ID for easy reference. {% endhint %} 1. **Use Case Title and Identifier** * *What is the name of the use case?* * *Is there an identifier or code used internally or by the consortium?* {% hint style="success" %} **Purpose:** Define the environmental or operational challenge being addressed. {% endhint %} 2. **Problem Definition & Context** * *What environmental, regulatory, or market need does this use case aim to solve?* * *What is the context in which this problem occurs (sector, region, system)?* * *What makes the problem relevant for the Green Deal or EU sustainability goals?* * *How can gaps in data availability or quality be addressed when choosing use cases?* {% hint style="success" %} **Purpose:** Clarify the goals and ambitions of the use case. {% endhint %} 3. **Use Case Objectives** * *What are the specific outcomes this use case aims to achieve?* * *Which sustainability metrics or business goals will it support?* * *How will success be measured?* * *How can business, regulatory, and technical requirements be integrated efficiently?* {% hint style="success" %} **Purpose:** Identify key actors in the data value chain and their roles. {% endhint %} 4. **Stakeholder Involvement** * Who are the key stakeholders involved (e.g., data providers, processors, users, decision-makers)? * *What role does each actor play (e.g., share data, analyse, visualise, take action)?* * *Are any public authorities, SMEs, or NGOs participating?* * *How can participants provide input to ensure use cases are relevant and practical?* {% hint style="success" %} **Purpose:** Describe what data is needed and where it comes from. What types of data are required (e.g., emissions data, material flows, building info)? {% endhint %} 5. **Data Needs & Sources** * *What types of data are required (e.g., emissions data, material flows, building info)?* * *Who are the data providers?* * *What is the format, frequency, and level of detail of the data?* * *Are there interoperability or standardisation challenges?* {% hint style="success" %} **Purpose:** Describe how data will be shared and exchanged between parties. {% endhint %} 6. **Data Sharing & Interactions** * *What data sharing agreements or governance rules are needed?* * *Which participants will consume or enrich the data?* * *How will data sovereignty and access control be ensured?* * *Is there a need for a specific Trust Framework or data space technical connector?* * *How can alignment among participants be maintained during implementation* {% hint style="success" %} **Purpose:** Show how the use case integrates with the broader architecture. {% endhint %} 7. **Architecture** * *Which building blocks (Governance, Business, Technical) are used?* * *Will the use case integrate a Data Space Connector, a Trust Anchor, or a data intermediary?* * *Does it follow some standards, like DSSC, iSHARE, SIMPL, etc?* * *What mechanisms ensure smooth scaling and integration with existing systems?* * *How can coordination be improved across federated operators or multiple ecosystems?* * *Which tools best support collaboration and scaling?* {% hint style="success" %} **Purpose:** Define the development status and roadmap of the use case. {% endhint %} 8. **Timeline and Maturity** * *Is this a concept, pilot, or operational use case?* * *What are the key milestones (e.g., prototype, deployment, scaling)?* * *What technical or organisational dependencies exist?* * *How can insights from abandoned use cases guide future decisions?* * *How can feedback loops be structured to allow flexible adaptation?* {% hint style="success" %} **Purpose:** Summarise the added value for stakeholders and broader sustainability goals. {% endhint %} 9. **Value Proposition & Expected Impact** * *What concrete value does this use case deliver to stakeholders (economic, social, environmental)?* * *How does it contribute to Green Deal objectives (e.g., circular economy, emissions reduction)?* * *Is there potential for replication or scaling?* {% hint style="success" %} **Purpose:** Identify potential challenges and mitigation strategies. {% endhint %} 10. **Risks and Barriers** * *What are the technical, organisational, or legal barriers?* * *Are there risks related to data quality, privacy, or stakeholder engagement?* * *How can these be mitigated?* {% hint style="success" %} **Purpose:** Ensure strategic alignment with regulatory and policy frameworks. {% endhint %} 11. **Alignment with EU Policies or Standards** * *Does the use case align with EU Taxonomy, CSRD, EPBD, SFDR, or other legislation?* * *Are any standardisation frameworks (e.g., ETSI, CEN/CENELEC) being applied?* {% hint style="success" %} **Purpose:** Provide diagrams, mock-ups, or links that support understanding. {% endhint %} 12.**Supporting materials (Optional)** * *Data flow diagrams* * *Mockups or MVP screenshots* * *Stakeholder maps* * *Links to documentation or previous results* # Data Space Offerings {% hint style="info" %} In the DSSC Blueprint 3.0 version, Data Products are key concepts of the Data Space Offerings, which may also include related Data Services. {% endhint %} Data space offerings play a central role in how value is created and exchanged within a data space. As described in the DSSC Blueprint 3.0, a data product is more than just data; it is a structured bundle of data, metadata, and relevant usage terms designed to be discoverable, reusable, and valuable across multiple use cases. When combined with related data services, it becomes a data space offering, which can be published in a catalogue to make it discoverable. While the iSHARE Trust Framework does not define data products directly, we encourage each data space initiative to interpret and implement this building block in a way that ensures: * Clear ownership and accountability, * Transparent terms of use and licensing (see [iSHARE Licenses](https://licenses.ishare.eu/)), * Quality and interoperability across services, * A clear approach for identifying, managing, and governing data space offerings. A well-designed data product typically includes:

Figure 5. Components of a Well-Designed Data Product.

These elements help both data providers and consumers understand what is being offered, under what conditions, and how it can be accessed in a secure and trusted way. Although the iSHARE Trust Framework doesn’t mandate data product governance, it supports modularity and participant control, allowing each data space to define its own policies, onboarding requirements, and management rules for data products. Doing so helps ensure discoverability, avoids ambiguity, and enables participants to combine offerings across multiple use cases, which is a key factor for scaling and value creation It is also valuable to support participants in bringing high-quality data space offerings by providing clear processes, practical guidance, and supporting tools where relevant. This can help lower the barriers for participants and make offering easier to develop, publish, and maintain over time, as also noted in the DSSC Blueprint. We recommend defining a lightweight internal governance approach for data products to ensure clarity, especially as more organisations join the ecosystem. {% hint style="info" %} The complete DSSC description is available [here](https://blueprint.dssc.eu/?pane=business\&intro=blueprint-in-the-broader-context\&f%5BblueprintVersion%5D=v3.0\&business=data-space-offerings#DataSpaceOfferings). {% endhint %} {% hint style="info" %} Data Space Offerings connects closely with other building blocks: * **Use Case Development:** Defines participant needs and guides the data space design. * **Intermediaries & Operators:** Help data providers and users work together smoothly. * **Organisation Form & Governance Authority:** Keeps participants aligned and coordinated. * **Participation Management:** Manages stakeholders and processes across the data space. {% endhint %} {% hint style="warning" %} The guiding questions can help in the co-creation process and in defining this building block, so please see the next section. {% endhint %} # Guiding Questions {% hint style="success" %} **Purpose of this Building Block Component:** The offering comprises data assets and associated services that enable use cases. This includes: data products and services. {% endhint %} {% hint style="info" %} It is essential to bundle offerings in a way that reflects user needs (e.g. emissions dashboard for real estate owners; API-based footprint verification for consultants). **This should also account for:** * Licensing models * Terms of use * User support services * Interoperability with EU data infrastructure (e.g. Data4Sustainability, EUDR registries) A well-structured offering enhances usability, legal certainty, and trust, increasing uptake and long-term engagement. {% endhint %} **Data products:** structured environmental, spatial, emissions, material flow, or asset-level data **Services:** access control, consent management, data quality assurance, enrichment tools, compliance reporting modules {% hint style="success" %} **Purpose:** Clearly structured environmental, spatial, emissions, material flow, and asset-level data. {% endhint %} 1. **Data Products** * *What key data assets will be initially offered?* * *How will data assets be standardised and validated?* * *How frequently will data be updated and shared?* * *How can data products be designed to be modular and reusable across multiple use cases?* * *How can data assets be standardized and validated efficiently?* * *How can offerings remain aligned with participant needs over time?* 2. **Functional Questions:** * *What data model will be used?* 3. **Functional/Technical Questions:** * *How can offerings remain aligned with participant needs over time?* * *What is the source of the data?* {% hint style="success" %} **Purpose:** * Data access control & consent management * Data quality assurance & validation * Data enrichment tools (e.g., analytics, visualisation) * Compliance reporting modules (aligned with CSRD, etc) {% endhint %} 4. **Associated Services** * *Which services are critical to the initial use cases?* * *How will compliance and consent management be technically enforced?* * *What are the minimum standards for data quality assurance?* * *Which services add the most value to participants while remaining interoperable?* * *How should services be prioritized based on current and future use cases?* {% hint style="success" %} **Purpose:** Licensing models clearly aligned with open data standards or commercial/regulated usage. Define clear terms of use, including IP rights, access rights, and permitted usage. {% endhint %} 5. **Licensing and Terms of Use** * *Under which license models will data be provided?* * *Are there specific data-usage restrictions or access tiers?* {% hint style="success" %} **Purpose:** Define helpdesk, training resources, and dedicated support channels. {% endhint %} 6. **User Support** * *How will support needs differ across stakeholders (public/private, technical/non-technical)?* * *Who will deliver these support services (in-house, third-party)?* * *How can support resources be tailored to different types of participants?* * *How can training ensure quality data contribution?* {% hint style="success" %} **Purpose:** Alignment with EU-wide data infrastructures (Data4Sustainability, EUDR registries, Copernicus) and Common EU Data Spaces (CEADS, EMDS, etc). Define Standardised data formats and APIs. {% endhint %} 7\. **Interoperability** * *Which external EU registries and frameworks should be integrated to ensure compliance and interoperability?* * *How will ongoing alignment with evolving EU data interoperability standards be ensured?*
# Data Space Intermediaries & Operators The DSSC Blueprint 3.0 identifies two key types of enabling actors within a data space: intermediaries and operators. These are organisations that don’t necessarily provide or consume data themselves but instead deliver supporting services that keep the data space running smoothly and scale in a trusted way. At iSHARE, we embrace this distinction and provide a foundation for it within our governance model, even though the Trust Framework itself does not define these roles explicitly. * Intermediaries are specialised actors offering enabling services such as onboarding, identity validation, registry operations, or policy enforcement. They contribute to the scalability, trustworthiness, and good governance of the ecosystem without centralising control. * Operators may act as coordinators of the data space infrastructure, responsible for orchestrating participant engagement, ensuring compliance, and supporting the daily operations of the data space. {% hint style="info" %} The complete DSSC description is available [here](https://blueprint.dssc.eu/?pane=business\&intro=blueprint-in-the-broader-context\&f%5BblueprintVersion%5D=v3.0\&business=intermediaries-and-operators#UseCaseDevelopment). {% endhint %} In practice, iSHARE-compliant data spaces are encouraged to define these roles clearly and assign responsibilities transparently. These actors often: * Help new participants onboard safely, * Support service interoperability and data discoverability, * Implement trust-enabling services in line with iSHARE specifications, * Reduce operational and governance risks through clearly assigned responsibilities. The iSHARE Trust Framework defines 4 Certified roles that can act as Data Intermediaries: Identity Broker, Identity Provider, Authorisation Registry, and Participant Registry. See more about the [Framework and Roles](https://framework.ishare.eu/main-aspects-of-the-ishare-trust-framework/framework-and-roles), as well as the related [functional requirements](https://framework.ishare.eu/detailed-descriptions/functional/functional-requirements-per-role).

Figure 6.Data Space Roles.

The iSHARE Trust Framework supports the certification and oversight of such roles through [Service Level Agreements](https://framework.ishare.eu/detailed-descriptions/operational/service-levels/service-levels-for-certified-parties-satellite) and a modular trust structure. This ensures that enabling parties operate in line with the same principles of fairness, transparency, and interoperability that apply to all data space participants. In this context, the Data Sharing & Governance Act (DSGA) can help define how intermediaries and operators are organised and governed within the data space. Whether your data space opts for a single operator or a distributed network of intermediaries, the key is to maintain a neutral, rule-based environment, as recommended by both iSHARE and the DSSC Blueprint, where no single party dominates and all actors can collaborate effectively. This also helps support clearer accountability and a stronger approach to regulatory and operational compliance. {% hint style="info" %} Data Space Intermediaries & Operators connects closely with other building blocks: * **Participation Management:** Intermediaries help with enrolment, engagement, and managing participants. * **Use Case Development:** Intermediaries help define, develop, and run use cases. * **Business Model Development:** Working across data spaces creates opportunities, supports interoperability, and drives competition. * **Regulatory Compliance:** Intermediaries must follow rules like the Data Governance Act (DGA). {% endhint %} {% hint style="warning" %} The guiding questions can help in the co-creation process and in defining this building block, so please see the next section. {% endhint %} # Guiding questions {% hint style="info" %} **Purpose of this Building Block Component:** Intermediaries and operators play a crucial enabling role, making data accessible, trustworthy, and compliant with EU regulations. They help reduce complexity and lower barriers to entry for participants. Key responsibilities may include: * Identity and access management (e.g. authenticating participants, issuing credentials) * Service brokerage (e.g. data search and matchmaking) * Compliance assurance (e.g. ensuring data usage aligns with CSRD, EPBD, or GDPR) * Onboarding and support for participants, especially SMEs and municipalities Operators might include neutral industry bodies, domain-specific hubs, or trusted IT providers. Multiple operators can coexist under federated rules, enabling sectoral specialisation while ensuring interoperability through shared frameworks. {% endhint %} {% hint style="success" %} **Purpose:** Authentication mechanisms (e.g., credentials issuance, federated logins). Clear participant identity verification. {% endhint %} 1. **Identity & Access Management** * *How will participants be authenticated (federated identity, credentials)?* * *What trust anchors or standards will be used?* {% hint style="success" %} **Purpose:** Data discovery and matchmaking between providers and users. Efficient search and service recommendation systems. {% endhint %} 2. **Service Brokerage** * *Which discovery functionalities are critical for initial use cases?* * *Who is responsible for matching data providers with data consumers?* * *How can intermediaries ensure services scale as participation grows?* * *How can intermediaries’ models align with overall data space goals?* {% hint style="success" %} **Purpose:** Ensuring data transactions align with regulatory frameworks (CSRD, EPBD, GDPR). Data governance and audit trail management. {% endhint %} 3. **Compliance Assurance** * *How will operators enforce compliance (policy engine, audit trails)?* * *Who will validate that data usage aligns with EU and national regulations?* * *How can neutrality be ensured while operators comply with rules?* {% hint style="success" %} **Purpose:** Dedicated support structures for smooth onboarding. Special focus on SMEs, municipalities, and smaller participants. {% endhint %} 4. **Onboarding & Participant Support** * *Which resources or tools facilitate onboarding, especially for smaller or less digitally mature participants?* * *Who handles participant support, and how is quality assured?*
{% hint style="success" %} **Purpose:** Sectoral or regional hubs enable specialisation, while interoperability among multiple operators is ensured through common rules. {% endhint %} 5. **Federation & Specialisation** * *Will multiple domain-specific operators exist? What are their defined roles?* * *What mechanisms will ensure interoperability among the federated operators?* * *What contingency measures ensure continuity if an operator fails?* * *How can dependency risks be mitigated across multiple services?* {% hint style="success" %} **Purpose:** Transparent operational standards ensuring neutrality and trustworthiness of operators. {% endhint %} 6. **Governance and Trust** * *What governance rules apply to operators? Are these clearly documented?* * *How is neutrality and fairness guaranteed across operators?* # Governance Building Blocks According to the DSSC Blueprint 3.0, strong governance is the backbone of any trustworthy data space. Two foundational elements, Organisational Form & Governance Authority and Participation Management, shape how a data space is structured, how decisions are made, and how participants are welcomed, managed, and held accountable. The first building block focuses on the legal and organisational setup of the data space. It explores how to select an appropriate legal form, establish a governance structure, and assign authority to oversee the rulebook, ensure compliance, and support conflict resolution. Early decisions here lay the groundwork for building trust, maintaining transparency, and enabling data quality, especially as your data space grows or federates over time. The second building block ensures that participants are engaged in a secure, inclusive, and consistent way. It provides guidance on onboarding and offboarding procedures, role definitions, access policies, and governance rules. Clear and inclusive participation management is essential to support collaboration, reduce governance risks, and maintain trust between participants. Together, these building blocks form the core governance layer of the data space. Supported by the broader business, legal, and technical dimensions, they help the data spaces to operate effectively, scale responsibly, and uphold trust among all actors. {% hint style="info" %} See the complete DSSC description [here](https://blueprint.dssc.eu/?pane=business\&intro=blueprint-in-the-broader-context#BusinessandOrganisationalBuildingBlocks-2.2GovernanceBuildingBlocks). {% endhint %} # Governance Design Layers Before defining the already mentioned governance building blocks, it is recommended to first establish a clear understanding of how governance needs to be structured and what it should enable. The suggested layered approach below supports the design of an evolving governance structure, capable of adapting as the data space matures while maintaining clear responsibilities for strategic direction, operational execution, stakeholder participation, and independent oversight.\ \ Governance frameworks are typically developed iteratively, based on existing best practices, example governance models and continuous input from stakeholders. For this reason, in this iSHARE Data Space Template, there is not only a suggested co-creation methodology, including some guiding questions that stakeholders can utilise, but also the below suggested design layers that you can follow. Layer One draws insights from governance models from other European data spaces, like GDDS, EMDS, CEEDS, ETDS, Catena-X, EBSI, ToIP/DC4EU, AgriDataSpace, DS4SSCC, Health-X, and EMREX. It concludes 9 main Design principles that Data Space Governance should follow when created. The second layer is derived from stakeholder input and from the requirements directly defined in the data space itself. This can differ per data space. Applying a layered governance approach helps to: * ensure alignment between stakeholders, * support a successful governance design, * reduce complexity, * support a structured path towards implementation and scaling, * and enable transparency and accountability, meanwhile. Within iSHARE, this approach is supported as a practical way to design and implement governance. It provides a solid foundation that can be reused and adapted across different data spaces, while ensuring consistency with common principles and frameworks. ### **Layer 1 – Governance Design Principles** This layer outlines the core principles that underpin any robust data space governance model. {% tabs %} {% tab title="1" %} #### 01. Governance as the foundation The "soft infrastructure" that enables trust and balances interests. Governance acts as the defining element of a data space, enabling trust between participants, balancing public and private interests, and aligning legal, technical, business, and ethical dimensions. * Enables trust between participants * Balances public and private interests * Supports scalability and sustainability * Enables secure, sovereign data exchange {% endtab %} {% tab title="2" %} #### 02. Multi-layer governance structure Four nested layers from ecosystem to participant level. Effective data spaces consistently apply a layered approach spanning from broad ecosystem alignment down to individual participant obligations. * Ecosystem: cross-space alignment * Data space governance: core rules * Use case/domain: context-specific * Participant: access, rights, obligations {% endtab %} {% tab title="3." %} #### 03. Role of governance authorities A facilitator and steward, not an overly centralised controller. A governance authority is essential but should act as a facilitator or steward, often complemented by delegated or federated governance structures. * Maintains and enforces the rule framework * Defines participation conditions * Ensures regulatory compliance * Oversees trust and interoperability It does not replace public enforcement authorities. {% endtab %} {% tab title="4." %} #### 04. Subsidiarity and federation Decisions taken at the lowest appropriate level. Governance should follow the principle of subsidiarity, escalation occurs only when broader coordination is required, enabling flexibility and bottom-up feedback. * Flexibility across domains * Bottom-up feedback loops * Coexistence of multiple models {% endtab %} {% tab title="5." %} #### 05. Trust as a core element Addressed both technically and organisationally. Trust frameworks should combine technology (credentials, policies) with governance processes such as audits and accountability mechanisms. * Identity and credential management * Verification mechanisms * Access control policies * Trust registries and oversight {% endtab %} {% tab title="6." %} #### 06. Data Space Rulebooks as Key Instruments The primary governance artefact is modular and versioned. Best practices include modular design and clear separation between baseline and domain-specific rules. * Defines roles, rights, and obligations * Mandatory vs optional rules * Integrates legal requirements * Evolves through structured versioning {% endtab %} {% tab title="7." %} #### 07. Separation of governance and operations Governing entity and operating entity are kept distinct. A clear distinction between the governing entity (rules, oversight) and the operating entity (execution, daily operations) avoids conflicts of interest and enables scalability. * Avoids conflicts of interest * Enables scalability * Supports outsourced operations {% endtab %} {% tab title="8." %} #### 08. Inclusivity and balance Fair representation, transparency, and accountability. Voting structures and board composition should prevent dominance by single actors and ensure fair representation of all stakeholders, including smaller participants. * Fair stakeholder representation * Inclusion of smaller participants * Balance of public and private interests * Transparency and accountability {% endtab %} {% tab title="9." %} #### 09. Evolution over time Designed as an evolving system, not a rigid structure. Governance typically progresses through formation, operation, improvement, and long-term sustainability. Overly rigid or premature structures should be avoided. 1. Initial formation phase 2. Operational phase 3. Continuous improvement 4. Long-term sustainability {% endtab %} {% tab title="10." %} #### Key implications and requirements A governance framework should satisfy all of the following design requirements. * Be multi-layered and federated * Clearly define Governance Authorities and delegated scopes * Embed a Trust Framework (technical + organisational) * Separate governance from operations * Enable subsidiarity and bottom-up feedback * Use a modular, evolving Rulebook * Ensure inclusive, balanced representation {% endtab %} {% endtabs %} *Editor’s note: This section synthesises governance principles derived from analysis of existing European data space initiatives and reference frameworks. It informs the design of the Data Space Governance Framework but does not prescribe a fixed organisational structure.* ### **Layer 2 – Governance Capabilities (Operational Perspective)** This layer defines what governance should enable within a data space from an operational perspective. {% columns %} {% column width="41.66666666666667%" %} **Governance capabilities should be derived from:** * the specific use cases, * the needs of participating organisations, * and the operational context of the data space. {% endcolumn %} {% column width="58.33333333333333%" %} **These capabilities may include, for example:** * participant onboarding and offboarding, * access and usage control, * compliance monitoring, * dispute resolution, * lifecycle management of rules and policies, * coordination across domains and stakeholders. {% endcolumn %} {% endcolumns %} *Editor's Note: This section should be informed by the Data Space itself, including the use cases and the participants who are designing the data spaces. They can provide/ should provide their specific, governance related requiremnts here.* ### **Examples:** {% stepper %} {% step %} ### Trust and Assurance for Data Providers The Governance Framework shall provide enforceable trust, control, and accountability mechanisms that allow Data Providers to confidently offer their data, retain data sovereignty, and rely on both Data Space–level and DSG-level governance arrangements. {% endstep %} {% step %} ### Clear Participation and Onboarding Paths The Governance Framework shall define clear participation categories and onboarding paths, including Anonymous Users, pre-registered users, Participants, and cross-data-space users, enabling all users to understand what is required to participate (trust, governance and onboarding requiremnets) and what capabilities are available at each stage. This will also allow Cross- Data spcae accessibility, and Graduated Access for Non-Onboarded Users. {% endstep %} {% step %} ### Attribute- and Role-Based Access Governance The Governance Framework shall support access control based on participant attributes, roles, group membership, and declared purposes, enabling fine-grained and policy-driven data access. {% endstep %} {% endstepper %} # Organisational Form & Governance Authority {% hint style="info" %} In the DSSC Blueprint 3.0, this building block is known as 'Organisational Form & Governance Authority'. The complete DSSC description is available [here](https://blueprint.dssc.eu/?pane=business\&intro=blueprint-in-the-broader-context\&business=organisational-form-and-governance-authority#OrganisationalFormandGovernanceAuthority). {% endhint %} Establishing how your data space is structured, governed, and held accountable is one of the first and most critical design decisions. In alignment with the DSSC Blueprint 3.0, this building block focuses on three main aspects: * The organisational/legal form your data space will take (e.g. foundation, consortium, association), * The creation of a governance framework that outlines shared internal rules and third-party-facing policies, * The establishment of a governance authority responsible for managing, enforcing, and evolving this framework. Together, these elements provide the foundation for transparency, accountability, and trust across the data space.

Figure 7. Data Space Governance Structure.

A governance authority should represent the interests of participants and take on key responsibilities, such as: * Setting rules and policies for how the data space operates, * Ensuring alignment with both internal agreements and external regulations, * Supporting conflict resolution, continuous improvement, and long-term accountability. Importantly, these decisions should be made early in the lifecycle of the data space, ideally before operations begin, while still leaving room for evolution as the space grows or federates.

Figure 8. Governance authority of an incorporated data space.

### Governance Approach From an iSHARE perspective, this building block is where the Trust Framework’s value becomes tangible. iSHARE provides a ready-to-use model for data space governance that aligns with DSSC principles while introducing a federated and role-based structure. This model ensures that responsibilities are clearly distributed, collaboration remains inclusive, and governance processes are transparent and scalable. To maintain coherence and alignment across various domains and operational levels, iSHARE distinguishes four complementary governance layers. Together, these layers form a federated governance model that supports interoperability, trust, and accountability across the entire data space ecosystem.

Figure 9. Elements of a data space governance framework

**1. Cross-Data Space Governance Layer** This layer addresses the governance of the broader community of practice and related digital infrastructures surrounding the ecosystem. Its focus is to foster collaboration, align on shared goals, and develop a common understanding of terms, principles, and technical concepts, thereby ensuring interoperability across interconnected data spaces and sectors. **2. Data Space Governance Layer** This layer defines how a specific data space is structured, managed, and operated. It sets the foundation for enabling trusted data transactions and innovation, and includes entities such as the Governance Authority (or the Data Space Governance Body\*), the Operating Entity, and one or more Legal Data Intermediaries. Together, they ensure compliance with governance rules, operational efficiency, and continuous evolution. In practice, the **Governance Framework** can be understood as consisting of two main elements. First, the rules that define the internal roles, responsibilities, and procedures of the data space itself. Second, by rules that directly shape how the data space relates to third parties, such as data providers, data consumers, and service providers. This difference helps make the governance framework clearer and more operational. The **Governance Framework** provides the overall structure for how the data space is governed. The Rulebook, or Data Space Template, is an artefact of this governance framework: it documents and operationalises the rules, policies, and governance specifications of the data space. {% hint style="info" %} Note: Terms and conditions of use, as well as contracts with participants or service providers, may be based on the Data Space Governance framework, such as the Data Space Rulebook or Data Space Template, but they are not part of the governance framework itself. {% endhint %} \*Within this layered model, the Governance Authority plays a key role in ensuring coherence and accountability. Under the iSHARE Trust Framework, this governance role is fulfilled by the Data Space Governance Body, while the technical component is the Participant Registry. Together, these two elements were previously known as the iSHARE Satellite. The Data Space Governance Body serves as the main representative of a data space and is responsible for defining, evolving, maintaining, and governing participant lifecycle processes. This function closely corresponds to the Governance Authority as described in the DSSC Blueprint. The Governance Body can be a legal entity or a non-legal consortium operating under agreed governance principles. In some cases, a single legal entity may perform both the [Participant Registry](https://framework.ishare.eu/glossary-and-legal-notices/glossary#participant-registry-role) and [Data Space Governance Body roles](https://framework.ishare.eu/glossary-and-legal-notices/glossary#glossary-satellite-role-satellite-role), while in others, these may be separated through contractual arrangements. The iSHARE Data Space Template (this document) supports data spaces in defining their own governance frameworks and internal policies while maintaining alignment with the overarching iSHARE Trust Framework. It allows flexibility in design choices, enabling each data space to determine its optimal balance between autonomy and interoperability. This federated approach allows data spaces to evolve organically while ensuring shared accountability, transparent decision-making, and a consistent foundation for trust across the wider ecosystem.

Figure 10. Rules that directly define relations with third parties.

**3. Participant Governance Layer** This layer operationalises the part of the governance framework that governs the relationship between the data space and its participants or third parties. In practice, this includes admission criteria, onboarding and verification, role assignment, compliance check, monitoring, warnings or suspensions where relevant, and offboarding. It manages participant lifecycle processes and policy enforcement, ensuring accountability and transparency at the operational level.

Figure 11. Federated, Multi-Layered Governance Framework.

**4. Use Case Governance Layer** Each use case within a data space operates under the overarching governance of its data space, but can adopt additional, use case–specific rules or restrictions. This enables innovation while maintaining alignment with the data space’s shared governance framework. {% hint style="info" %} Organisational Form & Governance Authority connects closely with other building blocks: * **Business Model:** Decisions about legal form and operations affect the organisational structure. * **Participation Management:** Organisational form sets rules for member admission, roles, and responsibilities. * **Contractual Framework:** Contracts depend on the organisational form and define member rights and obligations. {% endhint %} {% hint style="warning" %} The guiding questions can help in the co-creation process and in defining this building block, so please see the next section. {% endhint %} # Guiding Questions {% hint style="info" %} **Purpose:** The Organisational Form and Governance Authority building block defines the structural foundation and decision-making mechanisms crucial for the effective governance and operation of the data space. Drawing inspiration from established governance models such as the iSHARE Trust Framework and guided by the DSSC Blueprint, it establishes a governance authority that is responsive, transparent, and representative of its participants. {% endhint %} {% hint style="success" %} **Purpose:** Clearly define the purpose, structure, and legal characteristics of the data space. {% endhint %} 1. **Determining the Organisational Form** 1.1. Permanence & Stability * *Should the initiative be established as a permanent entity or as a temporary (multi-year) collaboration?* * *What is the anticipated lifetime and scale of the initiative* * *How should the organisational form balance flexibility and stability?* 1.2. Legal Personality * *Should the initiative have a distinct legal personality?* * *What are the advantages or constraints of becoming an incorporated entity (e.g., association, foundation, limited liability company)?* 1.3. Profit vs Non-Profit Orientation * *Is the initiative designed to generate profit, or is it primarily aimed at non-profit sustainability outcomes?* * *How will generated revenue (if any) be managed and reinvested?* 1.4. Country and Jurisdiction * *In which EU country should the initiative be legally established?* * *What regulatory, tax, or operational benefits does this jurisdiction provide?* 1.5. Level of Participant Involvement * *How much direct involvement do the initial consortium members want in the daily governance and operational management?* * *What degree of autonomy should the governance authority have from its founding members?* * *How can participant involvement in governance be maximized without slowing decision-making?* 1.6. Options for Organisational Form | | Unincorporated data space | Incorporated data space | | ------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Temporal existence | Data space is a temporary establishment, although it may exist for several years. The termination is pre-determined by the founding agreement. | Data space is a permanent establishment, its termination is not pre-determined by the founding agreement. | | Legal personality | Data space is not a legal person. | Data space is a legal person, separate from its members. | | Ability to enter into contracts | Data space cannot conclude contracts with third parties in its own name. Only members can conclude contracts. | Data space can conclude contracts in its own name with third parties. | | Ownership of property | All property is owned and disposed of by members, individually or jointly. | Data space owns (intellectual) property and disposes of it. | | Liability | Members are liable for their actions. Data space cannot bear any liability. | Data space bears liability for the actions of its governance bodies. | | Complexity of the founding agreement | The founding agreement is a highly complex document regulating various aspects of relationships between members. | The founding agreement is fairly simple document establishing the data space and regulating only certain monetary relationships between the data space and its members. | | Control over the data space | Members are in complete control of the data space. | Data space is in control of itself through its governance bodies. | | Addition of new members | The process requires consent of all existing members and re-negotiation of the founding agreement. | The process varies depending on the legal form, but usually does not require re-negotiation of the founding agreement. | {% hint style="success" %} Define the roles, structure, and operation of the governance authority clearly. {% endhint %} 2. **Establishing the Governance Authority** 2.1. Governance Bodies * *What governance bodies are necessary (e.g., Council of Participants, Supervisory Board, Change Advisory Board)?* * *How will these bodies be structured, and what are their specific roles?* * *Which processes ensure continuous improvement of governance structures?* 2.2. Decision-making Processes * *How will decisions be taken within governance bodies (consensus, majority voting, etc.)?* * *How will transparency and accountability in decision-making be ensured?* * *How can rules and procedures remain transparent and accessible to participants?* * *How can governance updates be effectively communicated and enforced?* 2.3. Operational Management * *Who is responsible for the day-to-day management and operational activities?* * *What reporting or accountability mechanisms are required for operational oversight?* 2.4. Dispute Resolution & Compliance * *How will conflicts between participants be addressed and resolved?* * *Who ensures compliance with internal and external regulations (GDPR, CSRD, EPBD, etc.)?* 2.5. Continuous Improvement and Adaptation * *How will the governance authority adapt to changing requirements or scaling of the data space* * *What procedures are in place for updating governance structures or policies?* {% hint style="success" %} Define internal rules, policies, and guidelines that govern participant interactions within the data space. {% endhint %} 3\. **Creation of the Governance Framework** 3.1. Founding Agreements * *What fundamental agreements underpin the governance structure?* * *How detailed are founding agreements regarding roles, responsibilities, liabilities, and rights?* 3.2. Terms and Conditions for Participants * *What specific terms must participants agree to for engaging with the data space?* * *How do these terms reflect compliance with EU regulations?* 3.3. Internal Policies and Procedures * *What internal operational policies and procedures are necessary?* * *How will these policies be created, reviewed, and approved?* 3.4. Technical Specifications & Requirements * *Which technical standards and specifications (APIs, semantic models, connectors, security protocols) are adopted and enforced?* * *How will technical standards evolve over time?* 3.5. Documentation and Accessibility * *How will all internal rules and guidelines be documented?* * *In what formats (human-readable, machine-readable) will these documents be accessible?* {% hint style="success" %} These questions facilitate active stakeholder engagement in the governance design process. {% endhint %} 4\. **Additional Strategic Questions for Co-Creation** * *Do stakeholders prefer an incorporated or unincorporated organisational form, and why?* * *What legal or operational constraints exist that might influence the choice of organisational form?* * *How will the governance structure ensure representation and accountability of all participant groups?* * *What processes will be used for onboarding new members or adjusting roles and responsibilities?* * *What governance mechanisms will ensure ongoing compliance with evolving regulatory requirements?* * *How will decisions within the governance authority be made, monitored, and reviewed over time?* # Participation Management Smooth and secure participation is at the core of a functioning data space. According to the DSSC Blueprint 3.0, this building block outlines how participants are defined, onboarded, managed throughout their lifecycle, and, if needed, offboarded, with a strong emphasis on trust, clarity, legal alignment, and the conditions needed for secure and compliant data transactions and service provision. According to DSSC, effective participation management includes: * Clear roles and categories for data space participants, * Defined onboarding and offboarding procedures, including identification, eligibility assessment, assignment of roles and access rights; monitoring of participant compliance with governance rules; suspension, revocation, or voluntary withdrawal procedures, * Internal governance readiness, including role taxonomy (e.g. data rights holders, data providers, data consumers, etc), a common understanding of rights, responsibilities, technical access rules, and participation conditions aligned with the Data Space Governance Framework, and the Rulebook if defined (as described in the [Organisational Form & Governance Authority](https://template.ishare.eu/business-and-organisational-building-blocks/governance-building-blocks/organisational-form-and-governance-authority)), * Mechanisms for ensuring inclusivity, compliance, data sovereignty, and scalability as the data sovereignty space grows. By defining clear participation rules and lifecycle processes, the Participation Management, together with the Trust Framework and Governance Framework, ensures that data exchange takes place in a trusted environment where responsibilities, permissions, and accountability are clearly defined. {% hint style="info" %} The complete DSSC description is available [here](https://blueprint.dssc.eu/?pane=business\&intro=blueprint-in-the-broader-context\&f%5BblueprintVersion%5D=v3.0\&business=participation-management#ParticipationManagement). {% endhint %} The iSHARE Trust Framework directly supports this building block by offering:
Identification and Authorisation mechanisms [Identification ](https://trustbok.ishare.eu/apply-ishare/identification)and [authorisation mechanisms](https://trustbok.ishare.eu/apply-ishare/authentication) that are aligned with eIDAS and organisational trust standards. * **Multiple Identifiers:** Participants under the iSHARE Framework can be recognised by multiple identifiers (EORI or chamber of commerce numbers), which are recognised by converting into a common identifier, [iSHARE ID,](https://framework.ishare.eu/glossary-and-legal-notices/glossary#glossary-ishare-id) reducing onboarding barriers and improving interoperability across ecosystems.
Participant Registry The Participant Registry role is fulfilled by a participant who validates and onboards the participants into the data space. The Data Space Governance Body defines the requirements and governs the process of onboarding participants into the data space. * Can hold information on all participants in the data space; i.e. information indicating their level of assurance, services offered and roles performed in the data space. * Has processes and criteria in place allowing for the onboarding or registration, update and review of participants; * Can confirm whether a participant is a member of the data space. * Can register and maintain claims for participants that are registered by other Participant Registries, provided that such claims are within the scope of the data space it governs and that mandatory validation requirements are fulfilled before claim submission. * **Participant Registry API**: These specifications enable the creation and updating of participant information via API, ensuring alignment, automation, and participant lifecycle management. For technical requirements, refer to [Participant Registry getting started in the developer portal.](https://dev.ishare.eu/participant-registry-role/getting-started)
A Role-Based Architecture with Functional Requirements per Role See more here about [role-based architecture](https://framework.ishare.eu/main-aspects-of-the-ishare-trust-framework/framework-and-roles) and [functional requirements per role](https://framework.ishare.eu/detailed-descriptions/functional/functional-requirements-per-role).
Predefined Operational Processes For [Admission](https://framework.ishare.eu/detailed-descriptions/operational/operational-processes/admission), [Withdrawal or Downgrade](https://framework.ishare.eu/detailed-descriptions/operational/operational-processes/withdrawal-or-downgrade), [Warnings, Suspension and Exclusion](https://framework.ishare.eu/detailed-descriptions/operational/operational-processes/warnings-suspension-and-exclusion),
Standardised Delegation Requests Onboarding and participation processes now include the creation of standardised delegation evidence, strengthening trust and compliance (see here in [Structure of Delegation Evidence](https://framework.ishare.eu/detailed-descriptions/technical/structure-of-delegation-evidence)).
iSHARE also enables participants to define and enforce their own access and usage policies through [delegation structures](https://framework.ishare.eu/detailed-descriptions/functional/delegation-paths) and [licenses](https://framework.ishare.eu/detailed-descriptions/functional/licenses), further reinforcing participant autonomy and trust. (These are further discussed in the [Access and Usage Policies Enforcement](https://template.ishare.eu/technical-building-blocks/data-sovereignty-and-trust/access-and-usage-policies-and-enforcement) building block).

Figure 12. Offerings of the iSHARE Trust Framework.

#### **Participant requirements** It is important to note that requirements may differ depending on the role and context. For example, a small organisation may need onboarding support to meet technical requirements, while a larger or more critical participant may be subject to stricter interoperability, security, or data quality checks. Likewise, a Data Provider may need clear internal responsibility for data rights and quality, while a service provider may need to demonstrate operational and technical compliance before admission.

Figure 13. Steps for the participation lifecycle

#### **How It Applies in Practice** In practice, this requires organisations to establish clear internal responsibilities, decision-making processes, and the necessary capabilities for identification, attestation, delegation, and participant registry management. It is also important to consider admission criteria, data quality, interoperability, and ongoing compliance as the data space grows. While the core onboarding procedures are provided by the iSHARE Trust Framework, each data space remains free to: * Define additional operational, legal, or technical criteria, * Customise participant categories and approval processes, * Decide how strict admission criteria should be, balancing lower barriers to entry with interoperability, data quality, and compliance needs, * Layer in sector-specific rules and lifecycle management mechanisms. In short, well-managed participation is what transforms a set of organisations into a trusted data-sharing ecosystem. iSHARE provides the tools; your data space decides how to apply them throughout the participant lifecycle and as the ecosystem scales. {% hint style="info" %} Participation Management connects closely with other building blocks: * **Identity & Attestation Management** – ensures verified and trusted participant identities. * **Access & Usage Policies Enforcement** – makes sure that only participants with the right permissions and licenses can access a specific data set. * **Regulatory Compliance & Contractual Frameworks** – embeds legal certainty into the participant lifecycle. * **Organisational Form & Governance Authority:** Sets rules and requirements for establishing and running the data space. * **Intermediaries & Operators:** Facilitate data transactions and operations while following governance rules. * **Provenance & Traceability:** Require rules and processes to ensure compliance and transparency. {% endhint %} {% hint style="warning" %} The guiding questions can help in the co-creation process and in defining this building block, so please see the next section. {% endhint %} # Guiding questions {% hint style="success" %} **Purpose:** Clarify the entities and actors engaging in the data space, their categories, rights, and responsibilities. {% endhint %} 1. **Defining Participant Roles** 1.1. Participant Categories * *Who are the Data Providers, Data Users, Data Rights Holders, Intermediaries, and Operators?* * *Should additional roles, such as Data Space Members or Governance Authority Members, be defined?* * *How should intermediary and operator roles be formally defined?* * *What are the distinctions in access, rights, and obligations among different roles?* 1.2. Role-Specific Responsibilities * *What responsibilities do different participant types hold regarding data quality, compliance, and technical readiness?* * *How will intermediary services (e.g. service brokers, trust anchors) be governed as participants?* 1.3. Additional: Strategic Questions * *Who are the internal and external stakeholders affected by the data space?* * *How can underrepresented stakeholders be included in decision-making?* * *What roles will each stakeholder assume within the data space?* * *How will participant roles be formalised in the Rulebook?* {% hint style="success" %} **Purpose:** Ensure structured and transparent integration of new participants. {% endhint %} 2. **Onboarding Procedures** 2.1. General Terms and Conditions * *What common terms (admission criteria, rights, duties, access policies) apply to all participants* * *How are terms tailored based on data type (e.g., environmental, personal, sensitive) and regulation?* 2.2. Pre-Conditions for Entry * *What eligibility criteria must be met (e.g., compliance checks, identity verification, technical requirements)?* * *What attestation mechanisms will be used (first-, second-, or third-party)?* 2.3. Onboarding Process * *Will onboarding be application-based or automatic upon fulfilling conditions?* * *How will conformity be assessed? What mechanisms verify adherence to governance policies?* * *How will candidates be notified of approval or rejection?* 2.4. Post-Onboarding Support * *How will access credentials be issued?* * *What technical support will be provided to ensure seamless integration?* * *How will continuous monitoring and feedback loops be implemented?* 2.5. Additional Strategic Questions * *What rules and mechanisms ensure onboarding supports legal compliance (e.g. GDPR)?* * *How is access managed and monitored post-onboarding?* * *How can onboarding lower participation barriers while maintaining data quality?* {% hint style="success" %} ***Purpose:** Facilitate secure, interoperable data sharing among participants.* {% endhint %} 3. **Data Transaction Enablement** 3.1. Operational Enablement * *How are participants technically enabled to publish or consume data services/products?* * *How are mismatches between supply and demand identified and addressed?* 3.2. Governance Adaptation * *What feedback mechanisms exist to update governance rules as the ecosystem scales?* * *How are new sectors, countries, or regulatory updates incorporated?* 3.3. Additional Strategic Questions * *How does the governance authority promote seamless data transactions?* * *What procedures exist to attract new participants based on ecosystem gaps?* * *How is the Rulebook updated to reflect evolving business, technical, or legal needs?* {% hint style="success" %} **Purpose:** Ensure smooth and secure participant exits while safeguarding ecosystem integrity. {% endhint %} 4. **Offboarding Procedures** 4.1. Exit Scenarios * *What are the valid reasons for offboarding (voluntary, non-compliance, insolvency)?* * *How are these scenarios managed differently?* 4.2. Offboarding Process * *What formal steps must participants follow to exit the data space?* * *How are obligations verified (e.g., contractual closure, data deletion, financial settlement)?* * *What support is provided during the offboarding transition?* 4.3. Post-Exit Oversight * *How are affected parties notified?* * *How is identity and access removed from registries and systems?* * *How are participant credentials managed after exit (revocation, expiration)* 4.4. Additional Strategic Questions * *What rules define contract and data handling obligations upon exit?* * *How are security and data sovereignty ensured during offboarding?* * *How frequently is the offboarding framework reviewed and updated?* {% hint style="success" %} To support stakeholder co-creation and governance design. {% endhint %} 5. **Additional Strategic Questions** * *How will participation policies foster inclusivity and trust while maintaining regulatory rigour?* * *What role does the Rulebook play in managing expectations across use cases and participant types?* * *How can the governance authority continuously improve the efficiency of onboarding and offboarding processes?* * *How are external stakeholders’ concerns incorporated, even if they are not direct participants?* * *What mechanisms exist for conflict resolution between participants during their lifecycle?* * *How can collaboration be strengthened across the ecosystem?* * *Which mechanisms encourage active engagement from all participant types?* # Legal Building Blocks According to the DSSC Blueprint, the Regulatory Compliance and Contractual Framework building blocks aim to enhance understanding of compliance and contract issues within a data space: * [Regulatory Compliance](https://dssc.eu/space/BVE2/1071253931): This building block highlights key elements for ensuring compliance within the data space and outlines actions to be undertaken by data space participants or potential policies that the governance authority shall consider creating. It takes a practical approach by focusing on legal triggers, i.e. elements, criteria or events that have occurred in a particular context of a data space and signals that a specific legal framework must or should be applied. * [Contractual Framework](https://blueprint.dssc.eu/?pane=business\&business=contractual-framework): This building block provides a functional overview of essential contracts in a data space, categorising agreements according to their objects: institutional agreements, data sharing agreements, and service agreements. For each category of agreements, it highlights horizontal issues that are likely to emerge or are common to all sectors (e.g., the requirement of fairness in data contracts). These building blocks are designed to provide a basic approach to organising compliance within a data space, regardless of its specific characteristics. Regulatory and contractual requirements vary across sectors and depend on business, governance, and technical infrastructure decisions. Consequently, these blocks are not intended to provide exhaustive detail or all-encompassing templates. They do, however, provide references to relevant resources and further reading and offer some initial guidance on navigating the legal landscape for data spaces. Future editions will include additional information, guidance from relevant authorities, and new tools and templates as they become available. {% hint style="info" %} See the complete DSSC description [here](https://blueprint.dssc.eu/?pane=business#BusinessandOrganisationalBuildingBlocks-2.3LegalBuildingBlocks). {% endhint %} # Regulatory Compliance Legal certainty is essential for building trust in any data space. According to the DSSC Blueprint 3.0, the Regulatory Compliance building block helps identify which legal frameworks, obligations, and regulatory triggers are relevant to the design, operation, and participation within a data space. It also helps clarify legal entitlements to data and provides practical guidance on how to apply legal frameworks, assign responsibilities, and remain compliant over time. Each data space should establish clear procedures for:

Figure 14. Data Space Compliance Procedures.

This should be assessed against a broader set of relevant EU, sectoral, and national legal frameworks, depending on the context of the data space. For example, see the relevant DSSC section on [Types of data](https://blueprint.dssc.eu/?pane=business\&business=types-of-data-data-as-a-trigger) that may trigger differernt legar requirements, and [domain-specific use cases](https://blueprint.dssc.eu/?pane=business\&business=examples-of-domain-specific-use-cases) that may introduce additional obligaitons. {% hint style="info" %} The complete DSSC description is available [here](https://blueprint.dssc.eu/?pane=business\&business=regulatory-compliance). {% endhint %} While compliance starts with awareness, it must be embedded into both governance and technology. The iSHARE Framework supports these activities through predefined legal provisions and trust-based mechanisms that help participants meet requirements such as GDPR, eIDAS, and sector-specific rules, without duplicating compliance work across the ecosystem. See more details here on the [Legal Context](https://framework.ishare.eu/detailed-descriptions/legal/legal-context). In line with DSSC 3.0, compliance can also be supported through [LegalTech and RegTech](https://blueprint.dssc.eu/?pane=business\&business=regulatory-compliance#RegulatoryCompliance-3.4LegalTechandRegTechinthecontextofdataspaces) approaches, helping to enable auditability, policy enforcement, automation, and compliance by design. {% hint style="info" %} LegalTech refers to technology that supports legal processes, such as contract automation, licensing enforcement, and compliance monitoring, while RegTech refers to technology that supports regulatory compliance, for example, through identity verification, transaction monitoring, auditability, reporting, and policy management. {% endhint %} Data spaces may still need to customise legal interpretation for their domain and assess additional sector-specific or national requirements where relevant. {% hint style="info" %} Regulatory Compliance connects closely with other building blocks: * **Intermediaries & Operators:** Some may be subject to the DGA, especially Chapter III rules. * **Organisation Form & Governance Authority:** Business model and legal form must comply with national and EU laws. * **Participation Management:** Onboarding and offboarding must follow data protection policies. * **Contractual Framework:** Contracts need to cover legal requirements like data protection, IP, cybersecurity, and interoperability. * **Provenance & Traceability:** Supports compliance with GDPR and access control requirements. * **Identity & Attestation Management:** Participant verification must follow GDPR and eIDAS 2.0 rules. * **Use Case Development:** Different use cases may be subject to sectoral or national regulations. {% endhint %} {% hint style="warning" %} The guiding questions can help in the co-creation process and in defining this building block, so please see the next section. {% endhint %} # Guiding Questions {% hint style="success" %} **Purpose:** Identify and monitor all relevant EU and national laws to guarantee that operations remain legally sound. {% endhint %} 1. **Applicable Legal Frameworks** * *Which EU and national regulations (e.g. GDPR, Data Act, competition law, sectoral directives) are directly relevant?* * *How should the governance authority keep track of evolving regulatory obligations?* {% hint style="success" %} **Purpose:** Clarify which compliance duties belong to the governance authority versus individual participants to ensure accountability. {% endhint %} 2. **Compliance Responsibilities** * *What compliance obligations should rest with the data space authority versus the individual participants?* * *Should there be baseline legal compliance requirements for all participants before joining the initiative?* * *How can legal obligations be clearly communicated to all participants?* * *What support is needed to help participants meet compliance effectively?* {% hint style="success" %} **Purpose:** Establish a fair distribution of liability and safeguards to minimize legal and operational risks. {% endhint %} 3. **Risk and Liability** * *How should liability be distributed in case of breaches of regulatory obligations (e.g. data protection violations, misuse of data)?* * *What safeguards or monitoring mechanisms are necessary to minimize compliance risks?* * *How can compliance checks be automated to reduce manual effort?* * *Which tools help monitor ongoing regulatory adherence?* {% hint style="success" %} **Purpose:** Determine the most effective mechanisms for verifying ongoing compliance and trustworthiness of participants {% endhint %} 4. **Certification and Assurance** * *Should compliance be verified through certification, attestation, or self-declaration?* * *How frequently should compliance checks or audits be carried out?* {% hint style="success" %} **Purpose:** Integrate sectoral requirements while ensuring alignment with overarching EU legal frameworke. {% endhint %} 5. **Sector-Specific Rules** * *Are there additional environmental or sectoral regulations that need to be explicitly incorporated into participation rules?* * *How should conflicts between sector-specific rules and overarching EU frameworks be managed?* {% hint style="success" %} **Purpose:** Define clear processes and authorities for addressing and resolving compliance breaches. {% endhint %} 6. **Enforcement Mechanisms** * *How should compliance breaches be addressed (warnings, sanctions, suspension, exclusion)?* * *What governance body or process will be responsible for handling non-compliance cases?* # Contractual Framework Contracts are the formal expression of trust within a data space. They define the relationships, responsibilities, and rights that make collaboration possible. The DSSC Blueprint views the contractual framework as the set of agreements that make a data space function smoothly, legally, technically, and organisationally to support its operation. These agreements fall into three categories: * Institutional agreements that define governance and participation terms, * Data-sharing agreements that set the conditions for using and protecting shared data, * Service agreements that clarify expectations around operational support or enabling services.

Figure 15. Structure of Contractual Framework Building Block, including iSHARE Agreement Types.

{% hint style="info" %} The highlighted references above can be accessed via the links below: [Terms of Use & Accession Agreements ](https://framework.ishare.eu/detailed-descriptions/legal) [General Terms & Conditions](https://framework.ishare.eu/detailed-descriptions/legal) [Data Licenses](https://licenses.ishare.eu/) [Service Level Agreements](https://framework.ishare.eu/detailed-descriptions/operational/service-levels) {% endhint %} Rather than prescribing a single format, DSSC encourages flexibility, recognising that each data space has its own sectoral needs, risk profiles, and cultural norms. What matters most is that contracts are clear, fair, enforceable, and, where possible, interoperable and scalable. They should support collaboration while protecting each party’s rights and responsibilities. This building block is also closely tied to governance and compliance: your contracts should reflect the rules of your data space and create a reliable foundation for onboarding, policy enforcement, service provision, and conflict resolution. {% hint style="info" %} The complete DSSC description is available [here](https://blueprint.dssc.eu/?pane=business\&business=contractual-framework). {% endhint %} In iSHARE, all participants adhere to a consistent set of baseline agreements that establish fairness, accountability, and interoperability. Therefore, the iSHARE Trust Framework is underpinned by legal agreements to which all participants (both Adhering Parties and Certified Parties) need to adhere: * [Legal Provisions](https://framework.ishare.eu/main-aspects-of-the-ishare-trust-framework/legal-provisions) * [Legal Agreements & Terms of Use](https://framework.ishare.eu/detailed-descriptions/legal) In the iSHARE Terms of Use, 'Conditions of Exchange' are referred to as the ‘Licenses’ as mentioned also in the [Legal Provisions](https://framework.ishare.eu/main-aspects-of-the-ishare-trust-framework/legal-provisions#legalprovisions-licenses) section. See the [iSHARE Licenses Portal.](https://licenses.ishare.eu/) Part of the Terms of Use are the service level agreements with which adhering and certifying parties should comply: * [Service levels](https://framework.ishare.eu/detailed-descriptions/operational/service-levels) * [Service levels for Adhering Parties](https://framework.ishare.eu/detailed-descriptions/operational/service-levels/service-levels-for-adhering-parties) * [Service levels for Certified Parties](https://framework.ishare.eu/detailed-descriptions/operational/service-levels/service-levels-for-certified-parties-satellite) The service levels for Certified Parties or Adhering Parties are monitored by the Foundation as the Scheme Owner. For each data space, the members can define service levels more firm or specific, but not conflicting with ones defined by the Framework. A service level requirement for 95% availability can be set to 99% if it is more applicable for the data space, but not reduced to 80%. {% hint style="info" %} Contractual Framework connects closely with other building blocks: * **Organisational Form & Governance Authority:** Determines the structure of contracts and accession policies. * **Regulatory Compliance:** Ensures agreements follow laws so they are valid and enforceable. * **Provenance & Traceability:** Supports compliance by monitoring transactions and verifying data origins. * **Identity & Attestation Management:** Verifies participant identities to ensure agreements are enforceable. * **Data Space Offering:** Contracts cover data products and ensure licences are compatible for use cases. * **Participation Management:** Defines participation rules, roles, and offboarding, which are included in agreements. * **Access & Usage Policies Enforcement:** Implements and enforces contractual and regulatory rules technically, controlling access and use of data. {% endhint %} {% hint style="warning" %} The guiding questions can help in the co-creation process and in defining this building block, so please see the next section. {% endhint %} # Guiding questions {% hint style="success" %} **Purpose:** Standardize essential contractual terms to ensure clarity and fairness across all participants. {% endhint %} 1. **Core Structure of Agreements** * *What standard contractual elements should every participant agreement include (e.g. roles, rights, obligations, liability)?* * *Should there be a universal participation agreement or differentiated agreements depending on participant role (e.g. provider, consumer, intermediary)?* {% hint style="success" %} **Purpose:** Ensure that contractual arrangements reinforce overarching governance principles and adapt to evolving governance decisions. {% endhint %} 2. **Alignment with Governance** * *How can the contractual framework reflect and reinforce the governance principles (e.g., fairness, interoperability, accountability)?* * *Should governance decisions automatically amend contractual terms, or require explicit participant consent?* {% hint style="success" %} **Purpose:** Design contractual entry and exit processes that safeguard trust, compliance, and continuity. {% endhint %} 3. **Onboarding and Offboarding** * *What contractual processes should regulate entry into the data space (e.g., signature of framework contract, compliance verification)?* * *How should termination or exit of participants be managed contractually, including data handling and ongoing obligations?* {% hint style="success" %} **Purpose:** Balance the need for uniformity with customizable modules to address sector-specific requirements. {% endhint %} 4. **Flexibility vs. Standardisation** * *To what extent should the contractual framework allow customization by participants versus enforcing strict uniformity?* * *Should industry-specific annexes or modules be foreseen (e.g., CO₂ reporting standards for real estate, technical protocols for energy data)?* {% hint style="success" %} **Purpose:** Provide clear mechanisms for conflict resolution to maintain trust and minimize disruption. {% endhint %} 5. **Dispute Prevention and Resolution** * *How should contracts define mechanisms for conflict resolution (e.g., escalation procedures, mediation, arbitration)?* * *Should dispute-handling be centralized via a governance authority or decentralized among participants?* {% hint style="success" %} **Purpose:** Define how contractual compliance will be monitored, enforced, and sanctioned in case of breaches. {% endhint %} 6. **Compliance and Enforcement** * *How should contractual obligations be monitored and enforced (e.g., audits, sanctions, suspension)?* * *What should be the consequences of non-compliance with contractual terms, especially in relation to data misuse or sustainability targets?* # Introduction According to the DSSC description, to make a data space work in practice, you need more than governance and legal agreements; you need the technical capabilities that bring them to life. These capabilities, or “building blocks,” provide the tools that every participant can rely on to ensure consistency, trust, and interoperability across the ecosystem. The purpose of these building blocks is simple: * Help data spaces identify what’s needed. * Point to common standards, specifications, and proven solutions. * Make it easier to reuse, connect, and interoperate without reinventing the wheel. This way, participants reduce complexity, speed up adoption, and support interoperability both within and between data spaces. Similar to DSSC components, iSHARE groups these capabilities into three pillars: Technical capabilities are structured according to [three pillars](https://blueprint.dssc.eu/?pane=technical#TechnicalBuildingBlocks-2.Overviewofpillars): 1. **Data Interoperability**: agreeing on how data is described, formatted, viewed, and exchanged across different data ecosystems. This also includes recording provenance, traceability, and observability when necessary. 2. **Data Sovereignty and Trust**: making sure participants and their assets can be reliably identified, trusted, and given the right level of access and usage control. 3. **Data Value Creation Enablers**: describing, publishing, and discovering data, services , and offerings so participants can build use cases and generate value together. Through these building blocks, other participants can work together to define the technical rulebook of a specific data space. {% hint style="info" %} See the complete DSSC description [here](https://blueprint.dssc.eu/?pane=technical). {% endhint %} # Data Interoperability For a data space to function, everyone needs to speak the same language. According to DSSC, data interoperability is about making sure both people and systems can interpret shared data in the same way consistently. This has two sides: * Semantic interoperability: agreeing on the meaning of terms and concepts (e.g., what counts as a "delivery date” or a "location"). * Technical interoperability: agreeing on the syntax and formats (e.g., API, data model, or message structure used to exchange the information). In addition, it's also important to track where data came from, how it has been used, and by whom. This is where provenance and traceability of data come in, providing the evidence needed for auditing, compliance, or regulated industries. Within this pillar, we focus on three building blocks: 1. [Data Models](https://blueprint.dssc.eu/?pane=technical\&technical=data-models): defining and reusing shared semantics so participants “speak the same language.” 2. [Data Exchange](https://blueprint.dssc.eu/?pane=technical\&technical=data-exchange): setting up the actual flow of data between participants, usually through open and standardised APIs. 3. [Provenance, Traceability & Observability](https://blueprint.dssc.eu/?pane=technical\&technical=provenance-traceability-observability): capturing evidence of the data-sharing process so its transparent and verifiable. {% hint style="info" %} See the complete DSSC description [here](https://blueprint.dssc.eu/?pane=technical). {% endhint %} # Data Models According to the DSSC, data models make sure participants in a data space interpret data the same way. Without them, two systems might exchange information but come to different conclusions, which would undermine trust and create errors. DSSC 3.0 recommends first reusing existing data models where possible, extending them where needed, and only creating new models when necessary. * A data model works like a shared dictionary: it explains what each element means and how it relates to others. * Agreeing on a reusable model enables semantic interoperability, so providers and consumers “speak the same language” using common standards. * Different organisations have different needs, so data spaces must balance uniformity (to keep things clear and consistent) with flexibility (to fit diverse contexts).

Figure 16. Conceptual Model of the Data Models Building Block.

To support this in practice, DSSC 3.0 highlights the use of a vocabulary service for publishing, maintaining, and discovering data models. Datasets and services can then reference the model they follow using standard approaches such as DCAT-AP and `dcterms:conformsTo`, improving discoverability and semantic interoperability across data spaces. {% hint style="info" %} See the complete DSSC description [here](https://blueprint.dssc.eu/?pane=technical\&technical=data-models). {% endhint %} The iSHARE Trust Framework does not prescribe specific models. Instead, data spaces are encouraged to: * Reuse established standards where possible (sectoral or cross-domain). * Define lightweight governance rules for creating, updating, and adopting models. * Focus on lowering barriers so new participants can onboard easily. * Follow standard data sharing guidelines (like OpenID, etc.) while catering to industry-specific requirements. Well-managed data models help reduce costs, improve interoperability, and make it easier to link datasets across domains. {% hint style="info" %} Data Model connects closely with other building blocks: * **Data Exchange:** Defines how data is structured and transferred. * **Data Exchange & Data Sovereignty and Trust Pillar:** Uses protocols to ensure secure and reliable data transfer. * **Data, Services and Offerings Description:** Describes data and services using standard models like DCAT. {% endhint %} {% hint style="warning" %} The guiding questions can help in the co-creation process and in defining this building block, so please see the next section. {% endhint %} # Guiding questions {% hint style="success" %} **Purpose:** Define the key concepts and relationships that must be standardised to ensure semantic alignment across use cases. {% endhint %} 1. **Understanding Scope & Semantics** * *Which data products require semantic expression through a shared data model?* * *Which concepts, entities, and relationships must be standardised for your use case?* {% hint style="success" %} **Purpose:** Decide whether to reuse, extend, or develop new data models based on adoption, compatibility, and domain standards. {% endhint %} 2. **Selecting or Creating Models** * *Can existing data models be reused directly? If not, can they be extended rather than replaced?* * *Which standards organisations or communities maintain the most relevant models for your domain?* * *What factors (adoption level, integration compatibility, constraints) influence model selection?* {% hint style="success" %} **Purpose:** Choose meta-standards and reference vocabularies to ensure consistent, machine-readable representation of data models. {% endhint %} 3. **Expressing the Models** * *Which meta-standards will be used to represent data models? (e.g., RDF/OWL, SKOS, JSON Schema, XML Schema, CSVW)?* * *What reference datasets or controlled vocabularies (e.g., EU vocabularies, ISO codes) will be linked?* * *Does your dataspace use W3C as a recognized standards for Identity Management?* * *Does Dataspace use JSON-LD type as a recognized standard of Identity & Access Management?* * *Are vocabularies in RDF (Resource Description Framework OWL complaint?* {% hint style="success" %} **Purpose:** Establish processes for managing ownership, versioning, and stakeholder engagement around data models. {% endhint %} 4. **Governance and Maintenance** * *Who will act as the data model provider for each model (e.g., Standards Development Organisation, The governance team, sectoral community)?* * *How will versioning, change approval, and stakeholder engagement be managed?* * *What processes will be in place for resolving conflicts or inconsistencies between models?* {% hint style="success" %} **Purpose:** Provide accessible platforms and services to host, discover, and link data models with exchange schemas and APIs. {% endhint %} 5. **Tooling and Accessibility** * *Which Vocabulary Service platform will host the data models?* * *How will models be made discoverable across other EU data spaces?* * *How will models be linked to actual data exchange schemas and APIs?* * *Does your dataspace have a browser-based UI & API?* * *Does your dataspace provide a vocabulary service?* # Data Exchange Once participants agree on the meaning of data, they need a secure and reliable way to exchange it. Data exchange within a data space typically takes place through APIs, but can also include messaging, data streaming, or algorithm-to-data approaches, and, where relevant, credential exchange mechanisms, depending on the sector and technical setup. A data space may choose to limit or standardise certain data exchange protocols in its rulebook, while still allowing flexibility where needed. DSSC3.0 makes a clear distinction between: * Control plane: manages trust, identity, discovery, and access conditions, * Data plane: executes the actual transfer of data. These layers must work together to ensure that access and usage policies are enforced consistently. iSHARE does not prescribe a single method for data exchange. Instead, it aligns with and adheres to widely recognised industry standards that ensure interoperability and trust, such as PKI, OAuth 2.0, OpenID Connect 1.0, and Verifiable Credentials (VCs), based on W3C Verifiable Credentials, see more [here](https://dev.ishare.eu/introduction/specific-technical-standards). When participants use the iSHARE Framework, they automatically operate within these established standards, ensuring that authentication, identification, and authorisation (as defined in the [Data Sovereignty & Trust](https://template.ishare.eu/technical-building-blocks/data-sovereignty-and-trust) pillar) are consistently applied before and after any data flow occurs. By adhering to open standards and iSHARE trust mechanisms, data exchange across the ecosystem becomes secure, repeatable, and interoperable, making it easier for participants to connect and collaborate across data spaces.

Figure 17. Conceptual Model of the Data Exchange Building Block.

DSSC 3.0 also highlights protocol selection, governance, and publication. In practice, this means that the governance framework or rulebook should define how supported data exchange protocols are selected, approved, documented, version-managed, updated, and, where necessary, phased out over time. The protocol specifications themselves should then be published and maintained in a way that makes them findable, accessible, interoperable, and reusable, in line with FAIR principles. This helps create [Synergies of Data Spaces](https://blueprint.dssc.eu/?pane=technical\&technical=best-practice-defining-data-exchange-protocols#Bestpractice%3ADefiningDataexchangeprotocols-5.Synergiesofdataspaces) and enables a network of interconnected ecosystems. In this context, iSHARE-compliant components play an important role. They can be understood as an implementation of DSSC participant agent services: enabling the actual exchange of data while working together with control-plane functions such as identity, trust, discovery, and policy enforcement. These components secure and govern data exchange across participants, supported by connectors that can be aligned with iSHARE specifications. {% hint style="info" %} See the complete DSSC description [here](https://blueprint.dssc.eu/?pane=technical\&technical=data-exchange). {% endhint %} {% hint style="info" %} Data Exchange connects closely with other building blocks: * **Data Models:** Provides the technical foundation for formats like JSON. * **Access & Usage Policies and Enforcement:** Ensures transactions follow access and usage rules. * **Trust Framework:** Secures transactions through trust protocols. * **Data, Services, and Offerings Descriptions:** Retrieves the correct version and location of data assets. * **Value Creation Services:** Defines protocols and versions for data exchange. {% endhint %} {% hint style="warning" %} The guiding questions can help in the co-creation process and in defining this building block, so please see the next section. {% endhint %} # Guiding questions {% hint style="success" %} **Purpose:** Identify core transmission protocols and sector-specific APIs that enable seamless data exchange. {% endhint %} 1. **Protocol Selection** * *Which generic transmission protocols (e.g., REST/HTTP, NGSI-LD, LDES, MQTT) should be adopted?* * *Which domain-specific APIs are required for sectoral use cases?* * *Should a “preferred protocol set” be provided for faster onboarding?* * *Are Event Streaming (HTTPS or MQTT), IDSCP, or Protocol Buffers used for transmission?* {% hint style="success" %} **Purpose:** Define when data should be exchanged via push, pull, streaming, or batch transfers to meet diverse use cases. {% endhint %} 2. **Modes of Exchange** * *Will data be exchanged as push (provider sends) or pull (consumer requests), or both?* * *Which scenarios require continuous streaming versus finite batch transfers?* * *How will real-time updates and triggered exchanges be handled?* {% hint style="success" %} **Purpose:** Ensure protocols are aligned with semantic models and discoverable through catalogs. {% endhint %} 3. **Integration with Semantics & Discovery** * *How will protocols link to the agreed semantic data models?* * *How will API specifications and protocol details be published for discoverability?* {% hint style="success" %} **Purpose:** Implement mechanisms for ensuring accuracy, resilience, and compatibility in data transfers. {% endhint %} 4. **Quality & Reliability** * *How will completeness and accuracy of data transfers be ensured?* * *What mechanisms for error handling, reconnection, and version compatibility will be in place?* {% hint style="success" %} **Purpose:** Guarantee interoperability with other EU data spaces through shared protocols and a common inventory. {% endhint %} 5. **Federation Readiness** * *How will interoperability with other EU data spaces’ protocols be ensured?* * *Will a shared “protocol inventory” be maintained for federated connections?* # Provenance, Traceability & Observability In some cases, apart from the data itself, participants also need to know where it came from, how it has been used, by whom, and how certain decisions or outcomes can be understood. According to the DSSC, the provenance, traceability & observability building block enables them to provide the evidence trail that supports trust, compliance, and accountability. * **Provenance** captures the origin and history of data (who created it, how it was processed). * **Traceability** records what happened during a transaction (who accessed it, under what terms, and what actions were performed). * **Observability** helps make decisions, events, or outcomes understandable for monitoring, troubleshooting, and operational control.

Figure 18. Conceptual Model for Provenance, Traceability & Observability.

In practice, DSSC 3.0 distinguishes between evidence generated by participant agents and, where needed, the use of a dedicated observability service to collect and store relevant logs centrally. Which events need to be recorded, how logs are structured, who may access them, and whether storage is local or centralised should be defined in the data space rulebook. {% hint style="info" %} See the complete DSSC description [here](https://blueprint.dssc.eu/?pane=technical\&technical=provenance-traceability-observability). {% endhint %} These mechanisms are especially important in regulated sectors or when dealing with high-value data, including AI-related use cases, where knowing the origin, transformation, and permitted use od data helps support regulatory compliance, responsible reuse, and overall reliability of AI-driven services within the ecosystem (e.g., in finance, healthcare, logistics, or AI, where the EU AI Act may apply). They also play a crucial role in meeting obligations set out in European legislation, including the EU Data Act and the Data Governance Act (DGA), which emphasise transparency, interoperability, and accountability in data sharing. iSHARE aligns with these European frameworks, ensuring that its trust, governance, and technical specifications reinforce the same goals: legal clarity, accountability, and cross-sector interoperability in data exchanges. Because provenance, traceability & observability data are valuable in themselves, they must be handled with the same care as the primary data. This includes: * Clear semantics and structure so it can be understood. * Access and usage rules so only authorised parties can see or use it. * A balanced approach to granularity: detailed enough to build trust and meet compliance needs, but not so heavy that it slows down the system. The iSHARE Trust Framework does not prescribe a single approach here. Data spaces are free to design solutions that fit their governance and legal context, whether centralised, decentralised, or distributed. What matters is that the chosen model supports scalability, security, and alignment with contractual and regulatory requirements. {% hint style="info" %} Provenance, Traceability & Observability connects closely with other building blocks * **Data Models:** Ensures provenance and traceability data is understandable across participants. * **Data Exchange:** Shares provenance data securely using standard protocols. * **Identity and Attestation Management & Access and Usage Policies Enforcement:** Controls who can access provenance data. * **Data Value Creation Enablers:** Uses provenance data to create added value * **Business:** Supports agreements and governance based on provenance data. * **Legal:** Ensures provenance data meets regulatory and contractual requirements. * **Governance:** Defines rules and maintenance for provenance and traceability across the data space. {% endhint %} {% hint style="warning" %} The guiding questions can help in the co-creation process and in defining this building block, so please see the next section. {% endhint %} # Guiding Questions {% hint style="success" %} **Purpose:** Capture regulatory and business needs for data lineage to support compliance and value-added services. {% endhint %} 1. **Requirements & Use Cases** * *Which legal, contractual, or sectoral requirements exist for provenance and traceability?* * *Are there AI Act or other regulatory triggers that mandate detailed data lineage or traceability?* * *Are there business cases for using provenance data to add value (e.g., sustainability claims, quality certification)?* {% hint style="success" %} **Purpose:** Adopt or extend existing provenance ontologies to flexibly represent traceability information. {% endhint %} 2. **Data Modelling** * *Will existing ontologies (e.g., W3C PROV-O, PAV) be adopted and extended for sector needs?* * *Should provenance be modelled as “events” (e.g., CloudEvents) for flexibility?* {% hint style="success" %} **Purpose:** Define storage, retention, encryption, and access policies for provenance data across participants. {% endhint %} 3. **Storage & Management** * *Will provenance/traceability data be stored locally by participants, by certified 3rd parties, or in a hybrid model?* * *What are the retention, encryption, and access control policies?* {% hint style="success" %} **Purpose:** Clarify which processes and telemetry data should be observable for governance and monitoring purposes. {% endhint %} 4. **Observability Scope** * *Which Control Plane activities (catalog publication, contract negotiation, transfer process) will be observable?* * *Will operational telemetry (uptime, performance) also be included under the same governance?* {% hint style="success" %} **Purpose:** Designate certified observability providers while avoiding centralization and systemic risks. {% endhint %} 5. **Trust & Third Parties** * *Which organisations could act as certified observability service providers?* * *How will centralization risks be mitigated?* {% hint style="success" %} **Purpose:** Integrate provenance and traceability rules into the rulebook under governance oversight.\ **Governance Linkages** {% endhint %} 6. **Governance Linkages** * *How will rules for provenance and traceability be reflected in the rulebook?* * *Which governance body will approve changes to provenance and traceability standards or processes?* # Data Sovereignty & Trust According to the DSSC description, trust is the foundation of any data space. Participants need to know who they are dealing with and must be able to exercise control over their own data. The building blocks in this pillar provide the technical capabilities that make this possible. The Data Sovereignty and Trust pillar consists of the following three building blocks. * [Identity and Attestation Management](https://blueprint.dssc.eu/?pane=technical\&technical=identity-attestation-management): establishing who participants are, and providing verifiable proofs of their attributes or roles. * [Trust Framework](https://blueprint.dssc.eu/?pane=technical\&technical=trust-framework): ensuring everyone follows the same baseline agreements and trust rules. * [Access and Usage Policies Enforcement](https://blueprint.dssc.eu/?pane=technical\&technical=access-usage-policies-enforcement): giving participants the tools to control who can use their data and under what conditions. Together, these form the backbone of a secure and reliable environment for data sharing. {% hint style="info" %} See the complete DSSC Description [here](https://blueprint.dssc.eu/?pane=technical). {% endhint %} # Identity & Attestation Management This building block ensures that every participant, whether a legal entity, service provider, or natural person, can be uniquely identified, verified, and trusted across data ecosystems. It provides the foundation for a secure and interoperable identity and attestation management by enabling identities and credentials to be issued, stored, exchanged, and verified in a consistent and secure way. This supports the onboarding, secure interactions, authorisation, and accountability within the data space. The data space can follow iSHARE’s principles on digital identity management: * **iSHARE-ID:** Each participant is assigned a globally unique identifier, improving interoperability between data spaces and enabling cross-ecosystem recognition. See more [here](https://framework.ishare.eu/detailed-descriptions/functional/functional-requirements-per-role/party-identification). * **Multiple Identifiers:** Participants can be recognised by multiple identifiers (EORI or chamber of commerce numbers), which can be linked to a common identifier, iSHARE ID, supporting portable and verifiable identity across ecosystems. See more [here](https://trustbok.ishare.eu/apply-ishare/identification/multiple-identifiers). * **Accredited Identity Providers:** Certified Identity Providers issue and manage identities for both legal entities and their human representatives. They act as trust anchors within the ecosystem. * **eIDAS and W3C Compliance:** The iSHARE identity model recognises European eIDAS standards and global Verifiable Credential formats to ensure compatibility and legal validity. * **Alternative Onboarding Routes:** Service consumers without PKI certificates can now onboard securely using approved alternative verification flows. ### **Attestations** Attestations are verifiable proofs about an entity, such as its identity, membership, role, certification, or compliance status. In a data space, they help prove not only who or what entity is, but also whether it is allowed to participate and under which conditions. At a minimum, this can include a data space membership credential, but in iSHARE this is typically reflected through a broader set of claims and attestations, such as data space membership, data space agreement, data space role, framework agreement, framework compliance, framework role, IDP assertions, or X.509 certificates, depending on the use case and trust requirements. See more [here](https://dev.ishare.eu/participant-registry-role/claim-models). Using W3C Verifiable Credentials and eIDAS alignment, attestations enable trust from the first interaction and support role-based authorisation, compliance monitoring, and automated onboarding within the Participant Registry. ### **Implementation in the Data Space** Implementation in the data space typically involves both federation-level trust services and participant-level credential management. * Trust services are responsible for issuing and verifying Verifiable Credentials and supporting trust or rights delegation, * Participant-controlled credential stores allow participants to store, manage, present, and exchange credentials securely under their own control. To ensure interoperability, compatible credential exchange protocols or credential store implementations should be used across the data space.
Cover image
The Data Space Governance Body Selects and oversees accredited Identity Providers within the iSHARE governance model. Also, it defines the requirements and governs the process of onboarding of participants into data space./files/Br2qP0goDCSeKle65JD4
Identity ProvidersIssue, manage, and verify participant identities following the Framework specifications./files/Nz3YSRGPjseX75ZPaRsY
Human representatives of organisationsAuthenticate via their verified identity credentials./files/vzvQd2pPt1vhUL7ZgAYq
The Participant Registry Maintains up-to-date information on all data-space participants—including their assurance level, services, and roles—and manages the processes and criteria for onboarding, updating, reviewing, and confirming their membership, aligned with the Data Space Governance Body. /files/iPSF93GyUYIQld0ef1F1
Credential exchange is an important part of this building block. Depending on the use case, this can be supported through protocols from the OpenID for Verifiable Credentials family, such as OID4VCI for credential issuance and OID4VP for credential presentation, or through other compatible approaches such as DCP. These protocols help participants issue, present, and verify credentials securely while keeping control over what they share and with whom. With the introduction of iSHARE-ID and DID-based verification, participants can engage across ecosystems with confidence, knowing that every entity they interact with has been verified according to transparent, globally recognised standards. These enhanced mechanisms create a distributed yet cohesive trust layer, one that supports secure data sharing, smooth onboarding, and scalable governance across interconnected data spaces. {% hint style="info" %} Identity & Attestation Management connects closely with other building blocks: * **Trust Framework:** Works with Identity & Attestation Management to establish overall trust and define trusted entities. * **Access & Usage Policies Enforcement:** Depends on verified participant identities to control access and usage. * **Participation Management:** Relies on identity verification for onboarding, offboarding, and attesting participation. * **Regulatory Compliance:** Translates rules into digital mechanisms for validation and verification. {% endhint %} {% hint style="warning" %} The guiding questions can help in the co-creation process and in defining this building block, so please see the next section. {% endhint %} # Guiding questions {% hint style="success" %} **Purpose:** Define how legal entities and representatives will be uniquely and reliably identified. {% endhint %} 1. **Participant Identification** * *What identifiers (EORI, VAT ID, DUNS, DID, etc.) will be accepted for legal entities?* * *How will natural persons be identified and cryptographically bound to their role as authorised representatives of legal entities (e.g., Verifiable Credentials such as W3C/OpenID?* * *Will eIDAS-compliant solutions be mandatory, optional, or one of several supported schemes?* * *Will authentication rely on PKI?* {% hint style="success" %} **Purpose:** Establish the credentials and attestations required for onboarding, compliance, and sector-specific participation. {% endhint %} 2. **Credential Types & Attestations** * *Which credential types are required for onboarding (identity, membership, compliance)?* * *Will W3C/OpenID Verifiable Credentials be the primary format for organisational identity and representative roles?* * *What sector-specific or regulation-driven attestations will participants need to provide?* * *Will conformity assessments based on ISO/IEC 17000 be recognised for certain claims/attestations?* * *How will validity periods, renewals, and revocations be managed?* {% hint style="success" %} **Purpose:** Determine who issues credentials, how trust anchors are structured, and how verification will operate. {% endhint %} 3. **Credential Issuance & Verification** * *Who acts as the Trust Anchor(s) for credential issuance?* * *Will credential issuance be centralised under DSGA or federated across multiple accredited providers?* * *How will the verification process be implemented (centralised compliance service vs. distributed verification)?* * *How are credential issuance, renewal, and revocation managed (trust anchors, revocation lists/registries)?* * *Will verification align with eIDAS/ETSI trust lists and support automated status/revocation checks?* {% hint style="success" %} **Purpose:** Adopt interoperable standards to ensure credentials are machine-readable and compatible across data spaces. {% endhint %} 4. **Standards & Interoperability** * *Which technical standards (W3C VC, DIDs, OIDC4VC, SHACL, ETSI Trusted Lists) will be adopted* * *Will JSON-LD be used for credential data models and metadata?* * *How will interoperability with other data spaces and trust frameworks be ensured?* * *Will machine-readable rulebooks be published for automated compliance checks?* * *Will PKI profiles and secure-channel requirements be defined for credential transport?* {% hint style="success" %} **Purpose:** Set rules for managing credential changes, revocations, and disputes to maintain trustworthiness. {% endhint %} 5. **Governance & Lifecycle Management** * *How will credential revocation, suspension, and reinstatement processes be triggered and managed?* * *How will changes in participant status (mergers, closures, ownership changes) be handled in credential records?* * *What is the escalation process for identity disputes or fraudulent credential usage?* * *Where and how will conformance evidence (certificates, manifests, audits) be published for discovery (e.g., in catalogs/registries)?* # Trust Framework Trust in this data space is established through the[ iSHARE Trust Framework](https://framework.ishare.eu/). It defines the common agreements, roles, and standards that every participant must follow, ensuring consistency and fairness across the ecosystem. In this way, the trust framework helps translate governance rules into practical trust decisions that participants and services can verify and use in daily operations. The framework provides the baseline for identity, authorisation, governance, and compliance, making it possible for independent parties to interact with confidence. The trust is achieved with the following principles:

Figure 19. iSHARE Trust Principles.

The latest iSHARE Framework introduces several enhancements that strengthen the trust layer across interconnected data spaces: * **iSHARE-ID and DID-based identification:** Participants are identified through globally unique and verifiable identifiers, ensuring interoperability between different ecosystems. * **Verifiable Credential support:** The framework supports credential-based trust interactions using W3C Verifiable Credentials 2.0, including portable participant credentials and verifiable identity flows. * **Credential exchange protocols:** Credential exchange can be supported through protocols from the OpenID for Verifiable Credentials family and through DCP, depending on the use case and implementation context. * **Trust Services Based on iSHARE-ID:** Authorisation, delegation, and certification processes now leverage iSHARE-ID to ensure consistent verification across all participating entities. * **Licenses Portal:** The dedicated portal provides authoritative license templates and trust references, creating transparency and alignment in how data use and permissions are defined. Now, modular use of licenses makes the data ecosystems more scalable. See more [here](https://licenses.ishare.eu/). * **Harmonised Governance:** The Trust Framework links organisational and technical governance, enabling data spaces to federate under a shared trust baseline while maintaining autonomy. * **Updated onboarding and conformity logic:** The latest framework also clarifies onboarding and participant adherence, supporting a more structured and automatable trust process.
By building on these principles, the iSHARE Trust Framework 3.0 allows participants to engage securely and confidently. Every transaction, delegation, and license is backed by a consistent and verifiable foundation of trust. It also supports machine-readable trust information, helping interactions scale across data spaces. \ This shared framework transforms isolated initiatives into a federated, trusted network of data spaces that is scalable, compliant, and ready for cross-data-space interoperability. {% hint style="info" %} Trust Framework connects closely with other building blocks: * **Identity & Attestation Management:** Verifies identities and establishes trust using standard procedures. * **Access & Usage Policies Enforcement:** Controls data access and usage according to rules. * **Data Exchange:** Secures data sharing by checking participants and managing consent. * **Organisational Form & Governance Authority:** Creates and enforces governance rules, approving trusted entities. {% endhint %} {% hint style="warning" %} The guiding questions can help in the co-creation process and in defining this building block, so please see the next section. {% endhint %} # Guiding questions {% hint style="success" %} **Purpose:** Define the roles and recognition of trust anchors, providers, and accredited entities in the data space. {% endhint %} 1. **Trust Entities & Roles** * *Which Trust Anchors will the data space recognise (e.g., EU authorities, accredited certification bodies)?* * *What roles will Trust Service Providers play in the ecosystem?* * *Will the data space maintain its own accredited trust entities or federate from existing frameworks?* {% hint style="success" %} **Purpose:** Specify baseline and sectoral criteria for trust entities, aligned with the data space rulebook. {% endhint %} 2. **Criteria & Rulebook Alignment** * *What baseline criteria must a trust entity meet to be recognised in the data space?* * *How will sector-specific or regulation-driven trust requirements be added to the rulebook?* * *Will the data space adopt existing cross-sector rules (e.g., Gaia-X trust principles) or develop bespoke ones?* * *How will conformity with these criteria be evidenced (e.g., ISO/IEC 17000-based attestations, certificates)?* {% hint style="success" %} **Purpose:** Establish how claims and attestations will be validated, exchanged, and revoked when necessary. {% endhint %} 3. **Validation & Verification Processes** * *How will claims and attestations be collected, exchanged, and validated?* * *What technical standards (e.g., W3C VC, ISO CASCO) will the data space require for claims formatting?* * *How will revocation and suspension of trust entities or credentials be handled?* * *Will verification support dynamic attributes (e.g., DAT) where applicable to usage control?* {% hint style="success" %} **Purpose:** Create transparent, discoverable registries of trust entities to support verification and compliance. {% endhint %} 4. **Registry & Transparency** * *What type of registry will store accredited and revoked trust entities?* * *How will participants and third parties discover and verify trust entities?* * *Will registry entries be machine-readable for automated compliance checks?* {% hint style="success" %} **Purpose:** Integrate and adapt existing trust frameworks to meet high-risk requirements. {% endhint %} 5. **Leveraging Existing Frameworks** * *Which existing trust frameworks will the data space leverage (Gaia-X, iSHARE, IDSA, domain-specific)?* * *How will the data space extend these frameworks for domain-specific needs?* * *Will stricter trust criteria be applied for high-risk data or sensitive transactions?* * *How will cross-framework interoperability be proven (conformance testing, cross-certification, or mapped profiles)?* # Access & Usage Policies Enforcement This building block ensures that participants retain full sovereignty over their data. It enables them to define who may access their data, under which conditions, and for what purposes, while ensuring those terms are respected across the entire ecosystem. Within iSHARE, this supports scalable access and usage control by allowing standard terms, delegations, and usage conditions to be exchanged, verified, and enforced in a structured way, without requiring manual review for every transaction (policies must be machine-readable).

Figure 20. Participant-Controlled Trusted Data Access.

The iSHARE Framework delivers several integrated trust services that together form the enforcement layer for access and usage control: 1. **Authorisation Registry (AR) -** The AR stores and validates delegations, allowing participants to grant, verify, or revoke permissions in a standardised, machine-readable format. * The framework supports standardised delegation creation requests, ensuring consistent trust exchange and compatibility across ecosystems. * Each delegation is traceable and references the participant’s verified iSHARE-ID. 2. **Licenses and Usage Policies** - Licenses define the legal and operational boundaries of data use. * The [iSHARE Licenses Portal ](https://licenses.ishare.eu/)provides standardised license templates and metadata for both data and service offerings. * Data spaces can reference these licenses directly to ensure clarity and legal consistency between participants. 3. **Delegation Evidence** - [Delegations ](https://framework.ishare.eu/detailed-descriptions/technical/structure-of-delegation-evidence)are expressed using a shared JSON-LD structure that provides verifiable proof of rights granted. * Each piece of evidence can include license references, identity attributes, and usage conditions, ensuring complete transparency and traceability. 4. **Consent and Compliance Management** - Consent mechanisms, especially relevant when personal data is involved, can be integrated with delegation and license processes to ensure compliance with GDPR, eIDAS, and other regulatory frameworks. ### **Data Space Implementation** Each data space can build on these trust services to define: * Sector-specific access policies or license extensions; * Role-based permission schemes linked to participation management; * Additional guidance on the semantics of delegation and policy targets; * Enhanced auditing and monitoring to verify adherence to granted rights. This modular design allows flexibility without compromising interoperability. By combining iSHARE-ID, delegations, licenses, and structured evidence, data spaces can achieve a fine balance between participant control and ecosystem-wide trust. Through the integration of iSHARE-ID, standardised delegations, and the Licenses Portal, the Framework empowers participants to govern access and usage with precision, confidence, and scalability. The result is a federated system of trust in which access decisions are verifiable, usage rights are transparent, and participants remain in control of their data. {% hint style="info" %} iSHARE provides a generic approach for delegations, including generic licenses. Each data space can further refine this by defining more specific guidance, standards, or semantics for policy targets and by allowing more detailed licenses where needed. {% endhint %} {% hint style="info" %} Access & Usage Policies Enforcement connects closely with other building blocks: * **Identity & Attestation Management:** Verifies participants so access rules can be enforced. * **Trust Framework:** Sets rules and standards to support policy enforcement. * **Contractual Framework & Regulatory Compliance:** Ensures policies follow laws and contracts, including consent for personal data. {% endhint %} {% hint style="warning" %} The guiding questions can help in the co-creation process and in defining this building block, so please see the next section. {% endhint %} # Guiding Questions {% hint style="success" %} **Purpose:** Define common baseline policies while allowing participants to set stricter rules within their domains. {% endhint %} 1. **Policy Scope & Governance** * *Which common access and usage policies will the data space enforce platform-wide?* * *What is the minimum baseline for policy enforcement (security, privacy, sustainability criteria)?* * *Can participants define stricter policies within their own DUGs?* {% hint style="success" %} **Purpose:** Specify shared registries and consent points that integrate with identity and trust services. {% endhint %} 2. **Policy Information Points (PIPs)** * *Which shared PIPs should the data space maintain (e.g., GDPR consent registry)?* * *How will PIPs integrate with the Trust Framework and Identity Management?* * *Should sector-specific consent management be centralised or left to DUGOs?* {% hint style="success" %} **Purpose:** Enable machine-readable policy agreements, revocations, and checks throughout the data lifecycle. {% endhint %} 3. **Policy Lifecycle & Negotiation** * *How will machine-readable agreements be negotiated (ODRL templates, bilateral APIs)?* * *At what points in the data transaction lifecycle will policy checks occur?* * *How will policy revocations be propagated across participants?* {% hint style="success" %} **Purpose:** Design a distributed or centralised enforcement system using standard policy decision and enforcement points. {% endhint %} 4. **Enforcement Architecture** * *Will the data space operate a central policy engine or federate enforcement to participants?* * *How will the PEP/PDP/PIP/PAP architecture be implemented in multi-cloud or hybrid environments?* * *What contextual data (identity, contract terms, asset metadata) will be required for decisions?* {% hint style="success" %} **Purpose:** Provide audit trails, retention rules, and real-time alerts to ensure accountable policy enforcement. {% endhint %} 5. **Compliance Tracking & Proof** * *How will audit trails be generated, stored, and accessed?* * *What is the retention period for enforcement proof?* * *How will the data space support real-time policy breach alerts?* * *Will conformance evidence (logs, proofs, certificates) be published to support audits and marketplace listing requirements?* {% hint style="success" %} **Purpose:** Align policies with trust, identity, and legal frameworks to create a coherent enforcement ecosystem. {% endhint %} 6. **Interlinkages & Dependencies** * *How will Access & Usage Policies integrate with the Trust Framework?* * *How will identity attestations influence policy enforcement?* * *Which parts of the Legal Building Blocks must be mirrored technically here?* * *How will policy outcomes be reflected in discovery/marketplace visibility (e.g., eligibility, access tiers)?* # Data Value Creation Enablers The purpose of a data space is not only to enable secure sharing but to create real value for its participants. For this to happen, participants must be aware of the data, services, and offerings available in the data space. This pillar brings together the technical capabilities to make all the above possible: * [Data, Services and Offering Descriptions](https://blueprint.dssc.eu/?pane=technical\&technical=data-services-and-offerings-descriptions): capabilities to describe data, services, and offerings in a way that can be understood by participants across the data space. * [Publication and Discovery](https://blueprint.dssc.eu/?pane=technical\&technical=publication-and-discovery): mechanisms for publishing those descriptions so they can be found by potential data users. Supported by standardised endpoints and aligned with FAIR principles. (Findable, Accessible, Interoperable, and Reusable). * [Value Creation Services](https://blueprint.dssc.eu/?pane=technical\&technical=value-creation-services)[:](https://dataspacessupportcentre.atlassian.net/wiki/spaces/BV/pages/143720695) additional services that help create value from available data and support their appropriate provision, delivery, and use, for example, by enabling enrichment, analytics, or quality checks. {% hint style="info" %} See the complete DSSC Description [here](https://blueprint.dssc.eu/?pane=technical). {% endhint %} # Data, Services & Offerings Descriptions According to the DSSC, a cornerstone of any data space is the precise and comprehensive description of data products, services, and offerings. These descriptions are created using machine-readable metadata so that both people and software systems can use them. This supports seamless interactions, discovery, and automation.

Figure 21. Example of how data products, services, and offerings are described, published in a catalogue, and discovered by both software systems and data product consumers.

They can include metadata for various elements, including data products, services, data licenses, usage terms, and additional details such as commercial terms and pricing, all systematically organised within a catalogue. This helps data providers publish their resources clearly and allows potential data users to assess whether the available data, services, or offerings are relevant, understandable, and usable for their needs. {% hint style="info" %} High-quality metadata plays a critical role in ensuring the discoverability, interoperability, and usability of data products and services, forming the foundation for an efficient data sharing ecosystem. {% endhint %}

Figure 22. Lifecycle of a Data Space Offering.

For participants to find and use what a data space offers, these [offerings](https://blueprint.dssc.eu/?pane=business\&technical=data-services-and-offerings-descriptions\&business=data-space-offerings) must be clearly described. Good descriptions reduce misunderstandings, support automation, and make it easier for new participants to onboard. They should be designed with the end-user in mind and mantained in a structured and scalable way over time. In line with DSSC 3.0 and Article 33 of the Data Act, offering descriptions should cover at least: * **Data content**, including scope, use restrictions, licences, data quality, and uncertainty; * **Data Structures and Semantics**, such as formats, vocabularies, classification schemes, taxonomies, and code lists; * **Technical access**, including APIs or other access methods, their terms of use, and quality of service; * and, where relevant, C**ommercial and Operational Details**, such as pricing, usage tiers, or service conditions. High-quality metadata helps ensure that offerings are discoverable, interoperable, governed, and usable across participants and domains. In practice, this also requires capabilities for creating metadata, validating it against agreed standards and rulebook requirements, and updating it with version control throughout the lifecycle of the data product or service. The DSSC recommends standards such as [DCAT](https://www.w3.org/TR/vocab-dcat-3/) and [DCAT-AP](https://op.europa.eu/en/web/eu-vocabularies/dcat-ap) as a basis for structuring these descriptions. The iSHARE Trust Framework does not prescribe a specific metadata model for describing offerings, each data space is free to define or adopt the standards that fit best, but doing so in a structured and consistent way is key to building an efficient and trustworthy ecosystem. For the full recommended metadata dimensions, operational guidance, and further implementation examples, see the relevant DSSC section on [Best practices: Creating and Maintaining Metadata](https://blueprint.dssc.eu/?pane=technical\&technical=best-practice-creating-and-maintaining-metadata). {% hint style="info" %} See the complete DSSC Description [here](https://blueprint.dssc.eu/?pane=technical\&technical=data-services-and-offerings-descriptions). {% endhint %} {% hint style="info" %} Data, Services & Offerings Descriptions connects closely with other building blocks: * **Publication and Discovery:** Publishes and discovers datasets using machine-readable descriptions.(e.g. DCAT) * **Provenance and Traceability:** Tracks who created or changed datasets for transparency and quality. * **Data Space Offering:** Includes metadata like usage, quality, access, and pricing in data products. * **Data Models:** Defines dataset structure, formats, and standards. * **Access & Usage Policies and Control:** Ensures secure access using embedded policies. * **Value Creation Services:** Describes services like AI models, anonymization, and orchestration. * **Regulatory Compliance:** Data and services must comply with laws like the GDPR and Data Act. Descriptions should include these rules to inform users about applicable regulations. {% endhint %} {% hint style="warning" %} The guiding questions can help in the co-creation process and in defining this building block, so please see the next section. {% endhint %} # Guiding questions {% hint style="success" %} **Purpose:** Ensure that all datasets, services, and offerings are described using common vocabularies, ontologies, and schemas, so that they can be understood and used across Member States and sectors. {% endhint %} 1. **Standardised Metadata Models** * *Which metadata standards (e.g., DCAT-AP, schema.org, sector-specific ontologies) should be adopted as the baseline?* * *Do we need to extend existing metadata models with Green Deal–specific descriptors (e.g., CO₂ footprint, energy efficiency, circularity indicators)?* * *How can we ensure interoperability with other European Data Spaces (health, mobility, manufacturing)?* * *Will connector software manifests (root of trust, OS/app) be published to support supply-chain trust?* * *Which metadata standards (e.g., DCAT-AP, schema.org, sector-specific ontologies) should be adopted as the baseline?* * *Do we need to extend existing metadata models with Green Deal–specific descriptors (e.g., CO₂ footprint, energy efficiency, circularity indicators)?* * *How can we ensure interoperability with other European Data Spaces (health, mobility, manufacturing)?* * *Will connector software manifests (root of trust, OS/app) be published to support supply-chain trust?*
{% hint style="success" %} **Purpose:** Embed usage rights, data-sharing rules, and sustainability-related policies directly into dataset and service descriptions, so that participants can quickly understand the conditions of use. {% endhint %} 2. **Policy-Aware Descriptions** * *What types of data usage policies (e.g., open, restricted, commercial, research-only) should be standardised?* * *How should sustainability obligations (e.g., alignment with EU taxonomy, compliance with CSRD or energy reporting) be represented in dataset metadata?* * *Should policy metadata be mandatory for all offerings, or only for those connected to regulated domains (like emissions reporting)?* {% hint style="success" %} **Purpose:** Guarantee that descriptions are not only human-readable, but also machine-actionable to support automation in publication, discovery, and integration. {% endhint %} 3. **Machine-Readability and FAIR Compliance** * *Which formats and APIs should be enforced for machine-readable descriptions?* * *How can FAIR principles be operationalised across sectors?* * *Should minimal mandatory metadata fields be defined?* * *Will policy/usage terms be machine-readable and linked to identity/trust artifacts?* * *Will JSON-LD be used to express metadata/context, and will SHACL validation rules be provided?* {% hint style="success" %} **Purpose:** Allow extensions of the base metadata model with domain-specific fields that address the unique needs of Green Deal–aligned use cases. {% endhint %} 4. **Sector-Specific Extensions:** * *Which sustainability-related attributes should be mandatory in sector-specific extensions (e.g., building lifecycle data in construction, CO₂ intensity in energy)?* * *How do we balance general interoperability with the need for highly specialised descriptors?* * *Should governance rules for approving new sector-specific extensions be established, and by whom?* {% hint style="success" %} **Purpose:** Ensure that all participants have a transparent overview of what is available in the ecosystem, enabling efficient resource matching and value creation. {% endhint %} 5. **Ecosystem Visibility and Transparency** * *How can a unified catalogue or registry be maintained and updated?* * *What mechanisms (e.g., dashboards, registries, APIs) are needed to maintain transparency for participants?* * *Should there be obligations for providers to regularly update or validate their dataset/service descriptions to prevent outdated information?* # Publication & Discovery For a data space to create value, participants must be able to publish what they offer, and others must be able to discover it easily. Within the iSHARE context, this already connects to several discovery-related capabilities: * (Data) Services: All participants providing services must provide a[ /capabilities endpoint](https://dev.ishare.eu/all-roles-common-endpoints/capabilities), as defined in the developer documentation. This endpoint provides information on the available iSHARE service offerings. * Participants and Data Spaces: Participants or full data spaces can be made discoverable through the[ /parties endpoint](https://dev.ishare.eu/participant-registry-role/parties) or [ /dataspaces endpoint](https://dev.ishare.eu/participant-registry-role/dataspaces) of any iSHARE Participation Registry. * **Supplementary agreements or specifications:** While partly covered by the iSHARE Trust Framework, a data space remains free to define additional agreements or specifications on top of this building block, depending on its governance and use cases.

Figure 23. iSHARE-Based Service and Participant Discovery.

For a data space to create value, participants must be able to publish what they offer, and others must be able to discover it easily. Publication and Discovery therefore focuses on how offerings are exposed through catalogues, how they are managed throughout their lifecycle, and how potential data users can find them in a secure and interoperable way. #### Catalogue interfaces and offering lifecycle Each participant agent should be able to expose its offerings through a catalogue interface so that they can be discovered by data consumers. Offerings should also be managed throughout their lifecycle: they can be published, updated, removed, and discovered. Depending on the data space design, visibility and access to offerings may be open to all participants or limited to a specific group. #### Catalogue Protocol DSSC 3.0 places the Dataspace Protocol Catalogue Protocol at the centre of this building block. It enables the querying of a Participant Agent’s catalogue and supports the exchange of offering metadata using DCAT-AP-based structures. Access and usage conditions can be expressed through ODRL policies. This allows catalogues to support not only publication, but also interoperable discovery and controlled visibility of offerings across participants and, where relevant, across data spaces. #### Catalogue setup options A data space may choose different architectural approaches for catalogue services. Catalogues can remain decentralised, with each participant agent exposing its own catalogue, or a data space may introduce a centralised discovery or broker component. The choice between these models should be defined in the governance framework, based on visibility needs, interoperability goals, trust relationships, and operational complexity. #### In practice Publication and discovery usually involves four core functions: * publish an offering * update an offering * remove an offering * discover an offering These functions depend on clear metadata descriptions, authentication and authorisation, and the ability to control who may see or access a given offering. {% hint style="info" %} See the complete DSSC Description [here](https://blueprint.dssc.eu/?pane=technical\&technical=publication-and-discovery). {% endhint %} {% hint style="info" %} Publication and Discovery connects closely with other building blocks: * **Data Space Offering:** Describes the data and services offered. * **Regulatory Compliance:** Covers rules for data intermediation services. * **Data, Services and Offerings Description:** Manages offerings for publication and discovery. * **Value Creation Services:** Publishes available services via the Publication and Discovery building block {% endhint %} {% hint style="warning" %} The guiding questions can help in the co-creation process and in defining this building block, so please see the next section. {% endhint %} # Guiding questions {% hint style="success" %} **Purpose:** Define the breadth and depth of the catalogue to balance discoverability, transparency, and accessibility. {% endhint %} 1. **Scope & Functionality of the Catalogue** * *What is the appropriate scope of the catalogue (minimal index or rich metadata repository)?* * *Should offerings be accessible to non-participants (public visibility) or only to registered participants?* * *What level of detail in metadata is required to ensure both discoverability and trustworthiness?* * *Will the catalogue manage service offerings, support dynamic data transactions, and enforce access management for offerings?* {% hint style="success" %} **Purpose:** Clarify who manages the catalogue and how access rights are assigned, authenticated, and authorized. {% endhint %} 2. **Governance & Access Control** * *Who governs the catalogue (central authority vs. distributed responsibility)?* * *How should access be managed, open, tiered (role-based), or restricted to use-case participants?* * *What mechanisms should be in place for authentication and authorization when publishing and discovering offerings?* {% hint style="success" %} **Purpose:** Decide whether the catalogue operates as a central service, a federated network, or a hybrid model. {% endhint %} 3. **Catalogue Architecture (Centralised vs. Decentralised)** * *Should a federated model, central broker model, or hybrid be adopted?* * *If federated, how should synchronisation work across distributed catalogues? (push, pull, gossip protocols).* * *If centralised: who operates and funds the central catalogue service, and what are the implications for neutrality and inclusivity?* * *How will cross-space interoperability for discovery be ensured (common APIs/profiles, conformity tests)?* {% hint style="success" %} **Purpose:** Adopt common metadata standards and align with EU infrastructures to ensure cross-data-space discoverability. {% endhint %} 4. **Interoperability & Standards** * *Which metadata standards (DCAT v3, ODRL, FAIR) should be mandatory?* * *How should the catalogue align with EU infrastructures (data.europa.eu, national catalogues, sectoral hubs)?* * *How to ensure cross-data-space discoverability while maintaining control over sensitive offerings?* {% hint style="success" %} **Purpose:** Establish processes for managing, updating, and preserving catalogue entries with sustainability in mind. {% endhint %} 5. **Offering Lifecycle & Sustainability** * *How should providers manage the lifecycle of offerings (versioning, updates, retirement)?* * *Should sustainability attributes (e.g. environmental impact, CO₂ data quality) be part of metadata descriptions?* * *How do we ensure long-term persistence of identifiers (PIDs) to support reuse across data spaces?* {% hint style="success" %} **Purpose:** Ensure catalogue entries are reliable, searchable, and validated to build user confidence and usability. {% endhint %} 6. **User Experience & Trust** * *What mechanisms ensure offerings are searchable, transparent, and reliable?* * *Should a data-space-wide search portal be provided for non-technical users?* * *How do we build confidence in entries (validation, certification, provenance)?* * *Will verification links be exposed for trust decisions?* # Value Creation Services {% hint style="info" %} This topic is not covered in the iSHARE Trust Framework. The data space is free to define agreements or remove this section. {% endhint %} Beyond simply sharing data, many data spaces benefit from services that help participants create additional value. According to the DSSC, value creation services are technical services that add functionality on top of data sharing. They can support individual participants, for example, through transformation or analytics, or create broader value by combining data from multiple sources. Unlike core interoperability and trust services, these value-adding services are not defined in the iSHARE Trust Framework. They are not mandatory for every data space, but depending on the business model, use cases, or offerings, they may be important. Each data space is free to decide which services are relevant for its community and under what conditions they are provided. A few practical principles apply:

Figure 24. Principles of Value-Adding Services.

In line with DSSC, value creation services should also be described in a structured way so they can be published and discovered consistently, like other offerings. Standards such as [DCAT](https://www.w3.org/TR/vocab-dcat-3/) or [DCAT-AP](https://op.europa.eu/en/web/eu-vocabularies/dcat-ap) can help here, although further profiles or extensions may be needed depending on the type of service. By introducing value creation services, data spaces can move from “data available” to “data usable and impactful,” helping participants unlock new applications and business opportunities. The business aspects of these services are considered in the [Data Space Offering](https://blueprint.dssc.eu/?pane=business\&technical=value-creation-services\&business=data-space-offerings) building block, while information about providers of such services is addressed in the [Intermediaries and Operators](https://blueprint.dssc.eu/?pane=business\&technical=publication-and-discovery\&business=intermediaries-and-operators) building block. {% hint style="info" %} See the complete DSSC Description [here](https://blueprint.dssc.eu/?pane=technical\&technical=value-creation-services). {% endhint %} {% hint style="info" %} Value Creation Services connects closely with other building blocks: * **Business Model:** Services add value and may generate revenue or costs. * **Use Case Development:** Services provide key capabilities for use cases. * **Data Space Offering:** Services enhance and extend data products. * **Intermediaries and Operators:** Defines who provides which services. * **Data, Services and Offerings Descriptions:** Provides metadata for service publication and discovery. * **Provenance and Traceability:** Tracks service interactions with data. * **Identity and Attestation Management:** Manages claims and attestations for services. {% endhint %} {% hint style="warning" %} The guiding questions can help in the co-creation process and in defining this building block, so please see the next section. {% endhint %} # Guiding Questions 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?* {% hint style="success" %} Rules are needed to define which services can operate within the data space, how they are accredited, and how participants can trust them. {% endhint %} 2\. **Governance and Participation** * *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)?* {% hint style="success" %} Services must integrate smoothly with shared data, registries, and other technical building blocks while ensuring FAIR principles. {% endhint %} 3. **Interoperability and Standards** * *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?* {% hint style="success" %} Value creation services should be accessible to all participants, not only large organizations with resources. {% endhint %} 4. **Access and Fairness** * *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?* {% hint style="success" %} Services need viable business models, balancing sustainability with impact. {% endhint %} 5\. **Sustainability and Business Models** * *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?* {% hint style="success" %} Trust mechanisms are required to ensure that services deliver accurate, unbiased, and reliable outputs. {% endhint %} 6. **Trust, Certification, and Quality Assurance** * *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?* # Co-Creation & Change Management Methodology A Practical Framework for Collaborative Rulebook/ Governance Framework Development ### 1. What Is Co-Creation? Co-creation is a collaborative and incremental design process in which diverse stakeholders jointly define challenges, explore ideas, and develop shared solutions. It moves beyond consultation, instead focusing on shared ownership, transparency, and learning through iteration. Co-creation brings together expertise from policy, business, technical, and legal domains to ensure that what is designed is inclusive, implementable, and collaborative. ### 2. Why Co-Creation Matters? * Ensures alignment between strategic goals and operational realities. * Builds trust and commitment among contributors. * Encourages transparency and accountability in decision-making. * Creates solutions that are tested, adaptable, and widely accepted. * Brings the community together and shares the ownership of the Governance Framework among the practical implementers * A collaborative approach to pragmatic improvements aligning with the needs of the users. ### 3. The Co-Creation Process Co-creation within a Data Space builds on a few practical, repeatable steps. Each Data Space initiative is free to tailor this process; this process is not linear, but there is a learning curve with being consistent with the guiding questions and building blocks defined in the Data Space Template/Rulebook. {% hint style="info" %} Note: Rulebook, Data Space Template, or Governance Framework are interchangeable. {% endhint %} | Steps | Purpose | Key Activities | | :---------------------------------------------------------------: | :--------------------------------------------------------------------------------------------------------------------------------: | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | |
  1. Prepare Your Foundation
| Establish your own working version of the iSHARE Data Space Template. | Copy the template, create a local version, and review the building blocks relevant to your initiative. | |
  1. Map Stakeholders and Responsibilities
| Identify who needs to be involved and where. | Map stakeholders and assign them to the most relevant building blocks. See the supporting template for this attached below. | |
  1. Explain the Co-Creation Approach
| Ensure everyone is aligned on the collaboration process. | Share the co-creation methodology, guiding questions, and topics from the Data Space Template with your stakeholders (You can use the supporting template shared above as well). Clarify how outcomes will feed into the Data Space Template. | |
  1. Plan and Prioritise
| Establish a shared understanding of which governance, business, and technical topics require immediate attention and sequencing.\* | Define the prioritise of each topic, building block and plan sessions with your stakeholders. | |
  1. Align with Your Roadmap
| Align sessions in sync with your project timeline. | Develop a roadmap of co-creation sessions that aligns with your initiative’s milestones. Ensure adequate time for feedback and iteration.\*\* | |
  1. Run and Document Sessions
| Capture input and make progress visible. | Facilitate sessions, collect notes and decisions, and document updates in your working version of the Data Space Template/Rulebook. See supporting template below. | |
  1. Consolidate and Iterate
| Translate outcomes into formal deliverables. | Integrate session results into the Rulebook, validate across teams, and refine where needed. | {% hint style="info" %} \*This step ensures that the co-creation sessions focus on the most critical and interdependent building blocks first, enabling a structured and efficient progression toward the development of the Governance Framework. {% endhint %} {% hint style="warning" %} \*\* It is highly recommended to adopt an internal release timeline to ensure structured collaboration and steady progress. Iterative drafts incorporating partner feedback and refinements promote transparency, alignment, and quality, while minimising inconsistencies. This approach supports continuous improvement and ensures that final deliverables are coherent, accurate, and reflect the participants’ collective expertise. {% endhint %} {% file src="/files/CLVmSkYCtgtqr5fAWblZ" %} Download the Template above and reuse it for your Co-creation planning. {% endfile %} {% file src="/files/4iI1hFm1UZQQnHCcs9WA" %} Download the Template above and reuse it for your Planned Co-creation session for documentation. {% endfile %} ### 4. Roles & Responsibilities * **Change Manager/ Main co-ordinator** (e.g. Working Group leader): Oversees the co-creation and change management process, ensures timely progress, documentation, and maintains overall coordination. * **Session Facilitators (e.g. Governance Task leader):** Guide discussions, capture key points, and ensure outcomes are recorded. See the template [here](https://docs.google.com/document/d/1lZn9qRK5C2YpND8_Kf59vofy9Mchmc_deqsf7jt4cjw/edit?tab=t.csqdp0m9ou7k#heading=h.mv9k8urm29a5). * **Consortium Participants:** Contribute to discussions, provide feedback, and submit proposals via GitHub following the established workflow (Latest only applicable, in case you are using those tools within your change management practice). * **Consortium Leader/Project leaders:** Facilitate conflict resolution and ensure decisions align with the project objectives. * **Change Advisory Group:** Review major changes, provide recommendations, and ensure cross-block consistency and alignment. {% hint style="info" %} Note: The roles and responsibilities outlined above are provided as an example. DSI may adapt or redefine its governance structure based on specific project requirements and operational preferences. {% endhint %} ### 5. Integrating Change Management (only applicable after the first complete deliverable of the Rulebook) Change management ensures that co-created outcomes are adopted, improved, and sustained over time. Hence, it is only integrated after the first completed version of the Rulebook/Data Space template is delivered/ published. It complements co-creation through structured governance and transparent documentation. **Key Enablers:** * **Communication:** Open channels before, during, and after each session. * **Documentation:** Clear traceability of inputs, versions, and rationales. * **Project Management:** Managing operational processes and day-to-day activities, meeting timelines, and making decisions on priorities. * **Participation:** Inclusive engagement from all relevant stakeholders. * **Feedback & Adaptation:** Iterative refinement to keep outputs relevant. **Step-by-Step Process of Change Management:** {% stepper %} {% step %} Identify areas for improvement within the Rulebook {% endstep %} {% step %} Propose the change {% endstep %} {% step %} Define how to implement the change / develop an implementation plan {% endstep %} {% step %} Analyse the potential impact of the change on the data space template component \\ {% endstep %} {% step %} Decide whether to approve the change based on the analysis (if approved, proceed to implementation) {% endstep %} {% step %} Implement the change {% endstep %} {% step %} Assess the results and document lessons learned {% endstep %} {% endstepper %} {% hint style="info" %} Note: Data Space initiatives can customise this and apply tools as they prefer. In the above scenario, we would suggest using GitHub, and/or Giftbook. {% endhint %} ### 6. Expected Outcomes
Cover image
A collaboratively built and versioned governance framework/rulebook./files/r35dM4ANwyYXnqsO7M4g
Documented stakeholder inputs and rationale for every decision./files/WudJEFO72hrSizXSlP7i
A living process that continues evolving after the formal project ends./files/pONQceQKOwxrYqFx4Cj8
{% hint style="info" %} #### In short: Co-creation builds alignment. While change management sustains it. Together, they ensure that collaborative frameworks remain dynamic, inclusive, and future-proof. {% endhint %}