DIDO Solutions technical documentation and FX Demo knowledge base https://wiki.didosolutions.com/ 2026-08-22T23:14:06+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/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-2-001?rev=1784403224&do=diff P2-REQ-16-2-001 Return to Requirements Statement The Logical Architecture / PIM SHALL define a distributed, node-based logical architecture that conforms to the Part 1 Conceptual Architecture. Source Part 2, Section 16.2: Distributed Node-Based Architecture Requirements. text/html 2026-07-18T19:33:44+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-2-002?rev=1784403224&do=diff P2-REQ-16-2-002 Return to Requirements Statement The Logical Architecture / PIM SHALL define one logical architecture and SHALL NOT imply that it represents every possible logical architecture that conforms to Part 1. Source Part 2, Section 16.2: Distributed Node-Based Architecture Requirements. text/html 2026-07-18T19:33:44+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-2-003?rev=1784403224&do=diff P2-REQ-16-2-003 Return to Requirements Statement The Logical Architecture / PIM SHALL organize the architecture around identifiable Logical Nodes. Source Part 2, Section 16.2: Distributed Node-Based Architecture Requirements. Rationale Logical Nodes provide the primary organizing concept for the Logical Architecture. Identifiable Logical Nodes establish clear responsibilities, communication relationships, governance boundaries, traceability, and reviewability while remaining independent … text/html 2026-07-18T19:33:44+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-2-004?rev=1784403224&do=diff P2-REQ-16-2-004 Return to Requirements Statement The Logical Architecture / PIM SHALL distinguish Logical Nodes from runtime deployments, implementation artifacts, deployment artifacts, execution mechanisms, and communication technologies. Source Part 2, Section 16.2: Distributed Node-Based Architecture Requirements. text/html 2026-07-18T19:33:44+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-2-005?rev=1784403224&do=diff P2-REQ-16-2-005 Return to Requirements Statement The Logical Architecture / PIM SHALL NOT prescribe execution granularity, deployment granularity, runtime packaging, deployment topology, communication technology, data serialisation format, programming language, middleware product, orchestration platform, or runtime infrastructure. text/html 2026-07-18T19:33:44+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-3-001?rev=1784403224&do=diff P2-REQ-16-3-001 Return to Requirements Statement The Logical Architecture / PIM SHALL define Logical Node, Logical Node Identity, Logical Node Role, Logical Node Responsibility, Logical Node Boundary, Logical Node Collaboration, and Logical Node Lifecycle State. Source Part 2, Section 16.3: Logical Node Requirements. text/html 2026-07-18T19:33:44+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-3-002?rev=1784403224&do=diff P2-REQ-16-3-002 Return to Requirements Statement A Logical Node SHALL represent a platform-independent participant in the distributed logical architecture. Source Part 2, Section 16.3: Logical Node Requirements. Rationale The Logical Node is the fundamental participant in the Logical Architecture / PIM. Defining it as platform independent ensures that architectural meaning remains separate from implementation technologies, deployment mechanisms, and runtime environments. text/html 2026-07-18T19:33:44+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-3-003?rev=1784403224&do=diff P2-REQ-16-3-003 Return to Requirements Statement A Logical Node Identity SHALL uniquely distinguish a Logical Node within the Logical Architecture / PIM. Source Part 2, Section 16.3: Logical Node Requirements. Rationale Logical Node Identity provides the basis for uniquely identifying Logical Nodes within the Logical Architecture / PIM. Unique identification supports communication, governance, traceability, compatibility assessment, operational review, and implementation mapping. text/html 2026-07-18T19:33:44+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-3-004?rev=1784403224&do=diff P2-REQ-16-3-004 Return to Requirements Statement A Logical Node Role SHALL identify a platform-independent responsibility assigned to or performed by a Logical Node. Source Part 2, Section 16.3: Logical Node Requirements. Rationale Logical Node Roles separate responsibilities from the Logical Nodes that perform them. This separation allows multiple Logical Nodes to perform the same role, a single Logical Node to perform multiple roles, and Domain Logical Profiles to specialize responsibi… text/html 2026-07-18T19:33:44+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-3-005?rev=1784403224&do=diff P2-REQ-16-3-005 Return to Requirements Statement A Logical Node Responsibility SHALL describe an obligation, function, or accountability associated with a Logical Node or Logical Node Role. Source Part 2, Section 16.3: Logical Node Requirements. Rationale Logical Node Responsibilities define what a Logical Node or Logical Node Role is expected to perform. Explicit responsibilities improve architectural clarity, governance, traceability, and implementation consistency while avoiding ambig… text/html 2026-07-18T19:33:44+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-3-006?rev=1784403224&do=diff P2-REQ-16-3-006 Return to Requirements Statement A Logical Node Boundary SHALL identify what the logical architecture treats as inside or outside a Logical Node for responsibility, interaction, Traceability, and review. Source Part 2, Section 16.3: Logical Node Requirements. Rationale Logical Node Boundaries define the scope of a Logical Node and distinguish internal responsibilities from external interactions. Clear boundaries support architectural review, governance, traceability, impl… text/html 2026-07-11T19:57:59+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-3-007?rev=1783799879&do=diff P2-REQ-16-3-007 Return to Requirements Statement Logical Node Collaboration SHALL identify explicit logical cooperation among Logical Nodes through Communication Endpoints and interaction patterns. Source Part 2, Section 16.3: Logical Node Requirements. Rationale Logical Node Collaboration defines how Logical Nodes cooperate without introducing hidden dependencies or implementation-specific relationships. Explicit collaboration improves interoperability, reviewability, governance, and tr… text/html 2026-07-18T19:33:44+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-3-008?rev=1784403224&do=diff P2-REQ-16-3-008 Return to Requirements Statement Logical Node Lifecycle State SHALL identify the logical operational condition associated with a Logical Node. Source Part 2, Section 16.3: Logical Node Requirements. Rationale Logical Node Lifecycle State provides a platform-independent representation of a Logical Node's operational condition. Lifecycle states support monitoring, governance, operational coordination, review, and later implementation mapping without prescribing runtime mech… text/html 2026-07-18T19:33:44+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-3-009?rev=1784403224&do=diff P2-REQ-16-3-009 Return to Requirements Statement The Logical Architecture / PIM SHALL distinguish a Logical Node from a process, service, container, pod, virtual machine, serverless function, thread, task, library, subroutine, RPC endpoint, REST resource, DDS participant, and deployment artifact. text/html 2026-07-18T19:33:44+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-4-001?rev=1784403224&do=diff P2-REQ-16-4-001 Return to Requirements Statement The Logical Architecture / PIM SHALL define Logical Communication Endpoint and Communication Role. Source Part 2, Section 16.4: Logical Communication Requirements. Rationale The Logical Communication Model establishes the platform-independent means by which Logical Nodes exchange information. Defining both Logical Communication Endpoints and Communication Roles provides a consistent foundation for modeling interactions while remaining inde… text/html 2026-07-18T19:33:44+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-4-002?rev=1784403224&do=diff P2-REQ-16-4-002 Return to Requirements Statement The Logical Architecture / PIM SHALL define communication roles for Publisher Role, Subscriber Role, Requester Role, Responder Role, Command Producer Role, Command Consumer Role, Event Producer Role, and Event Consumer Role. Source Part 2, Section 16.4: Logical Communication Requirements. Rationale Communication Roles define the ways in which Logical Nodes participate in Logical Communication Endpoints. Establishing a standard set of commu… text/html 2026-07-18T19:33:44+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-4-003?rev=1784403224&do=diff P2-REQ-16-4-003 Return to Requirements Statement A Logical Communication Endpoint SHALL identify a platform-independent point of information exchange among Logical Nodes. Source Part 2, Section 16.4: Logical Communication Requirements. Rationale Logical Communication Endpoints provide the architectural abstraction through which Logical Nodes exchange information. Treating endpoints as platform-independent concepts preserves architectural meaning while allowing different implementation te… text/html 2026-07-18T19:33:44+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-4-004?rev=1784403224&do=diff P2-REQ-16-4-004 Return to Requirements Statement A Communication Role SHALL identify how a Logical Node participates in a Logical Communication Endpoint. Source Part 2, Section 16.4: Logical Communication Requirements. Rationale Communication Roles describe the manner in which Logical Nodes participate in logical exchanges. Separating participation from the endpoint itself provides a reusable and technology-independent means of modeling communication relationships while supporting multip… text/html 2026-07-11T19:57:59+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-4-005?rev=1783799879&do=diff P2-REQ-16-4-005 Return to Requirements Statement The Logical Architecture / PIM SHALL define logical communication through explicit Logical Communication Endpoints rather than hidden coupling, undocumented dependencies, or implicit control paths. Source Part 2, Section 16.4: Logical Communication Requirements. text/html 2026-07-18T19:33:44+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-4-006?rev=1784403224&do=diff P2-REQ-16-4-006 Return to Requirements Statement The Logical Architecture / PIM SHALL distinguish Logical Communication Endpoints from DDS Topics, REST resources, RPC methods, Protocol Buffers services, message queues, event streams, files, database handoffs, shared-memory locations, network routes, and deployment artifacts. text/html 2026-07-18T19:33:44+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-4-007?rev=1784403224&do=diff P2-REQ-16-4-007 Return to Requirements Statement The Logical Architecture / PIM SHALL NOT prescribe one communication technology or interaction style. Source Part 2, Section 16.4: Logical Communication Requirements. Rationale The purpose of the Logical Communication Model is to define platform-independent communication relationships rather than implementation technologies. Preserving technology independence allows multiple Implementation Profiles to realize the same Logical Communication… text/html 2026-07-18T19:33:44+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-4-008?rev=1784403224&do=diff P2-REQ-16-4-008 Return to Requirements Statement The Logical Architecture / PIM SHALL support communication pattern independence by distinguishing logical communication relationships from the implementation mechanisms that realize them. Source Part 2, Section 16.4: Logical Communication Requirements. text/html 2026-07-18T19:33:44+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-5-001?rev=1784403224&do=diff P2-REQ-16-5-001 Return to Requirements Statement The Logical Architecture / PIM SHALL define Logical Data Structure Definition and Logical Data Structure Instance. Source Part 2, Section 16.5: Logical Information Requirements. Rationale The Logical Information Model requires both Logical Data Structure Definitions and Logical Data Structure Instances to distinguish reusable information definitions from their populated occurrences. This distinction supports platform-independent modeling, … text/html 2026-07-11T19:57:58+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-5-002?rev=1783799878&do=diff P2-REQ-16-5-002 Return to Requirements Statement The Logical Architecture / PIM SHALL define logical information categories, including Logical Message, Logical Event, Logical Command, Logical Acknowledgement, Logical Assertion, Logical Record, and Logical Information Lineage. Source Part 2, Section 16.5: Logical Information Requirements. Rationale Logical information categories classify information according to its architectural purpose rather than its implementation representation. Esta… text/html 2026-07-18T19:33:44+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-5-003?rev=1784403224&do=diff P2-REQ-16-5-003 Return to Requirements Statement A Logical Data Structure Definition SHALL describe the structure, meaning, and constraints of an information class at the platform-independent logical level. Source Part 2, Section 16.5: Logical Information Requirements. Rationale Logical Data Structure Definitions establish the platform-independent description of information used throughout the architecture. Separating logical definitions from implementation schemas preserves conceptual m… text/html 2026-07-11T19:57:58+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-5-004?rev=1783799878&do=diff P2-REQ-16-5-004 Return to Requirements Statement A Logical Data Structure Instance SHALL represent a populated occurrence of a Logical Data Structure Definition. Source Part 2, Section 16.5: Logical Information Requirements. Rationale Logical Data Structure Instances represent the actual occurrences of information exchanged, processed, or preserved by the architecture. Distinguishing populated instances from reusable definitions supports validation, traceability, lineage, governance, and… text/html 2026-07-11T19:57:58+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-5-005?rev=1783799878&do=diff P2-REQ-16-5-005 Return to Requirements Statement A Logical Message SHALL represent a Logical Data Structure Instance exchanged through a Logical Communication Endpoint. Source Part 2, Section 16.5: Logical Information Requirements. Rationale Logical Messages represent the primary means by which Logical Nodes exchange information. Defining a Logical Message as a Logical Data Structure Instance exchanged through a Logical Communication Endpoint preserves a clear separation between informat… text/html 2026-07-11T19:57:58+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-5-006?rev=1783799878&do=diff P2-REQ-16-5-006 Return to Requirements Statement A Logical Event SHALL represent a Logical Data Structure Instance reporting an occurrence, observation, state change, decision, or result. Source Part 2, Section 16.5: Logical Information Requirements. Rationale Logical Events communicate that something has occurred within the architecture. They provide a consistent, platform-independent representation of observations, state changes, decisions, and results while remaining independent of ev… text/html 2026-07-18T19:33:44+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-5-007?rev=1784403224&do=diff P2-REQ-16-5-007 Return to Requirements Statement A Logical Command SHALL represent a Logical Data Structure Instance expressing an intended action. Source Part 2, Section 16.5: Logical Information Requirements. Rationale Logical Commands communicate intended actions among Logical Nodes. Representing commands as Logical Data Structure Instances ensures that operational intent is modeled consistently while remaining independent of orchestration technologies, command protocols, or runtime i… text/html 2026-07-11T19:57:58+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-5-008?rev=1783799878&do=diff P2-REQ-16-5-008 Return to Requirements Statement A Logical Acknowledgement SHALL represent a Logical Data Structure Instance reporting receipt, acceptance, rejection, completion, failure, or outcome. Source Part 2, Section 16.5: Logical Information Requirements. Rationale Logical Acknowledgements communicate the outcome of previously initiated logical interactions. They provide a consistent, platform-independent means of reporting receipt and execution status while supporting accountabil… text/html 2026-07-11T19:57:58+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-5-009?rev=1783799878&do=diff P2-REQ-16-5-009 Return to Requirements Statement A Logical Assertion SHALL represent a Logical Data Structure Instance stating a conclusion, derived fact, validation result, interpretation result, analytical result, policy decision, or other claim. Source Part 2, Section 16.5: Logical Information Requirements. Rationale text/html 2026-07-11T19:57:58+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-5-010?rev=1783799878&do=diff P2-REQ-16-5-010 Return to Requirements Statement A Logical Record SHALL represent a Logical Data Structure Instance preserved for continuity, review, audit, provenance, replay, reconstruction, or Evidence. Source Part 2, Section 16.5: Logical Information Requirements. Rationale Logical Records preserve information beyond its immediate operational use. They provide the platform-independent foundation for auditability, provenance, replay, reconstruction, governance, and evidence planning w… text/html 2026-07-11T19:57:58+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-5-011?rev=1783799878&do=diff P2-REQ-16-5-011 Return to Requirements Statement Logical Information Lineage SHALL identify relationship history among Logical Data Structure Instances across exchange, transformation, validation, interpretation, assertion, persistence, replay, release, and Evidence. Source Part 2, Section 16.5: Logical Information Requirements. Rationale text/html 2026-07-18T19:33:44+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-5-012?rev=1784403224&do=diff P2-REQ-16-5-012 Return to Requirements Statement The Logical Architecture / PIM SHALL distinguish logical information structures from serialisation formats, schema languages, database structures, ontology languages, programming-language type systems, wire formats, generated code, and implementation payloads. text/html 2026-07-18T19:33:44+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-6-001?rev=1784403224&do=diff P2-REQ-16-6-001 Return to Requirements Statement The Logical Architecture / PIM SHALL define the following Logical Runtime Planes: Logical Control PlaneLogical Data PlaneLogical Health and Observability PlaneLogical Policy and Release PlaneLogical Audit and Provenance Plane Source Part 2, Section 16.6: Logical Runtime Plane Requirements. Rationale The Logical Runtime Plane Model separates architectural responsibilities according to purpose rather than implementation. Defining a standard s… text/html 2026-07-18T19:33:44+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-6-002?rev=1784403224&do=diff P2-REQ-16-6-002 Return to Requirements Statement The Logical Control Plane SHALL support operational coordination among Logical Nodes. Source Part 2, Section 16.6: Logical Runtime Plane Requirements. Rationale The Logical Control Plane provides the architectural foundation for coordinating the behavior of Logical Nodes. Separating operational coordination from information exchange and governance preserves a clear separation of architectural concerns while supporting platform-independent … text/html 2026-07-11T19:57:58+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-6-003?rev=1783799878&do=diff P2-REQ-16-6-003 Return to Requirements Statement The Logical Data Plane SHALL carry domain and analytical information among Logical Nodes. Source Part 2, Section 16.6: Logical Runtime Plane Requirements. Rationale The Logical Data Plane provides the architectural pathway for exchanging domain and analytical information. Separating information exchange from operational coordination, governance, and observability preserves architectural clarity while supporting technology-independent commu… text/html 2026-07-18T19:33:44+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-6-004?rev=1784403224&do=diff P2-REQ-16-6-004 Return to Requirements Statement The Logical Health and Observability Plane SHALL support observation of operational condition and behavior. Source Part 2, Section 16.6: Logical Runtime Plane Requirements. Rationale The Logical Health and Observability Plane provides architectural support for observing the operational condition and behavior of the distributed system. Separating observability from operational control and domain information improves governance, monitoring, … text/html 2026-07-11T19:57:58+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-6-005?rev=1783799878&do=diff P2-REQ-16-6-005 Return to Requirements Statement The Logical Policy and Release Plane SHALL support governed access, disclosure, safeguarding, and release of information. Source Part 2, Section 16.6: Logical Runtime Plane Requirements. Rationale The Logical Policy and Release Plane provides the architectural mechanisms for governing how information is accessed, disclosed, safeguarded, and released. Separating these responsibilities from operational coordination and information exchange p… text/html 2026-07-11T19:57:58+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-6-006?rev=1783799878&do=diff P2-REQ-16-6-006 Return to Requirements Statement The Logical Audit and Provenance Plane SHALL support auditability, provenance, Logical Information Lineage, reconstruction, replay, and defensibility. Source Part 2, Section 16.6: Logical Runtime Plane Requirements. Rationale The Logical Audit and Provenance Plane provides the architectural foundation for preserving historical information needed for auditability, provenance, reconstruction, replay, and defensible review. Maintaining these … text/html 2026-07-18T19:33:44+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-6-007?rev=1784403224&do=diff P2-REQ-16-6-007 Return to Requirements Statement The Logical Architecture / PIM SHALL distinguish Logical Runtime Planes from DDS domains, DDS topics, DDS partitions, REST resource groups, RPC service groups, message queues, event streams, Kubernetes namespaces, network segments, security zones, deployment environments, and runtime configuration groupings. text/html 2026-07-11T19:57:57+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-6-008?rev=1783799877&do=diff P2-REQ-16-6-008 Return to Requirements Statement Cross-plane logical relationships SHALL preserve the distinct architectural purpose of each Logical Runtime Plane involved. Source Part 2, Section 16.6: Logical Runtime Plane Requirements. Rationale Interactions among Logical Runtime Planes are expected within a distributed architecture, but those interactions must not blur the architectural responsibilities assigned to each Runtime Plane. Preserving distinct Runtime Plane purposes maintai… text/html 2026-07-18T19:33:44+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-7-001?rev=1784403224&do=diff P2-REQ-16-7-001 Return to Requirements Statement The Logical Architecture / PIM SHALL define reusable Logical Interaction Patterns. Source Part 2, Section 16.7: Logical Interaction Requirements. Rationale Logical Interaction Patterns define recurring forms of communication and collaboration among Logical Nodes. Establishing reusable patterns promotes architectural consistency, simplifies review, improves interoperability, and enables Domain Logical Profiles to build upon a common set of … text/html 2026-07-18T19:33:44+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-7-002?rev=1784403224&do=diff P2-REQ-16-7-002 Return to Requirements Statement The Logical Architecture / PIM SHALL define the following Logical Interaction Patterns: Register Node;Report Node Status;Publish Domain Information;Subscribe to Domain Information;Issue Control Command;Acknowledge Control Command; text/html 2026-07-11T19:57:57+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-7-003?rev=1783799877&do=diff P2-REQ-16-7-003 Return to Requirements Statement Each Logical Interaction Pattern SHALL identify participating Logical Nodes or Logical Node Roles. Source Part 2, Section 16.7: Logical Interaction Requirements. Rationale Every Logical Interaction Pattern exists to describe collaboration among Logical Nodes. Identifying the participating Nodes or Roles establishes responsibility, enables architectural review, supports governance, and preserves traceability across the Logical Architecture. text/html 2026-07-11T19:57:57+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-7-004?rev=1783799877&do=diff P2-REQ-16-7-004 Return to Requirements Statement Each Logical Interaction Pattern SHALL identify the Logical Communication Endpoints involved. Source Part 2, Section 16.7: Logical Interaction Requirements. Rationale Logical Interaction Patterns describe communication among Logical Nodes through Logical Communication Endpoints. Explicitly identifying the participating endpoints preserves architectural clarity, enables interoperability, supports governance, and maintains traceability indep… text/html 2026-07-11T19:57:57+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-7-005?rev=1783799877&do=diff P2-REQ-16-7-005 Return to Requirements Statement Each Logical Interaction Pattern SHALL identify the Logical Data Structure Instances exchanged, recorded, or referenced. Source Part 2, Section 16.7: Logical Interaction Requirements. Rationale Logical Interaction Patterns describe the movement and use of information among Logical Nodes. Identifying the Logical Data Structure Instances involved preserves semantic meaning, supports interoperability, enables governance, and provides the basi… text/html 2026-07-11T19:57:57+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-7-006?rev=1783799877&do=diff P2-REQ-16-7-006 Return to Requirements Statement Each Logical Interaction Pattern SHALL identify the Logical Runtime Plane(s) involved. Source Part 2, Section 16.7: Logical Interaction Requirements. Rationale Every Logical Interaction Pattern operates within one or more Logical Runtime Planes. Identifying the participating Runtime Planes preserves architectural separation of concerns, supports governance, and enables consistent reasoning about the purpose of each interaction. text/html 2026-07-11T19:57:57+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-7-007?rev=1783799877&do=diff P2-REQ-16-7-007 Return to Requirements Statement Each Logical Interaction Pattern SHALL identify Traceability expectations. Source Part 2, Section 16.7: Logical Interaction Requirements. Rationale Logical Interaction Patterns form important relationships among Logical Nodes, information, Runtime Planes, and governance. Explicitly identifying Traceability expectations enables architectural review, impact analysis, auditability, and consistent evolution of the Logical Architecture. text/html 2026-07-18T19:33:44+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-7-008?rev=1784403224&do=diff P2-REQ-16-7-008 Return to Requirements Statement Each Logical Interaction Pattern SHALL identify Evidence expectations for later deployment, testability, and Evidence planning. Source Part 2, Section 16.7: Logical Interaction Requirements. Rationale Logical Interaction Patterns establish expectations that later Deployment, Testability, and Evidence Plans realize. Identifying Evidence expectations at the logical level preserves traceability and supports verification without introducing im… text/html 2026-07-18T19:33:44+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-7-009?rev=1784403224&do=diff P2-REQ-16-7-009 Return to Requirements Statement Logical Interaction Patterns SHALL remain independent of DDS, REST, RPC, Protocol Buffers, message queues, event streams, file exchange, shared services, databases, logs, or deployment mechanisms. Source Part 2, Section 16.7: Logical Interaction Requirements. text/html 2026-07-18T19:33:44+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-8-001?rev=1784403224&do=diff P2-REQ-16-8-001 Return to Requirements Statement The Logical Architecture / PIM SHALL define a Logical Governance Model. Source Part 2, Section 16.8: Logical Governance Requirements. Rationale The Logical Governance Model establishes the platform-independent framework for governing logical definitions, relationships, responsibilities, compatibility, and change. Defining a Logical Governance Model ensures that governance responsibilities remain consistent across Domain Logical Profiles, I… text/html 2026-07-11T19:57:57+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-8-002?rev=1783799877&do=diff P2-REQ-16-8-002 Return to Requirements Statement The Logical Governance Model SHALL define Logical Ownership of Definitions, Logical Versioning, Logical Compatibility, Logical Change Control, Logical Admission Rules, and Logical Policy Constraints. Source Part 2, Section 16.8: Logical Governance Requirements. Rationale text/html 2026-07-11T19:57:57+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-8-003?rev=1783799877&do=diff P2-REQ-16-8-003 Return to Requirements Statement Logical Ownership of Definitions SHALL identify responsibility for defining, maintaining, approving, and reviewing logical definitions. Source Part 2, Section 16.8: Logical Governance Requirements. Rationale Clear ownership of logical definitions establishes accountability throughout the lifecycle of the Logical Architecture. Explicit ownership supports consistent maintenance, controlled evolution, governance reviews, and long-term steward… text/html 2026-07-11T19:57:57+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-8-004?rev=1783799877&do=diff P2-REQ-16-8-004 Return to Requirements Statement Logical Versioning SHALL identify versions of logical definitions, logical relationships, and logical constraints. Source Part 2, Section 16.8: Logical Governance Requirements. Rationale Logical Versioning provides the ability to manage architectural evolution while preserving continuity and compatibility. Identifying versions of logical definitions, relationships, and constraints supports governance, change management, impact analysis, an… text/html 2026-07-11T19:57:57+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-8-005?rev=1783799877&do=diff P2-REQ-16-8-005 Return to Requirements Statement Logical Compatibility SHALL identify whether logical elements work together without loss of meaning, structure, Traceability, governance, or Evidence expectations. Source Part 2, Section 16.8: Logical Governance Requirements. Rationale Logical Compatibility enables independently developed logical elements to interoperate while preserving their intended meaning and governance characteristics. Defining compatibility at the logical level supp… text/html 2026-07-11T19:57:57+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-8-006?rev=1783799877&do=diff P2-REQ-16-8-006 Return to Requirements Statement Logical Change Control SHALL govern changes to logical definitions, relationships, responsibilities, constraints, and interaction patterns. Source Part 2, Section 16.8: Logical Governance Requirements. Rationale Logical Change Control provides disciplined evolution of the Logical Architecture while preserving architectural integrity and traceability. Governing logical changes independently of implementation activities ensures that architec… text/html 2026-07-11T19:57:57+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-8-007?rev=1783799877&do=diff P2-REQ-16-8-007 Return to Requirements Statement Logical Admission Rules SHALL define conditions governing participation of logical elements in the logical architecture. Source Part 2, Section 16.8: Logical Governance Requirements. Rationale Logical Admission Rules establish the platform-independent criteria that determine when logical elements may participate in the Logical Architecture. Explicit admission rules promote consistency, interoperability, and architectural integrity across a… text/html 2026-07-11T19:57:57+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-8-008?rev=1783799877&do=diff P2-REQ-16-8-008 Return to Requirements Statement Logical Policy Constraints SHALL define platform-independent restrictions, conditions, obligations, or decision criteria governing logical interactions or information movement. Source Part 2, Section 16.8: Logical Governance Requirements. Rationale text/html 2026-07-18T19:33:44+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-8-009?rev=1784403224&do=diff P2-REQ-16-8-009 Return to Requirements Statement The Logical Governance Model SHALL remain independent of repositories, workflow tools, requirements-management systems, policy engines, rules engines, access-control products, ticketing systems, approval systems, configuration systems, and runtime governance services. text/html 2026-07-18T19:33:44+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-9-001?rev=1784403224&do=diff P2-REQ-16-9-001 Return to Requirements Statement The Logical Architecture / PIM SHALL define a Logical Traceability Model. Source Part 2, Section 16.9: Logical Traceability Requirements. Rationale The Logical Traceability Model establishes the platform-independent relationships that connect logical architectural elements to their conceptual origins and to later implementation, deployment, testing, and evidence artifacts. Defining a Logical Traceability Model ensures that architectural in… text/html 2026-07-11T19:57:57+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-9-002?rev=1783799877&do=diff P2-REQ-16-9-002 Return to Requirements Statement The Logical Traceability Model SHALL define Traceability from Part 1 conceptual elements to Part 2 logical elements. Source Part 2, Section 16.9: Logical Traceability Requirements. Rationale The Logical Architecture refines, but does not replace, the Part 1 Conceptual Architecture. Explicit traceability preserves the relationship between conceptual intent and logical realization, supporting governance, review, impact analysis, and long-ter… text/html 2026-07-11T19:57:57+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-9-003?rev=1783799877&do=diff P2-REQ-16-9-003 Return to Requirements Statement The Logical Traceability Model SHALL define Logical Node Traceability, Logical Endpoint Traceability, Logical Data Structure Traceability, Logical Runtime Plane Traceability, Logical Interaction Traceability, and Logical Evidence Traceability. Source Part 2, Section 16.9: Logical Traceability Requirements. Rationale The Logical Traceability Model is composed of several complementary traceability relationships that collectively describe how… text/html 2026-07-11T19:57:57+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-9-004?rev=1783799877&do=diff P2-REQ-16-9-004 Return to Requirements Statement Logical Node Traceability SHALL relate a Logical Node to its identities, roles, responsibilities, endpoints, interactions, Runtime Planes, governance relationships, and Evidence expectations. Source Part 2, Section 16.9: Logical Traceability Requirements. Rationale text/html 2026-07-11T19:57:57+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-9-005?rev=1783799877&do=diff P2-REQ-16-9-005 Return to Requirements Statement Logical Endpoint Traceability SHALL relate a Logical Communication Endpoint to participating Logical Nodes, Communication Roles, information structures, Runtime Planes, governance constraints, and Evidence expectations. Source Part 2, Section 16.9: Logical Traceability Requirements. Rationale Logical Endpoint Traceability establishes the complete architectural context for each Logical Communication Endpoint. Relating endpoints to participa… text/html 2026-07-11T19:57:57+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-9-006?rev=1783799877&do=diff P2-REQ-16-9-006 Return to Requirements Statement Logical Data Structure Traceability SHALL relate logical information structures and instances to definitions, Logical Nodes, endpoints, Runtime Planes, governance constraints, Logical Information Lineage, and Evidence expectations. Source Part 2, Section 16.9: Logical Traceability Requirements. Rationale text/html 2026-07-11T19:57:57+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-9-007?rev=1783799877&do=diff P2-REQ-16-9-007 Return to Requirements Statement Logical Runtime Plane Traceability SHALL relate logical interactions and information exchanges to their Logical Runtime Plane classification. Source Part 2, Section 16.9: Logical Traceability Requirements. Rationale Logical Runtime Plane Traceability preserves the architectural purpose assigned to each interaction and information exchange. Explicit Runtime Plane classification supports governance, review, impact analysis, and consistent ar… text/html 2026-07-11T19:57:56+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-9-008?rev=1783799876&do=diff P2-REQ-16-9-008 Return to Requirements Statement Logical Interaction Traceability SHALL relate a logical interaction pattern to Logical Nodes, roles, endpoints, information structures, Runtime Planes, governance constraints, and Evidence expectations. Source Part 2, Section 16.9: Logical Traceability Requirements. Rationale text/html 2026-07-18T19:33:44+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-9-009?rev=1784403224&do=diff P2-REQ-16-9-009 Return to Requirements Statement Logical Evidence Traceability SHALL relate logical elements and interactions to Evidence expectations for later realization, deployment, testing, and review. Source Part 2, Section 16.9: Logical Traceability Requirements. Rationale Logical Evidence Traceability establishes the relationship between architectural definitions and the evidence expected to support them during later implementation, deployment, testing, and operational review. Id… text/html 2026-07-11T19:57:56+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-9-010?rev=1783799876&do=diff P2-REQ-16-9-010 Return to Requirements Statement Logical Traceability SHALL support forward review from the conceptual concern to the logical model. Source Part 2, Section 16.9: Logical Traceability Requirements. Rationale Forward traceability allows reviewers to follow the refinement of conceptual concerns into the Logical Architecture. This capability demonstrates that every logical element is grounded in a conceptual purpose, supporting architectural validation, governance, and impact… text/html 2026-07-11T19:57:56+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-9-011?rev=1783799876&do=diff P2-REQ-16-9-011 Return to Requirements Statement Logical Traceability SHALL support backward review from logical element to conceptual source. Source Part 2, Section 16.9: Logical Traceability Requirements. Rationale Backward traceability enables reviewers to determine the conceptual basis for every logical element. This capability supports governance, architectural review, impact analysis, and confidence that logical definitions remain consistent with their conceptual origins. text/html 2026-07-18T19:33:44+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-9-012?rev=1784403224&do=diff P2-REQ-16-9-012 Return to Requirements Statement Logical Traceability SHALL support later traceability from logical elements to Domain Logical Profile elements, implementation artifacts, deployment artifacts, test scenarios, runtime observations, and Evidence records. Source Part 2, Section 16.9: Logical Traceability Requirements. text/html 2026-07-18T19:33:44+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-9-013?rev=1784403224&do=diff P2-REQ-16-9-013 Return to Requirements Statement Logical Traceability SHALL NOT require artificial one-to-one correspondence where one-to-many or many-to-one relationships better represent the architecture. Source Part 2, Section 16.9: Logical Traceability Requirements. Rationale text/html 2026-07-18T19:33:44+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-10-001?rev=1784403224&do=diff P2-REQ-16-10-001 Return to Requirements Statement A Domain Logical Profile SHALL preserve the Logical Architecture / PIM defined in this part. Source Part 2, Section 16.10: Profile and Implementation Boundary Requirements. Rationale A Domain Logical Profile extends the Logical Architecture for a specific financial domain while preserving the architectural meaning established by Part 2. Preserving the inherited Logical Architecture ensures consistency, interoperability, governance, and tr… text/html 2026-07-18T19:33:44+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-10-002?rev=1784403224&do=diff P2-REQ-16-10-002 Return to Requirements Statement A Domain Logical Profile SHALL specialize the Logical Architecture / PIM for a specific financial Domain. Source Part 2, Section 16.10: Profile and Implementation Boundary Requirements. Rationale Domain Logical Profiles exist to refine the common Logical Architecture for a particular financial domain. Specialization adds domain-specific behavior and definitions while preserving the architectural meaning inherited from Part 2. text/html 2026-07-18T19:33:44+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-10-003?rev=1784403224&do=diff P2-REQ-16-10-003 Return to Requirements Statement A Domain Logical Profile SHALL identify the Part 2 logical elements it inherits unchanged. Source Part 2, Section 16.10: Profile and Implementation Boundary Requirements. Rationale Explicitly identifying inherited logical elements distinguishes reused architecture from specialized architecture. This improves architectural review, governance, compatibility assessment, and traceability. text/html 2026-07-18T19:33:44+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-10-004?rev=1784403224&do=diff P2-REQ-16-10-004 Return to Requirements Statement A Domain Logical Profile SHALL identify the Part 2 logical elements it specializes. Source Part 2, Section 16.10: Profile and Implementation Boundary Requirements. Rationale Explicit identification of specialized logical elements enables reviewers to distinguish new domain behavior from inherited architecture while preserving governance and traceability. text/html 2026-07-18T19:33:44+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-10-005?rev=1784403224&do=diff P2-REQ-16-10-005 Return to Requirements Statement A Domain Logical Profile SHALL NOT introduce implementation technologies, deployment artifacts, runtime scripts, product choices, or Evidence-capture procedures. Source Part 2, Section 16.10: Profile and Implementation Boundary Requirements. text/html 2026-07-18T19:33:44+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/p2-req-16-10-006?rev=1784403224&do=diff P2-REQ-16-10-006 Return to Requirements Statement An Implementation Profile / PSM SHALL preserve the Logical Architecture / PIM defined in this part. Source Part 2, Section 16.10: Profile and Implementation Boundary Requirements. Rationale Implementation Profiles realize the Logical Architecture using selected technologies without redefining the underlying logical architecture. Preserving the Logical Architecture ensures that implementation remains consistent with the platform-independen… text/html 2026-07-11T19:59:35+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-02/start?rev=1783799975&do=diff Part 2 Requirements Return to Annex D: Requirements This page identifies the canonical requirement records for Part 2: Distributed Node-Based Logical Architecture. part-02 index ---------- © 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc.