Show pageOld revisionsBacklinksAdd to bookExport to PDFODT exportBack to top This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong. ====== 1. Scope ====== [[fxdemo:04-part:start | Go To Top ]] This part defines the Phase 0 Implementation Profile / Platform-Specific Model (PSM) for the Financial Systems Archetype. This part defines a phase-specific implementation profile. The Phase 0 Implementation Profile / PSM establishes the implementation baseline for the Phase 0 FX Demo. Later development phases may define additional implementation profiles that extend, refine, supersede, or replace this profile while preserving [[dido:99_annexes:annex-b-terms-and-definitions:t:traceability|traceability]] to the applicable conceptual, logical, and domain logical profile elements. This part maps selected elements of the Part 3 FX Demo Logical Profile to Phase 0 implementation technologies and implementation artifacts. Those elements include selected 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 Plane]] classifications, interaction patterns, governance relationships, [[dido:99_annexes:annex-b-terms-and-definitions:t:traceability|traceability]] relationships, and logical requirements. This part applies to the platform-specific implementation profile for Phase 0. It defines how the Phase 0 implementation profile maps selected FX logical elements to [[dido:99_annexes:annex-b-terms-and-definitions:d:dds|DDS]] communication, [[dido:99_annexes:annex-b-terms-and-definitions:i:idl|IDL]] structures, generated types, Quality of Service (QoS) profiles, implementation Nodes, implementation modules, scripts, repository structure, configuration artifacts, build artifacts, and supporting implementation conventions. This part establishes implementation discipline for Phase 0. It identifies the preconditions that must be in place before coding begins, including the required Phase 0 Developer Handbook. The Developer Handbook defines file-header conventions, generated-file rules, coding standards, naming conventions, logging conventions, exception-handling patterns, repository workflow, and review expectations. This part does not define the final implementation architecture for all development phases. It defines the selected Phase 0 implementation architecture and the implementation discipline required before Phase 0 coding begins. This part does not implement the later Policy / Governance Plane or Release Plane extensions anticipated for Phase 2. Phase 0 remains limited to the selected implementation baseline defined in this part. However, Phase 0 implementation artifacts, topic mappings, [[dido:99_annexes:annex-b-terms-and-definitions:i:idl|IDL]] structures, generated types, scripts, repository conventions, logging conventions, exception-handling conventions, and [[dido:99_annexes:annex-b-terms-and-definitions:t:traceability|traceability]] records should not preclude later addition of distributed policy enforcement, replicated policy decision capability, policy administration, policy information sources, metadata or aggregate view generation, release gateways, recipient-specific release products, release obligations, or release evidence. This part does not redefine the Part 1 Conceptual Architecture, the Part 2 Logical Architecture / [[dido:99_annexes:annex-b-terms-and-definitions:p:platform_independent_model|Platform-Independent Model (PIM)]], or the Part 3 FX Demo Logical Profile. Implementation artifacts realize selected logical elements; they do not redefine them. This part does not define Kubernetes or K3s deployment, runtime operations, operational dashboards, Crucible scenario execution, acceptance evidence, runtime evidence, final test results, or evidence packages. Part 5 addresses deployment, testability, runtime operation, observation, and [[dido:99_annexes:annex-b-terms-and-definitions:e:evidence|evidence]] for the selected Phase 0 implementation. This part guides authors, implementers, and reviewers in preserving [[dido:99_annexes:annex-b-terms-and-definitions:t:traceability|traceability]] from Phase 0 implementation artifacts back to the FX logical elements defined in Part 3. ---- <WRAP centeralign> © 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc. </WRAP> fxdemo/04-part/01-scope/start.txt Last modified: 2026/07/22 18:54by owen