| Both sides previous revision Previous revision Next revision | Previous revision |
| fxdemo:01-part:08-conceptual-runtime-plane-model:08-1-overview [2026/06/29 13:51] – ↷ Page moved from fxdemo:01-part:08-1-overview to fxdemo:01-part:08-conceptual-runtime-plane-model:08-1-overview nick_dido | fxdemo:01-part:08-conceptual-runtime-plane-model:08-1-overview [2026/07/18 12:33] (current) – external edit 127.0.0.1 |
|---|
| [[fxdemo:01-part:start | Go to Top ]] | [[fxdemo:01-part:start | Go to Top ]] |
| |
| 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. | The Conceptual [[dido:99_annexes:annex-b-terms-and-definitions:r:runtime_plane|Runtime Plane]] Model classifies runtime communication and behavior by architectural purpose. It helps authors and reviewers distinguish operational coordination, [[dido:99_annexes:annex-b-terms-and-definitions:d:data_plane|Data Plane]] information exchange, health reporting, policy-governed release, and audit/provenance activity before later parts map those concerns to technologies, deployment artifacts, or [[dido:99_annexes:annex-b-terms-and-definitions:e:evidence|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. | [[dido:99_annexes:annex-b-terms-and-definitions:r:runtime_plane|Runtime Plane]]s do not define implementation mechanisms. A later implementation profile may realize [[dido:99_annexes:annex-b-terms-and-definitions:r:runtime_plane|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. | Figure 8.1-1 identifies the conceptual Runtime Planes used by the Financial Systems Archetype. |
| Figure 8.1-1: Conceptual Runtime Plane Model | 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. | The model preserves separation between different runtime concerns while allowing explicit cross-plane relationships. For example, a [[dido:99_annexes:annex-b-terms-and-definitions:h:health_and_observability_plane|Health and Observability Plane]] event may trigger a [[dido:99_annexes:annex-b-terms-and-definitions:c:control_plane|Control Plane]] recovery command, a [[dido:99_annexes:annex-b-terms-and-definitions:d:data_plane|Data Plane]] event may require [[dido:99_annexes:annex-b-terms-and-definitions:p:policy_and_release_plane|Policy and Release Plane]] evaluation, and a [[dido:99_annexes:annex-b-terms-and-definitions:p:policy_and_release_plane|Policy and Release Plane]] decision may create an [[dido:99_annexes:annex-b-terms-and-definitions:a:audit_and_provenance_plane|Audit and Provenance Plane]] record. These relationships must remain explicit and [[dido:99_annexes:annex-b-terms-and-definitions:t:traceability|Traceable]] so one plane does not silently absorb or redefine another. |
| | |
| | ---- |
| | |
| | <WRAP centeralign> |
| | |
| | © 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc. |
| | |
| | </WRAP> |
| |