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.
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.
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.
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 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.
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.
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.