DDSP

A Data Space for Ireland

The European Union’s data strategy rests on a simple idea: organisations should be able to share data with each other under controlled, auditable, policy-driven conditions. Not open data — that’s already solved. Controlled data: company registrations, health statistics, workplace safety records. Data that has value, sensitivity, and legal constraints on who can see what.

The Derilinx Data Space Platform (DDSP) is a working prototype of this idea, grounded in Irish public sector data. It connects three simulated base registries — the Companies Registration Office (CRO), the Central Statistics Office (CSO), and the Health and Safety Authority (HSA) — through a central platform that mediates every data request. Want CRO company data? You need an active data sharing agreement. The platform checks your agreement, evaluates the policy, fetches the data from the registry, filters it to only the fields you’re permitted to see, logs the access, and returns the result. Every step is auditable. Every field is controlled.

It’s not a portal. It’s not a database. It’s the infrastructure that makes data sharing governable.

A Supervised Playdate for Data

Imagine three children each have a box of toys. They’re allowed to share some toys with each other, but only certain ones, and a grown-up has to watch. The grown-up checks the sharing rules (“Alice can borrow the red car but not the blue train”), hands over only what’s allowed, and writes down everything that was shared. DDSP is the grown-up. The children are government agencies. The toys are data.

Policy-Driven Data Mediation

1. Onboard participants

Organisations register as providers (data sources) or consumers (data users). Each participant is linked to one or more registries. Registries define the data they hold and the schema it follows.

2. Establish agreements

A data sharing agreement between provider and consumer specifies: which registry, which fields the consumer may access, the purpose of access, rate limits (requests per hour), and validity period. Agreements follow a state machine: Draft → Pending → Active → Suspended or Terminated.

3. Query through the platform

The consumer sends a query to the platform’s REST API, identifying themselves and the target registry. The platform looks up the active agreement, checks rate limits, evaluates the ODRL policy, calls the registry’s adapter, fetches the raw data, filters it to permitted fields, logs the access, and returns the result.

4. Audit everything

Every access creates an immutable log entry: who requested what, when, which fields were returned, under which agreement. Denied requests are logged too, with the reason. The audit trail supports GDPR accountability and regulatory compliance.

5. Visualise

A control room frontend shows data flows in real time. Animated particles trace the path from consumer to platform to registry and back. A live feed shows each request as it happens. Chord diagrams summarise data flows between participants.

Governed Data Sharing

Revenue accessing company data

The Revenue Commissioners need company registration data from the CRO for tax compliance purposes. An agreement permits access to company name, registration number, and registered address — but not director names or share structure. The platform enforces this at query time, returning only the agreed fields.

CSO accessing workplace safety statistics

The Central Statistics Office needs HSA accident data for national statistics. Their agreement permits aggregated records but caps requests at 100 per hour. The platform rate-limits the CSO’s access and logs every query for the HSA’s audit trail.

Cross-registry analysis

A government analyst needs to correlate company registrations (CRO) with workplace accident reports (HSA). Separate agreements with each registry permit access to specific fields. The analyst queries both through the platform and joins the results locally. The platform never exposes fields beyond what each agreement permits.

EU data space compliance

An EU regulator asks Ireland to demonstrate compliance with the Data Governance Act. The platform’s audit logs provide a complete, timestamped record of every data access: who accessed what, under which agreement, for what stated purpose. Compliance is demonstrable, not promised.

Under the Bonnet

Architecture

Central platform (Django + DRF) mediates all data access. Three simulated base registries (CRO, CSO, HSA) each run as separate Django services with their own databases. Open Policy Agent (OPA) evaluates access policies. Keycloak handles identity (currently stubbed). React frontend for the control room visualisation.

Django apps

participants, registries, agreements, audit, connectors, api, dsp, events, demo, policies, catalogue. Each app is self-contained with models, serialisers, and views.

Agreements

State machine: Draft → Pending → Active → Suspended → Terminated. ODRL-based policies stored as JSON. Permitted fields list per agreement. Rate limits enforced via AccessLog counting.

DSP protocol

Implements Dataspace Protocol 2025-1: ContractNegotiation and TransferProcess state machines. Bridges DSP wire protocol to the internal agreement governance model.

Connectors

HTTP adapters translate platform queries to registry-specific API formats. Each registry can have a different API; the connector normalises the interface.

Frontend

React + TypeScript + Vite. MapLibre for network visualisation. D3.js for chord diagrams. Zustand for state management. Server-Sent Events for real-time feed. Speed control (0.25×–2×) and autoplay for demos.

Deployment

Docker Compose: 9 containers (platform, 3 registries, OPA, Keycloak, frontend, and 5 PostgreSQL databases). 119 passing tests. Open source, licence TBC.

Regulatory alignment

Data Governance Act (DGA), Data Act, Interoperable Europe Act, European Health Data Space (EHDS). Platform design follows DSSC toolbox recommendations.