How it works
One fused picture, every track worked in parallel, and a gate on anything that commits.
DomeCommand sits above your sensors and effectors, and below the commander. Its job is turning a chaos of raw detections into a decision somebody can make in seconds.
Every track, in parallel
A person runs one decision loop at a time. They look at the picture, work out what matters, decide what to do, and act. Under a saturation raid there are hundreds of contacts, and the loops do not queue politely.
DomeCommand runs a loop per track, at once. Every contact is being observed, classified, assessed and planned against simultaneously, and the operator sees the results ranked rather than the work.
Three hundred loops is not three hundred operators. It is one operator, holding the authority over all of them.
:::note On the term Michael Raska (RSIS, NTU) calls this a super OODA loop. The phrase is his; we use it because it names the thing precisely. :::
The four stages
| Stage | What runs |
|---|---|
| Observe | Every sensor feed fuses into one picture. Deterministic, filtered, with an honest confidence per track. |
| Orient | Rules designate from facts. Fusion classifies. Where meaning is needed rather than arithmetic, agents assess intent and narrate what changed. |
| Decide | A configurable decision-support engine authors plans. Constraint solvers optimise against the objective you set, and doctrine decides which of those plans may run at all. |
| Act | Tasking goes out at whatever the line releases, and the engine holds the rest for a person. |
Orient is not only agents. Most of it is deterministic. Fusion classifies from the measurements, and identification rules designate from facts. Agents are added where the question is one of meaning, such as what a pattern of movement probably indicates and how to say it.
Decide is not only a solver. The solver is the arithmetic, and it is genuinely a solver: constraint-based optimisation over your assets and the threats. But which plans are permitted, which effects may be proposed at all, and who has to say yes are decided by doctrine sitting around it. Together those are the decision-support engine, and it is configurable per site. See Decision support.
Vocabulary
These are the words the product uses. Each is a real stage with a real output.
| What it is | |
|---|---|
| Observation | One detection, from one sensor, in one modality. The rawest typed input. |
| Track | A fused estimate of one object over time: position, velocity, classification, threat score. |
| Frame | A per-tick summary of the current picture, by sector. |
| Alert | A rule-triggered warning with a lifecycle. Edge-triggered, so it is not re-emitted every tick. |
| Sitrep | A narrative assessment of recent frames, written by the agent. |
| Course of action | A ranked response, produced by the solver and gated by authority. |
| Engagement | Execution of an authorised action against a target. |
| BDA | What actually happened. |
One contact, stage by stage
A radar returns a plot. That is an observation. It carries a position, an uncertainty and which sensor produced it. Seconds later an RF direction-finder produces a bearing with no range at all, and an acoustic node reports a zone.
Fusion makes them one track, because their geometry is consistent. Agreement is not the test; three sensors can agree and still be wrong about the same thing. The track carries a confidence that reflects how many independent sources support it and how recently. See Sensor fusion.
A frame summarises the tick. How many contacts, in which sectors, closing how fast.
A rule fires. The track is inside a keep-out zone and its affiliation is not friend, so it is designated SUSPECT and an alert opens. This is the fast loop, and it runs every tick.
The slow loop assesses. The agent reads recent frames and writes a sitrep in plain language. This is gated rather than continuous, because narrative assessment is expensive and the fast loop must not wait for it.
The solver authors plans. Each is scored on predicted leakers, cost and coverage, and ranked. See Solver configuration.
Authority decides whether anything runs. The autonomy line releases what sits at or below it, and holds the rest for a person. Cue a sensor is probably released. Intercept probably is not. See Decision support.
Something is engaged, and assessed. The result is recorded, the picture updates, and the next cycle adapts.
The fast and slow loops
| Runs | Does | |
|---|---|---|
| Fast, reflexive | Every tick | Ingest, fuse, frame, fire rules, raise alerts |
| Slow, cognitive | Gated | Assess, narrate, plan, recommend |
The fast loop must never wait for the slow one. An alert about a geofence breach cannot be held up because a narrative assessment is still being written.
Sensor feeds in the console
The console can show every sensor feed at once, each rendered by its modality: a waterfall for RF, video for a camera, a report for a detector that only says something is there.

Contracts between stages
Each stage has a contract, and the wire format strings are frozen. Change the internal representation as much as you like; the schema string never changes.
That is what makes a new sensor an adapter rather than a rewrite, a new fusion algorithm a swap behind a trait, and a new effector a port. It is also why DomeCommand can be sensor-agnostic and effector-agnostic without that being a marketing claim: nothing above the ingestion layer knows what produced an observation.
What is modelled rather than wired
The fusion and tracking mathematics, the layered pipeline and its contracts, threat scoring, authority gating, the solver, the API and the console are all real. The protocol decoders are real decoders.
Effectors are modelled, not wired to hardware, and kinetic action is gated behind a human at every line and ceiling a commercial site can set.
Where to go next
- Sensor fusion, where the picture comes from.
- Decision support for who may say yes.