MDOC Interoperability & Connector Support Matrix

Overview#

Argus catalogues every NATO and open standard its Multi-Domain Operations Cloud (MDOC) can carry as a live track feed, and publishes exactly which of those are native today, which require a certified partner gateway, and which are only planned, in one machine-generated matrix, without an NDA.

Most vendors in this space describe interoperability in a slide with checkmarks. This page is the source-code-derived alternative: the table below is generated directly from the SUPPORT_MATRIX list in Argus's connector SDK (app/domains/operational_picture/mdoc_connector_sdk.py), not hand-typed, so a standard cannot be quietly upgraded from "planned" to "native" in marketing copy without the same change landing in the code this page is generated from. The companion Partner Bridge Contract below documents the exact JSON shape, endpoint, authentication, and batch/latency limits a certified TDL (Tactical Data Link) or OEM platform-telemetry partner needs to integrate, again taken from the real dataclass in that same module, not paraphrased.

Last Reviewed: 2026-08-12 Last Updated: 2026-08-12

Connector Support Matrix#

Three support levels appear in the matrix, and they mean exactly what they say:

• native: Argus ships an in-process parser for the standard (in mdoc_feed_strategies.py) that turns a pushed payload directly into track records on the live operational picture. contributes_to_live_picture is true.
• partner: no in-process parser exists. A certified external gateway (TDL terminal, multilink bridge, or OEM platform link) must decode the native waveform itself and hand Argus already-normalized data. contributes_to_live_picture is hard-coded false in the SDK for every partner-level row today, regardless of certification status, because no certified partner bridge has been connected in production yet.
• planned: catalogued in the enum and the matrix for roadmap visibility. No parser, no transport, no live path. contributes_to_live_picture is false.

Regenerating this table#

Hand-transcribing this table is exactly the failure mode this page exists to avoid, so it isn't hand-transcribed. It comes from a small, read-only export script added alongside the SDK for this purpose:

cd argus_middleware
venv/bin/python scripts/export_mdoc_support_matrix.py

The script imports list_support_matrix() and list_partner_bridges() from mdoc_connector_sdk.py and serializes their output as-is; it makes no database calls, requires no environment bootstrap, and changes no production behavior. Whenever SUPPORT_MATRIX or PARTNER_BRIDGES changes in the backend, re-run the script and diff its output against the table and the raw JSON block below; anything that doesn't match is this page drifting out of date and should be fixed in the same change.

Every row currently shares the same classification_default (NATO_RESTRICTED), releasable_to (["NATO"]), and auth_ref_required (true); none has pull_supported set. STANAG_4607 (without the _GMTI suffix) is accepted as an alias of STANAG_4607_GMTI by the live-feed normalizer and is not a separate matrix row.

Two rows carry longer notes worth quoting exactly, because the wording matters:

LINK_16: "No native radio waveform; partner bridge only."

STANAG_4586: "DLI Message #101 (Inertial States) binary codec built and tested against the real published STANAG (app/integrations/nato/stanag_4586_dli.py) and reachable via TrackRegistryService.ingest_updates(), but no live transport/listener exists anywhere in this application that feeds it real wire bytes, and it has no entry in NATIVE_LIVE_STANDARDS (mdoc_feed_strategies.py), so it is not reachable via the generic /api/v1/mdoc/live/ingest push-feed endpoint either. Remains PLANNED until a real transport is wired: this is a mapping-layer-only step, not a live capability."

That STANAG 4586 note is the clearest illustration of why this page is generated, not written: a codec that exists and is tested is still catalogued as PLANNED, not NATIVE, because "the parser exists" and "there is a live path" are different questions and the matrix only answers the second one as "yes."

{
  "_generated_by": "scripts/export_mdoc_support_matrix.py",
  "_source": "app/domains/operational_picture/mdoc_connector_sdk.py",
  "native_live_standards": [
    "ADS_B",
    "AIS",
    "COT_2_0",
    "NFFI",
    "STANAG_4607",
    "STANAG_4607_GMTI",
    "STANAG_4676"
  ],
  "connectors": [
    {
      "connector_id": "native-stanag-4676",
      "standard": "STANAG_4676",
      "display_name": "STANAG 4676 ISR tracks",
      "support_level": "native",
      "transport": "http_push",
      "contributes_to_live_picture": true,
      "classification_default": "NATO_RESTRICTED",
      "releasable_to": ["NATO"],
      "auth_ref_required": true,
      "pull_supported": false,
      "notes": "Native MDOC strategy for STANAG_4676",
      "partner_certification": null
    },
    {
      "connector_id": "native-cot-2-0",
      "standard": "COT_2_0",
      "display_name": "Cursor-on-Target / TAK",
      "support_level": "native",
      "transport": "http_push",
      "contributes_to_live_picture": true,
      "classification_default": "NATO_RESTRICTED",
      "releasable_to": ["NATO"],
      "auth_ref_required": true,
      "pull_supported": false,
      "notes": "Native MDOC strategy for COT_2_0",
      "partner_certification": null
    },
    {
      "connector_id": "native-ads-b",
      "standard": "ADS_B",
      "display_name": "ADS-B air surveillance",
      "support_level": "native",
      "transport": "http_push",
      "contributes_to_live_picture": true,
      "classification_default": "NATO_RESTRICTED",
      "releasable_to": ["NATO"],
      "auth_ref_required": true,
      "pull_supported": false,
      "notes": "Native MDOC strategy for ADS_B",
      "partner_certification": null
    },
    {
      "connector_id": "native-ais",
      "standard": "AIS",
      "display_name": "AIS maritime surveillance",
      "support_level": "native",
      "transport": "http_push",
      "contributes_to_live_picture": true,
      "classification_default": "NATO_RESTRICTED",
      "releasable_to": ["NATO"],
      "auth_ref_required": true,
      "pull_supported": false,
      "notes": "Native MDOC strategy for AIS",
      "partner_certification": null
    },
    {
      "connector_id": "native-nffi",
      "standard": "NFFI",
      "display_name": "NFFI friendly force (STANAG 5527)",
      "support_level": "native",
      "transport": "http_push",
      "contributes_to_live_picture": true,
      "classification_default": "NATO_RESTRICTED",
      "releasable_to": ["NATO"],
      "auth_ref_required": true,
      "pull_supported": false,
      "notes": "Native MDOC strategy for NFFI",
      "partner_certification": null
    },
    {
      "connector_id": "native-stanag-4607-gmti",
      "standard": "STANAG_4607_GMTI",
      "display_name": "STANAG 4607 GMTI",
      "support_level": "native",
      "transport": "http_push",
      "contributes_to_live_picture": true,
      "classification_default": "NATO_RESTRICTED",
      "releasable_to": ["NATO"],
      "auth_ref_required": true,
      "pull_supported": false,
      "notes": "JSON detections or base64 packet; dual-written from sensor fusion",
      "partner_certification": null
    },
    {
      "connector_id": "partner-link-16",
      "standard": "LINK_16",
      "display_name": "Link-16 / J-series",
      "support_level": "partner",
      "transport": "partner_bridge",
      "contributes_to_live_picture": false,
      "classification_default": "NATO_RESTRICTED",
      "releasable_to": ["NATO"],
      "auth_ref_required": true,
      "pull_supported": false,
      "notes": "No native radio waveform; partner bridge only",
      "partner_certification": "Certified TDL gateway (JREAP-C or equivalent)"
    },
    {
      "connector_id": "partner-link22",
      "standard": "LINK22",
      "display_name": "Link-22",
      "support_level": "partner",
      "transport": "partner_bridge",
      "contributes_to_live_picture": false,
      "classification_default": "NATO_RESTRICTED",
      "releasable_to": ["NATO"],
      "auth_ref_required": true,
      "pull_supported": false,
      "notes": "Requires certified partner gateway; push TrackUpdates via MDOC live ingest",
      "partner_certification": "Certified multilink gateway"
    },
    {
      "connector_id": "partner-jreap",
      "standard": "JREAP",
      "display_name": "JREAP",
      "support_level": "partner",
      "transport": "partner_bridge",
      "contributes_to_live_picture": false,
      "classification_default": "NATO_RESTRICTED",
      "releasable_to": ["NATO"],
      "auth_ref_required": true,
      "pull_supported": false,
      "notes": "Requires certified partner gateway; push TrackUpdates via MDOC live ingest",
      "partner_certification": "Certified JREAP gateway"
    },
    {
      "connector_id": "planned-jc3iedm",
      "standard": "JC3IEDM",
      "display_name": "JC3IEDM / MIP mediation",
      "support_level": "planned",
      "transport": "http_push",
      "contributes_to_live_picture": false,
      "classification_default": "NATO_RESTRICTED",
      "releasable_to": ["NATO"],
      "auth_ref_required": true,
      "pull_supported": false,
      "notes": "Catalogued; no native strategy yet",
      "partner_certification": null
    },
    {
      "connector_id": "planned-mip-jc3iedm",
      "standard": "MIP_JC3IEDM",
      "display_name": "MIP JC3IEDM",
      "support_level": "planned",
      "transport": "http_push",
      "contributes_to_live_picture": false,
      "classification_default": "NATO_RESTRICTED",
      "releasable_to": ["NATO"],
      "auth_ref_required": true,
      "pull_supported": false,
      "notes": "Catalogued; no native strategy yet",
      "partner_certification": null
    },
    {
      "connector_id": "planned-stanag-4559",
      "standard": "STANAG_4559",
      "display_name": "STANAG 4559 NSILI",
      "support_level": "planned",
      "transport": "http_push",
      "contributes_to_live_picture": false,
      "classification_default": "NATO_RESTRICTED",
      "releasable_to": ["NATO"],
      "auth_ref_required": true,
      "pull_supported": false,
      "notes": "Catalogued; no native strategy yet",
      "partner_certification": null
    },
    {
      "connector_id": "planned-stanag-4586",
      "standard": "STANAG_4586",
      "display_name": "STANAG 4586 UAV control",
      "support_level": "planned",
      "transport": "http_push",
      "contributes_to_live_picture": false,
      "classification_default": "NATO_RESTRICTED",
      "releasable_to": ["NATO"],
      "auth_ref_required": true,
      "pull_supported": false,
      "notes": "DLI Message #101 (Inertial States) binary codec built and tested against the real published STANAG (app/integrations/nato/stanag_4586_dli.py) and reachable via TrackRegistryService.ingest_updates() -- but no live transport/listener exists anywhere in this application that feeds it real wire bytes, and it has no entry in NATIVE_LIVE_STANDARDS (mdoc_feed_strategies.py), so it is not reachable via the generic /api/v1/mdoc/live/ingest push-feed endpoint either. Remains PLANNED until a real transport is wired: this is a mapping-layer-only step, not a live capability.",
      "partner_certification": null
    }
  ],
  "partner_bridges": [
    {
      "bridge_id": "link16-jreap-partner",
      "standards": ["LINK_16", "JREAP", "APP_11"],
      "push_endpoint": "/api/v1/mdoc/live/ingest",
      "health_endpoint": "/api/v1/mdoc/live/health",
      "required_auth": "service_jwt_tenant_bound",
      "required_fields": ["sourceId", "tenantId", "standard", "payload"],
      "max_batch_size": 500,
      "max_latency_sla_ms": 5000,
      "classification_handling": "preserve_source_label",
      "notes": "Certified Link-16/JREAP partner pushes tracks; Argus fuses and policy-gates."
    },
    {
      "bridge_id": "platform-telemetry-partner",
      "standards": ["GROUND_MBT", "AIR_A4R", "UWW_FUWN"],
      "push_endpoint": "/api/v1/mdoc/live/ingest",
      "health_endpoint": "/api/v1/mdoc/live/health",
      "required_auth": "service_jwt_tenant_bound",
      "required_fields": ["sourceId", "tenantId", "standard", "payload"],
      "max_batch_size": 500,
      "max_latency_sla_ms": 5000,
      "classification_handling": "preserve_source_label",
      "notes": "OEM platform telemetry via partner; never inline secrets."
    }
  ]
}

Partner Bridge Contract#

A partner bridge is the contract a certified TDL or OEM gateway implements to push normalized track data into Argus. Two bridges are configured today:

The three standard codes on platform-telemetry-partner (GROUND_MBT, AIR_A4R, UWW_FUWN) do not appear in the OperationalSourceStandard enum or anywhere else in the connector matrix. Treat them as placeholder OEM telemetry categories, not a catalogued open standard, and confirm the exact schema with Argus integration engineering before building against them.

Required request fields#

Every push, regardless of bridge, sends the same four top-level JSON fields:

{
  "sourceId": "<the source_id Argus has configured for your tenant>",
  "tenantId": "<your tenant identifier, must match your service JWT>",
  "standard": "<the canonical OperationalSourceStandard value, e.g. COT_2_0>",
  "payload": { "...": "standard-specific track data, see below" }
}

format is optional (defaults to json; xml is accepted for STANAG 4676 and CoT).

The waveform-decode boundary: what a partner actually sends#

None of the three partner-only standards (LINK_16, LINK22, JREAP) has an in-process parser. mdoc_feed_strategies.py only knows how to turn STANAG 4676, CoT 2.0, ADS-B, AIS, NFFI, and STANAG 4607 GMTI payloads into track records. A certified TDL gateway is therefore responsible for decoding the tactical waveform itself and re-emitting the result in the JSON shape of one of those six native standards; the SDK's own contract note says this outright: "Partner must not claim native waveform ownership. Argus owns fusion, policy, audit, and COP."

