Matt Stokes · Design Exploration

The Decision Fabric

A command-interface proposal for sharing assessment across a contested network while keeping consequential action under human authority.

A linear kill chain is easy to understand because each step follows the last: Find, Fix, Track, Target, Engage, Assess. It also depends on stable communication and enough time to move from one step to the next.

In a contested network, sensors can disappear and links can be jammed. The time available to make a decision keeps shrinking. The first broken link can stop the sequence.

This design exploration uses military decision models as source material. It does not describe a fielded command system or a performance study.

Instead of depending on one intact sequence, each node should add what it can observe and receive the latest shared view, while rules still limit what the system is allowed to do. The proposed interface shows the current assessment, its confidence, and the authority attached to it. A person sets that boundary. That arrangement is the decision fabric.

Evolution of kill chain to decision fabric

Backup routes still return to one approval point

The Kill Chain has one path. A lost sensor or broken link can stop the whole sequence.

The Kill Web adds backup routes. Another platform can replace the lost sensor. Approval still returns to a central decision point.

The Decision Fabric spreads assessment and limited action across the network. In the proposal, a field unit can update the shared view and respond within clear rules. Decisions with serious consequences still return to a person.

OODA loop comparison

Assessment runs continuously

John Boyd's OODA loop describes how people observe a situation, understand it, decide, and act. A machine can keep updating its assessment without waiting for a person to complete that full cycle.

Observation and assessment run continuously. Action depends on the rules. The operator steps in when the decision carries more risk or consequence. The machine-assisted loop is OPAL-I: Observe, Process, Assess, Leverage, Intervene.

Signal fusion

Evidence keeps its source

Traditional fusion centers separate data by type and ask analysts to combine it later. Closer to collection, each new signal should change the shared assessment without erasing where it came from or how much it should count. A single answer with no supporting evidence would hide what the operator needs to judge.

The update rule in the proposal is Bayesian: the assessment updates as evidence arrives, and each signal keeps its source and level of influence.

The interface can stay simple while little is at stake. Before the system gains more authority, the operator must be able to inspect the evidence behind its assessment.

Authority view

Authority follows consequence

The command interface connects what the system may do to its confidence and the consequence of being wrong. The states below are policy examples:

Full autonomy (>95% confidence): The system can take a limited defensive action and report it immediately afterward.

Partial autonomy (80–95% confidence): The system prepares the action, shows the evidence behind it, and waits for approval.

Escalate (low confidence or high consequence): The action remains locked for human review.

The percentages are placeholders, not measured operating thresholds. A person remains responsible for setting the real boundary.

Adaptive density

Detail follows the decision that matters

A person in the field cannot supervise the full network. The display should show only what they need for the current decision.

During a low-threat patrol, basic location and navigation may be enough. When the threat changes, the display adds the markers and distance information needed to judge it.

Role-specific view

The proposal is only useful if an operator can identify the source of an assessment and stop a pending action without rebuilding the full network picture. That is the next test.