You can become a member of the Trustflows community by signing the charter below. By doing so, you acknowledge that the Trustflows community is built around a set of principles, agree that Trustflows is an architectural style with certain properties, and make four commitments.

Rooted in Ghent < Flanders < Europe, the community has the ambition to be front-runners in #datatech, positioning “Datatech made in Flanders” as a quality label in Europe and beyond. It however welcomes participants from all around the world.

Principles

The solutions discussed within the Trustflows community will be:

1. Interoperable: Interoperability ensures systems can connect seamlessly across organisational, sectoral, and national boundaries. We aim to reduce friction when building data integrations. The European Interoperability Framework (EIF, 2026) will guide us in fostering European (and global) interoperability on multiple levels.
2. Legally compliant: Our solutions are developed with close attention to alignment with key European legislation (such as GDPR, AI Act, NIS2, Data Governance Act, Interoperable Europe Act). Legal compliance empowers our datatech solutions to be deployable EU-wide. We bridge legal obligations and practical implementation, reducing compliance effort.
3. Trusted, with end-users in the centre: A solution should be designed not only from its own perspective, but rather from the viewpoint of the end-user seeking a seamless experience to accomplish a specific task. While this requires interoperability between services and legal compliance, it also requires trust, which becomes more challenging to establish across an ecosystem. When we say trust, we intend to cover all aspects of the word, such as: trust in the accuracy of the data flow as a trigger for business decisions; trust that the data is processed according to usage control policies that are a result of a negotiation between what reguliations demands, what end-users need to do their task, what data subjects feel comfortable with sharing, and the capabilities of the data provider; as well as trust in the security mechanisms to ensure a balance in confidentiality, availability, and integrity.

Properties of a Trustflows Architecture

The architectures discussed within the Trustflows community will also share certain properties.

