Going in, I had many questions about federation. The Data Spaces Support Centre has a relatively expansive definition of federation, speaking in broad terms about aligned rules on governance, including shared trust frameworks and shared business interests. But this level of alignment seems unrealistic to me, or at least it’s unrealistic without a central driver of some kind to bring parties together.

And this was the goal of the role play that we would run—to understand whether and how federation would form when a fictional real-estate developer of a smart community would require access to data across multiple data spaces. Here’s a bit more information on how we set up the role play, but feel free to skip over the summary.

An in-built premise: a Member State would drive federation

An important component of the role play is that each actor in the play receives a briefing that outlines not just the scenario, but also their motivations. We, as the builders of the role play, try to accurately reflect the intrinsic motivations of each stakeholder, but we also provide individuals with enough incentives to move the scenario forward and potential conflict points to reveal frictions.

In this role play, we had actors from both the private and public sector, including two national governments, two privately oriented data spaces, one city (with both data and the land for the smart community), and one private-sector consultancy with expertise in data spaces. We expected that the mix of public and private goals and incentives for participating would reveal some of those important frictions. This is a tension that we see every day in projects funded by Horizon Europe. As such, it was pretty easy to write a briefing to bring these elements out.

What was not immediately clear was how to drive the discussion of federation forward. The use case around which we build the scenario provided the impetus to bring together disparate data sets that might benefit from a federation that eases burdens accessing data. But just because there is a reason for people to come together does not mean that going through the inevitable negotiations around federation would make sense. After all, the status quo of negotiating with individual data holders–a process that would still be necessary even when dealing with data spaces–is a viable option with less initial overhead.

After much thought and debate, our belief was that an individual Member State was the most likely to start a conversation around federation, at least within our scenario. And so, as a part of the briefings, we gave a Member State clear incentives to drive federation and to be seen as a leader. It was made clear that money was available. The smart community was described as a test case and part of a broader digitalisation drive for economic competitiveness, meaning there was also political capital to spend. It was hard to put more motivation in their to lead the case for federation, and the actor playing that role certainly tried their best to make the case.

But, the Member State never did get any traction for federation.

The private sector took the lead (eventually)

It was, in fact, the consultancy and the two private-sector data spaces that presented the more credible case for co-operation and started to talk in terms of signing deals–though this only took place after some hours of discussion and debate. Despite the clear incentives and motivations of the leading Member State, private actors wanted to see the national government only play a steering role, distributing resources rather than being an orchestrator or leader of the community.

Even the local government from the Member State did not become a natural ally for a public-sector driven solution. They did not pick up and support the national governments desire to lead, rather viewing them as one stakeholder of many, focusing on their own needs rather than national ones. This makes sense, too. At the end of the day, the public sector is not a monolithic entity, and there are always frictions between different governments, whether that be disagreements between national governments or disagreements between national and regional ones. And the local government was looking for the most viable solution that would protect its interests.

Why did the private sector lead?

Despite the briefings explicitly mentioning public-private partnership—and even an intervention where we made it all the more explicit that all actors had ‘honest intentions’ in the negotiation—there was an ongoing disconnect between the actors that were public and privately oriented. Public actors simply had larger and more complex motivations to participate, looking to not just offer data and services that the developer would need, but also wanting to ensure that a broader public good was met.

These wider interests led to discussions that were, for the real-estate developer, outside of the scope of their interest and sometimes even felt like they could be a distraction. Importantly, it also increased the number of problems that would need to be resolved before any work could begin. The narrower focus for the private-sector parties helped them to stay on a more focused path, which allowed them to progress more quickly and not get pulled into wider discussions about digital sovereignty, data rights, and other (legitimate) public interests.

An added wrinkle: the weak value proposition for federation (and data spaces in general?)

While six hours of role play did see some convergence, the players ultimately came to option 2, forgoing federation. One point that was made clear was that the value proposition for the federation (or even the data spaces) was weaker than expected—and this came down to a key legal point. While joining a data space created obligations for onboarding, it did not resolve a significant obstacle, namely the need to make agreements with each of the data holders within those data spaces. Some participants assumed that the negotiation was unnecessary, and that signing up for the data space meant that all data would become available. In some cases, it was suggested that the governance authorities of the data spaces could help facilitate those discussions, but given the nature of the data (which in many cases would be personal), any kind of generic agreement would not suffice.

Incomplete lessons: an n of 1 and letting it play longer

Of course, this is only a single exercise, and the role play could have played out for longer to understand better whether the Member State would accept a secondary role, helping to lay conditions to facilitate distrust between private actors that would undoubtedly come to the foreground the longer that a negotiation would take place. And of course, lessons here need to be put into a broader context of data spaces (and federations) of differing scopes and purposes. I would expect, for example, that if we ran a role play on digital product passports, where compliance to public sector requirements is a driving goal, that it would have led to a completely different dynamic. Nonetheless, in a context where private interests are a driving factor, the private sector seemed best placed to move things forward.

