Overview#
Push JC3IEDM-formatted military objects into the platform through a single authenticated interface, and have them appear in the shared operational picture without manual re-keying or format conversion.
The Joint C3 Information Exchange Data Model (JC3IEDM, defined by STANAG 5525) is the common information backbone that lets coalition command and control systems describe the same operational reality in the same terms. Units, equipment, facilities, and activities each carry a recognised object type, hostility and operational status, and a location, so that any participating nation can read another nation's reported entities without bespoke translation. The platform accepts that traffic directly, persists every field, and makes the whole object set available to watch-floor analysts, mission planners, and software integrators through one consistent, organisation-scoped interface.
Once ingested, JC3IEDM objects sit alongside tactical tracks, sensor feeds, and other allied data sources in the same operational view. Watch staff can correlate a coalition-reported unit or facility with intelligence, surveillance, and reconnaissance products, automatic number-plate reads, and other domain data, all under one clearance model and one audit trail. Repeated feeds from the same source remain idempotent, so a system can re-send its picture safely without creating duplicates.
Key Features#
-
JC3IEDM Object Ingestion. Submit a JC3IEDM military object and have every field captured in one operation. The record preserves object identifier, object type, name, hostility status, operational status, location, time, and secrecy level, so nothing from the original report is lost on the way into the store.
-
Idempotent Upsert on Re-Feed. Each object is keyed by organisation and object identifier, and a repeated feed of the same object updates the existing record in place rather than duplicating it. A source system can re-send its full picture on every cycle and the store stays clean.
-
Clearance-Based Record Filtering. Each object carries a secrecy level, and a shared interoperability bridge filters the returned record set against the requesting user's clearance at read time, from unclassified up through the classified tiers. Records above a user's level are withheld rather than redacted, enforcing correct handling in multi-level secure coalition environments.
-
Volume-by-Type Statistics. A dedicated statistics path summarises stored objects grouped by object type and ordered by count, so command staff can see the composition of the coalition-reported picture at a glance, for example how many units versus facilities versus activities are currently held.
-
Automatic Audit Capture. Every ingestion writes an interoperability ingest audit record carrying the source standard, record identifier, secrecy level, object identifier, object type, and name, together with the acting user and organisation. Nothing enters the store without an immutable trail behind it.
-
Coalition Fusion Emission. On ingestion, each object also emits an operational entity of type mission context into the coalition domain of the shared fusion layer, tagged with its source standard and secrecy level. Coalition-reported entities therefore contribute to the same operational view as every other allied data source rather than living in isolation.
-
Organisation Data Sovereignty. All storage, queries, and statistics are scoped to the authenticated organisation, so coalition partners on the same platform never see one another's object holdings.
-
No Custom Tooling Required. Defence agencies and integrators connect a JC3IEDM feed directly into the platform and consume it through the same interface they use for every other data source, removing the need to commission and maintain a bespoke store, parser, or viewer for the data model.
Use Cases#
Coalition Command and Control#
A combined joint task force headquarters receives JC3IEDM object feeds from multiple participating nations. Operators route that traffic into the platform and read it through one authenticated path, giving watch staff a single, consistent view of coalition-reported units, equipment, facilities, and activities without standing up a separate data-model handling system for each national feed.
Shared Operational Picture Correlation#
Mission planners and watch-floor analysts correlate coalition-reported entities with intelligence, surveillance, and reconnaissance products, ground moving target indications, automatic number-plate reads, and other domain data. Because JC3IEDM objects land in the same fusion layer as those sources, an analyst can reason across them together rather than switching between disconnected tools.
Multi-Level Secure Holdings#
In an environment mixing clearances, the same object store serves users at different accreditation levels safely. Clearance-based filtering ensures each operator sees only the records permitted by their accreditation, so a single shared holding can support staff across multiple security levels.
Systems Integrator Onboarding#
A systems integrator building a joint C2 application connects an allied data-model gateway to the platform, feeds JC3IEDM objects through a documented interface, and reads them back through one consistent path, rather than reverse-engineering a bespoke schema. Idempotent re-feeds and a documented input shape shorten integration timelines for partner systems.
Compliance and After-Action Review#
Because every ingestion is captured in the audit trail with its source standard, object metadata, and acting user, the store provides a complete record for compliance reporting and after-action review. Analysts can reconstruct exactly which objects were received, by whom, and when.
Integration#
The capability is provided through a GraphQL API with two read paths and one write path. A read path returns stored JC3IEDM objects for the authenticated organisation with optional object-type filtering and standard pagination, a second read path returns object counts grouped by object type, and a write path ingests a single JC3IEDM object. All access is authenticated with OAuth 2.0 bearer tokens in JSON Web Token (JWT) format and scoped to the authenticated organisation, consistent with the platform's identity and authorisation layer.
Objects are ingested as a structured input carrying object identifier, object type, name, hostility status, operational status, location, time, and secrecy level. The ingestion response confirms the new record identifier, the object identifier, and a success flag, so a calling system can immediately reconcile what it sent. Because the store keys on organisation and object identifier, a connector can replay its full picture on each cycle and the platform reconciles updates against existing records automatically.
Stored objects are held on the platform's normalised model and surfaced into the coalition domain of the shared fusion layer as mission-context entities tagged with their source standard. Downstream consumers, including the shared operational view, reporting modules, and alerting rules, work with JC3IEDM objects in the same way they work with other coalition and allied data sources. The benefit to a customer is direct: connect a coalition data-model feed once, and that traffic becomes part of the same picture, audit trail, and clearance model as everything else on the platform, with no custom store or parser to build or maintain. The domain sits alongside the platform's wider NATO interoperability layer, so a customer adopting JC3IEDM also gains a consistent path to the messaging and imagery standards held there.
Open Standards#
- JC3IEDM (Joint C3 Information Exchange Data Model), STANAG 5525. The coalition information exchange data model the platform ingests, stores, and queries. Objects are captured against their JC3IEDM object type, hostility status, operational status, location, and secrecy level, providing a common backbone for multinational command and control interoperability.
- MIP JC3IEDM (Multilateral Interoperability Programme). The multinational programme that governs and evolves the JC3IEDM specification. The platform recognises the MIP profile of the model within its coalition interoperability layer, keeping ingested objects aligned with the agreed multilateral data model.
- STANAG 4774 (Confidentiality Metadata Label Syntax). The NATO standard for expressing confidentiality metadata labels. Each ingested object carries a secrecy level, and clearance-based filtering applies the same label-aware handling used across the platform's coalition interoperability layer.
- STANAG 4778 (Metadata Binding Mechanism). The companion NATO standard for binding security metadata to the data it protects. It governs how confidentiality labels are kept associated with coalition data as it moves through the platform's interoperability layer alongside JC3IEDM objects.
- OAuth 2.0 / JWT. All API access is authenticated using OAuth 2.0 bearer tokens in JSON Web Token format, consistent with the platform's identity and authorisation layer.
Security and Compliance#
Every stored object carries a secrecy level spanning unclassified through the classified tiers. Record-level filtering checks the requesting user's clearance before any object is returned, so users in a multi-classification environment cannot read holdings above their permitted level, and records the user is not cleared for are withheld rather than redacted. All storage, queries, and statistics are organisation-scoped, preventing one coalition partner from seeing another's object holdings on a shared platform.
Every ingestion is written to the audit trail with its source standard, record identifier, secrecy level, object metadata, and the acting user and organisation, providing a complete and reviewable history for compliance and after-action purposes. Network separation between classified and unclassified sources remains the responsibility of the operator: classified data-model feeds should reach the platform over networks physically or cryptographically separated from unclassified infrastructure. The platform enforces classification and clearance policy on stored and queried data; it does not substitute for network-layer separation.
Last Reviewed: 2026-05-26 / Last Updated: 2026-05-26