SystematicLand / Joint / HeadquartersIntegration status: Available on request

SynapseCommand Integration with SitaWare Headquarters

SitaWare Headquarters is an established headquarters and joint C4ISR environment. Nothing on this page proposes changing it. The question this page answers is narrower and more useful: if a staff already builds its joint common operational picture, its plans and its orders in SitaWare Headquarters, what analytical work still happens on whiteboards, in spreadsheets and in the heads of experienced officers, and could a sovereign multi-agent decision layer carry part of that load without taking authority away from the commander.

About the system

What SitaWare Headquarters is

Systematic describes SitaWare Headquarters as an operationally proven C4ISR system providing situational awareness, collaborative planning and interoperability across domains. Its published feature set centres on building and disseminating a joint common operational picture, correlating and fusing tracks into land, maritime and air pictures, visualising function-specific pictures for intelligence, logistics, fires and anti-submarine warfare, and holding unit readiness and holdings information alongside the geospatial picture.

The planning side is equally explicit in Systematic's material: collaborative construction of plans and orders, distribution of those products across echelons, and the exchange of information within national, joint and coalition battle networks. Systematic states that the product receives information from other national and coalition systems and sensors using a wide range of interoperability standards, without enumerating them on the public product page.

Two further published characteristics matter for anything that intends to sit alongside it. First, SitaWare Headquarters is a commercial off-the-shelf product with a continuous update cycle, so an integration cannot depend on a frozen version. Second, Systematic states that it is built on an open architecture allowing customised extensions and integration with legacy and third-party systems. That is an architectural statement about the product, not a published interface specification, and this page treats it as exactly that.

SitaWare Headquarters is the headquarters member of a wider suite that includes SitaWare Frontline for mounted commanders and SitaWare Edge for dismounted commanders, with information moving up and down the chain of command inside that suite.

Where SynapseCommand fits

Your C2 stays. SynapseCommand adds the decision layer.

A headquarters running SitaWare Headquarters has a picture and a planning environment. What it does not have, in any C2 product, is an auditable machine contribution to the analytical steps between the picture and the decision: framing the problem, generating genuinely distinct options, arguing the adversary case against each one, testing sustainment feasibility, and recording why one option was preferred over another.

SynapseCommand is designed for that gap. Authorised operational data leaves the command environment through an exchange path agreed for the deployment, is normalised into a canonical data model that preserves source, timing, classification and confidence, and is then reasoned over by specialist agents. Course-of-action development, adversary reasoning, sustainment analysis and rehearsal all happen in the decision layer, not in the C2 product.

The output is not an instruction. It is a set of attributable options with the reasoning attached, presented to the commander or an authorised staff officer at a human decision gate. What was known, what was recommended, what was rejected and who decided is written to an append-only decision record that can be replayed afterwards.

Whether any resulting product returns to SitaWare Headquarters, and in what form, is a deployment decision that belongs to the customer and to Systematic's own interface arrangements. SynapseCommand does not assume a write path and does not require one to be useful: an analysis environment that reads authorised data and produces staff-usable products is a complete deliverable on its own.

  1. 01
    SitaWare Headquarters
    The command environment stays as it is. The staff continues to work in the tools it is trained and accredited on.
  2. 02
    Authorised operational data exchange
    An exchange path agreed for the specific deployment, using whatever interface the customer and the vendor make available. SynapseCommand does not presume a particular interface, because Systematic does not publish one.
  3. 03
    SynapseCommand integration layer
    Reference adapters and a published JSON Schema contract that can be inspected before any data moves. Where an interface is not already covered, an adapter is written against the same contract.
  4. 04
    Canonical data model
    Every record carries its source, timing, classification and confidence. Provenance is a property of the data, not a report generated afterwards.
  5. 05
    Specialist agents
    Course-of-action development, adversary reasoning, planning support, sustainment and fusion agents work the problem in parallel, each with a declared remit.
  6. 06
    Operational analysis
    Understanding of the situation as it stands, including what is not known and how confident the layer is in each element.
  7. 07
    Course-of-action development and comparison
    Distinct options assessed against stated constraints of time, force, terrain and sustainment, with the contribution of each agent attributable.
  8. 08
    Human decision gate
    No recommendation becomes a decision without a named human. The gate is a control, not a confirmation dialogue.
  9. 09
    Replay
    An append-only record of inputs, reasoning and authority, replayable for after-action review, assurance and coalition scrutiny.

Data flows top to bottom; authority stays with the human decision gate.

What it adds

Decision intelligence around the existing picture

Option development at staff tempo

Multiple distinct courses of action generated against the stated mission, constraints and force list, rather than one option refined because there was no time to build a second.

A separate adversary voice

A dedicated agent argues the adversary case against each friendly option, so the most likely and most dangerous enemy courses of action are examined explicitly rather than assumed by the same staff that wrote the plan.

Comparison that shows its working

Options are compared against declared criteria with the reasoning attributable per agent, so a J3 can interrogate a judgement instead of accepting a score.

Sustainment feasibility

Manoeuvre intent is tested against holdings, routes and lift, so a plan is assessed for whether it can be supported and not only for whether it is tactically attractive.

Rehearsal before commitment

A selected option can be rehearsed against adversary reactions and branch conditions before it is issued as an order, with the rehearsal itself recorded.

Decision replay

An append-only record of what was known, what was recommended and who authorised the decision, which is what an assurance authority or a coalition partner actually asks for after the event.

Operational workflows

How the decision cycle runs

Mission analysis support

Authorised picture, intelligence and readiness data is normalised and summarised into a stated understanding of the situation, including explicit gaps. The staff keeps ownership of the mission analysis product; the decision layer contributes the reconciliation work that usually consumes the first hours.

Course-of-action development and wargaming

Options are generated, argued against a red agent and compared against declared criteria. The result feeds the staff's own decision brief rather than replacing it, and the wargame is repeatable because its inputs are recorded.

Branch and sequel preparation

Once a course of action is selected, branches and sequels are developed against trigger conditions, so a headquarters is not building its next option under contact.

Coalition scrutiny

Where a plan will be executed with partners, provenance matters more than presentation. Each element of a recommendation can be traced to a source and an agent, which is a different proposition from an unexplained output arriving in a coalition headquarters.

After-action review

The decision record is replayed to show what was known at each gate, which supports lessons work and assurance rather than reconstructing events from memory and chat logs.

Deployment

How this sits in a real environment

Interface access is the first dependency

Systematic publishes an open architecture but not an interface specification. Any programme starts with the customer securing the relevant interface documentation and test environment, which is a commercial and contractual step before it is a technical one.

Read-first integration

The default integration pattern is one-way: SynapseCommand consumes authorised operational data and produces analytical products. A write path into the command environment is only ever built where a customer explicitly authorises it and the interface arrangements permit it.

Version drift

SitaWare Headquarters is a continuously updated commercial off-the-shelf product. An adapter is therefore treated as maintained software with a test suite against the published contract, not as a one-off delivery.

Deployment footprint

SynapseCommand is designed for deployment up to NATO SECRET and runs disconnected. Headquarters deployments typically sit on the same accredited enclave as the staff who use them, with no dependency on an external service.

Security and trust

Where the data goes, and where it does not

  • No operational data leaves the customer enclave. SynapseCommand runs inside the accredited environment and makes no external model calls during operational use.
  • Classification and releasability travel with the individual record in the canonical data model, so a coalition releasability caveat is enforced at record level rather than at network level.
  • Records are ML-DSA-signed in assured deployments, so the decision record can be shown to be unaltered when an assurance authority or a partner nation asks.
  • Read the wider assurance position on the trust page and the layer-by-layer design on the architecture page rather than taking a summary here as the whole story.
Status and evidence

What is claimed, and what is not

Integration status: Available on request

A dedicated connector can be developed for a customer, integration programme or deployment.

Systematic publishes that SitaWare Headquarters is built on an open architecture that supports customised extensions and integration with legacy and third-party systems, but the specific interfaces are not published openly. SynapseCommand therefore claims no adapter, no validated exchange and no completed integration with SitaWare Headquarters. A dedicated integration can be developed for an authorised customer or programme, subject to access to the relevant interfaces, documentation and technical environment.

Qualification

References to SitaWare Headquarters describe potential technical interoperability only as explicitly stated on this page. They do not imply sponsorship, certification, endorsement or partnership with Systematic, nor a completed deployment.

Interfaces and data standards

No shared interface or data standard between SynapseCommand and SitaWare Headquarters is claimed here. Systematic states publicly that SitaWare Headquarters receives information from other national and coalition systems and sensors using a wide range of interoperability standards, but does not enumerate them on its public product page, and a Systematic capability is not automatically a SynapseCommand capability. SynapseCommand's own supported standards and its published JSON Schema contract are documented in the open integration layer; which of them would be relevant to a given SitaWare Headquarters deployment can only be established with access to the actual interfaces in use.

The SynapseCommand data contract is published for inspection in the open integration layer.

Open interoperability layer

SynapseCommand connects to external systems through an openly published interoperability layer rather than proprietary point interfaces. The canonical data model, the JSON Schema and the format adapters are inspectable before any integration is committed to. That layer describes what SynapseCommand implements; it is not a statement about SitaWare Headquarters and implies no interface to it.

Public sources

Factual statements about the named system on this page are drawn from these public sources.

Questions

Frequently asked

Does SynapseCommand replace SitaWare Headquarters?
No. SitaWare Headquarters is the command-and-control and operational picture environment. SynapseCommand is a decision layer that works alongside it, adding analysis, course-of-action development, rehearsal and replay. Keep your C2 and add the decision layer.
What is the current status of SynapseCommand alongside SitaWare Headquarters?
Available on request. There is no SynapseCommand adapter for SitaWare Headquarters, no validated exchange and no completed deployment. An integration can be developed for an authorised customer or programme once the relevant interfaces and technical environment are accessible.
Is the integration certified or endorsed by Systematic?
No. There is no certification, endorsement, partnership or commercial relationship with Systematic, and nothing on this page should be read as implying one.
What would a SitaWare Headquarters integration actually require?
Three things: authorised access to the relevant SitaWare Headquarters interface and its documentation, a test environment representative of the deployment, and a customer decision on whether the exchange is read-only or bidirectional. The adapter itself is written against SynapseCommand's published data contract.
How would SynapseCommand support operational planning alongside SitaWare Headquarters?
By taking authorised picture, intelligence and readiness data and producing distinct options with adversary reasoning, sustainment testing and attributable comparison. The staff continues to build its plan and orders in SitaWare Headquarters; the decision layer contributes the analysis that supports the choice.
Does SynapseCommand write orders back into the command system?
Not by default. The standard pattern is read-only consumption of authorised data. Any write path is a deliberate deployment decision, requires customer authorisation, and still passes a human decision gate first.

Discuss an integration

Briefings are available under NDA. SynapseCommand® integration work begins from the published data contract, so the interface can be reviewed before any commitment.

Third-party systems and trademarks

Product names, trademarks and registered trademarks referenced on this site are the property of their respective owners. References to third-party systems describe implemented, planned or potential technical interoperability as stated on each page and do not imply sponsorship, certification, endorsement or partnership unless expressly stated.

Category: Land C2 and battle management. Last reviewed 2026-09-06.