Start here
Two things working together: a brain and a practice-ground
The project, in plain words
Think of the project as building two things at once. A brain — AI that reads the battlefield picture, proposes plans, spots threats and helps commanders decide faster. And a practice-ground — an advanced military simulation where those plans, that AI, and real soldiers can be tested safely, again and again.
The brain must plug into the army's real command systems, work alongside NATO allies' systems, and — crucially — be trustworthy: hard to fool, hard to poison, hard to hack, with a human always in control of important decisions.
vExpertAI's job: we are not the simulation-engine builder. We build the AI brain's working parts, the trust-and-security layer around them, and the ability to run everything on a sealed, in-country system. The four tabs above walk through each official use case — what it asks for in plain words, and exactly where we add value.
The four cases at a glance
| Use case | Our role | The rare thing we bring |
|---|---|---|
| 1 · Battle dress rehearsal | Support | The translator between real command systems and simulation + the black-box recorder |
| 2 · Human + AI teams | Lead | An AI teammate that fails on command — and the metrics of the human response |
| 3 · AI battle plans | Build the system | Explained, challengeable plans turned into approved formal orders in minutes |
| 4 · Synthetic sea data | Co-lead | The data factory + the anti-poisoning security the call explicitly requires |
| All · AI security | Signature | Genuine red-team practice + sovereign, air-gapped deployment |
Use case 1
The full dress rehearsal of a battle
Live view · what our translator layer does
⚠ SPOOFED RADAR TRACK INJECTED → FLAGGED: low confidence, single source
What you're watching: orders and map data flowing both ways through our translator — then a fake radar track is injected as a stress test, gets flagged, and everything lands in the black-box recorder.
The official ask, in plain words
Before an army trusts a whole chain of systems — command software, AI, simulators, people, across land, sea, air, cyber and space — someone must measure how well the entire chain performs together, not each piece alone.
Three ingredients must run at once: the army's real command software (not a mock-up), an AI-driven simulated battle, and real officers making real decisions. Three stages: prepare the scenario, execute the battle, analyse what happened.
Stage 1 · Preparation
Make the real and the simulated speak one language
The problem: the real command system, the simulator and the AI each speak a different data "language." Until they're connected, there is no end-to-end anything — just three boxes that can't talk.
What we bring — the translator layer. The real C2 exports its operational picture; we translate it into what the simulator understands, and simulation events flow back onto real command screens. We commit to dated, checkable NATO standards: NETN-FOM v4.0, C2SIM, HLA / STANAG 4603.
Picture this
Today, a joint exercise means engineers spending weeks hand-copying unit positions, orders and maps from the command system into the simulator — and the two drift apart the moment the exercise starts. With the translator layer, an officer loads tomorrow's real operational picture into the rehearsal in minutes, and both sides stay in sync throughout.
Stage 2 · Execution
Run the AI, keep the human in charge, stress the system
- The orchestrator. Enemy behaviour, picture-fusion and decision-support agents must coordinate in real time. Proof this isn't slideware: our 5-agent system resolved a live network incident in 8 seconds, on stage at Cisco DevNet.
- The human-control gates. Every AI suggestion passes an approval gate — the officer decides, the AI proposes. This is how all five of our production agents already ship, audited, at enterprise customers.
- The stress-test injection. Mid-rehearsal we deliberately spoof a radar track or degrade the network — and measure whether AI and officers notice and cope.
Picture this
Forty minutes in, our harness silently injects a fake enemy track into the sensor feed. The AI assistant flags it: "low confidence — single source, no corroboration." The duty officer checks, discards it — and the exercise report later shows exactly how long detection took. That is a system-of-systems measurement, not just "did the plan win."
Stage 3 · Analysis
Prove what happened, decision by decision
The problem: after the rehearsal, the staff needs more than a score. They need: which decision, by whom, based on what information, caused which outcome?
What we bring — the black-box recorder and replay. Every trigger, every piece of evidence the AI saw, every recommendation, every human approval, every timing — logged automatically. Any sequence can be replayed: rewind to minute 40, change one input, re-run. The call explicitly requires replayable data streams — a requirement most bidders will treat as an afterthought. For us it is our regulator-grade audit pipeline, running in production today.
Who owns what
| Piece | Owner | Why |
|---|---|---|
| Battle engine — physics, terrain, units | M&S partner | We don't own a simulation engine — by design |
| Connect real C2 ↔ sim ↔ AI | vExpertAI | Translation-layer engineering is our production pattern |
| AI orchestration + human-control gates | vExpertAI | DevNet-proven orchestration; human-in-the-loop is shipped behaviour |
| Stress-testing under spoofing / jamming | vExpertAI | Our security heritage, applied to the exercise |
| Black-box recording, replay, analysis | vExpertAI | Our audit pipeline, running in production today |
Use case 2
Teaching people and AI to work as a team
Live view · the failure drill
labelling boat contacts
poisoned model: hostile boat reads "friendly"
cross-checks, overrides
detected in 12s · 0 errors after handover
DRILL RUNNING…
What you're watching: a training drill on loop. The AI teammate is deliberately sabotaged (it turns red), the operator catches it and takes back control, and the team gets a measured score.
The official ask, in plain words
Soldiers and AI assistants must learn to work as one team — including knowing when the machine should do more (routine work, information overload) and when the human must take back control (ambiguity, high stakes, machine failure).
The remarkable part: trainees must be deliberately exposed to AI failures and adversarial attacks during training — so they learn, by experience, what a wrong or manipulated AI looks like. And team performance must be measured with practical metrics, not impressions.
Component 1 · The failure playbook
An AI teammate that fails on command
The problem: you cannot train someone to catch a failing AI using an AI that never fails. Someone must make the machine fail — realistically, on schedule, without the trainee knowing.
What we bring: a library of realistic failure modes — a sudden confidence collapse, a slow accuracy drift, an adversarial "sticker" attack, a poisoned recommendation — that an instructor injects like difficulty levels during a live exercise. Built from our security-testing heritage: we already break AI systems on purpose for a living.
Picture this
An operator tracks boats with an AI that labels each one "friendly" or "threat." Secretly, we poison the AI so it starts calling a hostile boat "friendly." Does the operator notice? How long until they catch it and override? We measure exactly that — and the operator leaves having felt what a fooled AI looks like, so they will spot it for real.
Component 2 · The automation dial
Who is in charge, moment by moment
The problem: "adaptive levels of automation" means control must shift smoothly between human and machine as the situation changes — and both sides must always know who holds it.
What we bring: the controller that moves the dial, and the trust-aware interface that shows the operator how confident (or unsure) the AI is right now. Every shift of authority is logged.
Picture this
Contacts pile up and the operator is drowning. The controller hands the routine tracks to the AI and surfaces only the ambiguous ones to the human — then the metrics show whether that handover actually cut the errors, or just moved them.
Component 3 · The scoreboard
Practical metrics — including a hidden requirement
What we bring: the measurement pipeline — detection time, recovery time, error rates, over-trust and under-trust patterns — generated automatically from the same audit-trail machinery we run in production.
The hidden requirement it answers: the call demands mitigation of bias in AI-influenced human decision-making — not just bias in the model. Measuring when operators over-trust a confident-but-wrong AI is precisely that requirement, answered with instruments rather than intentions. Most bidders will miss it.
Who owns what
| Piece | Owner | Why |
|---|---|---|
| Failure-injection harness + attack library | vExpertAI | The rare piece — built from our offensive-security practice |
| Adaptive-automation controller + trust interface | vExpertAI | Extension of our shipped human-in-the-loop machinery |
| Team-performance metrics pipeline | vExpertAI | Same instrumentation discipline as our audit trail |
| Experimental design, ethics, human subjects | Research partner | Scientific validity belongs with an academic human-factors team |
| Training scenarios & doctrine | Military end-users | Operational realism comes from the people who live it |
Use case 3
AI that proposes battle plans and drafts the orders
Live view · from live map to approved order
LIVE MAP
PLANS A·B·C
EACH IN SIM
EXPLAIN WHY
APPROVES
WRITTEN
▸ FORMAL ORDER GENERATED & SENT — 90 SECONDS AFTER APPROVAL
What you're watching: the six-step pipeline lights up left to right. Three candidate plans are war-gamed; Plan B wins with its reason attached; the commander approves; the formal order writes itself.
The official ask, in plain words
The AI reads the live operational map, proposes several candidate plans (Plan A, B, C), tests each one in simulation, ranks them, explains why — and then drafts the formal written orders. A commander always approves before anything moves.
The "reinforcement learning agents" in the call text are AIs that learn good plans by playing the scenario thousands of times in simulation — like a chess engine, but for operations.
Piece 1 · The conductor
One pipeline from map to approved order
What we bring: the agentic system that runs the whole chain — read the picture → generate plans → simulate each → compare → present → approve → write the order. Coordinating specialist AI agents into one reliable pipeline is what our production platform does all day.
Piece 2 · The "why" you can challenge
Explanations, not verdicts
The problem: a commander will not — and should not — act on "the AI says Plan B" without knowing why.
What we bring: the explainability layer. Every ranking comes with its two or three decisive reasons, and the commander can interrogate it: change the risk tolerance, and the ranking updates live.
Picture this
A commander must relieve a surrounded unit. The AI proposes three routes and war-games each: "Route B is safest — 68% success, avoids the ambush zone, costs 20 minutes more." The commander asks: and if I accept more risk? The ranking flips, with reasons. The commander picks Route B and taps approve.
Piece 3 · The order-writer
From decision to formal order in minutes
What we bring: the moment the commander approves, the system writes the full formal order in correct military format and pushes it into the command system — a task that traditionally takes a staff 30–45 minutes of drafting and re-typing.
And the safety rail: the human-approval gate is not a checkbox — it is the same audited approval machinery our enterprise agents ship with, extended with doctrine-bounded authority levels.
Who owns what
| Piece | Owner | Why |
|---|---|---|
| Reinforcement-learning research (the plan-generating brain) | Research partner | Deep academic work — we deliberately do not claim it |
| Agentic pipeline around the RL core | vExpertAI | Multi-agent orchestration is our production platform |
| Explainability + challengeable "why" | vExpertAI | Extension of our audit / decision-rationale machinery |
| Order generation in military formats | vExpertAI | Structured, audited language generation — shipped pattern |
| Doctrinal validation of plans | Military experts | Plans must be sound by doctrine, not just by simulation score |
Use case 4
Manufacturing the data no one can film — threats at sea
Live view · the data factory
generated
🛡 provenance check: every frame signed at birth · 1 poisoned sample detected → quarantined
What you're watching: the simulated sea is rendered into sensor frames, each arriving already labelled (✓). The counter climbs into the thousands — and one poisoned sample (✕) is caught by the provenance check and thrown out.
The official ask, in plain words
To train an AI to recognise attack sea-drones (USVs), smuggler boats, swarm attacks or near-invisible semi-submersible craft, you need thousands of labelled examples — and that footage barely exists. You cannot schedule an adversary's drone for a photo shoot.
Sea drones make the point sharpest: recent conflicts have shown that small, cheap uncrewed craft can threaten major warships — yet they are tiny on radar, sit low in the water, move fast, come in swarms, and are easily mistaken for fishing skiffs or debris. Real attack footage is scarce or classified. Synthetic data is not a convenience here — it is the only way.
So the call asks: generate realistic fake sensor data in simulation — camera, thermal, radar, ship-signal feeds — and use it to train recognition AI that then works on the real sea. This maritime example is named in the call itself.
Piece 1 · The data factory
Realistic, labelled sensor data on demand
What we bring: the pipeline that turns simulated sea scenes into training data — rendering requests to the simulation engine, multi-sensor variation (day, night, fog, sea state), and automatic labelling: every frame arrives already annotated, because the simulation knows exactly what it drew.
Picture this
A swarm of five attack sea-drones approaches at dusk, hulls barely above the waterline — the kind of threat there is almost no real training footage of. The factory generates thousands of realistic thermal and radar sequences of exactly that: different swarm sizes, sea states, approach angles, day and night, each frame perfectly labelled. The recognizer trains on them — then we test it against the few real clips that do exist, and it recognises the threat it never truly "saw." The same factory covers semi-submersibles and dark smuggler craft.
Piece 2 · The recognizer
The AI that learns to spot the threat
What we bring: the detection models trained on the synthetic data, tuned to bridge the gap between simulated and real sensor imagery — including cross-checking sensors against each other. A contact whose camera image and radar signature don't match is itself a signal — and for drone swarms, the recognizer tracks behaviour over time, not just single frames: five small contacts converging on an intercept course mean something one blurry snapshot never could.
Piece 3 · The security — a named call requirement
Data that can't be poisoned, a recognizer that can't be fooled
The problem: a recognizer trained on synthetic data has a supply chain — and supply chains get attacked. Poison the training data and the AI learns a hidden blind spot; spoof a ship's broadcast identity and the AI mislabels the threat.
What we bring: signed provenance for every training sample, tamper detection on datasets and models, and adversarial testing of the finished recognizer against decoys and spoofed signals. The call names protection against dataset poisoning as a required competency — for us it is core business, not a compliance paragraph.
Who owns what
| Piece | Owner | Why |
|---|---|---|
| Sea-scene rendering (physics, sensors, weather) | M&S partner | The simulation engine draws the world |
| Data factory — pipeline + auto-labelling | vExpertAI | Data-pipeline engineering with provenance discipline |
| Threat recognizer | vExpertAI | Model training and sim-to-real tuning |
| Anti-poisoning + anti-spoofing security | vExpertAI | Named call requirement; our core business |
| Maritime & sensor realism validation | Domain experts | What a threat really looks like on each sensor |
Runs through all four cases
Keeping the AI itself un-hackable
Live view · the immune system
What you're watching: known AI attacks — decoys, poisoned data, spoofed signals — thrown at our own system in the lab, on purpose, so they bounce off in the field.
In plain words
If an adversary can trick, poison or hack the AI, the AI becomes a liability instead of an advantage. Across all four cases we run the immune system: attack our own AI on purpose — decoy patterns against recognizers, prompt injection against agents, poisoned data against training pipelines, mapped to the public MITRE ATLAS catalogue of AI attacks — find where it breaks, harden it, re-test.
And a human can always understand and override the system: every recommendation is explainable, every action gated, every decision logged. This aligns directly with NATO's Principles of Responsible Use of AI and the direction of its Data and AI Review Board.
Picture this
Before anything is fielded, our red team feeds the sea-threat recognizer a decoy pattern that makes it read a warship as empty sea. We catch that weakness in the lab, patch it, and re-test — so no adversary ever gets to use that trick outside the lab.
Add sovereign deployment — the entire framework runs sealed, in-country, offline, with no external cloud dependency — and these two capabilities together are what few AI or simulation teams can offer.
Proof, not promises
Why an enterprise AI company belongs in a defence consortium
Everything in the four cases rests on capabilities that run in production today at enterprise customers — not on slideware. The military content is new work, honestly scoped; the engineering underneath it is shipped, audited and demonstrated in public.
8 seconds
Live multi-agent incident resolution, demonstrated on stage at Cisco DevNet — detect, diagnose, propose, human-approve, remediate.
100% human-in-the-loop
All five production agents require human approval before acting — audited behaviour at enterprise customers, not a design goal.
Regulator-grade audit trail
Every trigger, evidence item, rule, approval and timing logged — the DORA/NIS2 machinery that becomes the exercise black box.
Sovereign by default
Agents run in the customer's cloud or on-premises — no shared cloud brain. Built in the EU (Germany), GDPR-native.
What transfers, what adapts, what is new — our honesty rule
For every capability we claim, we state three things: what transfers as-is from our production platform, what needs adaptation to military content, and what is genuinely new work. Example: our audit-trail machinery transfers as-is; its data schema adapts to military fields (rules of engagement, sensor provenance); mapping it to NATO's responsible-use evidence language is new. That discipline is how a research proposal stays credible.