====== 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>