{
  "$schema": "./rulebook-index.schema.json",
  "id": "https://empower-x.io/rulebook/v1.0",
  "title": "EMPOWER-X Data Space Rulebook",
  "version": "1.0",
  "status": "draft",
  "generated": "2026-10-27",
  "owner": "EMPOWER-X Governance Authority (ZERTIFIER, during the pilot phase)",
  "humanReadable": "https://empower-x.io/rulebook",
  "precedence": "The human-readable Rulebook pages prevail over these files. The Technical Committee corrects the files within 30 days of any mismatch.",
  "referenceFramework": [
    "DSSC Blueprint",
    "CEN/CLC/TS 18331:2026",
    "Gaia-X Trust Framework (Loire)"
  ],
  "foundations": {
    "bindingText": "This Rulebook is the single, binding set of rules for operating and taking part in the EMPOWER-X energy data space. It follows the DSSC Rulebook model, CEN/CLC/TS 18331:2026 and the Gaia-X Trust Framework (Loire release).\n\n**Document control**\n\n| Item | Value |\n|---|---|\n| Version | 1.0 |\n| Owner | EMPOWER-X Governance Authority (ZERTIFIER, during the pilot phase) |\n| Approval | Governance Authority, then ratified by the first General Assembly |\n| Applies from | Its publication on empower-x.io; transitional provisions below |\n| Review cycle | At least once a year, and whenever a change in law, in the Gaia-X Trust Framework or in a federation agreement requires it |\n| Reference framework | DSSC Blueprint; CEN/CLC/TS 18331:2026; Gaia-X Trust Framework (Loire) |\n\n**Purpose**\n\nThis Rulebook sets out who governs EMPOWER-X, who may take part and on which terms, and the business, legal, technical and trust rules that apply to every data and service exchange. Every participant accepts it by signing the Participation Agreement (R3.3).\n\n**Order of precedence**\n\nWhere rules conflict, the higher level prevails:\n\n1. Mandatory EU and national law.\n2. The Gaia-X Trust Framework and any federation agreement EMPOWER-X has signed (R6.4).\n3. This Rulebook and its annexes.\n4. The Participation Agreement.\n5. The terms, licence and policies attached to each individual offer.\n\nIndividual offers may add obligations but may not lower the protections set by levels 1 to 4.\n\n**Two formats, one Rulebook**\n\nThe Rulebook exists in a human-readable form (these web pages) and a machine-readable form (credential schemas, policy templates and validation rules, listed below and on Downloads). The human-readable text prevails if the two disagree; the Technical Committee then corrects the machine-readable form within 30 days.\n\n**How to read it**\n\nThe Rulebook has six chapters, one per DSSC maturity dimension:\n\n- R1 Governance: bodies, roles and the participation lifecycle.\n- R2 Business: value, use cases, funding and monitoring.\n- R3 Legal: regulations and agreements.\n- R4 Interoperability: architecture, data models, standards and exchange.\n- R5 Trust and data control: identity, access, usage, consent, traceability, compliance and security.\n- R6 Value creation: catalogues, publication, services, federation, community and satisfaction.\n\n**Scope, mission and principles**\n\nEMPOWER-X is a federated energy data space, a Gaia-X Lighthouse Project, for trusted sharing of data and services across energy, mobility and smart community contexts.\n\n**Mission**\n\nEnable municipalities, energy communities, energy and mobility operators, technology providers and citizens to share, certify and use energy data under their own control, in order to scale Positive Energy Districts and renewable energy communities.\n\n**Scope**\n\n| Dimension | In scope |\n|---|---|\n| Domains | Positive Energy Districts, renewable energy communities, electromobility, urban energy intelligence |\n| Assets | Datasets, algorithms and data services, compute resources |\n| Pilots | Rubí Positive Energy District pilot (DS4PED project) and further pilots approved by the Governance Board |\n| Geography | Organisations established in the EU/EEA; others by Governance Board decision |\n| Federation | Data spaces with which EMPOWER-X has a federation agreement (R6.4) |\n\nOut of scope: activities that require a licence as an energy market operator, trading of financial instruments, and any processing of personal data without a lawful basis.\n\n**Principles**\n\n1. **Data sovereignty.** Data holders decide who may use their data, for what and on which terms.\n2. **Truthfulness.** Everything EMPOWER-X publishes about offers, use and compliance reflects the platform as it is operated. Example records, test activity and planned features are never presented as real.\n3. **Interoperability and portability.** Open standards and open-source components; no lock-in to a single operator.\n4. **Trust by verification.** Participants and offers are backed by verifiable credentials checked against recognised trust anchors.\n5. **Openness and non-discrimination.** Any eligible organisation can join on the same published criteria.\n6. **Privacy by design.** Personal and household energy data leaves its holder only in aggregated or derived form, unless the data subject has consented.\n7. **Sustainability.** Rules support the energy transition and the long-term viability of the data space.\n\n**Definitions**\n\n| Term | Meaning |\n|---|---|\n| Participant | A legal person onboarded to EMPOWER-X with a valid Gaia-X participant credential and an EMPOWER-X membership credential. |\n| Offer | A dataset, algorithm or service published in the EMPOWER-X catalogue with its description, licence and policies. |\n| Data holder | The organisation that holds the rights to the data in an offer. It may publish the offer itself or authorise a provider to do so. |\n| Policy | The machine-readable access and usage conditions attached to an offer. |\n| Order | The act by which a consumer accepts an offer's terms and obtains access on the Ocean Enterprise infrastructure. It is recorded on the ledger. |\n| Completed use | An order followed by a successful download, service call or compute-to-data job. |\n| Compute-to-data | An access mode in which approved algorithms run where the data is held and only the results are returned. |\n| Federated offer | An offer published by another data space and visible in EMPOWER-X through a federation agreement. |\n| Production environment | The EMPOWER-X portal (portal.empower-x.io) and node (node.empower-x.io). |\n| Test activity | Orders, uses or records created by operators or providers to test the platform. |\n\n**Transitional provisions**\n\n1. Offers published before this Rulebook applies must pass the publication checklist within 60 days. Until then, offers without an approved licence show \"Licence pending\" under R3.4.\n2. Until the compute-to-data environment can block outbound internet access by default, each compute-to-data offer states whether outbound access is enabled and accepts only approved algorithms.\n3. Until the EMPOWER-X membership credential is issued to all participants, the Participants and Restricted access levels are enforced by allow lists.\n4. The first General Assembly takes place within 6 months of publication and ratifies this Rulebook.\n\n**Machine-readable artefacts**\n\n| Artefact | Purpose |\n|---|---|\n| Gaia-X credential schemas (Loire) | Participant and service offering credentials |\n| EMPOWER-X membership credential schema | Role and status of participants |\n| Credential status list | Revocation checks |\n| Access policy templates and ODRL mapping | One template per access level in R5.2 |\n| Offer metadata profile (DCAT-AP and Ocean Enterprise DDO) | Validation at publication |\n| Approved data models and reference datasets | Technical annex in R4.2 |\n| Conformance test package and latest results | R5.6 |\n| Implementation status of each rule in R5.6 | Updated with each platform release |\n\nThe artefacts are versioned together with this Rulebook and listed on Downloads."
  },
  "chapters": [
    {
      "id": "R1",
      "title": "Governance",
      "blueprintDimension": "Governance",
      "topics": [
        {
          "id": "R1.1",
          "title": "Model and phases",
          "inShort": "EMPOWER-X is governed at two levels: rules shared with Gaia-X and federated data spaces, and its own bodies for everything specific to energy. The model evolves in three phases.",
          "bindingText": "EMPOWER-X is governed at two levels: rules shared with Gaia-X and federated data spaces for cross-data-space interoperability, and EMPOWER-X's own bodies for everything specific to the energy data space.\n\n**Organisational form and its evolution**\n\n| Phase | Model | Governance Authority | Moves to the next phase when |\n|---|---|---|---|\n| 1. Pilot (current) | Leadership: the coordinator governs, advised by participants | ZERTIFIER | At least 10 participants outside the founding consortium, and a funding plan for operations |\n| 2. Growth | Shared: the Governance Board includes elected participant seats | ZERTIFIER with the Governance Board | Operating revenue covers at least half of running costs |\n| 3. Sustainable operation | Neutral coordination body | An independent legal entity (association or foundation) | — |\n\nThe General Assembly decides each move between phases on a proposal of the Governance Board.\n\n**Governance Authority**\n\nThe Governance Authority maintains this Rulebook, runs onboarding and offboarding, keeps the participant registry, decides on sanctions within its remit, mediates disputes and represents EMPOWER-X externally. It publishes its decisions to participants.",
          "page": "/rulebook/r1#r1-1"
        },
        {
          "id": "R1.2",
          "title": "Bodies and decisions",
          "inShort": "Four bodies, and simple decision rules published in advance.",
          "bindingText": "**Bodies**\n\n| Body | Members | Main responsibilities | Meets |\n|---|---|---|---|\n| General Assembly | All participants, one vote each | Ratifies the Rulebook and major changes, the fee schedule and phase changes | At least yearly |\n| Governance Board | 5 members: the Governance Authority, 2 data-provider seats, 1 consumer or service-provider seat, 1 municipality seat | Operational decisions, admissions, suspensions, proposals to change the Rulebook | Quarterly |\n| Technical Committee | Operator, node operators, technical leads of participants | Technical annex, data models, policies, conformance tests | Monthly |\n| Legal and Ethics Advisory Group | Legal and data-protection representatives of participants | Regulatory watch, agreement templates, data-protection and ethics review | Twice a year and on request |\n\nDuring phase 1, the Governance Authority fills Governance Board seats by invitation from among the use-case participants.\n\n**Decision making**\n\n- Ordinary decisions: simple majority of members present, with a quorum of half the members.\n- Major decisions (Rulebook changes affecting rights or obligations, fees, expulsions): two-thirds of the Governance Board, then ratification by the General Assembly.\n- The Governance Authority may block only decisions that would breach the law or the Gaia-X Trust Framework, and must explain why in writing.\n- Decisions and minutes are published to participants within 15 days.",
          "page": "/rulebook/r1#r1-2"
        },
        {
          "id": "R1.3",
          "title": "Roles",
          "inShort": "Nine roles. One organisation can hold several, and each carries its own obligations.",
          "bindingText": "**Roles and responsibilities**\n\nOne organisation may hold several roles; each role carries its own obligations.\n\n| Role | Who (current) | Main obligations |\n|---|---|---|\n| Governance Authority | ZERTIFIER | See R1.1 |\n| Data space operator | ZERTIFIER, operating the EMPOWER-X portal and node on the Zertipower multi-tenant platform | Runs the portal, catalogue, node and shared services; keeps production and test environments separate; reports real activity only |\n| Technology provider | ZERTIFIER, building on the open-source Ocean Enterprise stack | Maintains components; applies secure defaults; discloses security issues |\n| Data provider | Approved data providers, listed in the participant registry | Publishes accurate offers with an approved licence; holds the right to share; keeps personal-data processing lawful |\n| Data consumer | Any participant | Uses data only within the offer's licence, policy and stated purpose |\n| Service provider | Developers of algorithms and data services | Describes services accurately; respects compute-to-data limits |\n| Compute provider | Operators of compute-to-data environments | Runs approved algorithms only; keeps network and data isolation as required by R5.3 |\n| Trust anchor | Gaia-X trust anchors and Gaia-X Digital Clearing Houses | Verify identities and validate credentials |\n| Federation partner | Data spaces with a federation agreement (R6.4) | Apply their own rules to their offers; honour the federation agreement |",
          "page": "/rulebook/r1#r1-3"
        },
        {
          "id": "R1.4",
          "title": "Participation lifecycle",
          "inShort": "Any legal person meeting the published criteria may join, and may leave at any time. The how-to is under Join; this topic holds the rules.",
          "bindingText": "*As proposed for amendment: automatic admission. Pending adoption by the Governance Board.*\n\nAny legal person meeting the criteria below may join; admission is decided on these published criteria only.\n\n**Eligibility**\n\n1. Legal person established in the EU/EEA, or admitted by Governance Board decision, with an identity verifiable in an official register.\n2. A valid Gaia-X participant credential (R5.1).\n3. Activity related to the scope in Foundations, contributing to an existing use case or proposing a new one.\n4. Ability to meet the technical requirements of R4 for the role requested.\n5. No expulsion from EMPOWER-X or another Gaia-X data space in the previous two years.\n\n**Onboarding**\n\nJoining takes four steps in the portal:\n\n1. **Create an account.** A representative of the applicant registers with a name and work email.\n2. **Add the organisation.** Legal name, registration number, address and the roles requested. The organisation presents Gaia-X participant credentials (legal participant, registration number, terms and conditions) validated by a Gaia-X Digital Clearing House, or obtains them with the portal's help, and registers its DID and wallet.\n3. **Accept the Participation Agreement.**\n4. **Get started.** When the identity, credential and eligibility checks pass, admission is automatic: the operator issues the EMPOWER-X membership credential and portal access opens.\n\nIf a check fails or needs judgement, the Governance Authority decides and gives written reasons. A refusal can be appealed to the Governance Board.\n\nAfter joining, the operator helps providers publish a first offer that passes the publication checklist and helps consumers complete a first use. Thirty days after activation, the participant receives the onboarding survey (R6.6).\n\n**Ongoing obligations**\n\n- Keep credentials and offer descriptions current; report changes in legal, technical or organisational details within 30 days.\n- Comply with this Rulebook and with the licence and policy of every offer used.\n- Take part in audits, conformance tests and incident handling when asked.\n\n**Offboarding**\n\n1. A participant may leave at any time with 30 days' written notice.\n2. On leaving, its offers are unpublished, its EMPOWER-X membership credential is revoked, and orders in progress are completed or cancelled as their terms provide.\n3. Data received under a licence that requires deletion on exit is deleted, and deletion is confirmed in writing within 30 days.\n4. Confidentiality, usage restrictions on data already received and liability for past acts survive offboarding.\n5. Departing participants receive the exit survey (R6.6).",
          "page": "/rulebook/r1#r1-4",
          "machineReadable": [
            "credentials/gaia-x-credential-profile.json",
            "credentials/membership-credential.schema.json"
          ],
          "status": "Onboarding rule as proposed for amendment (automatic admission); pending adoption by the Governance Board"
        },
        {
          "id": "R1.5",
          "title": "Breaches and sanctions",
          "inShort": "Three levels of breach, each with a proportionate measure. You are always heard first, unless immediate suspension is needed to prevent harm.",
          "bindingText": "**Suspension and sanctions**\n\n| Breach | Measure | Decided by |\n|---|---|---|\n| Minor (late credential update, incomplete offer description) | Written notice with 30 days to remedy; affected offers hidden until fixed | Governance Authority |\n| Serious (use outside licence or policy, false statements in credentials or offers, repeated minor breaches) | Suspension of publishing or ordering rights | Governance Authority, confirmed by the Governance Board within 10 days |\n| Grave (unlawful processing, security attack, fraud) | Immediate suspension, then expulsion and credential revocation | Governance Board, two-thirds majority |\n\nThe participant is heard before any decision, except where immediate suspension is needed to prevent harm.",
          "page": "/rulebook/r1#r1-5"
        },
        {
          "id": "R1.6",
          "title": "Changing the Rulebook",
          "inShort": "Anyone can ask for a change. Minor changes are decided by the Governance Board. Major ones go to a 30-day consultation and then to the General Assembly.",
          "bindingText": "**Rulebook change management**\n\n1. Any participant or body may submit a change request through the support channel.\n2. The Governance Board classifies it as minor (editorial, technical annex) or major (rights, obligations, fees, governance).\n3. Major changes go to a 30-day consultation of participants in the portal.\n4. The Governance Board decides minor changes; the General Assembly ratifies major ones.\n5. The Technical Committee updates the machine-readable artefacts in the same release.\n6. Each release gets a version number and a changelog. Changes apply 30 days after publication unless the law requires sooner.\n7. A participant who does not accept a major change may leave without penalty under R1.4.\n\n**Size-adapted governance**\n\nThe Governance Board reviews every year whether the bodies, processes and support in this Rulebook still fit the number and type of participants, and proposes changes through R1.6.",
          "page": "/rulebook/r1#r1-6"
        },
        {
          "id": "R1.7",
          "title": "Support",
          "inShort": "One support channel, with published response times.",
          "bindingText": "**Support for participants**\n\n- **Helpdesk:** a single support channel, shown on Community; first response within 2 working days, within 4 working hours for incidents blocking production use.\n- **Documentation:** guides for onboarding, publishing, ordering and compute-to-data, kept current with each platform release.\n- **Test environment:** a separate test network where participants can try publishing and ordering without affecting production records.\n- **Onboarding sessions:** group sessions for municipalities and energy communities at least twice a year.\n- **Rulebook help:** every Rulebook page opens with a plain-language summary and says who it applies to.",
          "page": "/rulebook/r1#r1-7"
        }
      ]
    },
    {
      "id": "R2",
      "title": "Business",
      "blueprintDimension": "Business",
      "topics": [
        {
          "id": "R2.1",
          "title": "Value and goals",
          "inShort": "EMPOWER-X turns local energy data into decisions and services that raise renewable self-consumption, support energy communities and fight energy poverty, while each data holder keeps control of its data.",
          "bindingText": "**Business goal**\n\nEMPOWER-X turns local energy data into decisions and services that increase renewable self-consumption, support energy communities and fight energy poverty, while each data holder keeps control of its data.\n\n**Value for each participant**\n\n| Participant | Value from taking part |\n|---|---|\n| Municipalities | District-level energy insight for Positive Energy District planning and energy poverty measures, without centralising citizens' data |\n| Energy communities and producers | Traceable proof of renewable origin and new uses for surplus generation data |\n| DSOs and utilities | Forecasting and flexibility inputs; standardised exchange with communities and cities |\n| Mobility operators | Charging demand matched with local renewable supply |\n| Service and AI providers | Access to real energy data through compute-to-data and a channel to offer their services |",
          "page": "/rulebook/r2#r2-1"
        },
        {
          "id": "R2.2",
          "title": "Use cases and services",
          "inShort": "The Governance Authority keeps a public register of use cases and a catalogue of services, and reports every year on what is new.",
          "bindingText": "**Use case register**\n\nThe Governance Authority keeps the register of use cases shown on Use cases. Each entry states its goal, participants, data products, services and status. Current use cases include:\n\n| Use case | Participants | Data products and services |\n|---|---|---|\n| Rubí Positive Energy District | Rubí City Council and pilot partners | Municipal building consumption and generation datasets; district dashboards |\n| Solar surplus to electric-vehicle charging | Energy communities and a mobility operator | PV surplus and charging datasets; PV-to-EV Matcher algorithm |\n| Energy dashboards as a service | Data providers and municipalities | Dashboard generator service |\n\n**New services**\n\nAny participant may propose a new value-creation service built on shared data. The Technical Committee checks it against chapters R4 to R6 before it is listed in the service catalogue. The Governance Authority reports every year on new services and offers that arose beyond the initial use cases.",
          "page": "/rulebook/r2#r2-2"
        },
        {
          "id": "R2.3",
          "title": "Funding and pricing",
          "inShort": "Free during the pilot. Fees come later, only after participants have voted them and been told 60 days ahead.",
          "bindingText": "**Funding**\n\n- **Pilot phase:** EMPOWER-X is funded by its coordinator and by public research and innovation funding. Participation is free of charge.\n- **Operational phases:** EMPOWER-X will be funded by a combination of membership fees, a share of paid transactions and operator services (hosting, compute, onboarding support).\n- Fees apply only once a fee schedule has been adopted by the General Assembly and published at least 60 days in advance. No fee applies retroactively.\n\n**Pricing**\n\nProviders set the prices of their offers, including free offers. While settlement runs on a test network (R5.5), no real payments take place and prices are indicative.",
          "page": "/rulebook/r2#r2-3"
        },
        {
          "id": "R2.4",
          "title": "Measuring the business model",
          "inShort": "Six indicators, tracked every quarter and reported every year. The Governance Board reviews the business model against them every year.",
          "bindingText": "**Monitoring the business model**\n\nThe Governance Authority tracks the indicators below every quarter and reports them to participants every year. The Governance Board reviews the business model every year against them and proposes changes to the General Assembly.\n\n| Indicator | Definition |\n|---|---|\n| Active participants | Participants with at least one publication or completed use in the quarter |\n| Offers | Offers in the production catalogue, own and federated counted separately |\n| Completed uses | Completed uses by consumers other than the provider, test activity excluded |\n| New services | Services and offers added beyond the initial use cases |\n| Participant satisfaction | Results of the surveys in R6.6 |\n| Cost coverage | Share of running costs covered by operating revenue |",
          "page": "/rulebook/r2#r2-4"
        }
      ]
    },
    {
      "id": "R3",
      "title": "Legal",
      "blueprintDimension": "Legal",
      "topics": [
        {
          "id": "R3.1",
          "title": "Regulations that apply",
          "inShort": "Each participant is responsible for its own legal compliance. EMPOWER-X sets rules and tools that make compliance easier, and checks them where it can.",
          "bindingText": "Each participant is responsible for its own legal compliance. EMPOWER-X sets rules and tools that make compliance easier and checks them where it can.\n\n**Regulations, triggers and requirements**\n\n| Regulation | Triggered when | Requirement in EMPOWER-X |\n|---|---|---|\n| GDPR | An offer contains or derives from data about an identifiable person (smart meters, charging sessions, households) | Personal-data flag on the offer; lawful basis held by the data holder; compute-to-data or aggregation by default; DPIA where required |\n| Data Governance Act | A participant offers data intermediation services, or public-sector data under protection is reused | Neutrality and notification duties for intermediaries; conditions for reuse of protected public data |\n| Data Act | A user requests data generated by a connected product (meter, charger, inverter), or a participant provides data processing services | Support for user access and sharing requests; switching and portability; fair contractual terms |\n| Electricity Directive (EU) 2019/944 and national transposition | Metering and consumption data, or energy communities, are involved | Respect eligible-party access rules and DSO neutrality |\n| NIS2 | A participant is an essential or important entity in the energy sector | Security measures and incident reporting by that participant |\n| AI Act | An AI system is offered as a service | Provider classifies the system and supplies the required documentation |\n| Open Data Directive and Spanish reuse law | Public-sector bodies publish data | Reuse conditions and licences compatible with public-sector rules |\n| Spanish data protection law (LOPDGDD) | Personal data of individuals in Spain | Spanish-specific requirements on top of the GDPR |",
          "page": "/rulebook/r3#r3-1"
        },
        {
          "id": "R3.2",
          "title": "Compliance mechanisms",
          "inShort": "Compliance is checked at four moments, not once.",
          "bindingText": "**Compliance mechanisms**\n\n- **At onboarding:** credential validation and the eligibility check (R1.4).\n- **At publication:** the publication checklist, including licence, personal-data flag and access mode.\n- **Continuously:** credential status checks before each order, and the conformance tests in R5.6.\n- **Periodically:** a quarterly review of the catalogue and a yearly regulatory watch by the Legal and Ethics Advisory Group, which updates the table in R3.1.",
          "page": "/rulebook/r3#r3-2"
        },
        {
          "id": "R3.3",
          "title": "Agreements",
          "inShort": "Three agreements put the Rulebook into effect.",
          "bindingText": "Three agreements put this Rulebook into effect. The Participation Agreement is public on Downloads; the other templates are available to members.\n\n**Participation Agreement**\n\nSigned by each participant with the Governance Authority. It binds the participant to this Rulebook and sets the term, termination, liability and fees (when applicable).\n\n**Service Provisioning Agreement**\n\nApplies to algorithms, compute and other services. It adds a service description, service levels, support and limits of liability. Its standard terms are shown with each service in the service catalogue.",
          "page": "/rulebook/r3#r3-3"
        },
        {
          "id": "R3.4",
          "title": "Licences and data sharing",
          "inShort": "Every offer carries a licence the data holder has approved in writing. Without one, the offer is marked \"Licence pending\".",
          "bindingText": "**Data sharing: licence and offer terms**\n\n1. Every offer carries a licence approved in writing by the data holder. The licence states what the consumer may do with the data, for how long, and whether onward sharing is allowed.\n2. A privacy policy is not a licence. A link to a privacy policy, or to any document that does not grant usage rights, does not meet this rule.\n3. The licence link must open publicly from the internet. Internal network addresses and test domains are not accepted.\n4. Providers should use a standard licence (for example CC BY 4.0, CC0 or ODbL) or the EMPOWER-X standard data licence template. Bespoke licences are allowed if they are complete and approved by the data holder.\n5. Until the data holder has approved a licence, the offer shows the status \"Licence pending\" and may be used only by parties already authorised by the data holder (for example pilot partners).\n6. Ordering an offer is acceptance of its licence and policy, and forms the data sharing agreement between provider and consumer.\n\n**Transitional rule**\n\nOffers published before this Rulebook applies must pass the publication checklist within 60 days. Until then, offers without an approved licence show \"Licence pending\" under R3.4.",
          "page": "/rulebook/r3#r3-4",
          "machineReadable": [
            "offers/offer-profile.shacl.ttl"
          ]
        },
        {
          "id": "R3.5",
          "title": "Liability, IP and disputes",
          "inShort": "Each participant answers for its own acts. Publishing an offer transfers no ownership. Disputes go through three steps.",
          "bindingText": "**Liability, intellectual property and confidentiality**\n\n- Each participant is liable for its own acts and for the accuracy of its credentials and offers.\n- The Governance Authority and the operator are liable only for running the shared services with reasonable care, not for the content of offers.\n- Publishing an offer transfers no ownership. Results of compute-to-data jobs belong to the consumer unless the licence says otherwise.\n- Participants keep confidential any non-public information learned through EMPOWER-X.\n\n**Dispute resolution**\n\n1. Negotiation between the parties for 30 days.\n2. Mediation by the Governance Authority, or by an independent mediator when the Governance Authority is a party.\n3. If unresolved, the courts of the registered office of the Governance Authority, under Spanish law, unless mandatory law provides otherwise.\n\nThe Governance Authority keeps an anonymised register of disputes and their outcomes, used to improve this Rulebook.",
          "page": "/rulebook/r3#r3-5"
        }
      ]
    },
    {
      "id": "R4",
      "title": "Interoperability",
      "blueprintDimension": "Interoperability",
      "topics": [
        {
          "id": "R4.1",
          "title": "Reference architecture",
          "inShort": "Participants, portal, provider node, trust services and federated data spaces, and how they fit together.",
          "bindingText": "**Reference architecture**\n\nParticipants work through the EMPOWER-X portal. Publication, ordering and compute-to-data run on the Ocean Enterprise node, and identities are checked against Gaia-X trust services. Federated data spaces exchange catalogues and orders under federation agreements.",
          "page": "/rulebook/r4#r4-1"
        },
        {
          "id": "R4.2",
          "title": "Data models and reference datasets",
          "inShort": "Offers say which data model and version they use, so a consumer knows what it will receive before ordering.",
          "bindingText": "**Data models and reference datasets**\n\n- Offers use the data models adopted by the Technical Committee and published in the technical annex. For energy data these are based on SAREF4ENER, IEC CIM and the Smart Data Models energy domain; for municipal and district data, on the OASC Minimal Interoperability Mechanisms.\n- Offers state the model and version they use. Where no adopted model fits, the provider documents its schema in the offer.\n- Common reference datasets are used for codes and units: EU NUTS and LAU codes for territories, SI units, and the code lists listed in the technical annex.\n\n**Data model governance**\n\nThe Technical Committee keeps the list of adopted models and reference datasets, versions it, and announces breaking changes at least 90 days ahead. Participants propose new models or versions through the change process in R1.6.",
          "page": "/rulebook/r4#r4-2",
          "machineReadable": [
            "data-models/data-models.json"
          ]
        },
        {
          "id": "R4.3",
          "title": "Open standards",
          "inShort": "Open standards for identity, catalogue, policies and exchange, so nothing locks a participant in.",
          "bindingText": "**Open standards**\n\n| Area | Standard |\n|---|---|\n| Identity | W3C Decentralized Identifiers; W3C Verifiable Credentials; Gaia-X Trust Framework ontology |\n| Catalogue | DCAT-AP, in the version adopted by the Technical Committee, alongside Ocean Enterprise metadata (DDO) |\n| Policies | Machine-readable policies expressible in ODRL 2.2 (R5.2) |\n| Data exchange | Ocean Enterprise provider and compute-to-data APIs; Dataspace Protocol for exchanges with EDC-based data spaces through partner connectors |\n| Data models | As in R4.2 |",
          "page": "/rulebook/r4#r4-3",
          "machineReadable": [
            "offers/offer-profile.shacl.ttl",
            "policies/"
          ]
        },
        {
          "id": "R4.4",
          "title": "Data exchange and APIs",
          "inShort": "Inside EMPOWER-X, you order on the ledger and the provider node grants access. There is no separate contract negotiation, because the terms are fixed in the offer.",
          "bindingText": "**Data exchange protocol and APIs**\n\n- Inside EMPOWER-X, exchanges follow the Ocean Enterprise protocol: a consumer orders an offer on the ledger, and the provider node grants access (download, service call or compute-to-data job) after checking the order and the policy.\n- Ocean Enterprise has no separate contract-negotiation step: the terms are fixed in the offer and accepted with the order.\n- Exchanges with data spaces built on Eclipse Dataspace Components (EDC) use the Dataspace Protocol, including its contract negotiation, through connectors operated by the partners involved. These exchanges are documented separately and are not recorded as EMPOWER-X marketplace orders.",
          "page": "/rulebook/r4#r4-4"
        }
      ]
    },
    {
      "id": "R5",
      "title": "Trust and data control",
      "blueprintDimension": "Control over data and trust",
      "topics": [
        {
          "id": "R5.1",
          "title": "Identity and trust",
          "inShort": "Every participant and every offer has a verifiable identity, checked against recognised trust anchors.",
          "bindingText": "**Identity**\n\n- Every participant is identified by a W3C Decentralized Identifier linked to its legal registration. Organisations use did:web on a domain they control.\n- Every offer is identified by its own DID and signed by its provider.\n- Credentials are hosted on production domains. Credentials on test domains are accepted only during onboarding.\n\n**Credentials**\n\n| Credential | Issued or validated by | Checked at |\n|---|---|---|\n| Gaia-X legal participant (Loire) | Participant, validated by a Gaia-X Digital Clearing House | Onboarding; publication |\n| Gaia-X legal registration number | Notarised by a Gaia-X Digital Clearing House | Onboarding |\n| Gaia-X terms and conditions | Participant | Onboarding |\n| EMPOWER-X membership credential (role, status) | Governance Authority | Each order on restricted offers |\n| Service offering credential | Provider, validated by a Gaia-X Digital Clearing House | Publication |\n\nCredentials follow the W3C Verifiable Credentials data model and are presented as Verifiable Presentations.\n\n**Trust anchors**\n\nEMPOWER-X recognises the trust anchors and Gaia-X Digital Clearing Houses listed in the Gaia-X Registry. The Governance Board may recognise further anchors; the list is published and reviewed every year.\n\n**Participant registry and revocation**\n\n- The operator keeps a registry of participants, their roles and the status of their credentials, published to participants.\n- Revoked or expired credentials are recorded in a status list checked before orders on restricted offers.\n- If a trust anchor or Gaia-X revokes a participant's keys, EMPOWER-X suspends that participant until the issue is resolved.",
          "page": "/rulebook/r5#r5-1",
          "machineReadable": [
            "credentials/gaia-x-credential-profile.json",
            "credentials/membership-credential.schema.json",
            "credentials/status-list.example.json"
          ]
        },
        {
          "id": "R5.2",
          "title": "Access control",
          "inShort": "Each offer has exactly one access level, set by the data holder, and the node must really enforce it.",
          "bindingText": "**Access levels**\n\nEach offer has exactly one access level, set by the data holder:\n\n| Level | Who may order | How it is enforced |\n|---|---|---|\n| Open | Any wallet | No restriction |\n| Participants | Holders of a valid EMPOWER-X membership credential | Credential check by the provider node |\n| Restricted | Named participants or roles chosen by the data holder | Allow list or credential check by the provider node |\n| Compute-to-data only | As one of the levels above, but raw data never leaves the provider | Compute-to-data environment (R5.3) |\n\n**One source of truth**\n\n1. The access level and policy published with the offer on the production node are the only authoritative ones. Exports, spreadsheets and documents do not override them.\n2. An offer may be labelled Participants or Restricted only if the provider node actually enforces that level. Labels that are not enforced are not allowed.\n3. Policies are expressed so that they can be represented in ODRL 2.2. Where the enforcement engine uses another policy language, the Technical Committee keeps a tested mapping to ODRL and publishes it with the machine-readable artefacts on Downloads.\n\n**Transitional rule**\n\nUntil the EMPOWER-X membership credential is issued to all participants, the Participants and Restricted access levels are enforced by allow lists.",
          "page": "/rulebook/r5#r5-2",
          "machineReadable": [
            "policies/"
          ]
        },
        {
          "id": "R5.3",
          "title": "Usage control and compute-to-data",
          "inShort": "What you may do with data after access is set in the licence. Compute-to-data enforces it technically. Everything else is enforced by contract and sanctions.",
          "bindingText": "**Usage control**\n\nUsage conditions (purpose, duration, onward sharing, deletion, attribution) are set in the licence. Compute-to-data enforces them technically by never releasing raw data. Other conditions are enforced contractually and through the sanctions in R1.5.\n\n**Compute-to-data safeguards**\n\n1. Each compute-to-data offer lists the algorithms approved to run on it. Accepting any algorithm is allowed only for offers whose data is open.\n2. Algorithm jobs must not have outbound internet access, unless the data holder has approved it for that offer and the offer says so.\n3. Results must not allow re-identification of individuals or reconstruction of the raw data. Household-level data is aggregated to at least 10 households unless the data subjects have consented otherwise.\n\n**Transitional rule**\n\nUntil the compute-to-data environment can block outbound internet access by default, each compute-to-data offer states whether outbound access is enabled and accepts only approved algorithms.",
          "page": "/rulebook/r5#r5-3",
          "machineReadable": [
            "policies/compute-to-data.odrl.json"
          ]
        },
        {
          "id": "R5.4",
          "title": "Consent",
          "inShort": "Where consent is the lawful basis, people can see it and withdraw it, and sharing stops within 72 hours of withdrawal.",
          "bindingText": "**Consent**\n\n- Where consent is the lawful basis, the participant collecting it records it in a tool that lets the data subject see and withdraw it. Withdrawal stops further sharing within 72 hours.\n- Offers based on consent carry the personal-data flag and reference the consent record.\n- Data subjects' requests under the GDPR or the Data Act are handled by the data holder within the legal deadlines; EMPOWER-X forwards any request it receives within 5 working days.",
          "page": "/rulebook/r5#r5-4"
        },
        {
          "id": "R5.5",
          "title": "Provenance, traceability and reporting",
          "inShort": "You can see where data comes from, who ordered it, and that what EMPOWER-X reports is real.",
          "bindingText": "**Provenance**\n\nEach offer records its source, data holder, processing steps and version. Derived offers reference the offers they come from.\n\n**Traceability**\n\nEvery order is recorded on the ledger with a transaction identifier that the parties and the Governance Authority can verify. Compute-to-data jobs keep a log of the algorithm, dataset and result delivered.\n\n**Reporting real activity only**\n\n1. Statistics that EMPOWER-X reports (offers, orders, completed uses), to participants, funders or evaluators, come only from records that can be verified on the ledger or in node logs.\n2. Test activity is labelled as such and excluded from statistics.\n3. Example records and placeholder counters are never published in the production catalogue.\n4. Federated offers and their use are reported separately and are never counted as EMPOWER-X's own.\n\n**Networks**\n\nOrders currently settle on a test network using test tokens, so no real-money transactions take place. The move to a production network is decided by the Governance Board after technical validation, and announced at least 30 days in advance.\n\n**Observability of agreements**\n\nProviders can see, for each of their offers, the orders received, the licence accepted and the uses completed. Consumers can see their orders and the licence that applies to each.",
          "page": "/rulebook/r5#r5-5"
        },
        {
          "id": "R5.6",
          "title": "Compliance checks and tests",
          "inShort": "Rules are checked automatically where possible, by people where not, and tested before every release.",
          "bindingText": "**Systematic compliance checks**\n\n| When | What is checked | By |\n|---|---|---|\n| Onboarding | Identity, credentials, eligibility | Governance Authority, Gaia-X Digital Clearing House |\n| Publication | Publication checklist | Operator |\n| Each order on restricted offers | Membership credential and status list | Provider node |\n| Quarterly | Whole production catalogue against the publication checklist; licence links; statistics against ledger records | Operator, reported to the Governance Board |\n| Yearly | Credential validity of all participants; regulatory watch | Governance Authority, Legal and Ethics Advisory Group |\n\n**Technical enforcement**\n\n| Rule | Where | Enforced by |\n|---|---|---|\n| Only identified legal persons participate | R1.4, R5.1 | Gaia-X credential validation |\n| Access level is respected | R5.2 | Provider node (allow lists, credential checks) |\n| Raw data does not leave compute-to-data offers | R5.3 | Compute-to-data environment |\n| Only approved algorithms run | R5.3 | Approved-algorithm list on the offer |\n| Revoked participants cannot order restricted offers | R5.1 | Status list check |\n| Orders are traceable | R5.5 | Ledger |\n\nThe Technical Committee keeps the implementation status of each rule up to date with each platform release.\n\n**Conformance tests**\n\nBefore a platform release and after any change to access control, the Technical Committee runs an end-to-end test package and keeps the results:\n\n1. A permitted case: an authorised consumer orders and uses an offer.\n2. A denied case: an unauthorised consumer is refused.\n3. A revocation case: a permission or credential is withdrawn and access is then refused.\n4. A federation case: an order and use across a federated data space.",
          "page": "/rulebook/r5#r5-6",
          "machineReadable": [
            "tests/conformance-tests.yaml",
            "status/implementation-status.json"
          ]
        },
        {
          "id": "R5.7",
          "title": "Security and incidents",
          "inShort": "Secure defaults, separate environments, and a 24-hour clock for reporting problems.",
          "bindingText": "**Service levels**\n\nThe operator aims for 99% monthly availability of the portal and node, excluding announced maintenance, and publishes maintenance windows at least 3 working days in advance.\n\n**Security**\n\n- The operator applies secure defaults to all components and reviews them at each release.\n- Production and test environments are kept separate.\n- Participants protect their keys; loss or compromise is reported within 24 hours.\n- Energy-sector participants subject to NIS2 also meet their own obligations.\n\n**Incidents**\n\n1. Participants report security incidents and suspected breaches of this Rulebook to the operator within 24 hours of becoming aware.\n2. The operator contains the incident and informs affected participants.\n3. Personal-data breaches are notified by the responsible controller; NIS2 incidents by the entity concerned.\n4. A post-incident report goes to the Governance Board, with any changes needed to this Rulebook.",
          "page": "/rulebook/r5#r5-7"
        }
      ]
    },
    {
      "id": "R6",
      "title": "Value creation",
      "blueprintDimension": "Value creation",
      "topics": [
        {
          "id": "R6.1",
          "title": "Catalogues",
          "inShort": "Two catalogues, one for data and one for services, searchable in the portal and readable by machines.",
          "bindingText": "**Catalogues**\n\n- **Data catalogue:** all offers, searchable in the portal and available in machine-readable form (DCAT-AP and Ocean Enterprise metadata).\n- **Service catalogue:** algorithms and value-creation services, with their service terms.\n- Federated offers are shown with their data space of origin and are clearly separated from EMPOWER-X's own offers.\n\n**What every offer must contain**\n\nTitle and description; data holder and provider; licence (R3.4); access level (R5.2); personal-data flag; data model and version; update frequency; known limitations; for algorithms, the input they expect and what they return. The 12-point checklist on Publish an offer turns this into checks.",
          "page": "/rulebook/r6#r6-1",
          "machineReadable": [
            "offers/offer-profile.shacl.ttl"
          ]
        },
        {
          "id": "R6.2",
          "title": "Publication rules",
          "inShort": "Publish real things, once, pointing to production. The checklist on Publish an offer is how it is checked.",
          "bindingText": "**Publication rules**\n\n1. Offers in production point to production endpoints (node.empower-x.io), never to development or internal addresses.\n2. Each offer is published once in production. If an offer also exists on a test network, its description says which network each listing belongs to.\n3. Offers must describe real data or services. Example offers are published only in the test environment.\n4. The operator reviews new offers against that checklist within 5 working days and may hide offers that do not comply until they are fixed.",
          "page": "/rulebook/r6#r6-2",
          "machineReadable": [
            "offers/offer-profile.shacl.ttl"
          ]
        },
        {
          "id": "R6.3",
          "title": "Service management",
          "inShort": "Every service has a version, an owner and a support contact, and changes are announced in advance.",
          "bindingText": "**Service management**\n\nServices have a version, an owner and a support contact. Breaking changes are announced 30 days ahead; retired services stay listed as deprecated for 90 days.",
          "page": "/rulebook/r6#r6-3"
        },
        {
          "id": "R6.4",
          "title": "Federation",
          "inShort": "EMPOWER-X connects to another data space only under a written agreement, and keeps its offers separate.",
          "bindingText": "**Federation agreements**\n\nEMPOWER-X federates with another data space only under a written federation agreement, which covers at least:\n\n1. Mutual authorisation of nodes, so that each side's node is on the other's list of authorised nodes.\n2. Catalogue visibility in both directions, including any labels or filters needed for offers to appear.\n3. Recognition of each other's participant credentials, or the rules for cross-onboarding.\n4. Which rules, licences and support apply to each side's offers.\n5. A joint test that proves an order and use in each direction.\n\n**Federated offers**\n\n- Federated offers remain under the rules and licences of their data space of origin. EMPOWER-X does not change their licences or descriptions.\n- Federated offers, their orders and their tests are not counted as EMPOWER-X activity.\n- Problems with a federated offer are referred to the data space of origin.\n\n**Current federations**\n\nEMPOWER-X is federating with the SENSE data space. Federation is reported as bidirectional only once all elements of R6.4 are in place and confirmed in writing by both parties.",
          "page": "/rulebook/r6#r6-4"
        },
        {
          "id": "R6.5",
          "title": "Community and reuse",
          "inShort": "The list of participants and roles is shared with participants, the community meets at least once a year, and reuse of data is measured.",
          "bindingText": "**Community**\n\nThe Governance Authority keeps the list of participants and their roles available to participants, holds an open community meeting at least once a year, and invites participants to propose use cases and services.\n\n**Data reuse**\n\nThe Governance Authority reports every year how many offers are used by more than one consumer, as a measure of data reuse.",
          "page": "/rulebook/r6#r6-5"
        },
        {
          "id": "R6.6",
          "title": "Participant satisfaction",
          "inShort": "Four short surveys, and results that come back to participants with an action plan.",
          "bindingText": "**Participant satisfaction**\n\n| Survey | Sent to | When |\n|---|---|---|\n| Onboarding survey | New participants | 30 days after activation |\n| Use pulse | Consumers and providers | After a participant's first completed use, and at most once a quarter after that |\n| Annual survey | All participants | Every year before the General Assembly |\n| Exit survey | Departing participants | On offboarding |\n\nSurveys are sent automatically from the portal where possible, and answers are handled under the GDPR. Results are presented at the General Assembly together with an action plan, and the follow-up of that plan is reported the next year. Each survey is a short questionnaire sent from the portal.",
          "page": "/rulebook/r6#r6-6"
        }
      ]
    }
  ]
}