SynapseCommand
Interoperability

Inspect the contract before you integrate.

ASTERIX, STANAG 4607, STANAG 4676, STANAG 4609, STANAG 4586, Cursor-on-Target, ADS-B, AIS and published data sources, each with its direction of exchange stated and the SynapseCommand-authored implementation published under Apache-2.0.

Inspect the open integration layer Request an integration
Inspect the contract before you integrate

Two layers, and only one of them is secret

SynapseCommand® is built around a canonical data model. Every external format is translated into that model by a thin adapter, and every consumer reads the model rather than the format. The current release, synapse-cdm 3.3.0 of 8 October 2026, contains 21 adapters: 14 bidirectional and 7 ingest only. Family and concept pages do not add to that count. Dedicated pages cover the 14 adapters already documented here; 7 more are described in the release catalogue below without a page of their own.

Earlier release 2.2.0 contained 14 adapters, 11 bidirectional and 3 ingest only. That count stays attached to 2.2.0.

That contract layer is published under Apache 2.0: the models, the generated JSON Schema, the adapters, their fixtures and the validation harness that verifies them. It is public because that is what a contract is for. An integration authority can read the mapping, run the harness and judge the claim before agreeing to anything.

The decision runtime is a different thing entirely. Doctrinal content, agent behaviour, model weights and deployment configuration are not published, and no page on this site describes their internals. Publishing the contract is not publishing the product.

This separation also addresses a central problem in Combined Joint All-Domain Command and Control: moving operational information across system and mission-partner boundaries without losing its meaning, provenance or security context in complex Multi-Domain Operations.

Canonical data model

Entity, Event, Track and plan objects, with provenance on every one.

Generated JSON Schema

Six schemas written from the models, so a non-Python consumer can validate without the package.

Validation harness

Six fixture checks cover translation, schema, provenance, loss accounting, round trip and golden output. PASS, FAIL and SKIP remain distinct.

Conceptual architecture

Shape, meaning and decision logic remain distinct

This is a conceptual separation of responsibilities. A deployment does not need to exercise every adapter or semantic feature for every record.

  1. External layer

    External systems, standards and feeds

    Source formats remain authoritative for their own wire semantics.

  2. Public layer

    Public adapters

    Translate source records into the public canonical layer and, where supported, back out.

  3. Public layer

    Canonical Data Model (CDM)

    Defines the normalised record shape.

  4. Public layer

    SC-OES + Operational Ontology

    Define assertion semantics and governed operational meaning.

  5. Private layer

    SynapseCommand decision runtime

    Applies proprietary reasoning, fusion, scoring and decision support.

The public repository exposes the integration contract and semantic vocabulary. It does not publish the SynapseCommand reasoning, inference, correlation, fusion, scoring or course-of-action runtime.

Read the public semantic layers in detail: the SC-OES architecture and event semantics and the Operational Ontology.

Interoperability assurance

Three evidence layers, kept distinct

Adapter engineering evidence is separate from SC-OES semantic conformance. The public release records what was tested, what did not apply and what remains limited. It is reproducible engineering evidence, not certification by NATO, a standards body or a vendor.

Layer A

Fixture validation harness

The same six fixture-level checks run for shipped and third-party adapters. This is the foundation of the wider suite, not the full suite itself.

Translate
The adapter runs and returns canonical objects.
Schema
Every output validates against the exported JSON Schema.
Provenance
Required source, adapter, identity and time provenance is present.
Loss accounting
Checks source-value preservation, declared transformations, residual fields and explicitly reported loss within the adapter's supported scope.
Roundtrip
Where egress applies, compares the return path under the adapter's declared byte-level or value-level tolerance.
Golden
Output matches the recorded expectation under a frozen clock.

Layer B

Synapse Conformance Suite

Fifteen adapter assurance dimensions extend the six harness checks. A check that does not apply reports SKIP with the declaration that made it inapplicable. SKIP is never converted to PASS.

  1. Translate
  2. Schema
  3. Provenance
  4. Lossless
  5. Roundtrip
  6. Golden
  7. Deterministic
  8. Malformed input
  9. Unknown preservation
  10. Temporal
  11. Identity
  12. Version
  13. Streaming
  14. Parser robustness
  15. Resource limits

Semantic framework

SC-OES dimensions A to E

Semantic conformance is reported separately. It is not converted into a success percentage or inferred from fixture-harness results.

  1. ACDM Conformance
  2. BSC-OES Core Syntax Conformance
  3. CSC-OES Semantic Type Conformance
  4. DSC-OES Profile Conformance
  5. EOntology Conformance

Layer C

Machine-readable evidence

A deterministic evidence record binds the run to the implementation and the files it measured. A third party can regenerate the record and compare it rather than rely on a badge.

  • adapter manifest
  • source commit
  • package, CDM, SC-OES, Adapter API and manifest versions
  • conformance and loss reports
  • fixture hashes and fixture provenance
  • artifact hashes when release artifacts exist
  • test command, result totals, Python version and platform
  • generation time

Preservation is adapter-specific

Preservation checks are adapter-specific. Eight adapters use declared path ledgers; thirteen use a value-presence heuristic. Results apply to the published fixtures and supported subset; they do not establish universal field-level preservation or validated external-system compatibility.

PRESERVED
The source value remains represented directly.
NORMALIZED
A declared reversible or meaning-preserving normalisation was applied.
DERIVED
The output was calculated from source values by a declared rule.
RESIDUAL
The value remains inspectable in a residual or attributes field.
UNSUPPORTED
A manifest limitation explicitly declares that source path unsupported.
DROPPED
The value is not represented and is reported as dropped.
How to read these pages

Direction is stated, never implied

Support is not one thing. A format that can be read is not a format that can be written, and neither is the same as a format that has been proven against a partner system. Every page in this section carries one of the following, and nothing on this site upgrades a claim without published code behind it.

Bidirectional

The published adapter implements both translation directions: the format into the canonical data model, and the canonical data model back out to the format. Both directions are replayed by the validation harness against shipped fixtures.

Input supported

The published adapter translates the format into the canonical data model. No egress path is implemented, and none is claimed.

Output supported

The published adapter emits the format from the canonical data model. No ingest path is implemented, and none is claimed.

Schema available

A published, generated JSON Schema describes the exchange, but no adapter translates the format itself.

Documented only

The interface is described in product documentation. No implementation is published for inspection, so nothing is claimed about it here.

Planned

On the integration roadmap. Not implemented today.

Air surveillance

EUROCONTROL ASTERIX categories, translated per category against their own pinned specifications.

ISR standards

NATO standardisation agreements for ground moving target indication and intelligence tracking.

Tactical situational awareness

The event format the tactical edge already carries, and an explicit statement of where that stops.

Cooperative surveillance

Self-reported broadcasts from aircraft and vessels, with every unavailable value handled as an absence.

Operational data sources

Feeds and vendor interfaces rather than standards, each translated from an already fetched payload with no client, credentials or state inside the adapter.

Release 3.3.0 catalogue

Seven adapters without a dedicated page

Each entry states the supported version and subset as declared in the release support matrix. Nothing outside that subset is claimed. Conformance levels (L3, L4) are scoped adapter evidence declared in each release manifest for the published fixtures and supported subset. They are not product or agent Technology Readiness Levels, and neither is certification or validated integration with a named system.

GeoJSON

Version:
RFC 7946 (August 2016)
Direction:
Bidirectional
Level:
L4
Claim status:
VERIFIED, scoped, not certification
Preservation basis:
Declared path ledger

Supported subset: Feature and FeatureCollection, six of the RFC's seven geometry types. Ingest yields one annotation plan object per feature (or a position-less overlay entity for a null geometry); egress writes a Feature or FeatureCollection under the generic or synapsecommand-exchange/1 profile.

Practical limit: GeometryCollection, bare top-level geometries, empty coordinates and any crs member are refused. bbox is kept verbatim, not projected. Egress refuses Event and Track objects. Not every property maps to canonical meaning.

Support matrixManifestSource

GeoPackage

Version:
1.4.0 (OGC 12-128r19)
Direction:
Ingest only
Level:
L3
Claim status:
VERIFIED, scoped, not certification
Preservation basis:
Declared path ledger

Supported subset: Vector feature layers of a GeoPackage 1.4.0 container in WGS 84 (EPSG:4326, OGC:CRS84 or EPSG:4979): one annotation plan object per feature row.

Practical limit: Other GeoPackage versions, other CRSs, M ordinates, GeometryCollection, non-linear and extended geometry types are refused. Raster tiles, gridded coverages, attribute-only tables and views are inventoried, never read. WAL-mode files are refused. No database functions or extensions.

Support matrixManifestSource

C2SIM

Version:
SISO-STD-019-2020 v1.0 (Core + SMX) with SISO-STD-020-2020 (LOX); XML schema C2SIMArtifacts v1.0.1
Direction:
Bidirectional
Level:
L4
Claim status:
VERIFIED, scoped, not certification
Preservation basis:
Declared path ledger

Supported subset: XML documents: initialisation (force sides, units, platforms, Route graphics), position and observation reports, task status, and ManeuverWarfareTask orders with MoveToLocation and HoldInPlace only.

Practical limit: A document adapter only: it does not open a simulator or server connection and does not establish an end-to-end exercise. Acknowledgement, plan, request and system bodies are refused; other task actions are refused; unpinned elements are preserved on ingest but not written back.

Support matrixManifestSource

AIXM 5.1.1

Version:
5.1.1 (XML Schema, April 2016; GML 3.2.1; Temporality 1.1)
Direction:
Ingest only
Level:
L3
Claim status:
VERIFIED, scoped, not certification
Preservation basis:
Declared path ledger

Supported subset: Airspace, AirportHeliport, Runway, RunwayDirection, Navaid and VerticalStructure time slices. Digital NOTAM only for AIXM 5.1.1 + Event Schema 2.0.m, scenarios RWY.CLS, ATSA.ACT, SAA.ACT and NAV.UNS (draft specification 2.0).

Practical limit: Other feature classes carry identity only. Arcs, circles, composite curves, CRSs other than EPSG:4326/CRS84 and a third dimension refuse by default. References resolved one hop, never over a network. Not a complete aviation implementation.

Support matrixManifestSource

AIXM 5.2

Version:
5.2 (XML Schema release 5.2.0, 17 January 2025; GML 3.2.1; Temporality 1.1)
Direction:
Ingest only
Level:
L3
Claim status:
VERIFIED, scoped, not certification
Preservation basis:
Declared path ledger

Supported subset: The same six feature families with the AIXM 5.2 property groups pinned.

Practical limit: No Digital NOTAM: no Event schema targets AIXM 5.2. Same geometry refusals as 5.1.1; composed airspace volumes produce no plan object; vertical limits project only where unit and reference exist. Not a complete aviation implementation.

Support matrixManifestSource

DIS 7

Version:
Protocol version 7 / IEEE 1278.1-2012, Entity State subset
Direction:
Bidirectional (egress is byte replay of an unchanged ingested Entity)
Level:
L4
Claim status:
VERIFIED, scoped, not certification
Preservation basis:
Declared path ledger

Supported subset: Entity State PDU only (version 7, PDU type 1, protocol family 1). Ingest yields one Entity. Egress replays the original bytes for an unchanged ingested Entity.

Practical limit: Bidirectional only in that replay sense: it cannot synthesize arbitrary new or edited PDUs. No other PDU types, no network transport or capture files, no validated simulator integration, no IEEE certification.

Support matrixManifestSource

TacticalAPI

Version:
rheinmetall.tactical_api.v0 at upstream commit 58661c9 (2026-09-01); no tag or release exists
Direction:
Ingest only
Level:
L3
Claim status:
VERIFIED, scoped, not certification
Preservation basis:
Declared path ledger

Supported subset: Blue-force read side only: GetBlueForcesResponse and SubscribeBlueForceEventsResponse, as protobuf Any bytes or the parsed twin, producing Entity and Event objects.

Practical limit: No egress. No gRPC transport, session, authentication, client or server; no live Battlesuite integration; no vendor endorsement or partnership. A pinned upstream data definition is not a vendor integration certification.

Support matrixManifestSource

All 21 adapters in release 3.3.0

Preservation checks are adapter-specific. Eight adapters use declared path ledgers; thirteen use a value-presence heuristic. Results apply to the published fixtures and supported subset; they do not establish universal field-level preservation or validated external-system compatibility. Round trips are fixture round trips, not operational compatibility proof.

Direction, level, claim status and preservation basis per adapter
AdapterDirectionLevelClaimPreservation basis
adsbBidirectionalL3VERIFIEDValue-presence heuristic
aisBidirectionalL3VERIFIEDValue-presence heuristic
aixm511Ingest onlyL3VERIFIEDDeclared path ledger
aixm52Ingest onlyL3VERIFIEDDeclared path ledger
c2simBidirectionalL4VERIFIEDDeclared path ledger
cat021BidirectionalL3VERIFIEDValue-presence heuristic
cat023BidirectionalL3VERIFIEDValue-presence heuristic
cat034BidirectionalL3VERIFIEDValue-presence heuristic
cat048BidirectionalL3VERIFIEDValue-presence heuristic
cat062BidirectionalL3VERIFIEDValue-presence heuristic
dis7BidirectionalL4VERIFIEDDeclared path ledger
geojsonBidirectionalL4VERIFIEDDeclared path ledger
geopackageIngest onlyL3VERIFIEDDeclared path ledger
gmtiBidirectionalL3VERIFIEDValue-presence heuristic
legionIngest onlyL3VERIFIEDValue-presence heuristic
pntmapIngest onlyL3VERIFIEDDeclared path ledger
stanag4586Ingest onlyL3VERIFIEDValue-presence heuristic
stanag4609BidirectionalL3VERIFIEDValue-presence heuristic
stanag4676BidirectionalL3PROVISIONALValue-presence heuristic
tacticalapiIngest onlyL3VERIFIEDDeclared path ledger
takBidirectionalL3VERIFIEDValue-presence heuristic

PROVISIONAL: stanag4676 reads and writes a provisional internal XML profile with element names bound in the public repository, not a verified normative binding. The verified binding needs the authorised XSD and fails BLOCKED without it.

Current product coverage: 30 adapters at TRL 8

Every adapter in the current SynapseCommand product is at TRL 8 as part of the complete, qualified product (what TRL 8 covers). Public release 3.6.0 (19 October 2026) lists 30 distinct adapters: 15 bidirectional and 15 ingest only. The detailed evidence above stays pinned to release 3.3.0 and its 21 adapters. The 9 adapters below were added in later releases; their conformance level and evidence are not restated here. TRL 8 does not change exchange direction, binding status or supported subset.

Adapters added after release 3.3.0
AdapterFormat and editionDirectionBindingFirst releaseReadiness
link16_gatewaySC Link16 Gateway; 1.0.0BidirectionalProvisional internal profile3.4.0TRL 8
airnow_hourlyEPA AirNow hourly observation files; AirNow hourly data file fact sheetsIngest onlyStandard encoding3.5.0TRL 8
coops_csvNOAA CO-OPS data API response; api.tidesandcurrents.noaa.gov/api/prodIngest onlyStandard encoding3.5.0TRL 8
ndbc_stdmetNDBC standard meteorological data; NDBC Web Data Guide 2.0Ingest onlyStandard encoding3.5.0TRL 8
nexrad2NEXRAD Level II (Archive II); ICD 2620010J and 2620002Y, Build 23.0Ingest onlyStandard encoding3.5.0TRL 8
readsb_tracereadsb trace JSON; readsb v3.16.17Ingest onlyStandard encoding3.5.0TRL 8
cogGeoTIFF / Cloud Optimized GeoTIFF; OGC GeoTIFF 1.1, OGC COG 1.0Ingest onlyStandard encoding3.6.0TRL 8
grib2GRIB2 (WMO FM 92 edition 2); NCEP WMO GRIB2 documentation 37.0.0Ingest onlyStandard encoding3.6.0TRL 8
iem_n0qIEM NEXRAD N0Q composite PNG; W3C PNG Third Edition; IEM composite_n0q gridIngest onlyStandard encoding3.6.0TRL 8

Source: documentation support matrix and release 3.6.0 manifests. Compatibility is not vendor endorsement.

Not claimed

Interfaces without published implementation evidence

Some interfaces appear in product documentation but have no implementation in the open integration layer. They get no page here, because a page with nothing to inspect would be an assertion dressed as evidence.

  • REST

    SynapseCommand deployments expose versioned service interfaces, but no REST implementation or interface specification is published in the open integration layer, so nothing about its coverage is claimed here. The published JSON Schema describes the canonical objects that any such interface would carry.

  • gRPC

    No service definition is published in the open integration layer. Until one is, no claim is made on this site about gRPC message coverage, streaming behaviour or conformance.

Related

Where to go next

On this site

Inspect it yourself

Talk to us

If a format you need is not listed, the adapter SDK and the harness are the same ones used for the shipped adapters. Tell us what the exchange has to carry.

Request an integration