1. From write to read. As processes anchor data in trust, Trustflows advocate building read interfaces as an effect of what was written before by one or more other actors. For example, when you’d like to change your first name, you don’t simply write your new name to a file, but you submit a “a name change request”, which will then need to follow a procedure. When the name change was approved, multiple read interfaces (e.g. your driver's license, ID card, or your family composition certificate) can be updated to reflect the new name.
2. Storage, identity, and authorization are separable components. Design authorization so it can be handled by a component independent of storage, just like authentication and identity providers are well-adopted as separate components. This way, policies can be defined and respected independent of where data is stored and processed. Authentication and authorization flows should follow standards where possible, or should be made interoperable through a debate in standardization committees, allowing the authentication and authorization layers to be substituted.
3. Specifications are reusable.

   To boost the reusability of specifications, we structure them as four complementary and interdependent asset types:

   1. Vocabularies publish reusable terms. By agreeing on semantics, vocabularies enable consistent reuse across services and domains.
   2. Shapes define the data structures exchanged between parties. They assemble vocabulary terms into reusable message and resource definitions: what fields exist, how they are typed, what is required vs. optional, and how objects relate.
   3. Interaction patterns capture reusable solutions for problems such as authorization, contract negotiation, data discovery, alignments, or domain specific workflows. An interaction pattern may specify the triggers for a state transition, and references shapes to describe the messages exchanged at each step.
   4. Developer documentation turn the reusable assets into an integration path for a specific solution. They document which interaction patterns are used. These guides are what developers follow to integrate with your service specifically, while adopting patterns that can reused elsewhere in the ecosystem.

Commitments as a Community Member

1. Disseminate use cases and assets with the Trustflows community through events and the website so the collective body of knowledge continues to grow.
2. Train your relevant architects and developers in how to build architectures that respect the Trustflows properties.
3. Include participating actively in standardisation initiatives such as OSLO, W3C, ISO, CEN/CENELEC, Eclipse or ETSI, in projects where possible and relevant. Standardisation takes time, yet pushes the state of the art for our entire ecosystem.
4. When delivering a project, strive towards publishing reusable assets, such as shapes, vocabularies, and interaction patterns.

Je wordt lid van de Trustflows-community door het onderstaande charter te ondertekenen. Daardoor erken je dat de Trustflows-community is gebouwd op een reeks principes, ga je akkoord dat Trustflows een architecturale stijl is met bepaalde eigenschappen, en engageer je je in de community (zie verder).

Met z’n wortels in Gent < Vlaanderen < Europa, heeft de community de ambitie om voortrekkers te zijn in #datatech. “Datatech made in Flanders” wordt een kwaliteitslabel in Europa en daarbuiten. Desalnietemin verwelkomen we leden van over de hele wereld.

Principes

De oplossingen die binnen de Trustflows-community worden besproken zullen voldoen aan deze principes:

1. Interoperabel: Interoperabiliteit zorgt ervoor dat systemen naadloos kunnen verbinden over organisatorische, sectorale en nationale grenzen heen. We zetten ons in om wrijving te verminderen bij het bouwen van datastromen die betrouwbaar moeten zijn. Het European Interoperability Framework (EIF, 2026) begeleidt ons bij het versterken van Europese (en mondiale) interoperabiliteit op meerdere niveaus.
2. Juridisch conform: Juridische conformiteit zorgt ervoor dat onze datatech-oplossingen EU-breed inzetbaar zijn. Onze oplossingen worden ontwikkeld met nauwgezette aandacht voor afstemming op belangrijke Europese wetgeving (zoals GDPR, AI Act, NIS2, Data Governance Act, Interoperable Europe Act). We slaan een brug tussen wettelijke verplichtingen en praktische implementatie, zodat de gevergde inspanning om juridisch conform te worden afneemt.
3. Vertrouwenswaardig, waarbij eindgebruikers centraal staan: Een oplossing moet niet alleen vanuit het eigen perspectief ontworpen worden, maar vanuit het standpunt van de eindgebruiker die een taak vlot wil uitvoeren. Dat vraagt interoperabiliteit tussen diensten en juridische conformiteit, maar ook vertrouwen, wat moeilijker wordt naarmate het ecosysteem groter wordt. Met vertrouwen bedoelen we alle aspecten van het begrip, zoals: vertrouwen in de accuraatheid van de datastroom als trigger voor zakelijke beslissingen; vertrouwen dat data worden verwerkt volgens usage control policies die het resultaat zijn van een onderhandeling tussen wat regelgeving vereist, wat eindgebruikers nodig hebben om hun taak uit te voeren, waar datasubjecten zich comfortabel bij voelen, en de mogelijkheden van de dataprovider; en vertrouwen in de security-mechanismen die een evenwicht garanderen tussen vertrouwelijkheid, beschikbaarheid en integriteit.

Eigenschappen van Trustflows architecturen

De architecturen die binnen de Trustflows-community worden besproken, delen bepaalde architecturale eigenschappen.

1. Van “write” naar “read”. Omdat processen data verankeren in vertrouwen, pleiten we met Trustflows voor het opbouwen van leesinterfaces als een verwerking van wat eerder door een of meerdere actoren is geschreven. Bijvoorbeeld: wanneer je je voornaam wilt veranderen, schrijf je niet simpelweg je nieuwe naam naar een bestand, maar dien je een “verzoek tot naamswijziging” in, dat vervolgens een procedure moet volgen. Wanneer de naamswijziging is goedgekeurd, kunnen meerdere leesinterfaces (bijvoorbeeld je rijbewijs, identiteitskaart of attest van gezinssamenstelling) worden bijgewerkt om de nieuwe naam weer te geven.
2. Opslag, identiteit en autorisatie zijn scheidbare componenten. Ontwerp autorisatie zodat die afgehandeld kan worden door een component die onafhankelijk is van opslag, net zoals authenticatie en identiteitsproviders breed geadopteerd zijn als aparte componenten. Op die manier kan autorisatiebeleid worden gedefinieerd en nageleefd, onafhankelijk van waar data worden opgeslagen en verwerkt. Authenticatie- en autorisatiestromen volgen waar mogelijk standaarden, of worden interoperabel gemaakt via discussie in normalisatieorganen, zodat authenticatie- en autorisatielagen onderling uitwisselbaar zijn.
3. De specificaties zijn herbruikbaar.

   Om de herbruikbaarheid van specificaties te vergroten, structureren we ze in vier complementaire en onderling afhankelijke types van assets:

   1. Vocabularia publiceren herbruikbare termen. Door consensus over semantiek bereiken, maken vocabularia consistent hergebruik mogelijk in andere services en overheen domeinen.
   2. Shapes definiëren de datastructuren die tussen partijen worden uitgewisseld. Ze gebruiken termen uit vocabularia tot herbruikbare berichten- en resourcedefinities: welke velden bestaan, hoe ze getypeerd zijn, wat verplicht versus optioneel is, en hoe objecten samenhangen.
   3. Interaction patterns bouwen herbruikbare oplossingen voor uitdagingen zoals autorisatie, data discovery, contract negotiation, alignering of domeinspecifieke workflows. Een interaction pattern kan triggers voor state transitions specificeren en verwijzen naar shapes om de berichten te beschrijven die bij elke stap worden uitgewisseld.
   4. Developer documentatie zet de herbruikbare assets om in een integratiepad voor een specifieke oplossing. Ze documenteren welke interaction patterns worden gebruikt. Dit is wat ontwikkelaars lezen om met jouw dienst te integreren, terwijl ze patronen implementeren die elders in het ecosysteem herbruikbaar zijn.

Engagementen als communitylid

1. Dissemineer use cases en assets met de Trustflows-community via evenementen en de website.
2. Train relevante architecten en ontwikkelaars in het bouwen van architecturen die de Trustflows-eigenschappen respecteren.
3. Neem actief deel aan standaardisatie-initiatieven zoals OSLO, W3C, ISO, CEN/CENELEC, ETSI, of Eclipse in projecten waar mogelijk en relevant. Standaardisatie kost tijd, maar stuwt de stand van de techniek voor ons hele ecosysteem.
4. Streef er bij het opleveren van een project naar om herbruikbare specificaties te publiceren, zoals shapes, vocabularia en interaction patterns.