====== 10.6 Node Status Reporting ======

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

[[fxdemo:05-part:10-node-implementation-pattern:start | Return to Node Implementation Pattern ]]

Each Phase 0 [[dido:99_annexes:annex-b-terms-and-definitions:n:node|Node]] should report operational status through the approved [[dido:99_annexes:annex-b-terms-and-definitions:c:control_plane|Control Plane]] status topic. Status reporting gives the team a basic way to observe the distributed Node network and collect [[dido:99_annexes:annex-b-terms-and-definitions:e:evidence|Evidence]] that runtime participants exist and behave as expected.

A Node status message should identify:

  - Node Identity.
  - Node Role.
  - Current [[dido:99_annexes:annex-b-terms-and-definitions:l:lifecycle|Lifecycle]] state.
  - Timestamp.
  - Status reason or message.
  - Runtime instance identifier, where needed.
  - Version or build identifier, where available.
  - Health or readiness information, where applicable.
  - Error information, where applicable.

Status messages should use the generated [[dido:99_annexes:annex-b-terms-and-definitions:d:dds|DDS]] types derived from the approved [[dido:99_annexes:annex-b-terms-and-definitions:i:idl|IDL]] definitions. Nodes should not publish ad hoc status structures outside the governed Control Plane type model.

The Node should publish status at Lifecycle transitions and may publish periodic heartbeat or health status if the Phase 0 Baseline requires it. The team should avoid excessive status traffic in Phase 0, but status frequency should be sufficient to observe whether the Node network is running.

Status reporting should support acceptance Evidence. A reviewer should be able to see that each required Node started, reached ''Running'', responded to relevant commands where applicable, stopped cleanly, and produced logs consistent with its reported Lifecycle behavior.

----

<WRAP centeralign>

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

</WRAP>