Tactical situational awarenessImplementation status: BidirectionalInput supportedOutput supported

TAK: the event contract is implemented, the server protocol is not

The Team Awareness Kit ecosystem covers client applications, servers, plugins and mission data packages. SynapseCommand implements one part of it: the Cursor-on-Target event translation. This page states that boundary precisely, because the difference between speaking a format and integrating with a product is where most interoperability claims go wrong.

This adapter is at TRL 8 as part of the complete, qualified SynapseCommand product. The supported edition, exchange direction and interface scope are listed below. What TRL 8 covers and how it differs from the engineering levels below. All current adapters are listed on the interoperability hub.

About the standard

What TAK is

TAK is a family of government-owned situational awareness applications and the server infrastructure that connects them. Clients render a map, share position, exchange chat and pass geospatial objects between users.

Events on that network are carried as Cursor-on-Target documents. That is the part that is a format, and a format is something an external system can implement independently.

Everything else in the ecosystem is a product: the server's transport and authentication, client plugin frameworks, data package formats and the certification processes attached to them. Implementing the event format grants none of that.

Operational relevance

Why this matters to a commander

TAK clients are widely fielded, which makes them the display most likely to already be in a user's hand.

A decision layer that can put a proposed scheme of manoeuvre onto that display, as a drawing the client already understands, avoids asking anyone to adopt new software at the edge.

It also avoids the more expensive alternative, which is a bespoke integration per client version.

What is implemented

The exact behaviour, not a capability claim

One adapter, published in the open integration layer, translates Cursor-on-Target events in both directions. The details of what it maps, which sentinels it translates and what it deliberately refuses are on the Cursor-on-Target page.

There is no TAK server protocol client. The published layer opens no sockets, performs no certificate enrolment, subscribes to no stream and builds no data packages.

There is no client plugin. No plugin is published, none is claimed, and no vendor or government certification has been sought or granted for one.

How CoT documents reach the SynapseCommand boundary in a given deployment is an integration design question, answered with the authority that owns the network, rather than something this contract decides.

  • 01
    Implemented
    Cursor-on-Target event translation, both directions, published and harness verified.
  • 02
    Not implemented
    TAK server protocol, transport, authentication and enrolment.
  • 03
    Not implemented
    Client plugins for any TAK client.
  • 04
    Not implemented
    Mission data package creation or consumption.
  • 05
    Not claimed
    Any endorsement, certification or partnership with a TAK client or server provider.
Direction of exchange

Which way the data actually moves

Into the canonical model

  1. CoT event
    Delivered to the boundary by a mechanism agreed per deployment.
  2. Canonical objects
    Entity and Event.

Out of the canonical model

  1. Canonical objects
    Entity or plan object.
  2. CoT event
    Atom or free-form drawing.
Workflows

Where this data is used

Proposal to the edge

An approved course of action is emitted as a drawing that a TAK client can render. The approval happens before emission, at the human decision gate.

Edge reporting into the picture

Contact atoms become canonical objects the Blue-Force Posture Agent reasons over, with position source qualified rather than assumed.

Verification before commitment

An integration authority can run the published harness against the shipped fixtures before any deployment work is agreed.

Implementation evidence

Every claim above has a file behind it

These paths are in the public repository, published under Apache 2.0. The adapter module for this page is tak.

Source and fixtures

  • Adapter source
    packages/cdm/synapse_cdm/adapters/tak.py

    The whole of what is implemented for this ecosystem.

  • Fixtures
    packages/cdm/synapse_cdm/fixtures/tak/

    Shipped event fixtures with golden canonical output.

Test evidence

  • Harness test
    tests/test_cdm_tak_adapter.py

    Replayed by the validation harness shipped in the same package. Its six fixture checks keep PASS, FAIL and SKIP distinct and assess loss only within the adapter's declared scope.

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.

Manifest-backed assurance, release 2.2.0 record

The cards below are the historical 2.2.0 manifest record, linked at that release's commit. The current release is 3.3.0; its manifests are at the v3.3.0 commit. VERIFIED is a scoped claim-status axis. Neither maturity nor claim status means external certification or integration with a named system.

  • tak
    CLI alias:
    tak
    Module:
    tak
    Direction:
    bidirectional
    Edition/profile:
    Unknown
    Level (3.3.0):
    L3, manifest-declared
    Claim (3.3.0):
    VERIFIED, not deployed-system acceptance
    Preservation basis:
    Value-presence heuristic
    Round trip:
    values-level tolerance on published fixtures
    2.2.0 record:
    L4 VERIFIED, historical release-specific record. Release 3.3.0 declares L3: L4 now requires declared field mappings and a loss ledger, not the value-presence check

    Cursor-on-Target contact atoms on ingest; atoms and drawing shapes on egress.

    Limit: Document translation only. No server connection, authentication, enrolment, subscription or drawing ingest is implemented.

What these conformance levels mean

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.

L3 means required provenance survives translation. L4 adds applicable roundtrip evidence under the adapter's declared tolerance. L5 would require every applicable public conformance gate to pass. L6 requires an independent real implementation or system and cannot be awarded from this repository's synthetic fixtures.

Status and limits

What is claimed, and what is not

Implementation status: 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.

Last reviewed against the published implementation on 2026-09-06.

Limitations

  • Speaking Cursor-on-Target is not the same as integrating with a TAK server. This page exists to keep the two apart.
  • No completed government deployment is claimed on the basis of this adapter.
  • No plugin, certification, endorsement or partnership exists with any TAK client or server provider.

Security boundary

  • No certificates, enrolment procedures, server addresses or credentials appear in the published layer or on this site.
  • The decision runtime is not published. Only the data contract is.
Questions

Frequently asked

Does SynapseCommand integrate with TAK Server?
SynapseCommand implements the Cursor-on-Target event format that the TAK ecosystem carries. It does not implement the server protocol, transport or authentication, and no completed deployment against a government TAK server is claimed.
Is there an ATAK or WinTAK plugin?
No. No plugin is published and none is claimed. Any plugin work would be a separate, scoped engagement agreed with the authority that owns the client baseline.
So what would an integration actually involve?
Agreeing how Cursor-on-Target documents reach the SynapseCommand boundary in your environment, and confirming that the conventions in the published mapping match the ones your network uses. Both can be checked against published code before any commitment.