====== 11.4 Control Plane Message Semantics ======

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

[[fxdemo:05-part:11-control-plane-topics:start | Return to Control Plane Topics ]]

[[dido:99_annexes:annex-b-terms-and-definitions:c:control_plane|Control Plane]] messages should use governed type definitions generated from approved [[dido:99_annexes:annex-b-terms-and-definitions:i:idl|IDL]] source files. [[dido:99_annexes:annex-b-terms-and-definitions:n:node|Nodes]] should not publish ad hoc Control Plane messages that bypass the approved Control Plane type model.

The team should define the meaning of each Control Plane field in the IDL comments, Topic Catalogue, Node Catalogue, or supporting Repository documentation. A field should not rely on private interpretation by one implementation.

Control Plane message semantics should distinguish:

  - Node Identity from Node Role.
  - [[dido:99_annexes:annex-b-terms-and-definitions:l:lifecycle|Lifecycle]] state from health detail.
  - Status message from error information.
  - Command type from command parameters.
  - Command target from the command issuer.
  - Command receipt from command completion.
  - Runtime instance Identity from logical Node Identity.

The team should define any required enumerations, such as Lifecycle states and command types, in a controlled way. When developers add, rename, or remove enumeration values, they should treat the change as a compatibility-impacting [[dido:99_annexes:annex-b-terms-and-definitions:b:baseline|Baseline]] change.

Control Plane messages should remain small, focused, and operational. They should support coordination, visibility, and [[dido:99_annexes:annex-b-terms-and-definitions:e:evidence|Evidence]] collection. They should not carry large payloads, domain records, or [[dido:99_annexes:annex-b-terms-and-definitions:d:data_plane|Data Plane]] content.

----

<WRAP centeralign>

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

</WRAP>