By Decent Cybersecurity, publisher of SynapseCommand®
Inside SynapseCommand: How Sovereign AI Supports Military Command
Follow the SynapseCommand workflow from operational information to specialist agent analysis, human review and a traceable decision record.

SynapseCommand® is Decent Cybersecurity’s sovereign multi-agent AI platform for military decision support. It connects operational information with specialist agents and the CommanderNL™ natural-language interface to help staff assess situations, compare options and prepare decisions. The SynapseCommand platform operates on customer-controlled infrastructure and preserves a traceable record of its recommendations, with consequential decisions remaining under human authority.
Its value becomes clearest when following a question through the system: which information was available, which functions used it, what assumptions shaped the answer and who had authority to act.
At a glance
| Aspect | SynapseCommand’s role |
|---|---|
| Purpose | AI-assisted analysis, planning and decision support alongside existing command environments |
| Operator interface | CommanderNL, connecting operational questions to governed agent workflows |
| Specialist capability | Fourteen agents across the product, including the White Force Agent for training only |
| Deployment | Sovereign cloud, on-premises and configured air-gapped environments |
| Integration | Published data adapters and separately documented, system-specific compatibility |
| Accountability | Traceable outputs, human approval gates and an append-only decision record |
The sections below explain how these elements work together and what an organisation should examine when evaluating them.
From an operational picture to a decision
A shared picture provides the starting point for staff work. A decision also requires context: the age and origin of the information, the constraints that apply, the alternatives available and the consequences of acting on an uncertain assumption.
SynapseCommand organises this work across its seven-layer architecture, from infrastructure and information exchange through orchestration, assurance, specialist agents and the operator interface. The architecture brings these functions into one deployable stack, with defined boundaries between them.
The workflow can be understood in five stages:
- Connect authorised information. Bring relevant operational data into a common representation, retaining the context needed to interpret it.
- Task the appropriate capabilities. Route the question to the agents and tools whose defined functions match the request.
- Develop and examine options. Combine relevant assessments, surface assumptions and compare possible courses of action.
- Apply controls and preserve the record. Evaluate the output, enforce applicable policy and record the recommendation before delivery.
- Support human review. Present the result so an authorised operator can inspect, challenge or approve it within the configured workflow.
This is a functional overview, rather than a promise that every question follows an identical chain. The relevant agents, information and approval requirements depend on the task and deployment.
What the operating environment shows
The demonstration screenshots make the relationship between analysis and oversight visible. A geographic picture occupies the centre, while the surrounding panels show tracks, selected contacts, CommanderNL, agent status, source status and the decision record. These are illustrative product views, not evidence of an operational deployment.

A contact’s position is only one part of its meaning. The selected-contact panel exposes attributes such as source and observation time. The source and agent panels make different kinds of status visible, including delayed feeds and unavailable services. This gives staff a basis for asking whether an assessment rests on sufficiently current information.

The density and trails views offer further perspectives on the same displayed environment. Density emphasises spatial concentration. Trails make movement history visible, while adjacent evidence panels provide context for examining the underlying record.


