Aviation domain attributes. From ADS-B, flight plans, radar, Link-16.

A circle defined by a center point and radius. No GeoJSON equivalent but widely used in military applications. Examples: engagement area, weapon effects radius, sensor range ring, circular error probable (CEP).

Upper triangle of a symmetric 3x3 matrix. For ENU covariance: xx=East-East, yy=North-North, zz=Up-Up. [ xx xy xz ] [ yy yz ] [ zz ]

An ellipse defined by center, semi-axes, and orientation. For a circle, set semi_major_axis_meters == semi_minor_axis_meters. Not GeoJSON compatible. Examples: positional uncertainty ellipse, radar coverage footprint, communications coverage area.

Emitter notation identification (ELNOT/CENOT).

Core representation of a tracked object in the battlespace. An Entity is anything with identity that warfighters need to track: platforms, units, facilities, equipment, personnel, events, control measures, etc. ## Flexible Field Model Entities use a **field-optional** design rather than strict entity subtypes. Most fields are optional - populate only what is relevant for the specific entity being represented. This flexibility allows the schema to represent diverse entity types without requiring separate message definitions for each category. Different entity types naturally use different field subsets: - **Maritime vessel**: location, motion, maritime info, identities (MMSI), dimensions - **Aircraft**: location, motion, aviation info, identities (Mode-S), assessment - **Ground vehicle**: location, motion, ground info, assessment, labels - **Facility**: location, dimensions, assessment (no motion) - **Person**: location, assessment (minimal fields) - **Control measure**: shape (or geometry), assessment, labels (no motion/dimensions) - **Event**: location, provenance, description (transient, no motion) ## Required vs Optional Fields **Minimally required for all entities:** - `id`: Unique identifier (generated if not provided) - `provenance.updated_at`: When this data was last modified **Commonly populated but optional:** - `name`: Human-readable identifier - `location.position`: Geographic coordinates - `assessment`: Tactical assessment (disposition, environment) **Domain-specific (populate as applicable):** - `type_info.maritime`: For ships, boats, submarines - `type_info.aviation`: For aircraft, helicopters, UAVs - `type_info.ground`: For vehicles, dismounts, equipment - `type_info.orbital`: For satellites, space objects - `type_info.signal`: For SIGINT/ELINT emissions **Motion-related (omit for stationary entities):** - `motion`: Velocity and acceleration (platforms in motion) - `orbital_motion`: Keplerian elements (satellites) - `state_vector`: Position and velocity vectors (high-precision orbital) **Specialized use cases:** - `shape`: Structured geometry (polygons, ellipses, circles, polylines) - `geometry`: Extended spatial representation as WKT string - `targeting`: When entity is a potential target - `dimensions`: Physical measurements when known - `details`: System-specific extensions ## Examples by Entity Type **Naval vessel (comprehensive):** ``` { "id": "...", "name": "USS Arleigh Burke", "location": {...}, "motion": {...}, "type_info": {"maritime": {"vessel_type": "MILITARY", "mmsi": "..."}}, "assessment": {"disposition": "FRIEND", "environment": "SURFACE"}, "dimensions": {...}, "provenance": {...} } ``` **Aircraft (typical):** ``` { "id": "...", "name": "REACH 421", "location": {...}, "motion": {...}, "type_info": {"aviation": {"aircraft_type": "C-17A", "callsign": "REACH421"}}, "assessment": {"disposition": "FRIEND"}, "provenance": {...} } ``` **Ground vehicle (minimal):** ``` { "id": "...", "location": {...}, "motion": {...}, "assessment": {"disposition": "HOSTILE", "environment": "SURFACE"}, "provenance": {...} } ``` **Facility (no motion):** ``` { "id": "...", "name": "FOB Lightning", "location": {...}, "assessment": {"disposition": "FRIEND"}, "dimensions": {...}, "provenance": {...} } ``` **Event (transient):** ``` { "id": "...", "name": "IED Strike", "description": "Vehicle-borne IED...", "location": {...}, "provenance": {...} } ``` ## Field Population Guidelines 1. **Populate what you know** - Omit unknown or irrelevant fields 2. **Don't invent data** - Empty/default values can mislead consumers 3. **Use type_info discriminator** - Populate the domain-specific section that applies 4. **Provenance is critical** - Always include source and timestamp 5. **Assessment is required for warfighting context** - Disposition and environment provide tactical context The authoritative timestamp for entity updates is in `provenance.updated_at`.

Warfighter's tactical assessment of this entity. IMPORTANT: This is ASSESSED affiliation, not ground truth. The actual identity may differ. Drives MIL-STD-2525 symbology and ROE.

