Differences

This shows you the differences between two versions of the page.

--- fxdemo:01-part:08-conceptual-runtime-plane-model:08-1-overview [2026/06/30 15:59] – owen
+++ fxdemo:01-part:08-conceptual-runtime-plane-model:08-1-overview [2026/07/18 12:33] (current) – external edit 127.0.0.1
@@ Line 1: / Line 1: @@
 ====== 8.1 Overview ======
 [[fxdemo:01-part:start | Go to Top ]]
-The Conceptual [[fxdemo:99_part_annexes:annex-b-terms-and-definitions:r:runtime_plane|Runtime Plane]] Model classifies runtime communication and behaviour by architectural purpose. It helps authors and reviewers distinguish operational coordination, [[fxdemo:99_part_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 artefacts, or [[fxdemo:99_part_annexes:annex-b-terms-and-definitions:e:evidence|Evidence]] packages.
-[[fxdemo:99_part_annexes:annex-b-terms-and-definitions:r:runtime_plane|Runtime Plane]]s do not define implementation mechanisms. A later implementation profile may realise [[fxdemo:99_part_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.
+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.
+[[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.
@@ Line 14: / Line 15: @@
 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 [[fxdemo:99_part_annexes:annex-b-terms-and-definitions:h:health_and_observability_plane|Health and Observability Plane]] event may trigger a [[fxdemo:99_part_annexes:annex-b-terms-and-definitions:c:control_plane|Control Plane]] recovery command, a [[fxdemo:99_part_annexes:annex-b-terms-and-definitions:d:data_plane|Data Plane]] event may require [[fxdemo:99_part_annexes:annex-b-terms-and-definitions:p:policy_and_release_plane|Policy and Release Plane]] evaluation, and a [[fxdemo:99_part_annexes:annex-b-terms-and-definitions:p:policy_and_release_plane|Policy and Release Plane]] decision may create an [[fxdemo:99_part_annexes:annex-b-terms-and-definitions:a:audit_and_provenance_plane|Audit and Provenance Plane]] record. These relationships must remain explicit and [[fxdemo:99_part_annexes:annex-b-terms-and-definitions:t:traceability|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>