State Model

BLUF

Stateless transport

Each message carries everything needed to interpret it on its own:

• A header with the originating node (source), the message_type, a schema version, and time_sent.
• A body with the full payload for that message type.

There is no connection setup, no sequence numbers, and no requirement that messages arrive in order to be individually valid. This makes the format transport-agnostic — it rides equally well over DDS, MQTT, or a file drop. Identity and recency are carried in the data (GUID identifiers and time_of_validity / timestamp fields) rather than in transport state.

Stateful domain

While delivery is stateless, the message set operates on state that endpoints accumulate. Three mechanisms make the domain stateful:

1. The shared picture, maintained by DYNAMIC_UPDATE

DYNAMIC_UPDATE carries incremental operations against the receiver's data-product store, so a receiver must hold and reconcile state across messages.

Because updates are keyed by GUID and stamped with time_of_validity, they are idempotent and order-tolerant: a late or duplicated update reconciles to the same picture.

2. The task lifecycle

Tasking is an explicit state machine. A TASK_ADMIN action drives transitions; the node reports progress with TASK_FEEDBACK and final products with TASK_RESULT. TaskStateEnum defines 21 states; the core lifecycle is:

The full TaskStateEnum also models the acknowledgement handshakes (WAITING_FOR_PUSH_ACK, WAITING_FOR_CANCEL_ACK, …) and planning states (PLANNING, PREPARED, ACTIONABLE). TaskAdminActionEnum is the input alphabet: ASSIGN, PUSH, PULL, UPDATE, PAUSE, RESUME, CANCEL.

3. Track lifecycle

A Track carries a TrackPhase that evolves as observations arrive or stop:

A tasking exchange end-to-end

Putting it together — stateless messages that advance stateful task and track machines between a C2 node and an unmanned system:

Implications for implementers

• Keep the message handler stateless — validate and route each message on its own; never require prior messages to parse one.
• Keep a reconciling store for the shared picture, keyed by identifier (GUID) and ordered by time_of_validity; apply DYNAMIC_UPDATE operations idempotently.
• Track task state explicitly per task GUID; treat TASK_ADMIN as the only driver of transitions and TASK_FEEDBACK as the observable state.
• Tolerate loss, duplication, and reordering — the design assumes lossy links.