10.6 Node Status Reporting

Go To Top

Return to Node Implementation Pattern

Each Phase 0 Node should report operational status through the approved Control Plane status topic. Status reporting gives the team a basic way to observe the distributed Node network and collect Evidence that runtime participants exist and behave as expected.

A Node status message should identify:

1. Node Identity.
2. Node Role.
3. Current Lifecycle state.
4. Timestamp.
5. Status reason or message.
6. Runtime instance identifier, where needed.
7. Version or build identifier, where available.
8. Health or readiness information, where applicable.
9. Error information, where applicable.

Status messages should use the generated DDS types derived from the approved 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.