Differences

This shows you the differences between two versions of the page.

--- fxdemo:01-part:04-traceability-to-parent-and-source-architectures:04-1-traceability-to-sip-ra [2026/06/24 17:43] – removed - external edit (Unknown date) 127.0.0.1
+++ fxdemo:01-part:04-traceability-to-parent-and-source-architectures:04-1-traceability-to-sip-ra [2026/08/04 07:09] (current) – ↷ Links adapted because of a move operation nick_dido
@@ Line 1: / Line 1: @@
+===== 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>