4. Gaia-X Conceptual Model

The Gaia-X Conceptual Model, shown in the figure below, describes all concepts in the scope of Gaia-X and relations among them. Supplementary, more detailed models may be created in the future to specify further aspects. Minimum versions of important core concepts in the form of mandatory attributes for Self-Descriptions are specified in the Gaia-X Trust Framework. The general interaction pattern is further described in the section Basic Interactions of Participants.

The Gaia-X core concepts are represented in classes. An entity highlighted in blue shows that an element is part of Gaia-X and therefore described by a Gaia-X Self-Description. The upper part of the model shows different actors of Gaia-X, while the lower part shows elements of commercial trade and the relationship to actors outside Gaia-X.

Gaia-X conceptual model

4.1 Participants

A Participant is an entity, as defined in ISO/IEC 24760-1 as “item relevant for the purpose of operation of a domain that has recognizably distinct existence”1, which is onboarded and has a Gaia-X Self-Description. A Participant can take on one or more of the following roles: Provider, Consumer, Federator. Section Federation Services demonstrates use cases that illustrate how these roles could be filled. Provider and Consumer present the core roles that are in a business-to-business relationship while the Federator enables their interaction.

4.1.1 Provider

A Provider is a Participant who operates Resources in the Gaia-X Ecosystem and offers them as services. For any such service, the Provider defines the Service Offering including terms and conditions as well as technical Policies. Furthermore, it provides the Service Instance that includes a Self-Description and associated Policies.

4.1.2 Federator

Federators are in charge of the Federation Services and the Federation, which are independent of each other. Federators are Gaia-X Participants. There can be one or more Federators per type of Federation Service.

A Federation refers to a loose set of interacting actors that directly or indirectly consume, produce, or provide related Resources.

4.1.3 Consumer

A Consumer is a Participant who searches Service Offerings and consumes Service Instances in the Gaia-X Ecosystem to enable digital offerings for End-Users.

4.2 Service Composition

flowchart TB so[Service Offering] provider[Provider] consumer[Consumer] resource[Resource] so -- isOfferedBy --> provider consumer -- configures --> so subgraph composition [Composition] direction TB so -- composed of --> resource end

Gaia-X conceptual model

4.3 Resources

Resources describe in general the goods and objects of the Gaia-X Ecosystem.

A Service Offering can be associated with other Service Offerings.

classDiagram ServiceOffering o-- Resource: aggregation of Resource o-- Resource: aggregation of class Resource{ <<abstract>> } Resource <|-- "subclass of" PhysicalResource: Resource <|-- "subclass of" VirtualResource VirtualResource <|-- "subclass of" InstantiatedVirtualResource InstantiatedVirtualResource <..> ServiceInstance : equivalent to

Resource Categories

A Resource can be a:

  • Physical Resource: it has a weight, position in space and represents physical entity that hosts, manipulates, or interacts with other physical entities.
  • Virtual Resource: it represents static data in any form and necessary information such as dataset, configuration file, license, keypair, an AI model, neural network weights, …
  • Instantiated Virtual Resource: it represents an instance of a Virtual Resource. It is equivalent to a Service Instance and is characterized by endpoints and access rights.

4.3.1 Policies

Policy is defined as a statement of objectives, rules, practices, or regulations governing the activities of Participants within Gaia-X. From a technical perspective Policies are statements, rules or assertions that specify the correct or expected behaviour of an entity23.

The Policy Rules Document explains the general Policies defined by the Gaia-X Association for all Providers and Service Offerings. They cover, for example, privacy or cybersecurity policies and are expressed in the conceptual model indirectly via Gaia-X Federation Service Compliance and as attributes of the Resources, Service Offerings, and Service Instances.

These general Policies form the basis for detailed Policies for a particular Service Offering, which can be defined additionally and contain particular restrictions and obligations defined by the respective Provider or Consumer. They occur either as a Provider Policy (alias Usage Policies) or as a Consumer Policy (alias Search Policy):

  • A Provider Policy/Usage Policy constrains the Consumer’s use of a Resource. For example, a Usage Policy for data can constrain the use of the data by allowing to use it only for x times or for y days.

  • A Consumer Policy describes a Consumer’s restrictions of a requested Resource. For example, a Consumer gives the restriction that a Provider of a certain service has to fulfil demands such as being located in a particular jurisdiction or fulfil a certain service level.

In the Conceptual Model, they appear as attributes in all elements related to Resources. The specific Policies have to be in line with the general Policies in the Policy Rules Document.

graph TD; A[Policy Rules] --> |defines| B[general Gaia-X Policies] B --> |basis for| C[Resource-specific Policies] C -->D[Provider Policy/ Usage Policy] C -->E[Consumer Policy/ Search Policy]

4.4 Federation Services

Federation Services are services required for the operational implementation of a Gaia-X Data Ecosystem. They are explained in greater detail in the Federation Services section.

They comprise four groups of services that are necessary to enable Federation of Resources, Participants and interactions between Ecosystems. The four service groups are Identity and Trust, Federated Catalogue, Sovereign Data Exchange and Compliance.

4.5 Service Offerings, Service Instances and Service Contract

A Service Offering is defined as a set of Resources, which a Provider aggregates and publishes as a single entry in a Catalogue. Service Offerings may themselves be aggregated realizing Service Composition.

A Service Instance is the instantiation of a Service Offering at runtime, strictly bound to a version of a Self-Description.

During the ordering phase, the Provider is invited to generated a denormalized version of a self-description for the newly instantiated Service Instance. The format and content of this self-description is out of scope for this document.

