====== 12.1 Purpose of the Data Plane in Phase 0 ====== [[fxdemo:05-part:start | Go To Top ]] [[fxdemo:05-part:12-data-plane-topics:start | Return to Data Plane Topics ]] The [[dido:99_annexes:annex-b-terms-and-definitions:d:data_plane|Data Plane]] supports the exchange of typed domain data between [[dido:99_annexes:annex-b-terms-and-definitions:n:node|Nodes]]. It represents the path through which later phases will move FX transaction data, validation results, ACTUS-related requests and outputs, [[dido:99_annexes:annex-b-terms-and-definitions:p:provenance|Provenance]] records, audit events, and release-related Artifacts. Phase 0 does not need to implement the full financial-processing Data Plane. Instead, it should establish the basic discipline that later Data Plane work will follow. That discipline includes governed Topic names, [[dido:99_annexes:annex-b-terms-and-definitions:i:idl|IDL]]-derived data structures, defined publishers and subscribers, documented QoS expectations, repeatable generation, validation checks, and [[dido:99_annexes:annex-b-terms-and-definitions:t:traceability|Traceability]] to the FX Demo Logical Profile. The team should use Data Plane Topics in Phase 0 only where they support the demonstration Baseline. A Topic should not enter the Data Plane merely because the architecture may need it later. If a future Topic does not yet participate in the Phase 0 Node network, the team should record it as a future Topic candidate rather than adding an unused implementation Artifact. The Data Plane should remain separate from the [[dido:99_annexes:annex-b-terms-and-definitions:c:control_plane|Control Plane]]. Data Plane Topics should not carry Node Lifecycle status, runtime commands, command acknowledgements, operational health messages, or other control messages unless the architecture explicitly defines an exception. ---- © 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc.