Policy and rules

A rule is a conditional override of configuration, plus a proposal of actions. It is deliberately not an inference engine.

The rules list grouped by category

Rules grouped by category, three facts on a row: what it says, what it does at the line in force, and how often it has fired. The state dot toggles it, which is why there is no save button beside it.

What a rule is

A rule is one sentence of doctrine, made executable:

• A condition on facts about a track: its affiliation, confidence, range, closure, time to impact, altitude, speed, spoof risk, whether it carries a known serial, how long it has dwelled, and whether it is inside a zone.
• An effect: designate it, deny an action against it, raise its priority, emit an alert, or override a constant for this pass.
• A category and an order, so you can read the set as an ROE card.

The engine

The authoring model is the one Drools made familiar: a condition, an effect, and a set you can read top to bottom. The engine underneath deliberately is not a Rete inference engine, and the difference matters for a system that commits effectors.

What was kept:

• Rules as sentences, grouped by category, readable as a set.
• Templates for the common cases, and a free-form editor for the rest.
• Live firing counts beside each rule.

What was dropped, and why:

• No chaining. A rule reads facts, never another rule's conclusion. One pass, no fixpoint, so it always terminates.
• No salience arithmetic. Rules evaluate in the order you put them in.
• No wall clock, no I/O, no randomness. Enforced by the grammar rather than by convention: there is no fact for the current time, so no rule can read one.
• Bounded effects. Every derived value is clamped by a doctrine bound, and a clamp is recorded rather than silently applied.
• Total attribution. Every firing names its rule and its subject.

The cost is real: a rule cannot react to another rule's conclusion. That is paid deliberately, because emergent firing order is exactly what you cannot have when the output commits an effector.

Authoring with AI

You do not have to fill in a form. Describe the rule and the Copilot drafts it:

Designate any contact SUSPECT if it enters the outer keep-out zone below 120 m and its affiliation is not friend.

The draft arrives in the editor, validated, with nothing saved. There is no tool that saves a rule, so the human checkpoint is structural rather than a policy. See Agentic C2.

How conflicts resolve

One resolution policy for all effects is unsafe, so there are four.

Effect	Resolved by
Derive, Prioritise	Rule order. A tuning wants a visible precedence.
Designate	The lattice friend > unknown > suspect > hostile. Most careful wins, regardless of order.
Emit	No conflict. Both fire, deduplicated by verb and target.
Deny	Union. Narrowing composes; there is no "last denial wins".

The designation row is the one that matters. Last-writer-wins on designation is a fratricide path: a later rule marking a friendly aircraft hostile would win purely by sitting lower in the list. The lattice removes that without an operator having to configure anything correctly.

The locked self-defence rule

Exactly one shipped rule is locked. It is not editable, not reorderable and not deletable, because no rules of engagement remove the right of a unit under attack to defend itself.

It renders with a lock rather than being hidden, because a commander needs to see that it is there.

Authoring a rule

Settings → Decision support → Add. The picker asks one question at a time, along the graduated-response ladder, which is the order an ROE card reads in.

Adding a rule, one question at a time

Start from a sentence of doctrine, or from a ruleset written for a job like yours: an oil facility, a fast inbound, a firefighting flight sharing the airspace. The plain-English line is the control; the template name is secondary.

Then the editor, which is three parts: the sentence with its numbers as inline inputs, the WHEN and THEN rows as typed fields, and what the rule would actually do.

The rule editor

The verdict renders before the rule can be saved. A rejection names the rule and the reason rather than failing generically.

Every rule is editable, template or not. The template decides which form you are offered, never whether the row can be changed.

Drafting a rule with the Copilot

The case a template cannot cover is the one a commander actually hits. Describe it instead:

Designate any contact SUSPECT if it enters the outer keep-out zone below 120 m and its affiliation is not friend.

The Copilot drafts it into the editor. Three properties of that flow:

• The agent never saves. It produces a proposal; the page renders it; you decide.
• It is validated on screen first, before it can be saved at all.
• A rule cannot widen authority. Only a grant can, and never for self-defence.

Facts a rule can test

Facts are a closed set of typed predicates rather than arbitrary expressions. That is what keeps the purity guarantee enforceable.

A rule can read a track's affiliation, confidence, range, closure, time to impact, altitude, speed, spoof risk, cooperative ID, dwell, whether it is inside a kind of zone, and whether it is inside one named zone.

One fact deserves a note. Visual ID is true only when an imager has produced a picture of the contact and the fused class is in the UAS family. Either half alone is what the affiliation ceiling exists to refuse: a camera that saw a bird, or a radar that guessed a multirotor.

Where to go next

• Constants for the values rules read.
• Decision support for the gates that decide whether a proposal runs.