This is an old revision of the document!
8.1 Overview
The Conceptual Runtime Plane Model classifies runtime communication and behaviour by architectural purpose. It helps authors and reviewers distinguish operational coordination, domain information exchange, health reporting, policy-governed release, and audit/provenance activity before later parts map those concerns to technologies, deployment artefacts, or evidence packages.
Runtime Planes do not define implementation mechanisms. A later implementation profile may realise Runtime Plane separation through DDS Topics, topic namespaces, partitions, APIs, message queues, Kubernetes namespaces, security policies, network segmentation, configuration conventions, or other mechanisms. Those mechanisms may support plane separation, but they do not define the planes themselves.
Figure 8.1-1 identifies the conceptual Runtime Planes used by the Financial Systems Archetype.
Runtime Planes ├── Control Plane ├── Data Plane ├── Health and Observability Plane ├── Policy and Release Plane └── Audit and Provenance Plane
Figure 8.1-1: Conceptual Runtime Plane Model
The model preserves separation between different runtime concerns while allowing explicit cross-plane relationships. For example, a Health and Observability Plane event may trigger a Control Plane recovery command, a Data Plane event may require Policy and Release Plane evaluation, and a Policy and Release Plane decision may create an Audit and Provenance Plane record. These relationships must remain explicit and traceable so one plane does not silently absorb or redefine another.