====== 7.8 Node Naming ======

[[fxdemo:05-part:start | Go To Top ]]

[[fxdemo:05-part:07-naming-and-file-conventions:start | Return to Naming and File Conventions ]]

[[dido:99_annexes:annex-b-terms-and-definitions:n:node|Node]] names should identify the runtime participant and its role in the Phase 0 Node network. A Node name should help the team understand what the Node represents, which logical role it supports, and how it participates in [[dido:99_annexes:annex-b-terms-and-definitions:c:control_plane|Control Plane]] and [[dido:99_annexes:annex-b-terms-and-definitions:d:data_plane|Data Plane]] interactions.

Node names should use stable logical or demonstration role names rather than local process names, developer initials, or container names. The implementation may map a Node to a process, executable, service, or container, but the Node name should preserve the architectural role.

Representative Node names may include:

  * ''fx-reference-data-node''
  * ''fx-contract-ingestion-node''
  * ''fx-validation-node''
  * ''fx-calculation-node''
  * ''fx-attestation-node''
  * ''fx-release-node''
  * ''control-plane-observer-node''

For Phase 0 Hello World Nodes, the team may use simplified names, but those names should still point toward the future demonstration role rather than remaining generic placeholders. For example, ''fx-validation-node'' is more useful than ''hello-node-3''.

The team should document every Phase 0 Node in the Node Catalogue. The catalogue should identify the Node name, Node type, purpose, implementation language, [[dido:99_annexes:annex-b-terms-and-definitions:c:configuration|Configuration]] file, published topics, subscribed topics, [[dido:99_annexes:annex-b-terms-and-definitions:l:lifecycle|Lifecycle]] behaviour, and Control Plane status behaviour.

----

<WRAP centeralign>

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

</WRAP>