Object

An Object is anything with identity that the force needs to track in the battlespace. Examples include platforms, units, facilities, equipment, personnel, events, control measures, signals, and other operationally relevant things.

The Object schema is intentionally flexible. Producers populate the fields they know and omit fields that are unknown or irrelevant for that object. Different object types naturally use different subsets: a vessel may include maritime identity, position, motion, dimensions, and assessment, while a facility may include location, dimensions, and assessment without motion.

Example

{
  "id": "link16-track-47210",
  "name": "TRACK-47210",
  "status": "OBJECT_STATUS_ACTIVE",
  "ttl": "2026-05-27T21:36:04Z",
  "identities": [
    {
      "system": "link16_track",
      "identifier": "47210"
    }
  ],
  "location": {
    "position": {
      "latitudeDegrees": 36.12,
      "longitudeDegrees": 42.88,
      "altitudeHaeMeters": 11500.0
    },
    "orientation": {
      "headingDegrees": 270.0
    }
  },
  "motion": {
    "velocityEnuMps": {
      "x": -240.0,
      "y": 15.0,
      "z": 0.0
    }
  },
  "assessment": {
    "affiliation": "AFFILIATION_HOSTILE",
    "environment": "ENVIRONMENT_HIGH_ALTITUDE"
  },
  "typeInfo": {
    "aviation": {
      "aircraftType": "Su-35S",
      "verticalMode": "VERTICAL_MODE_LEVEL"
    }
  },
  "provenance": {
    "name": "aegis-radar-07",
    "updatedAt": "2026-05-27T21:31:04Z"
  }
}

Details

Use details as the Object-level extension surface for data that is not part of the first-class WDM Object. It lets producers carry arbitrary structured payloads without changing the Object schema.

When details carries a known payload shape, include a @type value so consumers can identify and decode the structure consistently.

{
  "details": {
    "@type": "com.example.airdefense.EngagementGuidance",
    "value": {
      "weapons_control_status": "weapons_tight",
      "positive_id_required": true,
      "hold_fire_reason": "inside_restricted_operating_zone"
    }
  }
}

Discipline

Include provenance.updatedAt on every publish.
Provide an id unless you intentionally want the service to generate a new random ID.
Include ttl so stale Objects age out of the active picture.
Populate strongly typed fields before using details.
Omit unknown data instead of sending empty strings.

Lifecycle

Use status to tell consumers whether the Object belongs in the active operational picture. Use ttl to set when an otherwise active Object should expire if no producer refreshes it.

Use OBJECT_STATUS_ACTIVE for Objects consumers should currently display, correlate, and reason over.
Use OBJECT_STATUS_INACTIVE when the Object should be retained but no longer treated as actively tracked.
Use OBJECT_STATUS_DELETED when the Object should be removed from the picture.
Refresh ttl on each publish while the Object remains current.

{
  "id": "link16-track-47210",
  "status": "OBJECT_STATUS_ACTIVE",
  "ttl": "2026-05-27T21:36:04Z",
  "provenance": {
    "name": "aegis-radar-07",
    "updatedAt": "2026-05-27T21:31:04Z"
  }
}

When an Object’s ttl passes, it stops appearing in normal reads and ages out of the active picture. The service then publishes a deleted event and later removes the stored object. Set persist to true only for Objects that should not auto-expire; persistent Objects ignore ttl. If persist is false and no ttl is supplied, the service applies its configured default TTL.