For an evaluator, these views suggest a useful test: introduce a known change to an authorised input, then inspect how it appears in the picture, the supporting assessment and the retained evidence. Visual coherence matters most when it reflects a coherent information path.
Specialist agents working as one system
The agent suite divides work into defined staff functions. Its fourteen agents cover red-force behaviour, blue-force posture, ISR fusion, scenario synthesis, course-of-action analysis, targeting and engagement support, operational planning, lessons learned, logistics, logic and planning, strategy and doctrine, air tasking, weather and White Force exercise control. The White Force Agent belongs to the training variant.
This division gives each capability a specific responsibility. A logistics assessment and a weather assessment answer different questions, even when both contribute to the same planning problem. Their outputs can be brought together without losing sight of those separate roles.
For example, the COA Analysis Engine produces ranked courses of action, risk distributions and sensitivity analysis. The ranking supports comparison; the commander retains the choice. Sensitivity analysis is particularly useful because it exposes how a preferred option depends on assumptions that may change.
The Operational Planning Agent supports mission analysis and the development of planning products. Its outputs remain drafts for staff and commanders to review, amend and sign. That distinction establishes a clear handover between machine assistance and command responsibility.
The practical benefit of an agent approach is therefore task-specific assistance within a common governance framework. An evaluation should examine both the quality of each specialist output and the integrity of the handovers between functions.
CommanderNL: ask a question, inspect the evidence
CommanderNL provides the natural-language interface to this workflow. It translates an operator’s intent into coordinated agent activity and presents traceable options. Its controls include classification-aware filtering, role-based permissions and release policies.
An illustrative evaluation question might be: “Which readiness assumptions have changed since the last staff review, and which sources support those changes?” This is an example of how to frame an assessment, not a quotation from a recorded product test.
A useful response should make the basis of the answer inspectable. The reviewer should be able to distinguish a retrieved fact from a calculation, a forecast or an interpretation, and identify information that is missing or stale.
CommanderNL’s documented traceability covers source information, model and tool versions, policy gates, confidence outputs and operator actions. Its approval controls are enforced within the system. Language interaction does not grant the model independent authority to carry out lethal or irreversible actions.
That combination makes the interface useful beyond asking a first question. Staff can use the resulting evidence to challenge an assumption, request clarification and decide whether further information is needed before proceeding.
Sovereignty across data, models and deployment
Sovereign military AI requires clear answers about who controls the information, the models and the environment in which they run. SynapseCommand’s deployment approach supports sovereign cloud, on-premises and air-gapped configurations, with customer-specific security and acceptance requirements assessed for the deployment.
The sovereignty and deployment FAQ explains the information boundary in more detail. In the reference federated model, source records, model weights, prompts and local inference traces remain at the originating node. Policy-authorised queries, derived outputs and required provenance metadata may cross between nodes. Embeddings require explicit approval under the deployment’s release policy.
That distinction makes coalition collaboration more precise. An organisation can define what information may be exchanged while retaining control of its local records and inference environment.
For a procurement team, sovereignty should become a set of verifiable deployment requirements: identify every external dependency, document update and support paths, inspect release controls and test operation under the intended connectivity conditions. The relevant question is whether the delivered configuration preserves the required boundary throughout normal use, maintenance and recovery.
Connecting to existing command systems
SynapseCommand is positioned as a decision-support layer alongside existing command, mission and operational-data environments. Integration therefore needs to be evaluated at two levels: the data interface and the named system with which it exchanges information.
The interoperability register documents supported standards and formats, including EUROCONTROL ASTERIX, relevant NATO STANAG interfaces, ADS-B, AIS and Cursor-on-Target. Direction of exchange and implementation scope vary by adapter. The public integration foundation provides inspectable models, schemas and testing material, while the decision runtime remains proprietary.
An adapter implementation establishes a specific data-exchange capability. Connecting it to a particular operational environment also requires agreement on configuration, semantics, permissions and acceptance criteria. Those requirements should be tested with representative data and the intended receiving system.
The company’s NATO Maven Smart System integration page currently identifies the status as Integrated. This is the published SynapseCommand integration status. NATO retains control over its interfaces and environments; the status should not be expanded into a claim of endorsement or an unspecified operational deployment.
For prospective users, the next step is a technical discussion about the authorised interface, the information to be exchanged and the evidence needed for acceptance in their environment.
Human authority and a verifiable decision record
An AI-supported recommendation needs both a sound basis and a record that can be examined afterwards. SynapseCommand addresses these as related but distinct engineering concerns.
Its published decision-quality evidence separates deterministic calculations, policy evaluation and source-record retrieval from language-model generation. Forecasts are identified as forecasts. The evaluation approach combines offline tool assertions, model-bearing verification cases and structural checks. Published results are dated and tied to the versions and agent roster tested.
This distinction helps evaluators ask better questions. A fluent explanation does not establish numerical correctness. A successful tool calculation does not, by itself, establish that the right information was selected or that the resulting recommendation is appropriate. Each part needs relevant evidence.
The platform’s decision record is append-only and hash-chained. In assured deployments, records carry ML-DSA signatures; records generated without an active signing key are explicitly marked UNVERIFIED. The record supports later examination of the inputs, configuration and actions associated with a recommendation.
NIST’s FIPS 204 standard specifies ML-DSA digital signatures. Their role is to help authenticate signed data and detect alteration. That is separate from the key-establishment function specified for ML-KEM in FIPS 203. These standards explain different cryptographic functions; citing them does not establish certification of an entire product or deployment.
Cryptographic integrity preserves evidence for scrutiny. The operational judgement still depends on the quality of the source information, the suitability of the analytical method and the authorised human decision.
NATO DIANA and product readiness
Decent Cybersecurity was selected for NATO DIANA’s 2026 Decision Superiority Challenge. The official DIANA announcement names the company among ten selected innovators and describes the programme’s focus on AI-enabled capabilities for Allied warfighters, including work involving the NATO Maven Smart System environment.
The selection provides a concrete programme context for SynapseCommand’s development and demonstration activities. Its meaning should remain tied to the announced challenge and the work carried out within it.
SynapseCommand’s current trust and assurance statement identifies the complete product as Technology Readiness Level 8, covering its features, agents and adapters. TRL 8 denotes a complete and qualified system. Customer-specific integration, deployment acceptance and security accreditation remain separate assessments.
That distinction is useful for acquisition planning. Product maturity can support a technical evaluation, while the organisation still establishes whether the proposed configuration meets its own mission, information-security and support requirements.
What a meaningful technical evaluation should establish
A strong evaluation starts with a bounded staff problem, representative information and agreed acceptance criteria. The following questions can turn a demonstration into a structured assessment.
Evaluation questions
| Evaluation area | Question to test | Evidence to request |
|---|---|---|
| Information quality | What happens when a source is delayed, absent or contradictory? | Input timestamps, provenance, visible caveats and output changes |
| Analytical behaviour | Which assumptions change the recommendation? | Defined criteria, sensitivity results and repeatable cases |
| Human authority | Which actions require approval, and who can approve them? | Role configuration, enforced gates and recorded operator actions |
| Sovereignty | Which data and services cross the customer boundary? | Deployment diagram, dependency inventory and release policies |
| Integration | Does the intended exchange work with the actual system configuration? | Interface scope, representative fixtures and acceptance results |
| Accountability | Can reviewers examine what supported an earlier recommendation? | Retained inputs, component versions, decision records and signature status |
These are proposed evaluation criteria, not additional claims about measured performance. Their purpose is to connect product capabilities to evidence that a customer can inspect.
An effective first engagement should also define the responsible users, the operational or training context, the required integrations and the conditions under which the system will operate. This gives both the customer and the engineering team a concrete basis for deciding what a successful evaluation looks like.
Explore SynapseCommand
SynapseCommand brings specialist analysis, natural-language interaction, sovereign deployment and decision traceability into a common platform. For military organisations, the opportunity is to apply AI assistance within a workflow whose information, permissions and decisions can be examined.
Request a technical briefing to discuss your staff workflow, integration requirements and deployment environment, and to define a focused SynapseCommand evaluation.