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 its 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. Without a canonical model in the middle, a set of fourteen formats would need ninety-one point-to-point translations and would carry fourteen private notions of what a contact is.

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 checks per fixture, including a never-drop lossless check. The same gate for your adapter as for ours.

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.
Lossless
No source value disappears without a declared treatment.
Roundtrip
Where egress applies, source to canonical model to source loses no value.
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

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

Nothing disappears silently

Every source leaf is assigned a declared treatment. Unsupported and dropped paths can exist, and their presence is evidence to inspect rather than a failure hidden behind a universal lossless claim.

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.

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