DIDO Solutions technical documentation and FX Demo knowledge base https://wiki.didosolutions.com/ 2026-08-22T23:13:34+00:00 https://wiki.didosolutions.com/ https://wiki.didosolutions.com/_media/wiki/logo.png text/html 2026-08-06T22:33:58+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-2-001?rev=1786055638&do=diff P4-REQ-21-2-001 Return to Requirements Statement The Phase 0 Implementation Profile / PSM SHALL define a phase-specific implementation baseline for the FX Demo. Source Part 4, Section 21.2: Phase 0 Profile Requirements. Rationale A phase-specific implementation baseline establishes the controlled scope of implementation work for Phase 0. It identifies the implementation context to which Phase 0 artefacts, mappings, conventions, governance, and traceability apply. text/html 2026-08-06T22:34:19+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-2-002?rev=1786055659&do=diff P4-REQ-21-2-002 Return to Requirements Statement The Phase 0 Implementation Profile / PSM SHALL map selected Part 3 FX Demo Logical Profile elements to Phase 0 implementation artefacts. Source Part 4, Section 21.2: Phase 0 Profile Requirements. Rationale The Phase 0 implementation must remain an explicit realisation of the FX Demo Logical Profile rather than an independent implementation design. Mapping selected Part 3 elements to implementation artefacts preserves the architectural rela… text/html 2026-08-06T22:34:34+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-2-003?rev=1786055674&do=diff P4-REQ-21-2-003 Return to Requirements Statement The Phase 0 Implementation Profile / PSM SHALL preserve traceability to the Part 1 Conceptual Architecture, the Part 2 Distributed Node-Based Logical Architecture / PIM, and the Part 3 FX Demo Logical Profile. Source Part 4, Section 21.2: Phase 0 Profile Requirements. text/html 2026-08-06T22:34:48+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-2-004?rev=1786055688&do=diff P4-REQ-21-2-004 Return to Requirements Statement The Phase 0 Implementation Profile / PSM SHALL NOT redefine Part 1 conceptual elements, Part 2 logical elements, or Part 3 FX logical profile elements. Source Part 4, Section 21.2: Phase 0 Profile Requirements. Rationale text/html 2026-08-06T22:35:03+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-2-005?rev=1786055703&do=diff P4-REQ-21-2-005 Return to Requirements Statement The Phase 0 Implementation Profile / PSM SHALL distinguish implementation artefacts from logical elements. Source Part 4, Section 21.2: Phase 0 Profile Requirements. Rationale Implementation artefacts are selected technical realisations of logical elements. Maintaining a clear distinction between the two prevents implementation mechanisms from becoming architectural definitions. text/html 2026-08-06T22:35:24+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-2-006?rev=1786055724&do=diff P4-REQ-21-2-006 Return to Requirements Statement The Phase 0 Implementation Profile / PSM SHALL define the implementation mappings needed for the Phase 0 implementation baseline. Source Part 4, Section 21.2: Phase 0 Profile Requirements. Rationale The Phase 0 baseline requires explicit mappings between the FX logical architecture and its selected implementation realisations. These mappings establish how logical Nodes, Communication Endpoints, information structures, Runtime Planes, inter… text/html 2026-08-06T22:35:36+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-2-007?rev=1786055736&do=diff P4-REQ-21-2-007 Return to Requirements Statement The Phase 0 Implementation Profile / PSM SHALL NOT define the final implementation architecture for all later development phases. Source Part 4, Section 21.2: Phase 0 Profile Requirements. Rationale Phase 0 establishes a phase-specific implementation baseline rather than a permanent implementation architecture. Later development phases may introduce additional capabilities, technologies, mappings, governance mechanisms, or implementation p… text/html 2026-08-06T22:35:49+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-2-008?rev=1786055749&do=diff P4-REQ-21-2-008 Return to Requirements Statement A later implementation profile MAY extend, refine, supersede, or replace the Phase 0 Implementation Profile / PSM while preserving traceability to the applicable conceptual, logical, FX logical, implementation, and Developer Handbook artefacts. text/html 2026-08-06T22:59:00+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-3-001?rev=1786057140&do=diff P4-REQ-21-3-001 Return to Requirements Statement The Phase 0 Implementation Profile / PSM SHALL identify the selected Phase 0 implementation technologies. Source Part 4, Section 21.3: Technology Selection Requirements. Rationale Explicit identification of the selected technologies establishes the technical implementation context for the Phase 0 baseline. It allows reviewers and contributors to distinguish governed Phase 0 technology choices from exploratory, alternative, or later-phase t… text/html 2026-08-06T22:59:38+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-3-002?rev=1786057178&do=diff P4-REQ-21-3-002 Return to Requirements Statement The Phase 0 Implementation Profile / PSM SHALL identify DDS as the selected Phase 0 communication technology. Source Part 4, Section 21.3: Technology Selection Requirements. Rationale DDS provides the selected communication mechanism through which Phase 0 implementation participants realise applicable FX logical Communication Endpoints and interaction flows. text/html 2026-08-06T22:59:51+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-3-003?rev=1786057191&do=diff P4-REQ-21-3-003 Return to Requirements Statement The Phase 0 Implementation Profile / PSM SHALL identify IDL as the selected Phase 0 data definition mechanism. Source Part 4, Section 21.3: Technology Selection Requirements. Rationale IDL provides the governed implementation-level mechanism for defining data structures used by the selected Phase 0 DDS implementation. text/html 2026-08-06T23:00:02+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-3-004?rev=1786057202&do=diff P4-REQ-21-3-004 Return to Requirements Statement The Phase 0 Implementation Profile / PSM SHALL identify QoS profiles as the selected Phase 0 communication behaviour controls. Source Part 4, Section 21.3: Technology Selection Requirements. Rationale QoS profiles provide controlled communication behaviour for the selected Phase 0 DDS implementation. They allow communication characteristics to be applied consistently to DDS Topic families and applicable Runtime Plane purposes. text/html 2026-08-06T23:00:22+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-3-005?rev=1786057222&do=diff P4-REQ-21-3-005 Return to Requirements Statement The Phase 0 Implementation Profile / PSM SHALL identify generated types as Phase 0 implementation data artefacts derived from governed IDL structures. Source Part 4, Section 21.3: Technology Selection Requirements. Rationale text/html 2026-08-06T23:00:35+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-3-006?rev=1786057235&do=diff P4-REQ-21-3-006 Return to Requirements Statement The Phase 0 Implementation Profile / PSM SHALL identify Python as the selected Phase 0 hand-authored implementation language. Source Part 4, Section 21.3: Technology Selection Requirements. Rationale Identifying Python as the selected hand-authored implementation language establishes a consistent development context for Phase 0 source modules, helpers, adapters, processing logic, and other approved hand-authored implementation artefacts. text/html 2026-08-06T23:00:46+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-3-007?rev=1786057246&do=diff P4-REQ-21-3-007 Return to Requirements Statement The Phase 0 Implementation Profile / PSM SHALL identify scripts as Phase 0 build, generation, execution, shutdown, cleanup, and workflow helpers. Source Part 4, Section 21.3: Technology Selection Requirements. Rationale text/html 2026-08-06T23:01:00+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-3-008?rev=1786057260&do=diff P4-REQ-21-3-008 Return to Requirements Statement The Phase 0 Implementation Profile / PSM SHALL identify repository structure as Phase 0 implementation organisation. Source Part 4, Section 21.3: Technology Selection Requirements. Rationale Repository structure provides the controlled organisation for Phase 0 source, generated, configuration, script, documentation, traceability, and build artefacts. text/html 2026-08-06T23:01:13+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-3-009?rev=1786057273&do=diff P4-REQ-21-3-009 Return to Requirements Statement The Phase 0 technology selections SHALL NOT redefine the conceptual architecture, logical architecture, or FX Demo Logical Profile. Source Part 4, Section 21.3: Technology Selection Requirements. Rationale Phase 0 technologies are implementation mechanisms selected to realise architectural elements defined by Parts 1, 2, and 3. Allowing those technologies to redefine architectural meaning would collapse the separation between architecture … text/html 2026-08-06T23:01:27+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-3-010?rev=1786057287&do=diff P4-REQ-21-3-010 Return to Requirements Statement A later implementation profile MAY extend, refine, supersede, or replace one or more Phase 0 technology selections. Source Part 4, Section 21.3: Technology Selection Requirements. Rationale Phase 0 technology selections establish a controlled implementation baseline for the current development phase rather than permanent technology mandates for all later phases. text/html 2026-08-06T23:02:33+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-4-001?rev=1786057353&do=diff P4-REQ-21-4-001 Return to Requirements Statement The Phase 0 Implementation Profile / PSM SHALL map selected FX logical Nodes to implementation artefacts. Source Part 4, Section 21.4: Logical Node Mapping Requirements. Rationale Explicit mapping between FX logical Nodes and Phase 0 implementation artefacts preserves the connection between logical architectural responsibilities and their selected implementation realizations. text/html 2026-08-06T23:02:46+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-4-002?rev=1786057366&do=diff P4-REQ-21-4-002 Return to Requirements Statement Each implementation node artefact SHALL identify the FX logical Node or Nodes it realises. Source Part 4, Section 21.4: Logical Node Mapping Requirements. Rationale An implementation node artefact must identify the logical Node responsibilities it realizes so that its architectural purpose remains explicit. text/html 2026-08-06T23:02:58+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-4-003?rev=1786057378&do=diff P4-REQ-21-4-003 Return to Requirements Statement Each implementation node artefact SHALL identify the FX logical Node Role or Roles it performs. Source Part 4, Section 21.4: Logical Node Mapping Requirements. Rationale Node Roles identify the logical responsibilities performed within or by an FX logical Node. Recording the applicable Node Roles makes the allocation of implementation responsibility explicit. text/html 2026-08-06T23:03:10+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-4-004?rev=1786057390&do=diff P4-REQ-21-4-004 Return to Requirements Statement Each implementation node artefact SHALL identify the Runtime Plane or Runtime Planes it supports. Source Part 4, Section 21.4: Logical Node Mapping Requirements. Rationale Runtime Plane identification preserves separation of concerns in the implementation profile. It makes clear whether an implementation artefact supports Control, Data, Health and Observability, Policy and Release, Audit and Provenance, or another applicable Runtime Plane … text/html 2026-08-06T23:03:20+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-4-005?rev=1786057400&do=diff P4-REQ-21-4-005 Return to Requirements Statement Each implementation node artefact SHALL identify the DDS Topics, IDL structures, generated types, configuration artefacts, scripts, and supporting modules it uses. Source Part 4, Section 21.4: Logical Node Mapping Requirements. text/html 2026-08-06T23:03:31+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-4-006?rev=1786057411&do=diff P4-REQ-21-4-006 Return to Requirements Statement Each implementation node artefact SHALL preserve traceability to the relevant Part 3 FX logical Node definition. Source Part 4, Section 21.4: Logical Node Mapping Requirements. Rationale Implementation node artefacts must remain tied to the logical Node definitions that justify their existence and responsibilities. text/html 2026-08-06T23:03:43+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-4-007?rev=1786057423&do=diff P4-REQ-21-4-007 Return to Requirements Statement Each implementation node artefact SHALL follow applicable Phase 0 Developer Handbook rules. Source Part 4, Section 21.4: Logical Node Mapping Requirements. Rationale The Phase 0 Developer Handbook defines the practical development discipline needed to produce consistent, reviewable, and governed implementation artefacts. text/html 2026-08-06T23:03:55+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-4-008?rev=1786057435&do=diff P4-REQ-21-4-008 Return to Requirements Statement Each implementation node artefact SHALL report or record observable behaviour according to the Phase 0 logging and exception-handling baseline. Source Part 4, Section 21.4: Logical Node Mapping Requirements. Rationale text/html 2026-08-06T23:04:09+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-4-009?rev=1786057449&do=diff P4-REQ-21-4-009 Return to Requirements Statement The Phase 0 Implementation Profile / PSM SHALL allow one implementation artefact to realise more than one FX logical Node when the mapping records that choice. Source Part 4, Section 21.4: Logical Node Mapping Requirements. text/html 2026-08-06T23:04:20+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-4-010?rev=1786057460&do=diff P4-REQ-21-4-010 Return to Requirements Statement The Phase 0 Implementation Profile / PSM SHALL allow more than one implementation artefact to realise one FX logical Node when the mapping records that choice. Source Part 4, Section 21.4: Logical Node Mapping Requirements. text/html 2026-08-06T23:04:30+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-4-011?rev=1786057470&do=diff P4-REQ-21-4-011 Return to Requirements Statement Runtime packaging SHALL NOT redefine FX logical Nodes or FX logical Node Roles. Source Part 4, Section 21.4: Logical Node Mapping Requirements. Rationale Runtime packaging determines how logical responsibilities are grouped into implementation processes, modules, or other runtime participants. It is an implementation decision rather than a logical architectural definition. text/html 2026-08-06T23:07:39+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-5-001?rev=1786057659&do=diff P4-REQ-21-5-001 Return to Requirements Statement The Phase 0 Implementation Profile / PSM SHALL map selected FX logical Communication Endpoints to DDS Topics. Source Part 4, Section 21.5: Communication Endpoint Mapping Requirements. Rationale Mapping FX logical Communication Endpoints to DDS Topics establishes the Phase 0 communication realization of the logical exchanges defined by the FX Demo Logical Profile. text/html 2026-08-06T23:07:50+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-5-002?rev=1786057670&do=diff P4-REQ-21-5-002 Return to Requirements Statement Each DDS Topic mapping SHALL identify the FX logical Communication Endpoint it realises. Source Part 4, Section 21.5: Communication Endpoint Mapping Requirements. Rationale A DDS Topic must identify the logical Communication Endpoint it realizes so that the architectural purpose of the Topic remains explicit. text/html 2026-08-06T23:08:01+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-5-003?rev=1786057681&do=diff P4-REQ-21-5-003 Return to Requirements Statement Each DDS Topic mapping SHALL identify the FX logical information structure carried by the endpoint. Source Part 4, Section 21.5: Communication Endpoint Mapping Requirements. Rationale A communication mapping must identify the logical information structure being exchanged so that the meaning of the transported information remains traceable to the FX Demo Logical Profile. text/html 2026-08-06T23:08:13+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-5-004?rev=1786057693&do=diff P4-REQ-21-5-004 Return to Requirements Statement Each DDS Topic mapping SHALL identify the IDL structure and generated type used for Phase 0 exchange. Source Part 4, Section 21.5: Communication Endpoint Mapping Requirements. Rationale The IDL structure and generated type define the selected Phase 0 implementation representation used for DDS exchange. text/html 2026-08-06T23:08:28+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-5-005?rev=1786057708&do=diff P4-REQ-21-5-005 Return to Requirements Statement Each DDS Topic mapping SHALL identify the producing FX logical Node or Node Role. Source Part 4, Section 21.5: Communication Endpoint Mapping Requirements. Rationale Identifying the producing Node or Node Role makes the source responsibility for each DDS exchange explicit. text/html 2026-08-06T23:08:40+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-5-006?rev=1786057720&do=diff P4-REQ-21-5-006 Return to Requirements Statement Each DDS Topic mapping SHALL identify the consuming FX logical Node or Node Role. Source Part 4, Section 21.5: Communication Endpoint Mapping Requirements. Rationale Identifying the consuming Node or Node Role makes the receiving responsibility for each DDS exchange explicit. text/html 2026-08-06T23:08:55+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-5-007?rev=1786057735&do=diff P4-REQ-21-5-007 Return to Requirements Statement Each DDS Topic mapping SHALL identify the Runtime Plane or Runtime Planes associated with the exchange. Source Part 4, Section 21.5: Communication Endpoint Mapping Requirements. Rationale Runtime Plane classification preserves separation of concerns in Phase 0 communication mappings. text/html 2026-08-06T23:09:03+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-5-008?rev=1786057743&do=diff P4-REQ-21-5-008 Return to Requirements Statement Each DDS Topic mapping SHALL identify the QoS profile or QoS profile family used for the topic. Source Part 4, Section 21.5: Communication Endpoint Mapping Requirements. Rationale QoS profiles define the selected Phase 0 communication behavior associated with DDS Topic exchange. text/html 2026-08-06T23:09:18+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-5-009?rev=1786057758&do=diff P4-REQ-21-5-009 Return to Requirements Statement Each DDS Topic mapping SHALL identify the applicable governance, versioning, and compatibility expectations. Source Part 4, Section 21.5: Communication Endpoint Mapping Requirements. Rationale DDS Topic mappings must remain governed and compatible across producers, consumers, data representations, and QoS configurations. text/html 2026-08-06T23:09:28+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-5-010?rev=1786057768&do=diff P4-REQ-21-5-010 Return to Requirements Statement Each DDS Topic mapping SHALL preserve traceability to the Part 3 FX logical Communication Endpoint. Source Part 4, Section 21.5: Communication Endpoint Mapping Requirements. Rationale Each DDS Topic is an implementation realization of a logical communication definition and must remain connected to that authoritative Part 3 source. text/html 2026-08-06T23:09:38+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-5-011?rev=1786057778&do=diff P4-REQ-21-5-011 Return to Requirements Statement DDS Topics SHALL NOT redefine FX logical Communication Endpoints. Source Part 4, Section 21.5: Communication Endpoint Mapping Requirements. Rationale DDS Topics are selected Phase 0 implementation mechanisms for realizing logical communication. They do not define the logical purpose, participants, information meaning, Runtime Plane classification, or governance of the corresponding Communication Endpoint. text/html 2026-08-06T23:10:40+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-6-001?rev=1786057840&do=diff P4-REQ-21-6-001 Return to Requirements Statement The Phase 0 Implementation Profile / PSM SHALL map selected FX logical information structures to IDL structures and generated types. Source Part 4, Section 21.6: Information Structure Mapping Requirements. Rationale text/html 2026-08-06T23:10:53+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-6-002?rev=1786057853&do=diff P4-REQ-21-6-002 Return to Requirements Statement Each IDL structure SHALL identify the FX logical information structure it realises. Source Part 4, Section 21.6: Information Structure Mapping Requirements. Rationale An IDL structure must identify the logical information structure it realizes so that its implementation purpose and architectural source remain explicit. text/html 2026-08-06T23:11:03+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-6-003?rev=1786057863&do=diff P4-REQ-21-6-003 Return to Requirements Statement Each generated type SHALL identify the IDL structure from which it derives. Source Part 4, Section 21.6: Information Structure Mapping Requirements. Rationale Generated types are derived implementation artifacts rather than independent source definitions. Identifying the originating IDL structure preserves generation repeatability and establishes the source of the generated representation. text/html 2026-08-06T23:11:17+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-6-004?rev=1786057877&do=diff P4-REQ-21-6-004 Return to Requirements Statement Each IDL and generated type mapping SHALL identify the Runtime Plane or Runtime Planes associated with the information structure. Source Part 4, Section 21.6: Information Structure Mapping Requirements. Rationale Runtime Plane classification preserves the separation of implementation concerns associated with the information structure. text/html 2026-08-06T23:11:31+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-6-005?rev=1786057891&do=diff P4-REQ-21-6-005 Return to Requirements Statement Each IDL and generated type mapping SHALL identify the DDS Topic or Topics that carry the generated type. Source Part 4, Section 21.6: Information Structure Mapping Requirements. Rationale Identifying the DDS Topics that carry a generated type connects the implementation data representation to the communication exchanges in which it participates. text/html 2026-08-06T23:11:39+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-6-006?rev=1786057899&do=diff P4-REQ-21-6-006 Return to Requirements Statement Each IDL and generated type mapping SHALL identify the producing and consuming FX logical Nodes or Node Roles. Source Part 4, Section 21.6: Information Structure Mapping Requirements. Rationale Identifying the producing and consuming logical responsibilities makes clear which FX logical Nodes or Node Roles create and use the represented information. text/html 2026-08-06T23:11:56+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-6-007?rev=1786057916&do=diff P4-REQ-21-6-007 Return to Requirements Statement Each IDL and generated type mapping SHALL identify the source IDL file. Source Part 4, Section 21.6: Information Structure Mapping Requirements. Rationale The source IDL file is the governed source artifact from which the applicable IDL structure and generated implementation types originate. text/html 2026-08-06T23:12:05+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-6-008?rev=1786057925&do=diff P4-REQ-21-6-008 Return to Requirements Statement Each IDL and generated type mapping SHALL identify the applicable generation rule. Source Part 4, Section 21.6: Information Structure Mapping Requirements. Rationale A defined generation rule establishes how governed IDL structures produce generated implementation types. text/html 2026-08-06T23:12:29+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-6-009?rev=1786057949&do=diff P4-REQ-21-6-009 Return to Requirements Statement Each IDL and generated type mapping SHALL identify the applicable versioning and compatibility expectations. Source Part 4, Section 21.6: Information Structure Mapping Requirements. Rationale IDL structures and generated types participate in communication exchanges that depend on compatible representations. text/html 2026-08-06T23:12:42+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-6-010?rev=1786057962&do=diff P4-REQ-21-6-010 Return to Requirements Statement Each IDL and generated type mapping SHALL preserve traceability to the Part 3 FX logical information structure. Source Part 4, Section 21.6: Information Structure Mapping Requirements. Rationale IDL structures and generated types are implementation representations of logical information definitions and must remain connected to those authoritative Part 3 sources. text/html 2026-08-06T23:12:51+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-6-011?rev=1786057971&do=diff P4-REQ-21-6-011 Return to Requirements Statement IDL structures SHALL NOT redefine FX logical information structures. Source Part 4, Section 21.6: Information Structure Mapping Requirements. Rationale IDL structures are selected Phase 0 implementation representations of logical information structures. They define implementation-level data representation, not architectural meaning. text/html 2026-08-06T23:13:03+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-6-012?rev=1786057983&do=diff P4-REQ-21-6-012 Return to Requirements Statement Generated types SHALL NOT redefine IDL structures or FX logical information structures. Source Part 4, Section 21.6: Information Structure Mapping Requirements. Rationale Generated types are derived implementation artifacts produced from governed IDL structures. They are not independent sources of data-definition or logical meaning. text/html 2026-08-06T23:14:05+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-7-001?rev=1786058045&do=diff P4-REQ-21-7-001 Return to Requirements Statement The Phase 0 Implementation Profile / PSM SHALL realize FX Runtime Plane distinctions through implementation artifacts and conventions. Source Part 4, Section 21.7: Runtime Plane Realization Requirements. Rationale FX Runtime Planes preserve separation of concerns among operational control, data exchange, health and observability, policy and release, and audit and provenance responsibilities. text/html 2026-08-06T23:14:16+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-7-002?rev=1786058056&do=diff P4-REQ-21-7-002 Return to Requirements Statement The Phase 0 Implementation Profile / PSM SHALL define Control Plane realization for operational coordination, commands, acknowledgments, registration, retry, recovery, and status-request interactions. Source Part 4, Section 21.7: Runtime Plane Realization Requirements. text/html 2026-08-06T23:14:44+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-7-003?rev=1786058084&do=diff P4-REQ-21-7-003 Return to Requirements Statement The Phase 0 Implementation Profile / PSM SHALL define Data Plane realization for FX transaction, validation, semantic, contract state, and cash-flow information exchange. Source Part 4, Section 21.7: Runtime Plane Realization Requirements. text/html 2026-08-06T23:14:58+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-7-004?rev=1786058098&do=diff P4-REQ-21-7-004 Return to Requirements Statement The Phase 0 Implementation Profile / PSM SHALL define Health and Observability Plane realization for Node status, lifecycle state, warning, degradation, failure, recovery, and operational condition reporting. Source Part 4, Section 21.7: Runtime Plane Realization Requirements. text/html 2026-08-06T23:15:22+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-7-005?rev=1786058122&do=diff P4-REQ-21-7-005 Return to Requirements Statement The Phase 0 Implementation Profile / PSM SHALL define Policy and Release Plane realization for policy decisions, release packages, release obligations, and authorized oversight consumption. Source Part 4, Section 21.7: Runtime Plane Realization Requirements. text/html 2026-08-06T23:16:37+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-7-006?rev=1786058197&do=diff P4-REQ-21-7-006 Return to Requirements Statement The Phase 0 Implementation Profile / PSM SHALL define Audit and Provenance Plane realization for audit records, provenance records, replay requests, replay results, lineage, reconstruction, and evidence-supporting relationships. text/html 2026-08-06T23:16:47+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-7-007?rev=1786058207&do=diff P4-REQ-21-7-007 Return to Requirements Statement Cross-plane implementation relationships SHALL preserve the distinct architectural purpose of each Runtime Plane involved. Source Part 4, Section 21.7: Runtime Plane Realization Requirements. Rationale Phase 0 implementation interactions may involve more than one Runtime Plane, but shared implementation mechanisms must not erase the architectural distinctions among those concerns. text/html 2026-08-06T23:16:56+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-7-008?rev=1786058216&do=diff P4-REQ-21-7-008 Return to Requirements Statement Implementation mechanisms SHALL NOT collapse Runtime Plane distinctions. Source Part 4, Section 21.7: Runtime Plane Realization Requirements. Rationale Implementation mechanisms such as DDS, shared modules, common logging, repository groupings, or runtime packaging may support multiple architectural concerns. Those mechanisms must not become a substitute for the Runtime Plane distinctions defined by the logical architecture. text/html 2026-08-06T23:18:20+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-8-001?rev=1786058300&do=diff P4-REQ-21-8-001 Return to Requirements Statement The Phase 0 Implementation Profile / PSM SHALL realize selected FX logical interaction patterns through Phase 0 implementation artifacts. Source Part 4, Section 21.8: Interaction Pattern Realization Requirements. Rationale text/html 2026-08-06T23:18:28+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-8-002?rev=1786058308&do=diff P4-REQ-21-8-002 Return to Requirements Statement Each interaction realization SHALL identify the FX logical interaction pattern it realizes. Source Part 4, Section 21.8: Interaction Pattern Realization Requirements. Rationale An implementation interaction must identify the logical interaction pattern that justifies its behavior and sequence. text/html 2026-08-06T23:18:41+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-8-003?rev=1786058321&do=diff P4-REQ-21-8-003 Return to Requirements Statement Each interaction realization SHALL identify the implementation participants involved. Source Part 4, Section 21.8: Interaction Pattern Realization Requirements. Rationale Identifying participating implementation artifacts makes the allocation of responsibilities within each realized interaction explicit. text/html 2026-08-06T23:18:49+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-8-004?rev=1786058329&do=diff P4-REQ-21-8-004 Return to Requirements Statement Each interaction realization SHALL identify the DDS Topic or Topics used. Source Part 4, Section 21.8: Interaction Pattern Realization Requirements. Rationale DDS Topics provide the Phase 0 communication mechanism used to realize applicable logical exchanges within an interaction pattern. text/html 2026-08-06T23:18:59+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-8-005?rev=1786058339&do=diff P4-REQ-21-8-005 Return to Requirements Statement Each interaction realization SHALL identify the IDL structures and generated types exchanged. Source Part 4, Section 21.8: Interaction Pattern Realization Requirements. Rationale Interaction realizations depend on defined implementation data representations. Identifying the applicable IDL structures and generated types allows reviewers to understand the information representation used at each exchange. text/html 2026-08-06T23:20:23+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-8-006?rev=1786058423&do=diff P4-REQ-21-8-006 Return to Requirements Statement Each interaction realization SHALL identify the Runtime Plane or Runtime Planes involved. Source Part 4, Section 21.8: Interaction Pattern Realization Requirements. Rationale Runtime Plane identification preserves the separation of architectural concerns represented within each implementation interaction. text/html 2026-08-06T23:20:35+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-8-007?rev=1786058435&do=diff P4-REQ-21-8-007 Return to Requirements Statement Each interaction realization SHALL identify the expected processing outcome. Source Part 4, Section 21.8: Interaction Pattern Realization Requirements. Rationale An interaction realization must define the expected result of its implementation processing so that execution can be evaluated against the intended logical behavior. text/html 2026-08-06T23:20:45+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-8-008?rev=1786058445&do=diff P4-REQ-21-8-008 Return to Requirements Statement Each interaction realization SHALL identify the required logging and exception-handling behavior. Source Part 4, Section 21.8: Interaction Pattern Realization Requirements. Rationale Interaction execution must expose sufficient operational information to make successful processing, warnings, degradation, failures, and recovery behavior reviewable. text/html 2026-08-06T23:20:54+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-8-009?rev=1786058454&do=diff P4-REQ-21-8-009 Return to Requirements Statement Each interaction realization SHALL identify the audit and provenance expectations where applicable. Source Part 4, Section 21.8: Interaction Pattern Realization Requirements. Rationale Interactions that affect lineage, accountability, replay, reconstruction, review, or evidence require explicit audit and provenance treatment. text/html 2026-08-06T23:21:06+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-8-010?rev=1786058466&do=diff P4-REQ-21-8-010 Return to Requirements Statement Each interaction realization SHALL identify the supporting scripts or configuration artifacts where applicable. Source Part 4, Section 21.8: Interaction Pattern Realization Requirements. Rationale Some Phase 0 interactions depend on scripts or configuration artifacts to prepare, start, coordinate, or configure the implementation participants involved. text/html 2026-08-06T23:21:15+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-8-011?rev=1786058475&do=diff P4-REQ-21-8-011 Return to Requirements Statement Each interaction realization SHALL preserve traceability to the Part 3 FX logical interaction pattern. Source Part 4, Section 21.8: Interaction Pattern Realization Requirements. Rationale Each Phase 0 interaction realization must remain connected to the logical interaction pattern that defines its architectural purpose. text/html 2026-08-06T23:21:24+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-8-012?rev=1786058484&do=diff P4-REQ-21-8-012 Return to Requirements Statement Implementation flows SHALL NOT redefine FX logical interaction patterns. Source Part 4, Section 21.8: Interaction Pattern Realization Requirements. Rationale Implementation flows are technical realizations of interaction patterns defined by the FX Demo Logical Profile. They may introduce implementation-specific sequencing, scripts, configuration, communication mechanisms, or runtime packaging, but they do not define the logical meaning of … text/html 2026-08-07T20:46:12+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-9-001?rev=1786135572&do=diff P4-REQ-21-9-001 Return to Requirements Statement The Phase 0 Implementation Profile / PSM SHALL define a Phase 0 QoS Profile Model. Source Part 4, Section 21.9: QoS Profile Requirements. Rationale A defined QoS Profile Model establishes the controlled communication behavior used by the selected Phase 0 DDS implementation. text/html 2026-08-07T20:59:12+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-9-002?rev=1786136352&do=diff P4-REQ-21-9-002 Return to Requirements Statement Each QoS profile mapping SHALL identify the Runtime Plane or Runtime Planes it supports. Source Part 4, Section 21.9: QoS Profile Requirements. Rationale Runtime Plane identification connects each QoS profile to the architectural purpose of the communication it supports. text/html 2026-08-07T20:59:22+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-9-003?rev=1786136362&do=diff P4-REQ-21-9-003 Return to Requirements Statement Each QoS profile mapping SHALL identify the DDS Topic or Topic family that uses the profile. Source Part 4, Section 21.9: QoS Profile Requirements. Rationale A QoS profile must identify the DDS communication exchanges to which its behavior applies. text/html 2026-08-07T20:59:40+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-9-004?rev=1786136380&do=diff P4-REQ-21-9-004 Return to Requirements Statement Each QoS profile mapping SHALL identify the communication purpose of the profile. Source Part 4, Section 21.9: QoS Profile Requirements. Rationale The communication purpose explains why a QoS profile exists and which implementation concern its behavior supports. text/html 2026-08-07T20:59:53+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-9-005?rev=1786136393&do=diff P4-REQ-21-9-005 Return to Requirements Statement Each QoS profile mapping SHALL identify the expected reliability behavior. Source Part 4, Section 21.9: QoS Profile Requirements. Rationale Reliability behavior determines the expected delivery assurance for communication using the QoS profile. text/html 2026-08-07T21:00:07+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-9-006?rev=1786136407&do=diff P4-REQ-21-9-006 Return to Requirements Statement Each QoS profile mapping SHALL identify the expected durability behavior. Source Part 4, Section 21.9: QoS Profile Requirements. Rationale Durability behavior determines whether and how previously published information remains available to later-joining participants. text/html 2026-08-07T21:00:36+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-9-007?rev=1786136436&do=diff P4-REQ-21-9-007 Return to Requirements Statement Each QoS profile mapping SHALL identify the expected history behavior. Source Part 4, Section 21.9: QoS Profile Requirements. Rationale History behavior determines how much communication history is retained for applicable DDS exchanges. text/html 2026-08-07T21:00:48+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-9-008?rev=1786136448&do=diff P4-REQ-21-9-008 Return to Requirements Statement Each QoS profile mapping SHALL identify the expected ordering behavior. Source Part 4, Section 21.9: QoS Profile Requirements. Rationale Ordering behavior determines whether communication sequence must be preserved when downstream processing or lifecycle progression depends on event order. text/html 2026-08-07T21:01:00+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-9-009?rev=1786136460&do=diff P4-REQ-21-9-009 Return to Requirements Statement Each QoS profile mapping SHALL identify the expected liveliness or availability behavior. Source Part 4, Section 21.9: QoS Profile Requirements. Rationale Liveliness and availability behavior supports detection of implementation participants that become unavailable, silent, or unable to perform their expected communication responsibilities. text/html 2026-08-07T21:01:14+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-9-010?rev=1786136474&do=diff P4-REQ-21-9-010 Return to Requirements Statement Each QoS profile mapping SHALL identify publisher and subscriber compatibility expectations. Source Part 4, Section 21.9: QoS Profile Requirements. Rationale DDS communication depends on compatible QoS expectations between publishers and subscribers. text/html 2026-08-07T21:01:27+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-9-011?rev=1786136487&do=diff P4-REQ-21-9-011 Return to Requirements Statement Each QoS profile mapping SHALL identify the configuration artifact that defines the profile. Source Part 4, Section 21.9: QoS Profile Requirements. Rationale A QoS profile must be tied to a governed configuration artifact so that its selected behavior can be reviewed, reproduced, changed, and versioned consistently. text/html 2026-08-07T21:01:39+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-9-012?rev=1786136499&do=diff P4-REQ-21-9-012 Return to Requirements Statement Each QoS profile mapping SHALL preserve traceability to the applicable FX logical Communication Endpoint and Runtime Plane. Source Part 4, Section 21.9: QoS Profile Requirements. Rationale QoS profiles implement communication behavior for logical exchanges and must remain connected to both the Communication Endpoint and Runtime Plane purpose that justify their selection. text/html 2026-08-07T21:01:49+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-9-013?rev=1786136509&do=diff P4-REQ-21-9-013 Return to Requirements Statement QoS profiles SHALL NOT redefine Runtime Planes, FX logical Communication Endpoints, FX logical information structures, or FX logical interaction patterns. Source Part 4, Section 21.9: QoS Profile Requirements. Rationale text/html 2026-08-07T21:12:56+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-10-001?rev=1786137176&do=diff P4-REQ-21-10-001 Return to Requirements Statement The Phase 0 Implementation Profile / PSM SHALL define a repository and build artifact model. Source Part 4, Section 21.10: Repository and Build Artifact Requirements. Rationale A defined repository and build artifact model establishes how Phase 0 implementation artifacts are organized, generated, reviewed, and distinguished within the implementation baseline. text/html 2026-08-07T21:13:09+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-10-002?rev=1786137189&do=diff P4-REQ-21-10-002 Return to Requirements Statement The repository model SHALL identify locations for hand-authored source files, IDL files, generated code, configuration files, scripts, documentation, traceability artifacts, build artifacts, and non-baseline material. Source text/html 2026-08-07T21:13:18+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-10-003?rev=1786137198&do=diff P4-REQ-21-10-003 Return to Requirements Statement Each repository location SHALL identify the artifact category it contains. Source Part 4, Section 21.10: Repository and Build Artifact Requirements. Rationale Each repository location must have an explicit implementation purpose so that contributors and reviewers can determine what type of material belongs there. text/html 2026-08-07T21:13:28+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-10-004?rev=1786137208&do=diff P4-REQ-21-10-004 Return to Requirements Statement Each repository location SHALL identify whether the artifacts are hand-authored, generated, configured, documented, temporary, local, or non-baseline. Source Part 4, Section 21.10: Repository and Build Artifact Requirements. text/html 2026-08-07T21:13:39+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-10-005?rev=1786137219&do=diff P4-REQ-21-10-005 Return to Requirements Statement Each repository location SHALL identify the applicable Developer Handbook rules. Source Part 4, Section 21.10: Repository and Build Artifact Requirements. Rationale Repository locations contain artifacts governed by different development, generation, modification, review, and cleanup rules. text/html 2026-08-07T21:13:48+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-10-006?rev=1786137228&do=diff P4-REQ-21-10-006 Return to Requirements Statement Each governed source file SHALL include the standard file header defined by the Developer Handbook. Source Part 4, Section 21.10: Repository and Build Artifact Requirements. Rationale The standard file header provides the metadata needed to understand a governed source artifact's purpose, ownership context, logical or implementation source, modification guidance, and traceability. text/html 2026-08-07T21:14:00+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-10-007?rev=1786137240&do=diff P4-REQ-21-10-007 Return to Requirements Statement Each generated file SHALL include the generated-file header defined by the Developer Handbook. Source Part 4, Section 21.10: Repository and Build Artifact Requirements. Rationale Generated files require explicit metadata describing their source definition, generator, generation context, regeneration rule, and manual-editing status. text/html 2026-08-07T21:14:07+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-10-008?rev=1786137247&do=diff P4-REQ-21-10-008 Return to Requirements Statement The repository model SHALL distinguish governed source artifacts from generated artifacts, temporary build outputs, local developer artifacts, exploratory material, and approved documentation. Source Part 4, Section 21.10: Repository and Build Artifact Requirements. text/html 2026-08-07T21:14:18+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-10-009?rev=1786137258&do=diff P4-REQ-21-10-009 Return to Requirements Statement Build artifacts SHALL remain distinguishable from governed source artifacts and generated artifacts. Source Part 4, Section 21.10: Repository and Build Artifact Requirements. Rationale Build outputs may be intermediate, compiled, packaged, reported, or otherwise produced during generation and build activity. They do not necessarily have the same governance status as source or governed generated files. text/html 2026-08-07T21:14:26+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-10-010?rev=1786137266&do=diff P4-REQ-21-10-010 Return to Requirements Statement Repository layout SHALL NOT redefine the architecture. Source Part 4, Section 21.10: Repository and Build Artifact Requirements. Rationale Repository layout is an implementation organization mechanism. Directory structure, file placement, generated-code locations, and build-output locations do not define logical Nodes, Communication Endpoints, information structures, Runtime Planes, or interaction patterns. text/html 2026-08-07T21:15:51+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-11-001?rev=1786137351&do=diff P4-REQ-21-11-001 Return to Requirements Statement The Phase 0 Developer Handbook SHALL exist and receive approval before Phase 0 coding begins. Source Part 4, Section 21.11: Developer Handbook Requirements. Rationale The Developer Handbook establishes the development discipline that contributors must follow when producing Phase 0 implementation artifacts. text/html 2026-08-07T21:16:03+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-11-002?rev=1786137363&do=diff P4-REQ-21-11-002 Return to Requirements Statement The Developer Handbook SHALL define file-header conventions. Source Part 4, Section 21.11: Developer Handbook Requirements. Rationale File-header conventions provide a consistent mechanism for identifying an artifact's purpose, ownership context, logical or implementation source, modification guidance, review status, and traceability. text/html 2026-08-07T21:16:18+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-11-003?rev=1786137378&do=diff P4-REQ-21-11-003 Return to Requirements Statement The Developer Handbook SHALL define generated-file header conventions. Source Part 4, Section 21.11: Developer Handbook Requirements. Rationale Generated files require metadata that identifies their source definition, generator, generation context, regeneration rule, and manual-editing status. text/html 2026-08-07T21:16:31+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-11-004?rev=1786137391&do=diff P4-REQ-21-11-004 Return to Requirements Statement The Developer Handbook SHALL define naming conventions. Source Part 4, Section 21.11: Developer Handbook Requirements. Rationale Naming conventions provide consistent identification across source files, modules, IDL structures, generated types, DDS Topics, QoS profiles, configuration files, scripts, and traceability artifacts. text/html 2026-08-07T21:17:13+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-11-005?rev=1786137433&do=diff P4-REQ-21-11-005 Return to Requirements Statement The Developer Handbook SHALL define coding style requirements. Source Part 4, Section 21.11: Developer Handbook Requirements. Rationale Coding style requirements establish consistent practices for hand-authored Phase 0 implementation code. text/html 2026-08-07T21:16:52+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-11-006?rev=1786137412&do=diff P4-REQ-21-11-006 Return to Requirements Statement The Developer Handbook SHALL define logging conventions. Source Part 4, Section 21.11: Developer Handbook Requirements. Rationale Logging conventions establish how Phase 0 implementation artifacts report lifecycle activity, processing outcomes, warnings, degradation, failures, recovery, commands, and communication errors. text/html 2026-08-07T21:17:25+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-11-007?rev=1786137445&do=diff P4-REQ-21-11-007 Return to Requirements Statement The Developer Handbook SHALL define exception-handling patterns. Source Part 4, Section 21.11: Developer Handbook Requirements. Rationale Exception-handling patterns ensure that implementation failures are handled or reported consistently rather than being silently hidden. text/html 2026-08-07T21:17:36+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-11-008?rev=1786137456&do=diff P4-REQ-21-11-007 Return to Requirements Statement The Developer Handbook SHALL define exception-handling patterns. Source Part 4, Section 21.11: Developer Handbook Requirements. Rationale Exception-handling patterns ensure that implementation failures are handled or reported consistently rather than being silently hidden. text/html 2026-08-07T21:17:48+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-11-009?rev=1786137468&do=diff P4-REQ-21-11-009 Return to Requirements Statement The Developer Handbook SHALL define repository workflow requirements. Source Part 4, Section 21.11: Developer Handbook Requirements. Rationale Repository workflow requirements control how implementation artifacts enter, change within, and leave the Phase 0 implementation baseline. text/html 2026-08-07T21:18:00+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-11-010?rev=1786137480&do=diff P4-REQ-21-11-010 Return to Requirements Statement The Developer Handbook SHALL define script usage requirements. Source Part 4, Section 21.11: Developer Handbook Requirements. Rationale Scripts can generate artifacts, alter repository state, start or stop implementation participants, and affect traceability. text/html 2026-08-07T21:18:17+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-11-011?rev=1786137497&do=diff P4-REQ-21-11-011 Return to Requirements Statement The Developer Handbook SHALL define review checklist requirements. Source Part 4, Section 21.11: Developer Handbook Requirements. Rationale Review checklists provide a repeatable acceptance mechanism for determining whether implementation artifacts conform to the Phase 0 development baseline. text/html 2026-08-07T21:18:28+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-11-012?rev=1786137508&do=diff P4-REQ-21-11-012 Return to Requirements Statement No Phase 0 implementation artifact SHALL enter the implementation baseline unless the applicable Developer Handbook rules exist and reviewers can apply them. Source Part 4, Section 21.11: Developer Handbook Requirements. text/html 2026-08-07T21:18:40+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-11-013?rev=1786137520&do=diff P4-REQ-21-11-013 Return to Requirements Statement The Developer Handbook SHALL remain subordinate to the Phase 0 Implementation Profile / PSM. Source Part 4, Section 21.11: Developer Handbook Requirements. Rationale The Developer Handbook translates Part 4 implementation requirements into practical contributor rules. It is not an independent architectural or implementation-profile authority. text/html 2026-08-07T21:18:49+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-11-014?rev=1786137529&do=diff P4-REQ-21-11-014 Return to Requirements Statement The Developer Handbook SHALL NOT redefine the implementation profile, the FX Demo Logical Profile, or the architecture. Source Part 4, Section 21.11: Developer Handbook Requirements. Rationale The Developer Handbook defines practical development conventions. It does not define architectural meaning or establish implementation-profile requirements independently of Part 4. text/html 2026-08-07T21:28:55+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-12-001?rev=1786138135&do=diff P4-REQ-21-12-001 Return to Requirements Statement The Phase 0 Implementation Profile / PSM SHALL define a Script and Execution Model. Source Part 4, Section 21.12: Script and Execution Requirements. Rationale A defined Script and Execution Model establishes how Phase 0 scripts support controlled preparation, generation, execution, shutdown, cleanup, and review. text/html 2026-08-07T21:29:09+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-12-002?rev=1786138149&do=diff P4-REQ-21-12-002 Return to Requirements Statement Each approved script SHALL identify its purpose. Source Part 4, Section 21.12: Script and Execution Requirements. Rationale A script must have an explicit purpose so contributors and reviewers can understand why it exists and which Phase 0 implementation activity it supports. text/html 2026-08-07T21:29:20+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-12-003?rev=1786138160&do=diff P4-REQ-21-12-003 Return to Requirements Statement Each approved script SHALL identify its expected inputs. Source Part 4, Section 21.12: Script and Execution Requirements. Rationale Explicit input expectations make script prerequisites and execution conditions reviewable and repeatable. text/html 2026-08-07T21:29:30+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-12-004?rev=1786138170&do=diff P4-REQ-21-12-004 Return to Requirements Statement Each approved script SHALL identify its expected outputs. Source Part 4, Section 21.12: Script and Execution Requirements. Rationale Expected outputs define the observable results produced by a script and allow contributors to determine whether the script completed its intended task. text/html 2026-08-07T21:29:41+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-12-005?rev=1786138181&do=diff P4-REQ-21-12-005 Return to Requirements Statement Each approved script SHALL identify the artifacts it affects. Source Part 4, Section 21.12: Script and Execution Requirements. Rationale Scripts may create, modify, generate, start, stop, move, or remove implementation artifacts. text/html 2026-08-07T21:30:40+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-12-006?rev=1786138240&do=diff P4-REQ-21-12-006 Return to Requirements Statement Each approved script SHALL identify its logging behavior. Source Part 4, Section 21.12: Script and Execution Requirements. Rationale Script logging provides observable information about invocation, activity, outcome, warnings, failures, and cleanup. text/html 2026-08-07T21:30:52+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-12-007?rev=1786138252&do=diff P4-REQ-21-12-007 Return to Requirements Statement Each approved script SHALL identify its error-handling behavior. Source Part 4, Section 21.12: Script and Execution Requirements. Rationale Scripts that fail silently can leave generated artifacts, repository state, runtime participants, or configuration in an ambiguous or invalid condition. text/html 2026-08-07T21:31:01+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-12-008?rev=1786138261&do=diff P4-REQ-21-12-008 Return to Requirements Statement Each approved script SHALL identify its relationship to the Phase 0 implementation baseline. Source Part 4, Section 21.12: Script and Execution Requirements. Rationale Approved scripts may support baseline generation, preparation, execution, cleanup, or review, but not every script necessarily has the same baseline status or authority. text/html 2026-08-07T21:31:14+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-12-009?rev=1786138274&do=diff P4-REQ-21-12-009 Return to Requirements Statement Phase 0 SHALL include a prerequisite-checking script or equivalent controlled procedure. Source Part 4, Section 21.12: Script and Execution Requirements. Rationale Generation, build preparation, and execution depend on a valid environment containing required tools, directories, dependencies, configuration, and repository conventions. text/html 2026-08-07T21:31:26+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-12-010?rev=1786138286&do=diff P4-REQ-21-12-010 Return to Requirements Statement Phase 0 SHALL include a controlled type-generation script or equivalent controlled procedure when generated types form part of the implementation baseline. Source Part 4, Section 21.12: Script and Execution Requirements. text/html 2026-08-07T21:31:37+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-12-011?rev=1786138297&do=diff P4-REQ-21-12-011 Return to Requirements Statement Scripts that affect baseline artifacts, generated artifacts, runtime execution, repository state, or traceability SHALL follow the Developer Handbook and repository workflow. Source Part 4, Section 21.12: Script and Execution Requirements. text/html 2026-08-07T21:31:52+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-12-012?rev=1786138312&do=diff P4-REQ-21-12-012 Return to Requirements Statement Scripts SHALL NOT redefine FX logical Nodes, FX logical Communication Endpoints, FX logical interaction patterns, Runtime Planes, or governance relationships. Source Part 4, Section 21.12: Script and Execution Requirements. text/html 2026-08-07T21:32:53+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-13-001?rev=1786138373&do=diff P4-REQ-21-13-001 Return to Requirements Statement The Phase 0 Implementation Profile / PSM SHALL define an Implementation Governance Model. Source Part 4, Section 21.13: Implementation Governance Requirements. Rationale A defined Implementation Governance Model establishes how Phase 0 implementation artifacts are owned, versioned, reviewed, changed, generated, and accepted into the implementation baseline. text/html 2026-08-07T21:33:03+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-13-002?rev=1786138383&do=diff P4-REQ-21-13-002 Return to Requirements Statement Implementation governance SHALL define implementation ownership. Source Part 4, Section 21.13: Implementation Governance Requirements. Rationale Implementation ownership identifies responsibility for maintaining Phase 0 implementation artifacts and preserving their relationship to the logical elements or implementation concerns they support. text/html 2026-08-07T21:33:17+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-13-003?rev=1786138397&do=diff P4-REQ-21-13-003 Return to Requirements Statement Implementation governance SHALL define implementation versioning. Source Part 4, Section 21.13: Implementation Governance Requirements. Rationale Implementation versioning allows reviewers to determine which versions of source files, generated artifacts, mappings, configuration, scripts, and handbook rules belong to a particular Phase 0 baseline. text/html 2026-08-07T21:33:27+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-13-004?rev=1786138407&do=diff P4-REQ-21-13-004 Return to Requirements Statement Implementation governance SHALL define implementation compatibility. Source Part 4, Section 21.13: Implementation Governance Requirements. Rationale Phase 0 implementation artifacts must work together without loss of logical meaning, communication compatibility, generated-type compatibility, QoS compatibility, traceability, or reviewability. text/html 2026-08-07T21:33:45+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-13-005?rev=1786138425&do=diff P4-REQ-21-13-005 Return to Requirements Statement Implementation governance SHALL define implementation change control. Source Part 4, Section 21.13: Implementation Governance Requirements. Rationale Implementation change control ensures that changes to Phase 0 artifacts, mappings, configuration, scripts, repository structure, and handbook rules are reviewed before altering the approved baseline. text/html 2026-08-07T21:33:57+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-13-006?rev=1786138437&do=diff P4-REQ-21-13-006 Return to Requirements Statement Implementation governance SHALL define generated artifact governance. Source Part 4, Section 21.13: Implementation Governance Requirements. Rationale Generated artifacts sit between governed source definitions and executable implementation behavior and therefore require explicit governance. text/html 2026-08-07T21:34:10+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-13-007?rev=1786138450&do=diff P4-REQ-21-13-007 Return to Requirements Statement Implementation governance SHALL define repository governance. Source Part 4, Section 21.13: Implementation Governance Requirements. Rationale Repository governance controls how Phase 0 artifacts enter, move within, or leave the implementation baseline. text/html 2026-08-07T21:34:27+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-13-008?rev=1786138467&do=diff P4-REQ-21-13-008 Return to Requirements Statement Implementation governance SHALL define Developer Handbook governance. Source Part 4, Section 21.13: Implementation Governance Requirements. Rationale The Developer Handbook controls contributor practice and therefore requires governance over its approval, revision, application, and review. text/html 2026-08-07T21:34:41+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-13-009?rev=1786138481&do=diff P4-REQ-21-13-009 Return to Requirements Statement Each governed implementation artifact SHALL identify the responsible owner, owning role, or review authority according to the Developer Handbook and repository workflow. Source Part 4, Section 21.13: Implementation Governance Requirements. text/html 2026-08-07T21:34:52+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-13-010?rev=1786138492&do=diff P4-REQ-21-13-010 Return to Requirements Statement Each implementation change SHALL identify the changed artifact, reason for change, affected logical element or implementation concern, compatibility impact, traceability impact, Developer Handbook impact, and review outcome. text/html 2026-08-07T21:35:07+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-13-011?rev=1786138507&do=diff P4-REQ-21-13-011 Return to Requirements Statement Implementation governance SHALL preserve the relationship between the FX Demo Logical Profile and the Phase 0 implementation artifacts that realize it. Source Part 4, Section 21.13: Implementation Governance Requirements. text/html 2026-08-07T21:35:19+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-13-012?rev=1786138519&do=diff P4-REQ-21-13-012 Return to Requirements Statement Implementation governance SHALL NOT replace Part 3 logical governance. Source Part 4, Section 21.13: Implementation Governance Requirements. Rationale Part 3 governs the FX Demo Logical Profile, while Part 4 governs Phase 0 implementation artifacts and implementation mappings. text/html 2026-08-07T21:36:43+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-14-001?rev=1786138603&do=diff P4-REQ-21-14-001 Return to Requirements Statement The Phase 0 Implementation Profile / PSM SHALL define an Implementation Traceability Model. Source Part 4, Section 21.14: Implementation Traceability Requirements. Rationale An Implementation Traceability Model provides the controlled relationships needed to connect Phase 0 implementation artifacts to their architectural and logical sources. text/html 2026-08-07T21:36:53+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-14-002?rev=1786138613&do=diff P4-REQ-21-14-002 Return to Requirements Statement Implementation traceability SHALL preserve the chain from Part 1 conceptual elements, through Part 2 logical elements, through Part 3 FX logical profile elements, to Part 4 implementation artifacts. Source Part 4, Section 21.14: Implementation Traceability Requirements. text/html 2026-08-07T21:37:03+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-14-003?rev=1786138623&do=diff P4-REQ-21-14-003 Return to Requirements Statement Implementation traceability SHALL support forward review from FX logical elements to Phase 0 implementation artifacts. Source Part 4, Section 21.14: Implementation Traceability Requirements. Rationale Forward traceability allows reviewers to begin with an FX logical element and determine how that element is realized within the Phase 0 implementation baseline. text/html 2026-08-07T21:39:33+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-14-004?rev=1786138773&do=diff P4-REQ-21-14-004 Return to Requirements Statement Implementation traceability SHALL support backward review from Phase 0 implementation artifacts to FX logical elements or implementation concerns. Source Part 4, Section 21.14: Implementation Traceability Requirements. text/html 2026-08-07T21:39:58+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-14-005?rev=1786138798&do=diff P4-REQ-21-14-005 Return to Requirements Statement Node implementation traceability SHALL relate FX logical Nodes and Node Roles to implementation participants and modules. Source Part 4, Section 21.14: Implementation Traceability Requirements. Rationale FX logical Nodes and Node Roles may be realized through different Phase 0 runtime participants, modules, or packaging arrangements. text/html 2026-08-07T21:40:10+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-14-006?rev=1786138810&do=diff P4-REQ-21-14-006 Return to Requirements Statement Topic implementation traceability SHALL relate FX logical Communication Endpoints to DDS Topics. Source Part 4, Section 21.14: Implementation Traceability Requirements. Rationale DDS Topics provide the selected Phase 0 implementation realization of FX logical Communication Endpoints. text/html 2026-08-07T21:40:27+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-14-007?rev=1786138827&do=diff P4-REQ-21-14-007 Return to Requirements Statement IDL and generated type traceability SHALL relate FX logical information structures to IDL structures and generated types. Source Part 4, Section 21.14: Implementation Traceability Requirements. Rationale IDL structures and generated types provide Phase 0 implementation representations of FX logical information structures. text/html 2026-08-07T21:40:37+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-14-008?rev=1786138837&do=diff P4-REQ-21-14-008 Return to Requirements Statement Runtime Plane implementation traceability SHALL relate FX Runtime Planes to DDS topic families, QoS profiles, logging categories, exception-handling behavior, and implementation conventions. Source Part 4, Section 21.14: Implementation Traceability Requirements. text/html 2026-08-07T21:40:51+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-14-009?rev=1786138851&do=diff P4-REQ-21-14-009 Return to Requirements Statement Script and repository traceability SHALL relate scripts and repository locations to implementation concerns. Source Part 4, Section 21.14: Implementation Traceability Requirements. Rationale Scripts and repository locations frequently support implementation activity without directly realizing an FX logical element. text/html 2026-08-07T21:41:05+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-14-010?rev=1786138865&do=diff P4-REQ-21-14-010 Return to Requirements Statement Developer Handbook traceability SHALL relate handbook rules to implementation concerns and Part 4 requirements. Source Part 4, Section 21.14: Implementation Traceability Requirements. Rationale Developer Handbook rules translate Part 4 implementation discipline into practical contributor guidance. Those rules must therefore remain connected to the implementation concerns and normative requirements they support. text/html 2026-08-07T21:41:18+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-14-011?rev=1786138878&do=diff P4-REQ-21-14-011 Return to Requirements Statement Implementation traceability SHALL NOT redefine logical traceability. Source Part 4, Section 21.14: Implementation Traceability Requirements. Rationale Logical traceability is established by the conceptual, logical, and FX logical architecture layers. Part 4 extends that traceability into implementation artifacts but does not replace or alter the logical relationships defined by earlier parts. text/html 2026-08-07T21:43:16+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-15-001?rev=1786138996&do=diff P4-REQ-21-15-001 Return to Requirements Statement The Phase 0 Implementation Profile / PSM SHALL identify implementation artifacts prepared for Part 5 deployment, testability, operation, observation, and evidence planning. Source Part 4, Section 21.15: Part 5 Handoff Requirements. text/html 2026-08-07T21:43:27+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-15-002?rev=1786139007&do=diff P4-REQ-21-15-002 Return to Requirements Statement The Part 5 handoff SHALL identify implementation node mappings. Source Part 4, Section 21.15: Part 5 Handoff Requirements. Rationale Part 5 must know which Phase 0 implementation participants realize the applicable FX logical Nodes and Node Roles before those participants can be deployed, started, observed, tested, or evidenced. text/html 2026-08-07T21:43:43+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-15-003?rev=1786139023&do=diff P4-REQ-21-15-003 Return to Requirements Statement The Part 5 handoff SHALL identify DDS Topic mappings. Source Part 4, Section 21.15: Part 5 Handoff Requirements. Rationale Part 5 uses the communication mappings defined by Part 4 when deploying, exercising, observing, and testing Phase 0 implementation participants. text/html 2026-08-07T21:43:51+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-15-004?rev=1786139031&do=diff P4-REQ-21-15-004 Return to Requirements Statement The Part 5 handoff SHALL identify IDL and generated type mappings. Source Part 4, Section 21.15: Part 5 Handoff Requirements. Rationale Part 5 requires the implementation data representations defined by Part 4 in order to exercise and observe the selected Phase 0 communication flows. text/html 2026-08-07T21:44:03+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-15-005?rev=1786139043&do=diff P4-REQ-21-15-005 Return to Requirements Statement The Part 5 handoff SHALL identify QoS profile mappings. Source Part 4, Section 21.15: Part 5 Handoff Requirements. Rationale Part 5 requires the selected Phase 0 communication behavior when deploying and exercising DDS participants. text/html 2026-08-07T21:44:12+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-15-006?rev=1786139052&do=diff P4-REQ-21-15-006 Return to Requirements Statement The Part 5 handoff SHALL identify Runtime Plane realization. Source Part 4, Section 21.15: Part 5 Handoff Requirements. Rationale Part 5 must preserve the Runtime Plane distinctions implemented by Part 4 when deploying, observing, operating, testing, and evidencing Phase 0 behavior. text/html 2026-08-07T21:44:23+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-15-007?rev=1786139063&do=diff P4-REQ-21-15-007 Return to Requirements Statement The Part 5 handoff SHALL identify interaction pattern realization. Source Part 4, Section 21.15: Part 5 Handoff Requirements. Rationale Part 5 uses the implementation flows defined by Part 4 to construct demonstrations, tests, observation procedures, and evidence collection. text/html 2026-08-07T21:44:32+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-15-008?rev=1786139072&do=diff P4-REQ-21-15-008 Return to Requirements Statement The Part 5 handoff SHALL identify repository organization. Source Part 4, Section 21.15: Part 5 Handoff Requirements. Rationale Part 5 requires a clear understanding of where approved implementation artifacts, generated artifacts, configuration, scripts, documentation, and supporting material reside. text/html 2026-08-07T21:44:43+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-15-009?rev=1786139083&do=diff P4-REQ-21-15-009 Return to Requirements Statement The Part 5 handoff SHALL identify the script model. Source Part 4, Section 21.15: Part 5 Handoff Requirements. Rationale Part 5 may use approved scripts to prepare, start, stop, clean, or otherwise support the Phase 0 implementation environment. text/html 2026-08-07T21:44:51+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-15-010?rev=1786139091&do=diff P4-REQ-21-15-010 Return to Requirements Statement The Part 5 handoff SHALL identify Developer Handbook requirements. Source Part 4, Section 21.15: Part 5 Handoff Requirements. Rationale The implementation artifacts used by Part 5 are produced under the development discipline defined by the Phase 0 Developer Handbook. text/html 2026-08-07T21:45:00+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-15-011?rev=1786139100&do=diff P4-REQ-21-15-011 Return to Requirements Statement The Part 5 handoff SHALL identify implementation governance rules. Source Part 4, Section 21.15: Part 5 Handoff Requirements. Rationale Part 5 uses implementation artifacts that remain governed by Part 4 even when those artifacts are deployed, exercised, observed, or used for evidence collection. text/html 2026-08-07T21:45:11+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-15-012?rev=1786139111&do=diff P4-REQ-21-15-012 Return to Requirements Statement The Part 5 handoff SHALL identify implementation traceability relationships. Source Part 4, Section 21.15: Part 5 Handoff Requirements. Rationale Part 5 must preserve the architectural justification for the implementation artifacts it deploys, tests, observes, operates, and evidences. text/html 2026-08-07T21:45:25+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-15-013?rev=1786139125&do=diff P4-REQ-21-15-013 Return to Requirements Statement Part 4 SHALL NOT define deployment topology, runtime operations, test execution, acceptance evidence, runtime evidence, dashboards, Kubernetes or K3s deployment, Crucible scenarios, or final evidence packages. Source text/html 2026-08-07T21:45:35+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/p4-req-21-15-014?rev=1786139135&do=diff P4-REQ-21-15-014 Return to Requirements Statement Part 5 SHALL NOT redefine the Phase 0 implementation artifacts defined by Part 4. Source Part 4, Section 21.15: Part 5 Handoff Requirements. Rationale Part 5 deploys, tests, observes, operates, and evidences the Phase 0 implementation artifacts defined by Part 4. It does not become a second source of implementation-profile definitions. text/html 2026-07-11T20:00:02+00:00 Anonymous (anonymous@undisclosed.example.com) https://wiki.didosolutions.com/dido/99_annexes/annex-d-requirements/part-04/start?rev=1783800002&do=diff Part 4 Requirements Return to Annex D: Requirements This page identifies the canonical requirement records for Part 4: Phase 0 Implementation Profile / PSM. part-04 index ---------- © 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc.