INTENT Operator Console

At a glance

The sixty second escort_transit sortie, recorded headless by the shipping app (python main.py demo escort_transit --autopilot --record --headless). Five uncrewed CCAs screen the crewed lead across Berlin against four waves of incoming fighters. The fourth wave appears inside minimum standoff range and has to be met close in. Every element on screen (map, aircraft, mission goals, engagement authorization, AI decision log) is drawn by the same code that renders the interactive window. The capture ends on the MISSION ACCOMPLISHED card, which appears only when every declared goal is met, and then on the after-action review with its decision timeline. Debrief: nothing ever fired at the human pilot, five of five uncrewed aircraft came home, all four waves were turned back.

Problem

One human, several uncrewed wingmen, time pressure.

As MUM-T concepts move from slideware into procurement, the flight profile is the easier half of the problem. The hard half is one operator tasking several aircraft at once, authorizing a weapon release within seconds, and leaving a message trail that survives an after-action review.

Existing MARL testbeds exist to train agents. The operator experience is an afterthought where it exists at all. A product team building the operator side needs the console prototyped on the same simulator that would train the autonomy, so one scenario replay exercises both. That is what INTENT is.

What it does

Four tasks, three postures, one human approval per action.

All four scenarios are defensive. The element escorts a transit and answers intruders that come to it, and nothing is engaged without a human approval inside the authorization window. INTENT turns operator intent into aircraft behaviour and keeps a record of every step. The operator selects a wingman or the whole element, assigns one of four tasks, sets the rules of engagement (ROE, the posture that says when a weapon may be used) and answers engagement requests with a key press. Scripted autonomy flies the aircraft, a deterministic safety gate bounds its actions, and mission goals declared in the scenario file are scored every frame and summarised in the after-action review.

• Weapons are safe by default. A release happens only in the AUTHORIZED state of the positive human control (PHC) queue. Under WEAPONS TIGHT each request opens a 5 second operator window, under WEAPONS FREE the operator has pre-delegated release inside the safety gate, and every release is followed by a 2 second cooldown. multi_shield_europe/authorization.py
• Four task primitives, ESCORT, SCREEN, INTERCEPT and RTB, plus an element-wide ROE posture HOLD, TIGHT or FREE, applied to one wingman or the whole element. multi_shield_europe/tasking.py
• Every tasking, request, grant, denial, release, state change and safety intervention is one JSON line with step, class, source, destination and payload in logs/session_<ts>.jsonl. multi_shield_europe/messages.py
• A deterministic safety gate clips actions before physics: a 100 px no-fly radius around the lead, a 1250 px leash, and a minimum firing distance near friendlies. multi_shield_europe/safety_gate.py
• Every request explains itself. Under each pending request the console shows the range, the closure rate, the seconds until the intruder could detect the requesting wingman, and how many wingmen hold the track. The map draws the request as a line from the wingman to its target with the seconds left to decide, and the same reasons go into the decision log. multi_shield_europe/sensing.py, console/panels.py
• Element abort. X pressed twice, or two clicks on the ABORT control, stands the whole element down in one action: every pending request is cancelled and every unused clearance revoked, the ROE goes straight to WEAPONS HOLD, and all five wingmen return to the human pilot. The shipped run measures every weapon safe in the same frame. main.py, multi_shield_europe/authorization.py
• Lost-link procedure. A wingman that loses its link to the console goes weapons safe at once and raises no request while out of contact. It holds its last task for ten seconds, then flies home on its own authority, and the log records that as its decision, not the operator’s. When the link returns it waits for a fresh order before it counts as under control again. Orders sent while it is out of contact are logged as not delivered, and tracks only it can see are shown as stale. multi_shield_europe/datalink.py
• Mission goals are declarative data in the scenario pack, evaluated every frame, shown live in the MISSION panel and replayed as a checklist with JSON export in the after-action review. multi_shield_europe/mission.py, console/aar.py

Solution

Console first, testbed underneath.

INTENT is an operator console (tasking, PHC engagement authorization, ROE cycling, AI decision log) on top of a PettingZoo ParallelEnv, the standard multi-agent simulation interface. The console attaches only in main.py. The training scripts import no console code, which I keep as a reviewed convention rather than a tested boundary.

The autonomy that flies the demo is scripted. A route pilot follows the scenario waypoints, a heuristic pilot changes behaviour with task and ROE, and the safety gate clips every action before physics. A 5M step PPO policy exists in the repo, regressed below the scripted pilot in training, and is never loaded by the demo. Four scenarios ship in the box, each with a ghost operator timeline that drives the console for replay. The --record flag streams frames straight into an H.264 encode, or an animated GIF where ffmpeg is absent, so the video above is produced by the app itself.

Result

The protected aircraft was never fired on, and a test asserts it.

