Policy enforcement is currently done only on the provider's connector, mainly focusing on access policies. Enforcing policies on the consumer's side would focus more on usage policies. In many cases, these types of activities happen after the transfer concluded, and Simpl-Open, depending on the storage and type of transfer, cannot gurantee the enforcement, and sometimes it is even out of their control. We are currently investigating possibilities for a limited set of generic use cases to implement usage policies, but the main focus is on access policies. However, since the connector is quite extensible, new types of policies and their enforcement can be implemented by the data spaces.

Please refer to the Business Processes described on the website: LINK.  For guidance on how to contribute, consult the Contribution Guide (Section 2.4 "How to contribute requirements"): LINK.

There is one item on our roadmap for an extension for data streaming, which we are currently working on.

Simpl-Open development follows security best practices and a strict security plan to avoid such incidents.

Then each organisation who will implement Simpl-Open in a production scenario will also be free (and responsible) to harden it and follow their own security guidelines.

No, currently only contract between a consumer and a provider are foreseen. You are welcome to open a discussion on GitLab to suggest this requirement.

End-users always connect through a participant, which is always an organisation. This connection within an organisation (also refered as "Tier 1" in Simpl) is not anonymous.

However between 2 participants, the machine to machine interaction (also refered to as "Tier 2") is anonymous.

The investment so far is around 40M€. 

No, Simpl‑Open does not require a Clearing House as part of its onboarding process.

Simpl‑Open is an open‑source middleware designed for secure data access, interoperability, and governance within European data spaces, not a payment or settlement system. Its architecture focuses on enabling organisations to configure their own onboarding rules, identity attributes, and data‑sharing policies, giving full control over how participants join and interact within a data ecosystem and not on financial transactions.

Fiware components are not part of Simpl-Open.

The architecture is not designed around any specific cloud vendor or geography. Simpl-Open is built on open standards, meaning that European data center operators and infrastructure providers can fully onboard and offer their services through the middleware, just like any hyperscale cloud provider.

Requiring European-only providers would strengthen independence in principle but risk hindering adoption in practice — particularly in the short term. The smarter design is to make Simpl-Open sovereignty-capable rather than sovereignty-mandated, allowing each deployment context to apply the appropriate level of constraint. The openness of the architecture becomes a feature, not a vulnerability, as long as robust certification, labelling, and governance frameworks sit alongside it.

Yes, and it is a widely recognised barrier across all data space initiatives — not just Catena-X.

This is also being addressed at the European level through the Data Governance Act and the DSSC's work on common legal building blocks. The key challenge ahead is ensuring these modules can be harmonised and reused across data spaces, rather than each initiative solving it independently.

The Governance Authority is the data space Participant that is accountable for creating, developing, operating, maintaining and enforcing the governance framework for a particular data space, without replacing the role of public enforcement authorities. You refer to: https://simpl-programme.ec.europa.eu/book-page/actor-definitions

The Simpl-Open Agent supporting the GA is centralised, but a data space can provide access to this agent to users from different organisations if their governance is more decentralised.

Simpl-Open does not impose any metadata standard, but is highly encouraged to use commonly used standards to define medata. For Smart Data Models, they are momstly concerned with the actual data to be shared, and the metadata of these. The catalogue in contract, is containing the medata of the resource offering, not the actual dataset. We will provide a way to reference the actual's data metadata. 

Each provider that shares data within the dataspace is responsible for ensuring that the data complies with all applicable standards and legal requirements, including copyright, confidentiality, data protection, and any other relevant regulations. This responsibility applies before any data exchange begins, as the provider does not upload or transfer data into a central environment.

Within the dataspace, Simpl ensures that data maintains its full integrity during transmission. While the Data Transfer components orchestrate and manage the flow of data between participants, they do not access, inspect, or analyze the content itself. Data integrity is ensured through underlying protocol‑level or storage‑level mechanisms, and connectors are able to enforce secure transfer mechanisms (e.g., encryption, secure channels) without performing data validation or compliance checks.

The Simpl‑Open agent follows this principle: it does not inspect or process the data it transports. Its sole function is to facilitate secure, protected, end‑to‑end data transfer within the dataspace, ensuring that confidentiality and integrity are preserved without engaging in content inspection or compliance evaluation.