====== 5.6 Logical Runtime Plane Model ====== [[fxdemo:02-part:start | Go To Top ]] The logical [[dido:99_annexes:annex-b-terms-and-definitions:r:runtime_plane|Runtime Plane]] model preserves the conceptual [[dido:99_annexes:annex-b-terms-and-definitions:r:runtime_plane|Runtime Planes]] defined in Part 1 and applies them to logical interactions. The logical Runtime Planes include: * [[dido:99_annexes:annex-b-terms-and-definitions:l:logical_control_plane|Logical Control Plane]] * [[dido:99_annexes:annex-b-terms-and-definitions:l:logical_data_plane|Logical Data Plane]] * [[dido:99_annexes:annex-b-terms-and-definitions:l:logical_health_and_observability_plane|Logical Health and Observability Plane]] * [[dido:99_annexes:annex-b-terms-and-definitions:l:logical_policy_and_release_plane|Logical Policy and Release Plane]] * [[dido:99_annexes:annex-b-terms-and-definitions:l:logical_audit_and_provenance_plane|Logical Audit and Provenance Plane]] Each logical interaction belongs to one or more logical Runtime Planes according to architectural purpose. A health report belongs to the Health and Observability Plane. A command belongs to the Control Plane. A transaction event belongs to the Data Plane. A release decision belongs to the Policy and Release Plane. A provenance record belongs to the Audit and Provenance Plane. Cross-plane relationships occur when one plane affects another. Examples include a health observation triggering a control command, a data-plane result requiring release evaluation, and a release decision generating an audit and provenance record. The Logical Architecture preserves the distinction among planes even when interactions connect them. ---- © 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc.