DIDO Solutions technical documentation and FX Demo knowledge base https://wiki.didosolutions.com/ 2026-08-24T06:09:09+00:00 https://wiki.didosolutions.com/ https://wiki.didosolutions.com/_media/wiki/logo.png text/html 2026-07-18T19:33:44+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/fxdemo/01-part/10-conceptual-traceability-model/10-1-overview?rev=1784403224&do=diff 10.1 Overview Go to Top The Conceptual Traceability Model defines how the Financial Systems Archetype preserves relationships among conceptual elements, logical elements, implementation artifacts, deployment artifacts, and Evidence. Traceability allows authors, reviewers, implementers, testers, operators, and auditors to understand how a concern moves through the document set. It also supports impact analysis when a concept, logical element, implementation artifact, deployment artifact, or text/html 2026-07-18T19:33:44+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/fxdemo/01-part/10-conceptual-traceability-model/10-2-traceability-across-layers?rev=1784403224&do=diff 10.2 Traceability Across Layers Go to Top Traceability across layers preserves architectural meaning as later parts specialize, realize, deploy, and provide Evidence for the conceptual architecture. Each layer has a distinct Traceability responsibility: Table 10.2-1: Traceability responsibilities across architectural layers text/html 2026-08-04T14:09:25+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/fxdemo/01-part/10-conceptual-traceability-model/10-3-conceptual-element-to-logical-element-pim?rev=1785852565&do=diff 10.3 Conceptual Element to Logical Element / PIM Go to Top A Conceptual Element traces to a Logical Element / Platform Independent Model (PIM) when the logical architecture specializes the concept without binding it to a specific implementation technology. For example, the concept Communication Endpoint may trace to a logical endpoint used for health reporting, work dispatch, transaction publication, validation results, policy decisions, or audit records. The logical endpoint remains text/html 2026-08-04T14:09:25+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/fxdemo/01-part/10-conceptual-traceability-model/10-4-logical-element-pim-to-implementation-artefact-psm?rev=1785852565&do=diff 10.4 Logical Element / PIM to Implementation Artifact / PSM Go to Top A Logical Element / PIM traces to an Implementation Artifact / PSM when an implementation profile maps the Platform Independent Model (PIM) to selected technologies. For example, a logical Communication Endpoint may map to a DDS Topic in a DDS-based implementation profile. A logical text/html 2026-08-04T14:09:25+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/fxdemo/01-part/10-conceptual-traceability-model/10-5-implementation-artefact-psm-to-deployment-artefact?rev=1785852565&do=diff 10.5 Implementation Artifact / PSM to Deployment Artifact Go to Top An Implementation Artifact / PSM traces to a Deployment Artifact when a deployment profile describes how the implementation runs in a concrete environment. For example, a container image may trace to a Kubernetes Deployment, Pod, or Helm chart. A DDS QoS profile may trace to a mounted configuration file or ConfigMap. A generated IDL binding may trace to a deployed service image using that binding. text/html 2026-08-04T14:09:25+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/fxdemo/01-part/10-conceptual-traceability-model/10-6-deployment-artefact-to-evidence?rev=1785852565&do=diff 10.6 Deployment Artifact to Evidence Go to Top A Deployment Artifact traces to Evidence when recorded information supports a claim about the deployed system. Evidence may support claims about deployment, execution, configuration, communication, health, recovery, policy enforcement, release, audit, provenance, or test results. text/html 2026-08-04T14:09:25+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/fxdemo/01-part/10-conceptual-traceability-model/10-7-bidirectional-review-and-impact-analysis?rev=1785852565&do=diff 10.7 Bidirectional Review and Impact Analysis Go to Top Traceability supports review in two directions. Forward Traceability starts with a conceptual concern and follows it outward through logical design, implementation mapping, deployment, and Evidence. It helps reviewers confirm that the system implements and evidences the intended architecture. text/html 2026-07-18T19:33:44+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/fxdemo/01-part/10-conceptual-traceability-model/10-8-traceability-boundaries?rev=1784403224&do=diff 10.8 Traceability Boundaries Go to Top Traceability has boundaries. The document set can preserve meaningful relationships without creating unnecessary administrative burden. A Traceability relationship can exist when it supports architecture review, implementation mapping, deployment verification, text/html 2026-07-07T23:50:26+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/fxdemo/01-part/10-conceptual-traceability-model/start?rev=1783468226&do=diff 10. Conceptual Traceability Model Go to Top The Conceptual Traceability Model defines the conceptual relationships that preserve traceability among the concepts of the Financial Systems Archetype. It provides the foundation for tracing conceptual meaning through later logical models, implementation profiles, deployment profiles, testability, and evidence while preserving the integrity of the conceptual architecture.10-conceptual-traceability-model index