Operational flags for data segregation.

Domain-specific attributes. Populate the relevant component based on entity domain.

Uncertainty expressed as an error ellipse. Captures sensor-reported error bounds without requiring conversion to a covariance matrix.

Fuel, ordnance, and gun ammunition state. Domain-agnostic: applicable to aircraft, ground vehicles, ships, and any other entity that carries fuel or munitions.

Field of view (FOV) for a sensor. Describes a 3D viewing volume defined as an angular cone with optional range bounds. Supports both symmetric (circular) and asymmetric (rectangular) apertures. The cone is oriented relative to the entity's body frame using an Orientation message (heading, pitch, roll). When the parent entity's location.orientation is also populated, consumers can compose the two to derive the absolute look direction in world coordinates. ## 3D Cone The 3D viewing volume is defined by: - look_orientation: direction the boresight points (body-frame) - horizontal_fov_degrees: total azimuth span of the cone - vertical_fov_degrees: total elevation span of the cone - min_range_meters / max_range_meters: near and far range limits For a symmetric (circular) FOV, set horizontal and vertical spans equal. ## 2D Projected Footprint The ground_footprint field provides a pre-computed 2D projection of the viewing volume onto the terrain surface. This is a Polygon because terrain intersection of a cone generally produces a quadrilateral or irregular shape, not a simple circle or ellipse. Producers that have access to a terrain model should populate this field. Consumers without terrain data can use it directly for map rendering without recomputing the projection.

Current fuel state for a single fuel type.

Ground domain attributes.

Onboard gun ammunition state.

External system identifier. Enables correlation across systems (AIS, ADS-B, Link-16, etc.).

A closed ring of positions forming a polygon boundary. The first and last positions must be identical to close the ring. Must contain at least 4 positions (3 distinct vertices + closing point). Winding order follows GeoJSON convention: - Exterior rings: counter-clockwise. - Interior rings (holes): clockwise.

Maritime domain attributes. Primarily from AIS.

Mode 5 IFF interrogation data.

Velocity and acceleration in the local East-North-Up (ENU) frame. ENU is a local tangent plane coordinate system: East: positive toward geographic east North: positive toward geographic north Up: positive away from Earth center (perpendicular to ellipsoid)

Semantic classification of the entity. Combines operational typing with extensible ontology references. The `category` enum provides a fixed operational classification grounded in BFO (Basic Formal Ontology) and CCO (Common Core Ontologies), while `refs` allows ontologists to supply formal type URIs from any ontology (BFO, CCO, DICO, domain-specific, etc.) without schema changes. This supports DNI/DIA mandates for BFO/CCO alignment while remaining ontology-agnostic at the schema level. CCO Alignment Notes: - Entity.name maps to cco:designated_by -> cco:DesignativeName - Entity.identities maps to cco:designated_by -> cco:CodeIdentifier - Entity.description maps to cco:described_by -> cco:DescriptiveInformationContentEntity - Entity.location maps to bfo:located_in -> cco:GeospatialRegion Example ontology_refs: "bfo:IndependentContinuant" "cco:Aircraft" "cco:MilitaryOrganization" "mil:APP-6D/SFGPUCIZ---"

Motion fields that generally match a Two-Line Element set.

A single expendable ordnance type carried by the entity. Covers weapons (missiles, bombs, torpedoes), countermeasures (flares, chaff, decoys), and other deployable stores (sonobuoys).

Orientation (attitude) in 3D space using Euler angles. Convention: Tait-Bryan angles (aerospace sequence). Order: Yaw (heading) -> Pitch -> Roll

Physical size and mass of the entity. Used for recognition, classification, and logistics planning.

A single geographic point. GeoJSON equivalent: Point. See https://datatracker.ietf.org/doc/html/rfc7946#section-3.1.2 Examples: observation post, waypoint, point target.

A closed polygon defined by an exterior ring and optional interior holes. GeoJSON equivalent: Polygon (only canonical representations accepted). See https://datatracker.ietf.org/doc/html/rfc7946#section-3.1.6 Follows the right-hand rule: exterior rings are counter-clockwise, interior rings (holes) are clockwise. Examples: area of operations (AO), engagement area, named area of interest (NAI), restricted operations zone (ROZ).

An ordered sequence of positions forming a line or path. GeoJSON equivalent: LineString. See https://datatracker.ietf.org/doc/html/rfc7946#section-3.1.4 Must contain at least 2 positions. Examples: route, main supply route (MSR), phase line, flight path.

