How Does the Model-Centric Data Flow Work?

In CIVITAS/CORE, model-centric data flow is implemented as a technology-independent architectural principle. The central idea is that data flows, data structures, access rules, transformations, persistence layers, and interfaces are first described at the model level. Only afterwards are these models translated into concrete technical configurations by specialized components or configuration adapters.

This does not mean that CIVITAS/CORE follows a model-centric or model-driven software development approach in which application code is generated from models at runtime. The models are not the source for generating new CIVITAS/CORE code while the system is running. Instead, they describe functional intent and configuration-relevant information. Existing components interpret these models, validate them, transport them, and derive runtime configuration from them.

In the target architecture, several logically separated platform areas jointly take on the role of model and data flow management. Users define datasets, datasources, datastructures, and pipelines at runtime in a functional platform language (intermediate representation). The functional control layer is the runtime-facing orchestration layer: it accepts those functional changes, validates them in the context of the functional model, and publishes them through a standardized event transport.

The model management layer is responsible for canonical model processing. It normalizes, validates, transforms, links, and versions data structure and pipeline models, derives common representations, and keeps them traceable and reusable across the platform. The versioned model repository belongs to this model management layer and acts as its persistence layer.

The split is therefore not "control layer versus repository". Instead, the control layer handles functional change and propagation, while model management owns model semantics, versioning, and persistence.

The actual execution of a data flow takes place in a dedicated execution area of the platform. There, model references, configuration requests, lifecycle changes, and result messages are transported and consumed by components or configuration adapters. Components that do not directly understand the models are configured on their behalf by adapters. This makes it possible to set up different target systems from the same functional model information. The concrete technology remains interchangeable; the modeled data flow remains stable.

model type	Implementation in the platform
Data flow model	Dataset/pipeline in the platform language, transported as an event or model reference, executed or provisioned by the execution area
Data structure model	Datastructure/DataStructureversion, processed and versioned through model management
Access model	Datasource configurations, authentication and authorization models, central decision and synchronization components
Transformation model	Pipeline steps, mapping and transformation definitions for a later execution technology
Analysis model	Extensible pipeline steps or specialized processing components
Meta-Data-model	Dataset metadata, catalog information, access rights, governance, and quality information
Interface model	Publication routes, interface standards, data access points, and catalog interfaces

Functional Platform Management

Functional Platform Management is the control layer of CIVITAS/CORE. The user interacts through a central functional entry point. That is where the business logic, dataset lifecycle management, and the stable domain model of CIVITAS/CORE live.

There is a clear separation between the static CIVITAS/CORE domain and modeled artifacts. Relatively stable entities such as Dataset, Datapool, users, groups, roles, or permissions are managed as a domain model and stored in a durable CIVITAS/CORE persistence layer. modeled artifacts such as data structures, model variants, or later pipeline models are managed in a separate model management layer. This model management layer can ingest, transform, validate, and link data models of different kinds.

Intermediate Representation

Functional Platform Management speaks a platform language, that is, a functional intermediate representation. It describes the functional concepts of CIVITAS/CORE in a technology-independent way. See Core-IR-Reference

This intermediate representation is deliberately not identical to the configuration language of individual target components. It is the stable functional description layer. Concrete technical configurations are derived from it through events, models, and adapters. The intermediate representation is under construction and is being extended iteratively according to agile processes.

Distribution and Execution of Data Flows

In the distribution and execution of data flows, platform components are loosely coupled via a central event transport. The functional control layer publishes events on this transport path. These events can contain model references, configuration commands, lifecycle changes, or result messages. Configuration adapters consume these events and translate the platform language into the respective component-specific language.

Each target component therefore continues to speak its own language. A target component can have its own language for identity, routing, data flow execution, persistence, interface exposure, or authorization decisions. The platform does not force these components into a shared technical language. Instead, the platform forms a functional intermediate layer from which the respective target languages are derived or configured.

Authentication and Authorization

Authentication and authorization also follow this separation. The platform provides a central login and central management of users, groups, and roles. The functional source of this information remains the CIVITAS/CORE domain. Technical execution components are synchronized through configuration adapters.

Authorization is implemented through a central decision logic. This decision logic receives the required functional permission information from the CIVITAS/CORE domain. This keeps the functional domain authoritative here as well, while technical components only perform execution roles.

Core Statement on Technology Independence

Model-centric data flow is technology-independent because the platform does not model directly in the languages of the target components. The user describes data, data structures, data flows, permissions, and publications in the platform language. The functional control layer manages this functional truth, the model management layer processes the modeled artifacts, and configuration adapters translate them into component-specific configurations.

Extending with Additional Components

CIVITAS/CORE will be extendable through additional components that are not part of the standard scope. This makes it possible to integrate individual processes and applications. A distinction must be made between external and internal extensions: An external extension (addon) uses only publicly accessible platform functions or openly provided data. An internal extension (plugin) can access internal platform functions. Such an extension can translate from the platform language into the respective component language through its own configuration adapter.

Capabilities

Model-centric data flow can be realized through a set of capabilities implemented by one or more platform components. These capabilities relate to how users work with data models, especially data structures and pipelines. They are briefly described below:

• Type Checking: verification of the structural integrity of models
• Validation: verification of the functional integrity of models (constraints)
• Model Storage: persistent storage of models
• Versioning: maintenance of multiple versions of a model
• Transformation: description of how data is transformed from one data structure into another.
• Formatting: transformation of the formatting/notation (JSON Schema, XSD, …) of models.
• Model Linking: relating/referencing models
• Reuse: reuse of a model defined once
• Semantics: maintenance of semantic information within models

Summary

CIVITAS/CORE separates functional modeling from technical execution. Functional Platform Management maintains a technology-independent platform language as a functional intermediate representation. The execution layer distributes model references, commands, lifecycle changes, and result messages via an event transport. Configuration adapters then translate them into the respective language of the target components. This allows model-centric data flow to be implemented with different technologies without changing the functional model of the data flow.