Next step: supplementing lessons with Agentic AI?

While it would have been great to have our actors for another day or two to continue the negotiation and see how the scenario would continue, people’s schedules (and perhaps energy levels) simply wouldn’t allow for it. It would also be helpful to run the scenario with different people to see if the same results would come about. While this does not seem to be a realistic option in a face-to-face setting, it doesn’t preclude using agentic AI–using our briefings for the appropriate prompts–to re-run the role play, tweaking the scenario and briefings to what changes it would bring about.

I’m currently using crewAI and have run the scenario once or twice using gpt-4o-mini to see what the result would be. I would hope my next post will address some of the results.

Now, does someone want to give me some tokens to play with?

Nonetheless, within the operational options that the DSSC blueprint provides, does it guide a data space to a clear pathway to build something operational and financially sustainable? For some of the potential options it provides, I would answer no. In fact, the organisational form of many data space initiatives—particularly those funded by the European Commission under Horizon Europe rules—make it particularly difficult to create a sustainable business model.

The problem for Horizon Europe funded data spaces is two-fold. First, Horizon Europe projects for data spaces are generally run under consortia agreements that are temporary in nature. The primary goal is not to make the data space a profitable or financially sustainable entity, but rather to further the goals of each entity involved in the project. Financial sustainability is an output (as symbolized by a work package) rather than a core goal.

Second, consortia are generally incapable of writing credible business plans unless there is a partner that is committed to take the assets created and making a business out of it, which needs to include some kind of commitment to future (capital) investment. Otherwise, any ‘sustainability plan’ is nothing more than an academic exercise when partners lack any kind of skin in the game.

The many options for the legal entity

In my last blog post, I mentioned how the DSSC describes different types of (legal) entities that could represent or be the data space. They provide a handy flow chart, which creators can follow to narrow down the options.

Ignoring the initial yes/no question of whether someone wants to build a data space (I would hope it’s yes if they’re reading the building block), the first question is whether the data space is a temporary or permanent entity. It’s on this distinction that I want to focus, because it helps to explain why data spaces funded by the European Union have such a difficult time sustaining themselves once funding expires.

The Consortium Conundrum

Many of the data spaces that receive Horizon Europe funding are consortia formed from disparate entities that have complementary skills to deliver on the objectives of a call. This is, as the flow chart outlines, a temporary entity that generally lasts as long as the funding from the European Commission is provided. Once the contract ends, so does the consortium agreement. Entities may continue to work with each other, sometimes even on projects of similar scope, but it will be under a new agreement, and not always with the same configuration of partners.

The DSSC is, in fact, a good example of this. The first iteration of the support centre is run by a consortium of organisations that includes research & technology organizations (RTOs), universities, associations, and private consultancies. They co-operate based on a consortium agreement and agree to work on deliverables as promised in a proposal. As DSSC winds down and a second iteration starts up, we see a new consortium with some of the old players, but not all of them, and a few new ones as well. The call changes, and as such, so does the consortium. There is limited organizational consistency between the two versions of the DSSC.

What happened with the DSSC is emblematic of a wider problem affecting many Horizon Europe data‑space consortia. Despite its successes, it also proved unwieldy as the needs of the data-space community shifted from inception to implementation.

This difficulty adjusting is, in fact, a feature of a consortium. They are inclusive and relatively painless to set up, but they can also be cumbersome, with major decisions requiring unanimous consent from diverse partners with different interests. This divergence of interests becomes less and less sustainable as time passes. Agility is not always a feature, particularly when a consortium is made up of many partners.

Consortia lack the organisational integrity to build a credible business model

Because consortia are temporary, project-driven entities, they lack the organisational integrity required to build a credible, long-term business model.

For example, the temporary nature of a consortia agreement raises a question of staff loyalty, and whether decisions are being taken for the good of a future data space’s business model, or whether decisions are being taken in the interests of the individual organisations that make up the consortium. The staff that are working for the data space are not employed by the data space itself, and as such, their loyalties lie with their home organization, and not the data space that they are supposed to represent. This creates, at best, instability, and at worst, conflicting incentives where the overall goals of the members take precedent over the needs of the data space itself.

This lack of organisational integrity can also be seen in how intellectual property is handled. Given that the consortium has no legal form, there is no entity to which intellectual property can be transferred. As such, at best, data spaces created under the auspices of Horizon Europe will get access to materials made available through a creative commons or open source license. They will not, however, have the option of developing commercially protected intellectual property that they can later monetise. This isn’t to say that a business model needs to rely on protected material, but it certainly narrows the business choices that any newly forming data space building on the foundations created by a data space project.

