====== 3.3 Traceability to Part 1 Conceptual Architecture ======

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

Part 1 defines the conceptual foundation for the Financial Systems Archetype. This part preserves that foundation by ensuring that Phase 0 implementation artifacts trace back to the applicable conceptual elements through Part 2 and Part 3.

The Phase 0 Implementation Profile does not redefine the concepts in Part 1. It maps implementation artifacts to FX logical elements that already specialize inherited conceptual elements. An implementation Node traces through an FX logical [[dido:99_annexes:annex-b-terms-and-definitions:l:logical_node|Node]] to a [[dido:99_annexes:annex-b-terms-and-definitions:l:logical_node|Node]]. A [[dido:99_annexes:annex-b-terms-and-definitions:d:dds|DDS]] Topic traces through an FX logical [[dido:99_annexes:annex-b-terms-and-definitions:l:logical_communication_endpoint|Communication Endpoint]] to a Communication Endpoint. An [[dido:99_annexes:annex-b-terms-and-definitions:i:idl|IDL]] structure or generated type traces through an FX logical information structure to a Data Structure Definition or Data Structure Instance. Implementation-level evidence hooks trace through FX evidence expectations to [[dido:99_annexes:annex-b-terms-and-definitions:e:evidence|Evidence]] and [[dido:99_annexes:annex-b-terms-and-definitions:t:traceability|Traceability]].

<WRAP table-caption>
**Table 3-3:** Part 1 concepts preserved by the Phase 0 Implementation Profile.
</WRAP>

^ Part 1 concept ^ Part 4: Phase 0 implementation treatment ^
| Node | Implementation Nodes, modules, processes, or runtime participants realize selected FX logical [[dido:99_annexes:annex-b-terms-and-definitions:l:logical_node|Nodes]] without redefining the Node concept. |
| Node Identity | Implementation identifiers preserve [[dido:99_annexes:annex-b-terms-and-definitions:t:traceability|traceability]] to FX logical Node identities. |
| Node Role | Implementation modules or responsibilities realize selected FX logical [[dido:99_annexes:annex-b-terms-and-definitions:l:logical_node_role|Node Roles]] without redefining the Node Role concept. |
| Runtime Plane | Implementation groupings, topic conventions, logging conventions, and runtime conventions preserve [[dido:99_annexes:annex-b-terms-and-definitions:r:runtime_plane|Runtime Plane]] distinctions. |
| Communication Endpoint | [[dido:99_annexes:annex-b-terms-and-definitions:d:dds|DDS]] Topics or selected communication artifacts realize FX logical [[dido:99_annexes:annex-b-terms-and-definitions:l:logical_communication_endpoint|Communication Endpoints]]. |
| Data Structure Definition | [[dido:99_annexes:annex-b-terms-and-definitions:i:idl|IDL]] structures, generated types, and implementation data representations realize FX logical information definitions. |
| Data Structure Instance | Runtime messages, samples, records, commands, acknowledgements, and generated type instances realize FX logical information instances. |
| Evidence | Implementation artifacts prepare for later [[dido:99_annexes:annex-b-terms-and-definitions:e:evidence|evidence]] capture, preservation, and review in Part 5. |
| Traceability | Implementation mappings preserve forward and backward [[dido:99_annexes:annex-b-terms-and-definitions:t:traceability|traceability]] among conceptual, logical, FX logical, and implementation artifacts. |
| Governance and Authority | Implementation conventions preserve governance, versioning, compatibility, change control, and review expectations. |

----

<WRAP centeralign>

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

</WRAP>