In the shipped escort_transit run, five wingmen turn back four waves of incoming aircraft and the crewed lead is never fired on. tests/test_superiority_outcome.py runs the same headless demo path and asserts that outcome. A determinism test takes a fingerprint of 500 steps of trajectory with sha256, a standard way to tell whether two files are identical, and asserts the two runs match. The AI decision log of the shipped run holds 79 lines: 14 taskings and ROE changes, 15 engagement requests, 19 authorizations, 16 weapon releases and 15 state transitions. All five wingmen appear as the source of a request, an authorization or a release, because the whole element is under the console.

Contested link

Out of contact means weapons safe, and control comes back through a person.

In the contested_link run, CCA-2 loses its link to the console while its engagement request is waiting for an answer. The request is cancelled in the same step and its weapon stays safe for the whole outage. CCA-3 is tasked onto the track. After ten seconds out of contact CCA-2 turns for home on its own, and the log names CCA-2, not the operator, as the source of that decision. The link returns after 25 seconds. CCA-2 keeps flying home with its weapon safe until the operator gives it a new order. Near the end a two-ship raid comes in. CCA-3 asks to engage the lead raider, the operator clears it and the raider is turned back. The second raider breaks off and runs for the border while a wingman is still asking to engage it. Chasing it would take the element out of the corridor, so the operator aborts: the open request is cancelled in the same frame, every weapon goes safe, and a banner on the map says what happened and why. tests/test_contested_link_outcome.py runs the shipped headless loop and checks each of these claims against the decision log itself, and a second run must produce an identical log.

The contested_link sortie, recorded the same way as the video above. Watch the CCA-2 card: LINK LOST with the seconds since contact, then the lost-link procedure, then LINK BACK with a prompt to re-task. Around 40 seconds the element fires on the lead raider of the late raid. At 45 seconds the abort is deliberate: the remaining raider is leaving, and following it out of the corridor is not the mission. Only the link to the console is modelled. The aircraft still share their sensor picture with each other.

The same console in its dark theme (--dark), six seconds in. Three wingmen ask to engage the same track. Each request is a line on the map with the seconds left to decide, and under the queue the console says why: 10.2 km, closing at 839 m/s, the intruder could see the wingman in 5 seconds, four wingmen hold the track.

Solution architecture

What it stands on, and what is new.

Sources: Overture Maps data is CDLA-Permissive 2.0 with the buildings theme partly ODbL via OpenStreetMap, fetched with DuckDB (MIT). PettingZoo, Gymnasium, Stable-Baselines3 and supersuit are MIT, PyTorch is BSD, pygame-ce is LGPL, Pillow is HPND, ffmpeg is an optional LGPL or GPL binary. The C2 (command and control) message classes are modelled on the NATO STANAG-4586 groups and are not compliant with the standard. Everything else is this project.

Why it matters

The human stays accountable, and the record proves it.

Uncrewed aircraft are arriving in European air defence whether or not the control seat is ready, and the question that decides whether they are acceptable is who remains answerable for what they do. INTENT puts that question in code rather than in slides. The machine holds no authority of its own, the path to any consequential action runs through a person, and the log lets a reviewer reconstruct each decision and name who made it. It also covers the moment contact is lost: the weapon goes safe, and control comes back only through a human order. The saturation scenario also shows where one operator runs out of attention. That limit matters for product design as much as for engineering.

How it was built

A sandbox, a failed policy, then the console.

Spec, PRD, product doctrine, thresholds and review by hand. Implementation with Claude Code agents. The console work is squashed into one commit. Measured from the repository.

The sandbox came first. Physics, the baked Berlin map and the PettingZoo environment landed in the first two days. Reinforcement learning followed with the RLlib wiring, SB3 PPO training and the safety gate around it. The trained policy regressed below the scripted pilot, so I shelved it and the project stood still for six months. When work resumed, it pivoted to the operator console, three scripted demo scenarios and the sensor model that makes the outcome emergent. A later pass put the whole five-ship element under the console and added the abort, the lost-link procedure and a fourth scenario to exercise them. A design pass after that made every request explain itself, reserved red for consequences, added a dark theme and a decision timeline, and fixed an abort that looked like a missed engagement on video because nothing on screen said why the wingmen held fire. The hardest part was making the demo falsifiable, so the superiority test drives the shipped demo path. Thrown away: the centralized critic claim and manual pilot mode as the main entry point.

Success criteria

When this counts as working.

• Every authorization action is written to the AI decision log on disk with a step, ROE state, track ID and outcome. A reviewer can reconstruct the decision without asking the operator.
• The ghost operator completes the escort, pincer, saturation and contested_link scenarios end to end without human intervention.
• A wingman out of contact never releases a weapon, and the decision log shows it: zero releases between LINK LOST and LINK RESTORED.
• One operator action makes every weapon on the element safe in the frame it is given.
• The console attaches only in main.py and the training scripts import no console code. This is a reviewed convention with no test behind it yet.
• The same code path renders the pygame window interactively and dumps frames headless under SDL_VIDEODRIVER=dummy.
• Scenario replays are deterministic. Fixed seed, deterministic environment and a deterministic operator timeline give the same trajectory hash.

Metrics, KPIs, evals

Numbers from the shipped runs.