Concretely, a Link-16 partner gateway that has already decoded a J-series track would push it as a CoT 2.0 contact (the most general native shape for point tracks), with the underlying feed source pre-configured on the Argus side as source_standard: COT_2_0, not LINK_16:

POST /api/v1/mdoc/live/ingest
Authorization: Bearer <RS256 service JWT>
Content-Type: application/json

{
  "sourceId": "tenant-alpha-link16-bridge-1",
  "tenantId": "tenant-alpha",
  "standard": "COT_2_0",
  "format": "json",
  "payload": {
    "contacts": [
      {
        "cot_uid": "LNK16-TRK-004821",
        "callsign": "EAGLE-1",
        "cot_type": "a-f-A",
        "lat": 54.271,
        "lon": -8.478,
        "hae": 9800,
        "speed_mps": 231.5,
        "course_deg": 274,
        "domain": "AIR",
        "observed_at": "2026-08-12T10:14:02Z"
      }
    ]
  }
}

Trying to configure a feed source with source_standard: LINK_16 and contributes_to_live_picture: true is rejected server-side, not just discouraged: the adapter raises an error stating the standard "cannot contribute to the live picture until a native MDOC strategy is registered." That check exists specifically so a partner-only standard can never be marked authoritative by configuration alone.

Current Implementation Status#

This section exists so relaxing any of the following is a visible, dated change to this page, not a quiet one: that is the reason this whole document is generated from code in the first place.

• Native standards are live today. All seven values in NATIVE_LIVE_STANDARDS (six matrix rows, since STANAG_4607 is an alias of STANAG_4607_GMTI) have a working in-process parser and can contribute to the production operational picture now.
• No partner bridge is live in production. The contributes_to_live_picture field is hard-coded false for every partner-level row in the SDK, independent of what partner_certification says: a certified gateway existing is not the same as one being connected. Nothing changes that until a certified bridge is actually wired and the code is updated to reflect it, which is exactly the change this page is designed to surface.
• Planned standards contribute nothing today. JC3IEDM, MIP JC3IEDM, STANAG 4559 NSILI, and STANAG 4586 are catalogued for roadmap visibility only. STANAG 4586 has a tested wire-format codec (stanag_4586_dli.py) but no live transport calling it; see the quoted note above.
• The generic multi-standard push endpoint is not yet reachable by anyone. Argus's internal service-JWT registry (app/security/service_scopes.py) maps each internal route to a required scope, and unregistered routes are rejected by design. As of this writing, /api/v1/mdoc/live/ingest (the endpoint named as the push_endpoint for both partner bridges above) has no registered scope, so it returns 401 to every caller, including a caller presenting an otherwise-valid service JWT. The only push route with a provisioned scope today is the legacy, STANAG-4676-only /api/v1/mdoc/live/stanag4676 route. A real partner integration requires Argus to register a scope for the generic route (or route the partner through the STANAG 4676 shape) as part of onboarding: this is an operational step to schedule with Argus integration engineering, not a self-service signup.
• Source provisioning is server-side, not self-service. POST /sources/register does not accept a source definition in the request body; it re-registers whatever sources are already defined in Argus's own feed configuration (a local file or environment variable) for the caller's tenant. A partner cannot create a new feed source purely by calling the API: Argus has to configure it first.
• The discovery endpoint now has a registered scope. GET /api/v1/mdoc/live/connectors/matrix returns this same matrix as JSON. It previously had no registered scope in app/security/service_scopes.py, the same root cause as the push endpoint above, so it returned 401 to every caller regardless of token validity. That has been fixed: the route now resolves to a dedicated, non-sensitive, read-only scope (middleware:mdoc-live:matrix:read), so a service JWT carrying that scope is accepted. /connectors/onboarding/{standard}, /connectors/validate, and the generic multi-standard /ingest push remain unregistered by deliberate decision, not the same oversight: opening those is a separate call about partner self-service ingest, not discovery. This markdown page and the live endpoint should now stay in sync; if the endpoint's response shape changes, update this page in the same change.
• No certification, accreditation, or formal validation is claimed anywhere above. Every "native" row means Argus implements the wire format of that standard's messages, verified by unit tests against the parser, not that Argus or the standard's implementation has passed NATO interoperability testing (CWIX), AV&V, or any accreditation process. partner_certification values name what the outside partner's own gateway must hold (for example, "Certified TDL gateway (JREAP-C or equivalent)"): they are not certifications Argus itself has received.

