===== 3.1 Traceability to SIP-RA ======
[[fxdemo:01-part:start | Go to Top ]]

SIP-RA supplies the parent architecture discipline for structured information processing systems. The Financial Systems Archetype specializes in [[dido:99_annexes:annex-b-terms-and-definitions:f:financial_system|Financial Systems]].

SIP-RA addresses structured information processing across domains where organizations must process structured artifacts, interpret [[dido:99_annexes:annex-b-terms-and-definitions:d:data|Data]], govern meaning, support [[dido:99_annexes:annex-b-terms-and-definitions:t:traceability|Traceable]] transformations, and preserve auditability and review. The Financial Systems Archetype carries those concerns into the [[dido:99_annexes:annex-b-terms-and-definitions:f:finance_ecosphere|Finance Ecosphere]] while preserving platform independence and implementation neutrality.

Part 1 preserves the following SIP-RA concerns at the conceptual level.

Table 3-1: SIP-RA concerns addressed by the Conceptual Architecture

^ SIP-RA concern ^ Part 1 treatment ^
| Separation of [[dido:99_annexes:annex-b-terms-and-definitions:d:data|Data]], [[dido:99_annexes:annex-b-terms-and-definitions:s:structure|Structure]], [[dido:99_annexes:annex-b-terms-and-definitions:s:semantic|Semantics]], and [[dido:99_annexes:annex-b-terms-and-definitions:i:interpretation|Interpretation]] | Defines separation of concerns as a conceptual principle. |
| Governed processing across boundaries | Defines [[dido:99_annexes:annex-b-terms-and-definitions:r:runtime_plane|Runtime Plane]]s, [[dido:99_annexes:annex-b-terms-and-definitions:t:traceability|Traceability]], [[dido:99_annexes:annex-b-terms-and-definitions:e:evidence|Evidence]], and governance of meaning. |
| Explicit architectural roles and responsibilities | Defines core conceptual elements, including [[dido:99_annexes:annex-b-terms-and-definitions:f:financial_node|Node]], [[dido:99_annexes:annex-b-terms-and-definitions:n:node_role|Node Role]], [[dido:99_annexes:annex-b-terms-and-definitions:c:communication_endpoint|Communication Endpoint]], [[dido:99_annexes:annex-b-terms-and-definitions:d:data_structure_definition|Data Structure Definition]], [[dido:99_annexes:annex-b-terms-and-definitions:r:runtime_plane|Runtime Plane]], and [[dido:99_annexes:annex-b-terms-and-definitions:e:evidence|Evidence]]. |
| Traceable [[dido:99_annexes:annex-b-terms-and-definitions:i:interpretation|Interpretation]] | Defines [[dido:99_annexes:annex-b-terms-and-definitions:t:traceability|Traceability]] as a conceptual element and architectural principle. |
| Platform independence | Keeps DDS, IDL, Python, Kubernetes, K3s, Docker, RTI Connext DDS, and Crucible out of the conceptual layer. |
| Audit and review | Treats [[dido:99_annexes:annex-b-terms-and-definitions:e:evidence|Evidence]], auditability, and provenance as architectural concerns. |
| Evolvability without loss of comparability | Preserves conceptual separation so later parts can evolve implementation and deployment profiles without redefining meaning. |

----

<WRAP centeralign>

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

</WRAP>