11.4 Control Plane Message Semantics

Go To Top

Return to Control Plane Topics

Control Plane messages should use governed type definitions generated from approved IDL source files. 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:

1. Node Identity from Node Role.
2. Lifecycle state from health detail.
3. Status message from error information.
4. Command type from command parameters.
5. Command target from the command issuer.
6. Command receipt from command completion.
7. 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 Baseline change.

Control Plane messages should remain small, focused, and operational. They should support coordination, visibility, and Evidence collection. They should not carry large payloads, domain records, or Data Plane content.