With these burdens weighing on the consortium, it creates a problem for any discussions around a business model.

Writing a good business plan requires skin in the game

Given that the temporary nature of a consortium and the lack of capital investment into any activities of the data space, it is little surprise that business planning that data spaces create—at least those funded by the European Commission under the auspices of Horizon Europe—tend to be theoretical exercises. The business models that they create talk about high-level value propositions that lack quantification. A business plan cannot calculate costs unless it knows the cost base of the organisation that will drive it.

More importantly, given that the consortium is driving a business plan that they will not ultimately execute, they have no incentive to measure risks in a credible manner. Proper market analyses are expensive to execute. As well, to demonstrate that a (theoretical) business plan can be successful, a consortia has every incentive to overestimate benefits and underestimate costs. This is a well-known and well-documented problem in public-private partnerships that use special-purpose vehicles (SPV) to build infrastructure. Ultimately, if bankruptcy comes, the SPV dies, but the founding members remain untouched.

Understanding and feeling risk is an essential element of business planning, creating discipline and forcing specificity on the writers of a business plan. No manager, bank, or investor will provide resources without a credible account of what can be delivered.

Until data-space initiatives adopt permanent legal forms with committed partners and capital investment, data spaces will be likely fail to produce sustainable data spaces. Achieving sustainable data spaces will require rethinking not only architecture and governance, but the very frameworks through which they are initiated.

This set me thinking about the legal agreements that should form the basis for the data exchanges taking place within a data space. The fact that legal agreements should exist to share data is not new or unique to data spaces. What would make this unique is if a data space has a specific legal form and framework for this rule creation.

To explore what this means, I find it instructive to explore existing organizational forms and the (legal) structures and obligations that they create for organizations.

A limited liability company, for example, follows particular norms when it comes to rule setting and organizational structure. While these rules can differ by Member State, they are set out by law and give a limited liability company a clearly identifiable form.

The organisational clarity of a limited liability company

A limited liability company requires articles of association or similar founding documents that must be registered with the appropriate authorities. These articles outline governance rules, capital contributions, profit distribution, and transfer restrictions. Many jurisdictions require a minimum share capital.

Some basic elements about how these types of companies are governed are also mandated. A limited liability company typically must hold at least one general meeting every year to approve accounts and address member resolutions. Important decisions are documented in minutes, which are also publicly available.

On reporting, most European limited liability companies must also file annual accounts with a commercial register, making basic financial information publicly available. Depending on company size, these may need to be audited. Many jurisdictions also require a register of members and, increasingly, a register of beneficial owners for anti-money laundering purposes.

Limited liability companies still have a lot of leeway in how they choose to operate and manage themselves. Nonetheless, there are commonalities between all limited liability companies that are embedded in the law.

Data spaces, as defined by the Data Spaces Support Centre, lack this organisational clarity

Returning to the data space, it lacks any kind of law or convention around how it needs to govern itself to be defined as a data space. If I read the building block labelled as organizational form and governance authority from the Data Spaces Support Centre (DSSC), I see decision trees that give many options: in fact, one of the forms for the governance authority that should represent the data space is a limited liability company. But the data space and its governance authority can assume other legal forms as well, including:

• A European Digital Infrastructure Consortium (EDIC), a special legal form which resembles European Research Infrastructure Consortium (ERIC), which support cross-border organisations that are largely publicly funded.
• A European Cooperative Society, which is a non-profit with characteristics of a cooperative and public limited company.
• A European Economic Interest Grouping, which is a non-profit legal entity similar to general partnerships, where members share unlimited liabilities, which flow through to the founding entities.

Each of these forms has specific rules around how they are organized, including how rules are formed and key decisions are made.

At the same time, the building block informs me that a data space can also be unincorporated, without legal form, where rules around rule-making are going to be decided according to an agreement between the various parties that are running the data space. Yet another organisational form that a data space can assume.

The DSSC ‘design principles’ do not help formalise how a data space is governed

Yes, the DSSC also provides a set of high-level ‘design principles‘, describing aspirations (not obligations) on transparency and inclusivity, among other principles. There are brief mentions of rulebook designs by organisations like the International Data Space Association (IDSA) and Sitra, but these are not requirements.

More importantly, there are inherent tensions in some of the principles whose resolution will be determined according to the legal shape of the data space. For example, governance authorities in data spaces are often composed of voting members, which is likely a small subset of the participants in the data space. Because their interests may not reflect all participants equally, there is a structural tension between full transparency and representative decision-making.

Without explicit mechanisms for inclusive representation or conflict resolution, how this tension is resolved likely depends on the legal form of the governance authority. If that’s a limited-liability company, the stated principle of full transparency will likely suffer.