A Contract is an agreement between a Consumer and a Provider, to allow and regulate the usage of one or more Service Instances. It is related to a specific version of a Service, from which it derives the attributes of the Service Instances to be provisioned. The Contract has a distinct lifecycle from the Service Offering and additional attributes and logic, which are out of scope of Gaia-X architecture document.

4.6 Contract

The Gaia-X Association is not getting involved into the realisation of the Contract. However, in order to ease participants with the establishement and to enter into a contractual relationship, we are defining below a common model for Contract.

4.6.1 Concept: Computable Contracts as a service

  • Contracts are the basis for business relationships.
  • Whereas a licensor has rights with respect to a resource and is willing to (sub-)license such rights by a defined set of conditions.
  • Whereas a licensee would like to get license rights with respect to a resource by a defined set of conditions.
  • Licensor and licensee agree on it in form of a contract.
  • Every role of the Gaia-X Conceptual Model as well as of operational model can be seen as legal persons and therefore may have a role as a licensor or licensee or both.
  • In traditional centralized driven ecosystems the platform provider which is very often the ecosystem owner, defines the contractual framework and participants need to accept without any possibility for negotiation.
  • In distributed and federated ecosystems individual contracting becomes much more important to support individual content of contractual relations, e.g., individual sets of conditions.
  • The ability to negotiate on contracts is key for a sovereign participation. The ability to observe if all parties of a contract behave the way it is agreed, to validate their rights, to fulfill their obligations and ensure that no one can misuse information is key for a trustful relationship.
  • Computable contracts aim to easy the complex processes of contract design, contract negotiation, contract signing, contract termination as well as to observe the fulfillment of contractual obligations and compliance with national law.
flowchart TB participant[Legal Person] op_role[Operational Model roles] cm_role[Conceptual Model roles] compliance[Gaia-X Compliance] licensor[Licensor] licensee[Licensee] lic_rights[License rights] usage[Gaia-X resource usage] t_c[Terms & Conditions] contract[Contract] cc_elts[Computable Contract Elements] cc[Computable Contract] ncc[Non computable Contract] op_role & cm_role -- defines --> participant participant -- is a --> licensee & licensor licensee -- requests --> lic_rights licensor -- owns --> lic_rights licensee -- accepts --> contract licensor -- offers --> contract lic_rights -- determines --> usage lic_rights -- sub-licensed_by --> t_c t_c -- defined by --> contract contract -- represented by --> ncc & cc cc -- consists of --> cc_elts cc_elts -- verified by --> compliance participant -- verified by --> compliance

4.7 Additional Concepts

In addition to those concepts and their relations mentioned above, further ones exist in the conceptual model that are not directly governed by Gaia-X. These concepts do not need to undergo any procedures directly related to Gaia-X, e.g., do not create or maintain a Gaia-X Self-Description.

First, the Service Instance realizes a Service Offering and can be used by End-Users while relying on a contractual basis.

Second, Contracts are not in scope of Gaia-X but present the legal basis for the Services Instances and include specified Policies. Contract means the binding legal agreement describing a Service Instance and includes all rights and obligations. This comes in addition to the automated digital rights management embedded in every entity’s Self-Description.

Further relevant actors exist outside of the Gaia-X scope in terms of End-Users and Resource Owners.

Resource Owners describe a natural or legal person, who holds the rights to Resources that will be provided according to Gaia-X regulations by a Provider and legally enable its provision. As Resources are bundled into a Service Offering and nested Resource compositions can be possible, there is no separate resource owner either. Resources can only be realized together in a Service Offering and Service Instance by a Provider, which presents no need to model a separate legal holder of ownership rights.

End-Users use digital offerings of a Gaia-X Consumer that are enabled by Gaia-X. The End-User uses the Service Instances containing Self-Descriptions and Policies.

4.8 Examples

4.8.1 Personal Finance Management example

This example describes the various Gaia-X concepts using the Open Banking scenario of a Personal Finance Management service (PFM) in SaaS mode.

Suppose that the service is proposed by a company called MyPFM to an end user Jane who has bank accounts in two banks: Bank1 and Bank2.
MyPFM is using services provided by Bank1 and Bank2 to get the banking transactions of Jane and then aggregates these bank statements to create Jane’s financial dashboard.

Jane is the End-User.

Bank1 and Bank2 are Providers defining the Service Offerings delivering the banking transactions and operating the corresponding Service Instances. They are also Resource Owners for the bank statements, which are Resources composing the Service Offerings (Jane is the data subject as per GDPR4).
The associated Resource Policies are in fact predefined by the PSD25 directive from the European Parliament.

MyPFM is the Consumer which consumes the Service Instances provided by Bank1 and Bank2 in order to create a financial dashboard and to offer it to Jane.
MyPFM is also likely consuming Service Instances from a PaaS Provider in order to run its own code, such as dashboard creation.


  1. ISO/IEC. IT Security and Privacy — A framework for identity management: Part 1: Terminology and concepts (24760-1:2019(en)). ISO/IEC. https://www.iso.org/obp/ui/#iso:std:iso-iec:24760:-1:ed-2:v1:en 

  2. Singhal, A., Winograd, T., & Scarfone, K. A. (2007). Guide to secure web services: Guide to Secure Web Services - Recommendations of the National Institute of Standards and Technology. Gaithersburg, MD. NIST. https://csrc.nist.gov/publications/detail/sp/800-95/final https://doi.org/10.6028/NIST.SP.800-95 

  3. Oldehoeft, A. E. (1992). Foundations of a security policy for use of the National Research and Educational Network. Gaithersburg, MD. NIST. https://doi.org/10.6028/NIST.IR.4734 

  4. Rights of the data subject https://gdpr-info.eu/chapter-3/ 

  5. Payment services (PSD 2) https://ec.europa.eu/info/law/payment-services-psd-2-directive-eu-2015-2366_en