Geographic position in WGS-84 coordinates. Supports multiple altitude references for interoperability: HAE: GPS-native, precision applications MSL: Aviation (flight levels, altimeters) AGL: Low-altitude ops, terrain following Depth: Subsurface operations

A rectangle defined by two centerline points and a width. The two points define the centerline (long axis) of the rectangle. The width extends perpendicular to that line on both sides. Orientation is implicit from the bearing of point_1 to point_2. ┌─────────────────────┐ │ ^ │ │ │ │ point_1 width point_2 │ │ │ │ v │ └─────────────────────┘ Structurally guarantees a valid rectangle. Examples: kill box, fire support area, restricted fire area (RFA), no-fire area (NFA), free-fire area (FFA).

Scanning behavior of a signal source.

A sensor mounted on an entity. Groups one or more fields of view under a named, typed sensor. Examples: "search radar", "spherical sonar array", "EO turret".

Typed MIL-STD-2525C symbol modifier fields. Each field corresponds to a modifier defined in MIL-STD-2525C, Appendix A, Table XIV. The field comment includes the 2525C modifier letter code in parentheses. All fields are optional; populate only what is known and relevant. Reference: MIL-STD-2525C, Appendix A, Table XIV.

Signal domain attributes. Core fields (frequency, RSSI, line of bearing) are sufficient for basic signal representation. Extended fields (SNR, pulse characteristics, scan behavior, emitter notations) support ELINT classification and EW-to-fires candidate scoring.

Structured geometric shape for spatial representation. Provides typed alternatives to the WKT-based Entity.geometry string field. Use for boundaries, coverage areas, routes, sensor footprints, and other non-point geometries. Exactly one shape type must be set. The shape defines the spatial extent of an entity: boundaries, coverage areas, routes, sensor footprints, and other non-point geometries. For simple point entities, use Entity.location instead. GeoJSON compatibility: - Point, Polyline, and Polygon map directly to GeoJSON Point, LineString, and Polygon types. - Circle and Ellipse have no GeoJSON equivalent but are common in military and geospatial applications.

Geographic position and orientation of an entity. Combines where something is (position) with how it's oriented (attitude). Position uses WGS-84 datum with multiple altitude representations to support different operational contexts.

Speed with explicit unit of measure. Used for the MIL-STD-2525C speed modifier (Z) where the unit system may vary by operational context.

Typed military symbology representation supporting MIL-STD-2525C/D. Provides both a raw SIDC string for interoperability and a decomposed, typed modifier structure for programmatic access. Consumers should prefer the typed modifiers when available; the raw sidc field serves as a canonical interchange format. Example (2525C friendly ground mechanized infantry): symbology { sidc: "SFGPUCIZ--*****" version: SIDC_VERSION_2525C modifiers { unique_designation: "1-87 IN" higher_formation: "3BCT" combat_effectiveness: "GREEN" } }

Targeting and threat assessment data.

Track quality and measurement metadata. Provides consumers with information about how this entity's position was derived and how much to trust it. Distinct from EntityAssessment, which captures the warfighter's tactical assessment (disposition, environment, confidence in identity).

IFF/transponder interrogation data. Mode 1-5 and Mode S codes from IFF interrogation. Applicable to air, surface, and ground entities with transponders.

Generic 3D vector. For ENU velocity: x=East, y=North, z=Up. For ENU acceleration: same convention.

Data lineage and source attribution for trust assessment. Provenance tracks where information originated, enabling consumers to assess reliability and make informed fusion decisions. Critical for intelligence analysis where source credibility affects confidence. Loosely modeled on W3C PROV-DM (https://www.w3.org/TR/prov-dm/), but intentionally simplified so it can be attached cheaply to every record.

Reconciliation engine decision metadata. Stamped on every entity that passes through the reconciliation engine. Tracks which policy made the decision, what action was taken, and why. Read-only; populated by the reconciliation engine on every upsert.

SecurityComponents contains the structured classification components

SecurityMarking represents normalized classification marking Compatible with df-classification ISM format

Reference to a person, unit, or system that can request, authorize, or execute tasks.

A directed action to be performed by a principal (e.g., person, unit, or system). Tasks represent the command and control (C2) layer: orders, requests, and assignments that drive operations. They connect requestors (who wants something done) with executors (who will do it). IMPORTANT: Tasks are immutable after creation except for state transitions. If task details need to change, cancel the existing task (set state to TASK_STATE_CANCELLED) and create a new one with the correct information. Examples: ISR collection request, fire mission, movement order, logistics request, sensor tasking.

Execution progress within a task's current state.