> For the complete documentation index, see [llms.txt](https://frameworks.greendealdata.eu/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://frameworks.greendealdata.eu/governnace-frameworks/governance-playbook/gdds-governance-authority-and-model/governance-model-for-the-project-phase-mvp1.md).
# Governance Model for the Project Phase (MVP1)
During the SAGE project phase, the GDDS operates as an unincorporated consortium under the Grant Agreement. The formal organisational form is therefore project-bound and contractual.
The MVP1 governance model represents the current focus of the project and is tailored to the project phase, during which the GDDS is being designed, implemented, and prepared for operation.
MVP1 governance is intentionally:
* lightweight and pragmatic,
* focused on coordination, rule definition, and co-creation,
* supportive of technical and organisational experimentation,
* and aligned with project delivery requirements.
The purpose of MVP1 governance is to:
* Establish a credible governance baseline
* Design and validate the GDDS Rulebook
* Test governance processes in a controlled project environment
* Prepare institutional continuity toward MVP2
The MVP1 phase, therefore, also serves as a testing environment for elements of the future governance model, allowing governance mechanisms to be validated before the full operational launch of the data space.
The Figure below showcases the MVP1 governance structure, in line with the current project organisation and includes the governance bodies.
Figure XXXXX: MVP1 Governance Model for SAGE Project Phase
***
### Detailed Description of Each Governance Body (MVP1)
Below you can find the detailed description of each body, their responsibilities, limitations, and the resources they require. Click on each extendable tab below to read further.
Community of Practice (Advisory & Participation Layer)
### Role and Function
The Community of Practice (CoP) represents the broadest and most inclusive engagement layer of the GDDS during the project phase. It functions as an open ecosystem forum designed to support collaboration, knowledge exchange, and stakeholder feedback.
The Community of Practice enables the project to remain closely connected to the broader data space ecosystem and helps ensure that the governance framework reflects the needs, expectations, and experiences of relevant stakeholders.
While the Community of Practice plays an important consultative role, it does not exercise formal governance authority within the project.
Participation in the Community of Practice is open and voluntary. It may include:
* members of the SAGE consortium,
* potential data providers and data users,
* service providers and technology actors,
* representatives of other European data spaces,
* public authorities and policy actors,
* organisations and experts interested in the development of the GDDS.
Participation is non-restricted and may evolve throughout the project as the ecosystem grows.
### Responsibilities & Limitations
The Community of Practice contributes to the governance development process through:
* providing feedback on GDDS components,
* sharing insights on ecosystem developments, policy trends, and emerging needs,
* identifying potential risks, opportunities, and cross-sector synergies,
* facilitating dialogue between GDDS and related initiatives.
Through these activities, the Community of Practice supports the legitimacy, transparency, and ecosystem relevance of the governance framework.
The Community of Practice does not exercise binding decision-making authority, but its input informs governance deliberations within the GA and Steering Committee.
### Resources
To function effectively, the Community of Practice requires:
* a collaborative engagement platform,
* periodic engagement sessions such as workshops or consultations,
* light coordination support,
* transparent access to relevant documentation.
General Assembly (Governance Authority)
### Role and Function
The General Assembly (GA) is the formal governing body of the SAGE consortium during the project phase. It operates under the Grant Agreement and represents the collective authority of the consortium partners.
The GA ensures that project activities remain aligned with contractual obligations, strategic objectives, and the overall mission of the GDDS initiative.
Within the MVP1 governance framework, the General Assembly acts as the primary governance authority.
### Composition
The General Assembly consists of representatives of all funded consortium partners participating in the SAGE project (for more details, visit this [page](https://www.greendealdata.eu/about/consortium/)).
Members participate through the organisational structure of the project, including Work Packages and coordination bodies.
The General Assembly meets:
* monthly online, and
* approximately every six months in person.
### Responsibilities & Limitations
The General Assembly performs both strategic oversight and project governance functions.
Its responsibilities include:
* monitoring overall project progress,
* reviewing coordination challenges and risk factors,
* aligning priorities across technical, governance, and use case domains,
* endorsing governance proposals and Rulebook developments,
* approving major project-level decisions and deliverables.
The GA also ensures that governance development remains consistent with the Grant Agreement and Digital Europe Programme requirements.
The GA may delegate structured strategic preparation tasks to a (GDDS Strategic) Steering Committee (if established), without transferring its contractual authority.
The General Assembly does not:
* perform day-to-day operational execution,
* directly manage technical implementation tasks,
* override contractual obligations defined in the Grant Agreement.
### Resources
The General Assembly requires:
* administrative and secretarial support,
* meeting infrastructure,
* access to financial reporting and project management information,
* access to legal
GDDS Strategic Steering Committee (Delegated Strategic Body)
### Function and Role
The SSC is established as an internal coordination and strategic alignment group within the SAGE project.
It does not modify the formal governance structure defined in the Grant Agreement or Consortium Agreement, nor does it introduce a new decision-making body at project level.
The SSC supports the design and development of the GDDS governance framework (MVP1) and operates under the authority of the General Assembly.
Any formal decisions affecting the SAGE project, including those related to governance structures defined in Annex 1 of the Grant Agreement, remain under the exclusive competence of the General Assembly and, where required, the Granting Authority.
The SSC therefore contributes to the development of GDDS governance without altering the legally binding governance of the SAGE project.
### Composition
The SSC is proposed to consist of approximately five to seven members, ensuring balanced representation across governance, technical, and use case perspectives.
Membership may include:
* Project Coordinators (ex officio)
* Selected representatives across governance, technical, business, legal and use case domains
* Optional: 1 external strategic advisor (non-voting), for example, a representative from the EU (DG ENV) who is seen as "owners" of GDDS.
### Appointment Process of SSC
First, the General Assembly votes on the establishment of the SSC, including its proposed mandates and compositions based on the Proposal prepared by the WP4 Governance Group. (see below also in the Mandate and Scope section).
Then, members of the GDDS Strategic Steering Committee are nominated by the General Assembly with the following rules in mind:
The SSC is proposed to consist of 5–7 members with balanced representation across five domains: Governance, Technical, Business, Legal, and Use Cases. Additionally, it should include the Project coordinators and an External Advisor. Members are expected to act with independence of judgement in the broader interest of the GDDS. The members must be part of the consortium to represent the domains.
Submission rules:
\
• One submission per consortium member organisation
\
• Maximum one nominee per domain (up to 5 nominees total)
\
• Self-nominations are not accepted
The SSC proposal sets out the following working principles for members:
\
• Diversity of expertise — complementary skills and perspectives
\
• Independence of judgement — acting in the best interest of the GDDS, not solely their organisation
\
• Commitment and availability — active participation throughout 2026-2027
\
• Transparency and accountability — regular reporting to the General Assembly
The final composition of the SSC shall be subject to approval by the General Assembly in accordance with the Consortium Agreement procedures.
{% hint style="info" %}
*Note: The GDDS SSC was confirmed in May, 2026 in the General Assembly hosted in Oslo. The nominations happened in June, 2026. During the nomination, requests from members of the General Assembly were received on expanding the composition of the SSC, specifically the UC representation from 1 to at least 2 members.* \
\
*This request is currently (26/06/2026) being considered, and the SSC nominee set up is expected to happen by the end of July, 2026.*
{% endhint %}
### Mandate and Scope
#### Strategic Alignment (Cross-Domain)
The SSC supports alignment between:
* Governance framework (Rulebook and policies)
* Technical architecture and implementation
* Business model and sustainability design
* Use case development and deployment
The SCC identifies inconsistencies, dependencies, and misalignments and formulates recommendations for resolution.
All alignment activities should be conducted in compliance with the applicable laws.
#### Escalation Handling and Issue Preparation
The SSC serves as the primary layer for analysing escalations that:
* Span multiple domains (e.g. governance–technical–legal-business interactions)
* Cannot be resolved at Work Package or operational level
* May have system-wide implications
The SSC evaluates such issues and prepares recommendations on whether they:
* Can be resolved operationally
* Should be escalated to the General Assembly
* Should be referred to Ethics & Compliance review
#### Governance & Rulebook Support
The SSC supports the structured evolution of the GDDS Rulebook by:
* Reviewing and pre-validating Rulebook drafts before submission to the GA
* Ensuring consistency between governance and legal rules, and technical/operational implementation
* Supporting governance change management processes
This function is performed as part of a broader cross-domain mandate.
#### System Coherence and Risk Monitoring
The SSC monitors system-level coherence and risks, including:
* Fragmentation between work streams
* Misalignment between governance, technical, business, and legal components
* Emerging legal, operational, or strategic risks
It formulates recommendations to improve system integrity and alignment.
#### Reporting & Transparency
* SSC reports formally to the GA every 6 months.
* Minutes documented and shared with the consortium.
* Major decisions are subject to GA endorsement where required.
#### MVP1 to MVP2 Transition Preparation
The SSC contributes to preparing the transition toward operational governance by:
* Identifying governance mechanisms that scale effectively
* Highlighting structural gaps, inefficiencies, or situations of non-compliance
* Supporting the conceptual design of future governance structures (MVP2)
While it does not exercise formal supervisory authority, its functions anticipate aspects of a future Supervisory Board under MVP2.
The SSC mandate will be reviewed at the end of MVP1.
### Boundaries and Limitations
To ensure clarity and avoid overlap, the SSC operates within clearly defined boundaries.
**Relationship with the General Assembly**
* The GA remains the formal governance authority under the Grant Agreement
* The SSC supports, prepares, and formulates recommendations for GA consideration
* The SSC does not take binding decisions requiring GA approval
**Relationship with the Operations Team**
* The SSC focuses on strategic alignment, coordination, and issue preparation
* The Operations Team remains responsible for execution and implementation
**Relationship with Ethics & Compliance**
* The SSC may identify potential compliance or ethical risks
* Formal assessment and enforcement remain the responsibility of Ethics & Compliance bodies
**Non-Functions of the SSC**
The SSC shall not:
* Replace the GA as contractual authority
* Execute operational tasks or manage Work Packages
* Override consortium partner rights
* Constitute a formal governance body under the Grant Agreement
Operations Team (Operational Layer)
### Function and Role
The Operations Team constitutes the execution layer of the MVP1 governance model. It is responsible for implementing the tasks defined in the Grant Agreement and for developing the technical, operational and governance foundations of the GDDS.
While for MVP2 the operational layer will have a structure and conduct activities typical for the operational area of a distributed system (run and enable functions of the GDDS like data exchange service delivery etc.), for MVP1, the operational layer will reflect the nature of a project-based delivery phase and mimic the structure and enable the functions of the project. Hence, through coordinated work across technical, governance, business, and use case domains, the Operations Team ensures the delivery of project outputs and supports the development of the future data space infrastructure.
### Composition
The Operations Team includes the key operational actors responsible for project implementation, including:
* the project coordinators,
* work package leaders,
* domain experts contributing to specific domain tasks.
Operational coordination is structured across several domains, including:
* Technical development (WP2, WP3, WP5),
* Governance, legal, and business model development (WP4, WP7, WP1),
* Use case implementation and coordination (WP6),
* project coordination, dissemination, and communication (WP8, WP9).
This structure ensures alignment between governance development, technical implementation, and ecosystem engagement.
### Responsibilities & Limitations
The Operations Team is responsible for the day-to-day execution of project activities.
Its responsibilities include:
* delivering work package tasks defined in the Grant Agreement,
* developing the technical and organisational components of the GDDS,
* drafting governance documents, technical specifications, and supporting materials,
* coordinating collaboration across work packages and project partners,
* preparing proposals and documentation for governance decisions.
The Operations Team reports to the General Assembly and, if established, may coordinate strategic matters with the Strategic Steering Committee.
It may also:
* receive ecosystem input from the Community of Practice, and
* escalate ethical or compliance concerns to the Ethics & Compliance oversight mechanism.
The Operations Team does not:
* take final governance decisions reserved for the General Assembly,
* deviate from the commitments defined in the Grant Agreement,
* override governance decisions taken by the GA or other authorised bodies.
Ethics & Compliance Committee (Independent Oversight)
### Function and Role
During the project phase, ethical and legal oversight is provided through an Ethics & Compliance Committee acting as an independent advisory body supporting the governance framework of the GDDS.
The committee safeguards legal and ethical compliance during the design and implementation of the data space and ensures that governance proposals and operational activities remain aligned with relevant regulatory and ethical standards.
The committee does not exercise strategic governance authority and does not participate in operational execution.
The committee’s responsibilities include:
* conducting legal and compliance assessment
* issuing compliance reports and risk assessment
* providing policy recommendations to strengthen legal and ethical robustness,
* managing escalation pathways in cases of non-compliance.
### Operational Requirements
To ensure effective and independent functioning, the committee requires:
* access to relevant governance, compliance, and audit documentation,
* clearly defined escalation and arbitration pathways,
* basic financial and organisational support to maintain independence and professional operation.
{% hint style="warning" %}
*This section might be updated based on the latest developments in the SAGE consortium, specifically considering the WP4 Governance working group. Since the project runs till 2028, the final GDDS deliverable is expected to have additional information on these sections. For example, governance bodies appointment, suggested procedures for voting etc.*
{% endhint %}