Logical Runtime Plane Traceability [Dido Solutions, Inc Wiki]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Logical Runtime Plane Traceability ======

[[dido:99_annexes:annex-b-terms-and-definitions:l:start|Return to L Terms]]

===== Discussion =====

Logical Runtime Plane Traceability relates a logical interaction to the Runtime Plane that frames its architectural purpose.

Logical Runtime Plane Traceability helps reviewers distinguish control, data, health and observability, policy, release, and audit and provenance concerns. It also supports cross-plane review by identifying when one plane affects, constrains, or produces information for another plane.

Logical Runtime Plane Traceability preserves the separation of runtime concerns, even when an interaction spans multiple planes.

===== Definition =====

//Traceability relationship connecting logical interactions and information exchanges to their Logical Runtime Plane classification.//

===== Source =====

Specialization of Runtime Plane and Traceability from Part 1, Sections 7.5 and 7.10; generalised from runtime-plane and cross-plane material in the original FX Demo Reference Architecture.

===== Note =====

Logical Runtime Plane Traceability does not prescribe DDS partitions, topic namespaces, Kubernetes namespaces, network segments, security zones, or implementation groupings.

===== Example =====

A degraded-status event traces to the Logical Health and Observability Plane. A recovery command triggered by that event traces to the Logical Control Plane. The relationship between those interactions identifies the cross-plane trace.

----

[[dido:99_annexes:annex-b-terms-and-definitions:l:start|Return to Top]]

----

<WRAP centeralign>
© 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc.
</WRAP>