DIDO Solutions technical documentation and FX Demo knowledge base https://wiki.didosolutions.com/ 2026-08-23T00:04: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/11-conceptual-rules-and-constraints/11-1-overview?rev=1784403224&do=diff 11.1 Overview Go to Top The Conceptual Rules and Constraints define the conceptual boundaries that later parts must preserve when they specialize, realize, deploy, test, or provide Evidence for the Financial Systems Archetype. These rules protect the separation between conceptual meaning, logical text/html 2026-08-04T14:09:25+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/fxdemo/01-part/11-conceptual-rules-and-constraints/11-2-conceptual-elements-remain-distinct?rev=1785852565&do=diff 11.2 Conceptual Elements Remain Distinct Go to Top The Financial Systems Archetype keeps core conceptual elements distinct. A Node is not a Node Role. A Node Identity is not a container name. A Communication Endpoint is not the Data Structure Instance it carries. A Data Structure Definition is not a Data Structure Instance. A Runtime Plane is not a DDS Domain, DDS partition, Kubernetes namespace, or network segment. text/html 2026-08-04T14:09:25+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/fxdemo/01-part/11-conceptual-rules-and-constraints/11-3-conceptual-architecture-does-not-prescribe-realisation-mechanisms?rev=1785852565&do=diff 11.3 Conceptual Architecture Does Not Prescribe Realization Mechanisms Go to Top The Conceptual Architecture defines architectural responsibilities and relationships. It does not prescribe execution granularity, deployment granularity, communication technology, interface style, text/html 2026-07-18T19:33:44+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/fxdemo/01-part/11-conceptual-rules-and-constraints/11-4-classification-values-do-not-define-runtime-boundaries?rev=1784403224&do=diff 11.4 Classification Values Do Not Define Runtime Boundaries Go to Top Classification values identify governed business and Semantic scope. They do not define Runtime communication boundaries, deployment boundaries, security zones, repository paths, or executable artifacts. For example, the classification path: text/html 2026-07-18T19:33:44+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/fxdemo/01-part/11-conceptual-rules-and-constraints/11-5-runtime-planes-remain-conceptual-classifications?rev=1784403224&do=diff 11.5 Runtime Planes Remain Conceptual Classifications Go to Top Runtime Planes classify communication and behavior by architectural purpose. They do not prescribe implementation mechanisms. A later implementation profile may realize Runtime Plane separation through DDS Topics, topic namespaces, partitions, APIs, queues, services, security policies, network segmentation, or deployment configuration. Those mechanisms support plane separation, but they do not define the text/html 2026-08-04T14:09:25+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/fxdemo/01-part/11-conceptual-rules-and-constraints/11-6-implementation-mappings-do-not-redefine-concepts?rev=1785852565&do=diff 11.6 Implementation Mappings Do Not Redefine Concepts Go to Top Implementation mappings realize conceptual and logical elements for a specific technology stack. They do not redefine the concepts they realize. For example, a Phase 0 implementation profile may map: text/html 2026-08-04T14:09:25+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/fxdemo/01-part/11-conceptual-rules-and-constraints/11-7-deployment-artefacts-do-not-redefine-implementation-artefacts?rev=1785852565&do=diff 11.7 Deployment Artifacts Do Not Redefine Implementation Artifacts Go to Top Deployment artifacts describe how implementation artifacts run in a concrete environment. They do not redefine the implementation artifacts or the conceptual elements behind them. text/html 2026-07-11T18:15:17+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/fxdemo/01-part/11-conceptual-rules-and-constraints/11-8-evidence-supports-claims?rev=1783793717&do=diff 11.8 Evidence Supports Claims Go to Top Evidence supports claims about architecture, implementation, deployment, execution, Interpretation, Governance and Authority, or review. Evidence does not replace the claim it supports. A log file, captured message, test result, provenance record, deployment record, or release audit entry contributes to text/html 2026-07-18T19:33:44+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/fxdemo/01-part/11-conceptual-rules-and-constraints/11-9-traceability-preserves-layering?rev=1784403224&do=diff 11.9 Traceability Preserves Layering Go to Top Traceability connects conceptual elements, logical elements, implementation artifacts, deployment artifacts, and Evidence. It allows reviewers to understand how a concern moves through the document set without allowing later layers to redefine earlier layers. text/html 2026-07-18T19:33:44+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/fxdemo/01-part/11-conceptual-rules-and-constraints/11-10-local-profiles-must-preserve-parent-meaning?rev=1784403224&do=diff 11.10 Local Profiles Must Preserve Parent Meaning Go to Top A Domain profile, implementation profile, or deployment profile may specialize, realize, deploy, or test parent-layer concepts. It does not change the meaning of those parent-layer concepts. A profile may introduce additional terms, mappings, constraints, or artifacts when needed. It can identify those additions clearly and distinguish them from inherited concepts. text/html 2026-07-18T19:33:44+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/fxdemo/01-part/11-conceptual-rules-and-constraints/11-11-conceptual-constraints-summary?rev=1784403224&do=diff 11.11 Conceptual Constraints Summary Go to Top The Conceptual Architecture applies the following constraints: Conceptual elements remain distinct from one another.Conceptual architecture does not prescribe execution granularity, deployment granularity, communication technology, interface style, text/html 2026-07-07T23:54:24+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/fxdemo/01-part/11-conceptual-rules-and-constraints/start?rev=1783468464&do=diff 11. Conceptual Rules and Constraints Go to Top The Conceptual Rules and Constraints define the conceptual boundaries that preserve the meaning, consistency, and integrity of the Financial Systems Archetype. These rules ensure that conceptual elements remain independent of logical, implementation, deployment, testability, and evidence concerns while providing a stable foundation for all later architectural specialisations.11-conceptual-rules-and-constraints index