Key Features#

Machine-Generated Support Matrix#

The connector table above is exported directly from SUPPORT_MATRIX via a one-command script, not maintained as separate prose, so the native/partner/planned classification a partner reads here cannot silently diverge from the classification the ingest code actually enforces.

Fail-Closed Native-Only Live Contribution#

A feed source cannot be marked contributes_to_live_picture: true unless its standard has a registered native parser. The check runs both at manifest-validation time (validate_manifest) and at feed-source-definition time (MdocFeedSourceDefinition.from_mapping), so a partner-only standard cannot reach the live picture by misconfiguration.

Tenant-Bound Service Authentication#

Every MDOC live route accepts only an RS256 service JWT presented as Authorization: Bearer <token>, scoped per-route by a central registry, and cross-checked so the JWT's own tenant claim must match the tenant named in the request body: a token scoped to one tenant cannot attribute tracks to another.

Onboarding Checklist Generator#

build_onboarding_checklist(standard) returns the concrete steps to bring a given standard live: define the feed source, set classification and releasability, register it, push a sample payload, and confirm the source shows HEALTHY with track assertions on the operational picture. For a non-native standard it returns the partner bridge contract instead of a native checklist.

Use Cases#

• Partner integration planning: A certified TDL terminal vendor or OEM platform-telemetry provider can read the exact push endpoint, required fields, batch/latency limits, and, critically, the waveform-decode boundary, before writing a line of integration code or signing anything.
• Procurement and interoperability due diligence: A coalition partner evaluating Argus against other C2 platforms can compare native-vs-partner-vs-planned claims against a page that is regenerated from the same code path that enforces those claims at runtime, rather than a sales deck.
• Internal drift auditing: Anyone re-running export_mdoc_support_matrix.py and diffing the output against this page has a mechanical, low-effort check for whether the public claim and the shipped code have quietly diverged.

Integration#

Native ingest is exposed at POST /api/v1/mdoc/live/ingest (multi-standard) and the legacy POST /api/v1/mdoc/live/stanag4676 (STANAG 4676 only, currently the only push route with a provisioned auth scope). Source registration is POST /api/v1/mdoc/live/sources/register. Health is GET /api/v1/mdoc/live/health. All routes require an RS256 service JWT via the Authorization: Bearer header; static API-key headers are not accepted. Sensitive routes (source registration, the legacy STANAG 4676 push) additionally claim the token's jti for replay protection and honor an optional X-Service-Nonce header. Every accepted or rejected call is written to a structured audit log line naming the actor, tenant, action, and outcome.

Open Standards#

• STANAG 4676 (NATO Track Data): Argus implements the wire format of STANAG 4676 track messages (JSON and XML) with a native parser and a dedicated ingest pipeline.
• Cursor on Target (CoT) 2.0: Argus implements the wire format of CoT 2.0 XML events and pre-normalized CoT-shaped JSON contacts, the same shape ATAK/WinTAK/TAK clients use.
• ADS-B: Argus implements the wire format of common ADS-B transponder position reports (ICAO/callsign, position, altitude, speed, course, squawk).
• AIS (ITU-R M.1371): Argus implements the wire format of AIS maritime position reports (MMSI, position, speed over ground, course over ground).
• NFFI / STANAG 5527 (Friendly Force Information): Argus implements the wire format of NFFI friendly-force position reports, including MIL-STD-2525-style affiliation normalization.
• STANAG 4607 (GMTI): Argus implements the wire format of STANAG 4607 ground moving target indicator detections, accepting either JSON detections or a base64-encoded binary packet.
• STANAG 4774 / STANAG 4778 (Confidentiality Labels / Binding): The security label contract every operational entity carries (classification, caveats, releasability, binding hash) is modeled on STANAG 4774/4778, with a dedicated label-generation and binding module.
• Link-16 / TADIL-J (MIL-STD-6016 / STANAG 5516), Link-22, JREAP: catalogued as partner-only. Argus does not implement these waveforms itself; a certified partner gateway must decode them and push the result in a native standard's wire format, as described above.
• JC3IEDM / MIP, STANAG 4559 (NSILI), STANAG 4586 (UAV control): catalogued as planned. No wire format is implemented for these yet; STANAG 4586 has a tested message codec with no live transport attached to it.
• OAuth 2.0 and JWT Bearer Token (RS256): service-to-service authentication for every MDOC live route uses bearer JWTs verified against a per-route scope registry.