Differences

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

--- fxdemo:01-part:08-conceptual-runtime-plane-model:08-7-cross-plane-relationships [2026/06/29 13:51] – removed - external edit (Unknown date) 127.0.0.1
+++ fxdemo:01-part:08-conceptual-runtime-plane-model:08-7-cross-plane-relationships [2026/08/04 07:09] (current) – ↷ Links adapted because of a move operation nick_dido
@@ Line 1: / Line 1: @@
+====== 8.7 Cross-Plane Relationships ======
+[[fxdemo:01-part:start | Go to Top ]]
+Cross-plane relationships occur when an event, decision, message, record, or action in one [[dido:99_annexes:annex-b-terms-and-definitions:r:runtime_plane|Runtime Plane]] affects, references, constrains, or produces information in another [[dido:99_annexes:annex-b-terms-and-definitions:r:runtime_plane|Runtime Plane]].
+The Financial Systems Archetype separates [[dido:99_annexes:annex-b-terms-and-definitions:r:runtime_plane|Runtime Plane]]s to preserve architectural clarity. That separation does not mean the planes operate in isolation. A [[dido:99_annexes:annex-b-terms-and-definitions:f:financial_system|Financial System]] often requires interactions across planes, but those interactions need to remain explicit, [[dido:99_annexes:annex-b-terms-and-definitions:t:traceability|Traceable]], and governed.
+For example, a health event in the [[dido:99_annexes:annex-b-terms-and-definitions:h:health_and_observability_plane|Health and Observability Plane]] may trigger a recovery command in the [[dido:99_annexes:annex-b-terms-and-definitions:c:control_plane|Control Plane]]. A [[dido:99_annexes:annex-b-terms-and-definitions:d:data_plane|Data Plane]] event may require a policy decision in the [[dido:99_annexes:annex-b-terms-and-definitions:p:policy_and_release_plane|Policy and Release Plane]] before information leaves an internal environment. A [[dido:99_annexes:annex-b-terms-and-definitions:p:policy_and_release_plane|Policy and Release Plane]] decision may generate an audit record in the [[dido:99_annexes:annex-b-terms-and-definitions:a:audit_and_provenance_plane|Audit and Provenance Plane]]. A [[dido:99_annexes:annex-b-terms-and-definitions:c:control_plane|Control Plane]] replay command may cause a [[dido:99_annexes:annex-b-terms-and-definitions:f:financial_node|Node]] to republish [[dido:99_annexes:annex-b-terms-and-definitions:d:data_plane|Data Plane]] information from preserved [[dido:99_annexes:annex-b-terms-and-definitions:e:evidence|Evidence]] or persisted records. Cross-plane relationships must not collapse the planes into one another. The architectural purpose of each plane remains distinct even when information flows between planes.
+A cross-plane relationship can identify:
+  * Originating [[dido:99_annexes:annex-b-terms-and-definitions:r:runtime_plane|Runtime Plane]]
+  * Receiving or affected [[dido:99_annexes:annex-b-terms-and-definitions:r:runtime_plane|Runtime Plane]]
+  * Event, message, decision, or record causing the relationship
+  * [[dido:99_annexes:annex-b-terms-and-definitions:f:financial_node|Node]] or [[dido:99_annexes:annex-b-terms-and-definitions:n:node_role|Node Role]] participating in the relationship
+  * [[dido:99_annexes:annex-b-terms-and-definitions:c:communication_endpoint|Communication Endpoint]] or mechanism involved
+  * [[dido:99_annexes:annex-b-terms-and-definitions:d:data_structure_definition|Data Structure Definition]] governing the exchanged information, where applicable
+  * The policy, rule, or condition authorizing the relationship, where applicable
+  * [[dido:99_annexes:annex-b-terms-and-definitions:t:traceability_and_evidence|Traceability and Evidence]] record supporting later review
+Examples of cross-plane relationships appear in Table 8.7-1.
+Table 8.7-1: Examples of cross-plane relationships among Runtime Planes
+^ Originating plane ^ Affected plane ^ Example ^
+| [[dido:99_annexes:annex-b-terms-and-definitions:h:health_and_observability_plane|Health and Observability Plane]] | [[dido:99_annexes:annex-b-terms-and-definitions:c:control_plane|Control Plane]] | A degraded [[dido:99_annexes:annex-b-terms-and-definitions:f:financial_node|Node]] status triggers a restart, retry, or recovery command. |
+| [[dido:99_annexes:annex-b-terms-and-definitions:d:data_plane|Data Plane]] | [[dido:99_annexes:annex-b-terms-and-definitions:p:policy_and_release_plane|Policy and Release Plane]] | A transaction result requires an evaluation for release before an external consumer receives it. |
+| [[dido:99_annexes:annex-b-terms-and-definitions:p:policy_and_release_plane|Policy and Release Plane]] | [[dido:99_annexes:annex-b-terms-and-definitions:a:audit_and_provenance_plane|Audit and Provenance Plane]] | A release decision creates an audit and provenance record. |
+| [[dido:99_annexes:annex-b-terms-and-definitions:c:control_plane|Control Plane]] | [[dido:99_annexes:annex-b-terms-and-definitions:d:data_plane|Data Plane]] | A replay command causes selected [[dido:99_annexes:annex-b-terms-and-definitions:d:data_plane|Data Plane]] records to be republished. |
+| [[dido:99_annexes:annex-b-terms-and-definitions:d:data_plane|Data Plane]] | [[dido:99_annexes:annex-b-terms-and-definitions:a:audit_and_provenance_plane|Audit and Provenance Plane]] | An analytical assertion creates provenance that links inputs, producing a [[dido:99_annexes:annex-b-terms-and-definitions:f:financial_node|Node]], model version, and output. |
+Cross-plane relationships support operational coordination, governed release, auditability, replay, recovery, and [[dido:99_annexes:annex-b-terms-and-definitions:e:evidence|Evidence]]. They also help reviewers understand how the system behaves without losing the separation between runtime concerns.
+----
+<WRAP centeralign>
+© 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc.
+</WRAP>