As data spaces evolve, I would expect a clearer organizational form to develop

This ‘long walk’ leads me back to my original definition of the data space, which is the fact that a governance authority sets the rules for the data space in some form; however, this rule-setting function isn’t (yet) defined by law or convention, excepting the rules around the legal form that the governance authority may end up assuming. The fact that a data space has a governance authority remains a defining characteristic, but how those rules are established and enforced is very much an individual decision at the moment.

Normally, I’m used to the social scientists embracing this kind of definitional fuzziness, debating concepts and splitting proverbial hairs in countless ways. But, in conversations with some leading experts, I find that it is the technical people that blur my vision.

Now, when I say that I don’t understand the definition of a data space, this isn’t strictly true. I know how I define it, and for me, there’s clear technical criteria that makes a data space what it is and makes it different from a data platform.

My (technical) definition of a data space

At its most basic level, a data space could consist of two entities that hold and exchange data via the data space protocol. The data space protocol, which is the connective tissue between the data holders, consists of two layers:

• The transport layer defines how data is transmitted—typically using standard web protocols like HTTPS or MQTT—while supporting authentication, encryption, and message integrity.
• The control layer manages data access, usage, and policy enforcement, ensuring that data exchanges comply with agreed-upon rules.

In the diagram below, we have two organisations looking to share data: one with CVs for potential employees and another with job openings.

What’s important to see in the diagram is that the data space has no central repository where data resides. There is no centralised data centre, and the data remains with the data holder. No party makes a copy of the data, but rather enters an environment where they can gain access to it.

From a data sovereignty perspective, this should give a data holder confidence that they retain full control over at least where their data is housed. When working with cloud providers, one needs to work on faith that data will always physically reside where that provider has promised.

Of course, IT departments have consciously moved away from maintaining their own server rooms, and there’s certainly added complexity to storing and securing data that you look to share. Witness the many (many) data breaches that happen on a daily basis. Nonetheless, this is the fundamental element of the data space.

But two servers don’t make a data space: the role of a service provider

Data spaces become more robust environments when they include service providers that analyse the data made available by the data holders. In essence, they make something more out of the data. They do the interesting stuff that people want to see: making maps that give us directions, showing us progress on health goals, or helping us find a job.

In the expanded example below, the service provider provides a matching service to the two data holders. This means that neither data holder has access to sensitive personal data but has what they want—namely a match of CVs and job opportunities. Yet more data sovereignty! Let the EU rejoice.

The final piece: the governance authority

Data spaces can become a complex web of data holders and service providers (among other entities). To keep the data space functioning well, it can adopt a legal form and be run by a governance authority.

This governance authority creates the rules by which data holders and service providers interact, and governs the data space to ensure that those rules are followed. This can include the following elements:

• Policy and Rule Definition. Establishes the legal, ethical, and operational framework for participation, including data usage policies, consent mechanisms, and compliance with regulations such as the GDPR.
• Certification and Onboarding. Manages participant admission by verifying their compliance with governance standards, issuing trust credentials, and maintaining registries of verified participants and services.
• Monitoring and Enforcement. Oversees adherence to the established rules, audits data transactions, and enforces corrective actions or sanctions when violations occur to maintain ecosystem integrity.

But what do the technical people say?

Having spoken with three leading technical experts that have been designing specifications around data spaces, the definition that they provide is decidedly less technical. In general, their answer to ‘what is a data space’ comes down to a number of concepts:

• Decentralised. Here there is alignment between how I think about data spaces and what the technical people have been telling me. The only difference is that I’m told I’m too hung up on the use of the data space protocol as a defining characteristic.
• Sovereign. More alignment, though for me, data sovereignty is more of an outcome of the technical infrastructure than a defining characteristic in and of itself.
• Non-discriminatory or participant autonomy. This is where the governance authority comes into play. The technical people say that the governance authority has obligations to ensure that the data space is governed without a central, controlling actor. Some go further as to argue that a data space cannot discriminate against data holders or service providers.
• Interoperable. Finally, a data space needs to be interoperable. Whether they mean within the data space or across different data spaces is a point of debate.

While I have no problem with these definitions, when they aren’t anchored in technical boundaries, it becomes difficult to distinguish between a data space and other forms of data sharing. A data-sharing partnership or federated research collaboration could meet these criteria, for example. Without the technical elements, any kind of structured data collaboration could claim to be a data space.

More importantly for me is that some elements–namely around being non-discriminatory or promoting participant autonomy–are clearly points of debate on which experts aren’t agreeing. It seems clear that the data space serves the interests of the governing authority, which is essentially its founding members. But how far can that governance authority go in settings terms and conditions?