R5Trust and data control

Identity

• Every participant is identified by a W3C Decentralized Identifier linked to its legal registration. Organisations use did:web on a domain they control.
• Every offer is identified by its own DID and signed by its provider.
• Credentials are hosted on production domains. Credentials on test domains are accepted only during onboarding.

Credentials

Credentials follow the W3C Verifiable Credentials data model and are presented as Verifiable Presentations.

Trust anchors

EMPOWER-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.

Participant registry and revocation

• The operator keeps a registry of participants, their roles and the status of their credentials, published to participants.
• Revoked or expired credentials are recorded in a status list checked before orders on restricted offers.
• If a trust anchor or Gaia-X revokes a participant's keys, EMPOWER-X suspends that participant until the issue is resolved.

Access levels

Each offer has exactly one access level, set by the data holder:

One source of truth

1. 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.
2. 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.
3. 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.

Usage control

Usage 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.

Compute-to-data safeguards

1. 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.
2. Algorithm jobs must not have outbound internet access, unless the data holder has approved it for that offer and the offer says so.
3. 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.

Consent

• 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.
• Offers based on consent carry the personal-data flag and reference the consent record.
• 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.

Provenance

Each offer records its source, data holder, processing steps and version. Derived offers reference the offers they come from.

Traceability

Every 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.

Reporting real activity only

1. 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.
2. Test activity is labelled as such and excluded from statistics.
3. Example records and placeholder counters are never published in the production catalogue.
4. Federated offers and their use are reported separately and are never counted as EMPOWER-X's own.

Networks

Orders 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.

Observability of agreements

Providers 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.

Systematic compliance checks

Technical enforcement

The Technical Committee keeps the implementation status of each rule up to date with each platform release.

Conformance tests

Before a platform release and after any change to access control, the Technical Committee runs an end-to-end test package and keeps the results:

1. A permitted case: an authorised consumer orders and uses an offer.
2. A denied case: an unauthorised consumer is refused.
3. A revocation case: a permission or credential is withdrawn and access is then refused.
4. A federation case: an order and use across a federated data space.

Service levels

The 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.

Security

• The operator applies secure defaults to all components and reviews them at each release.
• Production and test environments are kept separate.
• Participants protect their keys; loss or compromise is reported within 24 hours.
• Energy-sector participants subject to NIS2 also meet their own obligations.

Incidents

1. Participants report security incidents and suspected breaches of this Rulebook to the operator within 24 hours of becoming aware.
2. The operator contains the incident and informs affected participants.
3. Personal-data breaches are notified by the responsible controller; NIS2 incidents by the entity concerned.
4. A post-incident report goes to the Governance Board, with any changes needed to this Rulebook.