====== 3.5 Traceability to Part 3 FX Demo Logical Profile ======

[[fxdemo:04-part:03-traceability-to-parent-and-source-architectures:start | Go To Traceability to Parent and Source Architectures ]]

Part 3 defines the FX Demo Logical Profile. This section maps selected elements of the Part 3 FX logical profile to Phase 0 implementation artifacts.

Part 3 remains the authoritative source for FX logical [[dido:99_annexes:annex-b-terms-and-definitions:l:logical_node|Nodes]], logical [[dido:99_annexes:annex-b-terms-and-definitions:l:logical_node_role|Node Roles]], logical [[dido:99_annexes:annex-b-terms-and-definitions:l:logical_communication_endpoint|Communication Endpoints]], logical information structures, [[dido:99_annexes:annex-b-terms-and-definitions:r:runtime_plane|Runtime Planes]], interaction patterns, governance relationships, [[dido:99_annexes:annex-b-terms-and-definitions:t:traceability|traceability]] relationships, and logical requirements. This part does not redefine those elements. It selects Phase 0 implementation technologies and implementation artifacts that realize them.

<WRAP table-caption>
**Table 3-5:** Part 3 FX logical profile elements mapped by the Phase 0 Implementation Profile.
</WRAP>

^ Part 3 FX logical profile element ^ Part 4: Phase 0 implementation treatment ^
| FX logical Nodes | Mapped to selected implementation Nodes, modules, process entry points, or runtime participants. |
| FX logical Node Roles | Mapped to implementation responsibilities, modules, functions, classes, or service behaviors. |
| FX logical Communication Endpoints | Mapped to [[dido:99_annexes:annex-b-terms-and-definitions:d:dds|DDS]] Topics or other selected Phase 0 communication artifacts. |
| FX logical information structures | Mapped to [[dido:99_annexes:annex-b-terms-and-definitions:i:idl|IDL]] structures, generated types, and implementation data representations. |
| FX Runtime Planes | Mapped to implementation conventions, topic naming conventions, package groupings, logging categories, and operational conventions. |
| FX lifecycle states | Mapped to implementation-level state values, status messages, command acknowledgements, or recorded state transitions where Phase 0 requires them. |
| FX interaction patterns | Mapped to Phase 0 message flows, command flows, processing flows, scripts, or demonstration behaviors. |
| FX governance relationships | Mapped to versioning rules, compatibility rules, generation rules, repository rules, and review expectations. |
| FX traceability relationships | Mapped to [[dido:99_annexes:annex-b-terms-and-definitions:t:traceability|traceability]] tables, artifact metadata, file headers, generated-file markings, and implementation documentation. |
| FX logical requirements | Mapped to implementation requirements and acceptance preconditions for later deployment and [[dido:99_annexes:annex-b-terms-and-definitions:e:evidence|evidence]] planning. |

----

<WRAP centeralign>

© 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc.

</WRAP>