Skip to main content
Version: 2.0-rc2

ADR 038: Scope Definition of the CIVITAS/CORE Platform

Date: 2026-01-13

Status: Reviewed

Decision Makers: Architecture Board

Context​

The CIVITAS/CORE platform is intended to serve as a reusable, open, and modular Smart City core platform. It is composed of multiple open-source components that together provide foundational capabilities such as identity management, API management, data integration, and platform interoperability.

As the platform evolves, it is necessary to clearly define which components are considered part of CIVITAS/CORE, which components are explicitly not part of the platform but should be documented for community usage, and which components are out of scope entirely.

This ADRArchitecture Decision RecordA document capturing an architecture decision. Each ADR has a stable identifier and short title and is managed through four lifecycle states: Proposed, Accepted, Deprecated and Superseded. establishes a clear scope boundary for CIVITAS/CORE in order to:

  • Avoid ambiguity for implementers and operators
  • Ensure architectural consistency across deployments
  • Enable community-driven extensions without bloating the core
  • Provide a clear basis for documentation and future ADRsArchitecture Decision RecordA document capturing an architecture decision. Each ADR has a stable identifier and short title and is managed through four lifecycle states: Proposed, Accepted, Deprecated and Superseded.

Checked Architecture Principles​

  • [none] Model-centric data flow: this ADRArchitecture Decision RecordA document capturing an architecture decision. Each ADR has a stable identifier and short title and is managed through four lifecycle states: Proposed, Accepted, Deprecated and Superseded. does not influence this principle
  • [full] Distributed architecture with unified user experience
  • [full] Modular design
  • [full] Integration capability through defined interfaces
  • [full] Open source as the default
  • [full] Cloud-native architecture
  • [full] Prefer standard solutions over custom development
  • [full] Self-contained deployment
  • [full] Technological consistency to ensure maintainability
  • [none] Multi-tenancy: this ADRArchitecture Decision RecordA document capturing an architecture decision. Each ADR has a stable identifier and short title and is managed through four lifecycle states: Proposed, Accepted, Deprecated and Superseded. does not influence this principle
  • [partial] Security by design: we are caught between the conflicting priorities of minimising requirements for operators on the one hand and security by design on the other. This ADRArchitecture Decision RecordA document capturing an architecture decision. Each ADR has a stable identifier and short title and is managed through four lifecycle states: Proposed, Accepted, Deprecated and Superseded. reflects the compromise reached so far.

Decision​

The CIVITAS/CORE platform is defined as a logical and deployable core layer that provides identity, API access, data integration, and platform interoperability, while deliberately excluding infrastructure-level and security-operations components, that highly depends on the operators infrastructure decisions.

Components that are Part of the CIVITAS/CORE Platform​

The following components are considered part of the CIVITAS/CORE platform and must be supported, documented, and validated:

  • Relational Database: Postgres (optionally part of the deployment, can be provisioned independently of the CIVITAS/CORE deployment)
  • IAM: Keycloak (mandatory)
  • API Gateway: APISIX (mandatory)
  • User & Data Management PortalManagement PortalThe central user interface of the Platform that provides access to all functionalities for managing data, configurations, users, and access. It serves as the main entry point for working with data-related elements.: Backend, Frontend (mandatory)
  • Model Atlas / Fennec (mandatory)
  • Apicurio (mandatory)
  • STA: Frost Server (mandatory)
  • NGSI-LDNGSI-LDAn Open API and data model specification for context management, published by ETSI. It defines how context information (entities, relationships, and properties) is represented and exchanged. Context BrokerContext BrokerA component that manages context information (entities and their state) and exposes it through the NGSI-LD API. Part of the CIVITAS/CORE V2 target architecture (ADR 038); the choice of the broker product is still open. (optional, protocol might be provided by platform transformation)
  • Message Bus: Kafka (mandatory)
  • RedPanda Connect (mandatory)
  • Timeseries Database (mandatory)
  • Dashboard Superset (mandatory)
  • Dashboard Grafana as second tool (not fully integrated)
  • Geoserver Cloud (mandatory)
  • Geoportal (mandatory)

Components Not Part of CIVITAS/CORE, but Usage Must Be Described​

The following components are explicitly not part of the CIVITAS/CORE platform, but their deployment, integration and recommended usage must be described in documentation as some reference architecture to support community deployments:

  • Monitoring stack
  • Logging components
  • Application metrics
  • Certificate management
  • Private container registries
  • Ingress
  • Service Mesh

These components are considered environment-specific concerns and may differ between operators and deployment contexts.

Components Explicitly Out of Scope​

The following components are not part of CIVITAS/CORE and will not be further described or documented within the platform scope:

  • SIEM components
  • Web Application Firewall (WAF) implementations
  • Backup and restore solutions

These topics are considered operational or organizational responsibilities of platform operators.

Consequences​

  • CIVITAS/CORE remains lean, modular, and reusable, avoiding overreach into infrastructure and security operations.
  • Platform documentation must clearly distinguish between mandatory core components, recommended ecosystem components, and out-of-scope responsibilities.
  • Future ADRsArchitecture Decision RecordA document capturing an architecture decision. Each ADR has a stable identifier and short title and is managed through four lifecycle states: Proposed, Accepted, Deprecated and Superseded. must align with this scope definition and must not implicitly introduce out-of-scope components into the core.

Alternatives​

  • A1: Include full monitoring, logging, and security stacks in CIVITAS/CORE: Discarded because it would significantly increase complexity, reduce deployment flexibility, and overlap with existing organizational tooling for many operators.
  • A2: Mandate specific infrastructure implementations (e.g. service mesh, backup solutions): Discarded to avoid coupling the platform to specific vendors or operational models.

See also​

relevant ADRsArchitecture Decision RecordA document capturing an architecture decision. Each ADR has a stable identifier and short title and is managed through four lifecycle states: Proposed, Accepted, Deprecated and Superseded. are linked above in the text.