Distributed autonomy, bounded authority
Autonomous Kill Webs Lab
Explore how an autonomous kill web distributes sensing, state estimation, interpretation, decision support, bounded execution, assessment, and role reassignment across a synthetic network. The lab teaches the architecture in general rather than centering one platform or munition.
Research basis KW-RPT-012 KW-RPT-014 KW-RPT-028 KW-RPT-029
Core distinction
Network autonomy is not autonomous permission to use force.
Autonomy can manage sensing, tracking, message routing, local fusion, navigation, health, deconfliction, role assignment, and recovery while people and institutions retain high-consequence authority. The decisive question is not whether a system is “autonomous,” but which function is delegated, within what boundary, with what evidence, and with what realistic opportunity to intervene.
- Model
- Abstract system-of-systems
- Data
- Fixed synthetic states
- Permitted output
- Continue, recompose, challenge, quarantine, or hold
- Excluded
- Real platforms, targets, weapon assignment, and force authorization
General architecture
Autonomous behavior is distributed across layers.
A mature web is not one all-powerful model. It is a set of bounded services that exchange evidence, state, constraints, task status, and authority while preserving safe local behavior when links fail.
-
1
Perception autonomy What signals, objects, events, or anomalies are present?
-
2
State-estimation autonomy Where are observations, how are they changing, and how reliable is the estimate?
-
3
Interpretive autonomy Which activities or system conditions are consistent with the evidence?
-
4
Decision-support autonomy Which technically feasible and already authorized options remain?
-
5
Execution autonomy How does an approved, bounded task continue under changing conditions?
-
6
Force-application autonomy Who or what selects a specific object and initiates force?
-
7
Governance autonomy Who may change models, data, thresholds, permissions, and software during deployment?
Current posture
Bounded autonomous support
The synthetic web may sense, maintain state, and support decisions only inside the selected delegation, authority, trust, and oversight envelope.
Functions that may continue
- Perception autonomy: Continue local sensing, mark uncertainty, and quarantine suspect inputs.
- State-estimation autonomy: Degrade track quality, preserve alternatives, or drop the track.
- Interpretive autonomy: Return several hypotheses or no conclusion.
- Decision-support autonomy: Recommend, request evidence, or hold. Never manufacture permission.
Functions that must hold or isolate
- Force-application autonomy: The site does not model autonomous selection or application of force. An accountable human and applicable legal, policy, and safety process remain required.
- Governance autonomy: Model, threshold, software, mission, and authority changes require reviewed human change control.
Boundary: No additional warning was triggered, but the result remains fictional and non-authoritative.
Server-rendered analysis ready. No authority created.
Delegation ledger
Inspect every autonomy layer separately.
The interface does not produce a single “autonomy score.” High autonomy in navigation can coexist with strict human control over force, policy, model updates, and mission expansion.
Active within boundsperception
Perception autonomy
Local detection, classification, sensor health, and anomaly screening.
- Governing rule
- Outputs remain observations with provenance and uncertainty; detection is not identification or authority.
- Current reason
- The function may operate inside the selected synthetic boundary.
- Safe state
- Continue local sensing, mark uncertainty, and quarantine suspect inputs.
Active within boundsstate-estimation
State-estimation autonomy
Track association, timing, covariance, confidence, and local world-model maintenance.
- Governing rule
- Conflicting or stale tracks remain alternatives rather than being silently fused into false precision.
- Current reason
- The function may operate inside the selected synthetic boundary.
- Safe state
- Degrade track quality, preserve alternatives, or drop the track.
Active within boundsinterpretation
Interpretive autonomy
Competing hypotheses, pattern comparison, anomaly interpretation, and uncertainty estimation.
- Governing rule
- The system must surface contrary evidence and abstain outside validated conditions.
- Current reason
- The function may operate inside the selected synthetic boundary.
- Safe state
- Return several hypotheses or no conclusion.
Active within boundsdecision-support
Decision-support autonomy
Constraint screening, resource comparison, path recommendation, and opportunity-cost display.
- Governing rule
- Policy, legal, safety, trust, and authority gates are independent constraints—not soft optimization penalties.
- Current reason
- The function may operate inside the selected synthetic boundary.
- Safe state
- Recommend, request evidence, or hold. Never manufacture permission.
Not delegatedexecution
Execution autonomy
Navigation, message routing, role reassignment, formation, deconfliction, health management, and return-to-safe-state behavior.
- Governing rule
- Execution remains inside predeclared mission, geography, time, resource, and authority bounds.
- Current reason
- The selected delegation boundary ends before this function.
- Safe state
- Pause, return, isolate, continue locally, or request renewed authorization.
Outside public labforce-application
Force-application autonomy
Outside this public lab. The site does not simulate autonomous target selection or force initiation.
- Governing rule
- Connectivity, classification, confidence, and optimization never create legal or command authority.
- Current reason
- The site does not model autonomous selection or application of force. An accountable human and applicable legal, policy, and safety process remain required.
- Safe state
- Hold for an accountable human and applicable legal, policy, and safety process.
Institutional controlgovernance
Governance autonomy
Automated checks may detect drift or configuration mismatch, but institutional owners control changes.
- Governing rule
- No deployed system may silently expand its own mission, authority, target class, or learning boundary.
- Current reason
- Model, threshold, software, mission, and authority changes require reviewed human change control.
- Safe state
- Freeze the approved baseline, log the discrepancy, and require reviewed change control.
Abstract node and role ledger
Role reassignment is constrained, not improvised authority.
A fallback node may take over transport, local fusion, or health management only when the role, interfaces, limits, and safe behavior were designed and tested in advance.
| Abstract node | Type | Role | Current state | Reason | Fallback |
|---|---|---|---|---|---|
| Distributed Sensor AlphaSENSE-ALPHA | sensor | Independent observation and local classification | Available | Available inside the synthetic configuration. | SENSE-BRAVO |
| Distributed Sensor BravoSENSE-BRAVO | sensor | Corroborating observation and disagreement detection | Available | Available inside the synthetic configuration. | SENSE-ALPHA |
| Edge Compute AlphaEDGE-ALPHA | edge | Local preprocessing, track maintenance, and low-bandwidth summaries | Available | Available inside the synthetic configuration. | EDGE-BRAVO |
| Edge Compute BravoEDGE-BRAVO | edge | Alternate edge fusion, relay, and local-safe-state control | Available | Available inside the synthetic configuration. | EDGE-ALPHA |
| Mesh Relay NorthRELAY-NORTH | transport | Message transport and route health reporting | Available | Available inside the synthetic configuration. | EDGE-BRAVO |
| Federated Fusion ServiceFUSION-ONE | fusion | Cross-source state estimation, alternatives, and provenance checks | Available | Available inside the synthetic configuration. | EDGE-ALPHA |
| Policy and Authority GatePOLICY-GATE | authority | Independent eligibility, authority, safety, and scope enforcement | Available | Available inside the synthetic configuration. | |
| Mission Coordination ServiceCOORD-CORE | coordination | Compare permissible paths and assign bounded roles | Available | Available inside the synthetic configuration. | EDGE-ALPHA |
| Approved Task ExecutorEXECUTOR-ONE | execution | Perform a fictional approved non-force task inside declared bounds | Available | Available inside the synthetic configuration. | safe-state |
| Assessment and Learning NodeASSESS-ONE | assessment | Report outcome, uncertainty, system health, and need for renewed review | Available | Available inside the synthetic configuration. | local log |
How the general model works
A web senses, shares, constrains, assigns, executes, assesses, and recomposes.
No particular drone, aircraft, munition, ship, or vendor defines the architecture. Platforms are replaceable participants; the enduring subject is the governed interaction among capabilities.
- 1
Sense locally
Distributed nodes collect different kinds of observations and report health, time, provenance, and uncertainty rather than one unsupported “truth.”
- 2
Reduce at the edge
Local compute filters raw streams into compact observations and tracks so the web can function under constrained bandwidth.
- 3
Fuse without erasing disagreement
Federated services reconcile identity, time, geometry, confidence, and source lineage while preserving alternatives and contradiction.
- 4
Apply independent gates
Trust, evidence quality, compatibility, authority, policy, safety, and mission bounds exclude unusable paths before optimization.
- 5
Assign bounded roles
Coordination software recommends which available node can sense, relay, analyze, execute an approved task, or assess the result.
- 6
Execute inside the envelope
Local autonomy handles routing, navigation, health, deconfliction, and recovery without broadening the mission or inventing authority.
- 7
Assess and recompose
Outcome and system-health evidence return to the web. Lost, stale, untrusted, or unavailable components trigger a validated alternate or a safe hold.
What autonomy does not mean
Avoid the platform and “any sensor, any shooter” shortcuts.
| Shortcut | Why it fails | General kill-web treatment |
|---|---|---|
| One autonomous weapon defines the web | A platform may combine sensing and effect, but it does not provide the full data, authority, security, transport, assessment, and governance architecture. | Treat every platform as one replaceable node or bundle of capabilities. |
| Every sensor should connect to every executor | All-to-all connectivity creates congestion, attack surface, incompatible data, and authority confusion. | Use selective reachability, machine-readable capability contracts, and independent policy gates. |
| Machine speed should remove human friction | Some friction is verification, legal review, escalation control, or protection against automation bias. | Automate data handling and option comparison while preserving accountable pause, rejection, and abstention. |
| A human approval button guarantees control | Control is nominal when the operator lacks time, evidence, understanding, intervention access, or power to reject. | Test the combined human-machine workflow under realistic workload, deception, and link loss. |
| More autonomous layers imply a better system | Delegating a high-consequence function can increase risk even when lower-layer autonomy is reliable. | Evaluate each function by consequence, reversibility, evidence, supervision, and authority. |
Failure and assurance
The safe web assumes nodes, links, models, and judgments can fail.
Integrity before tempo
A plausible false track or corrupted confidence can be more dangerous than a visible outage. Suspect lineage must be isolatable.
Partition reconciliation
Disconnected clusters need predeclared local authority, durable logs, task ownership, duplicate-action controls, and safe reintegration.
Emergent role conflict
Two nodes can assign themselves the same task or hold inconsistent world models. Coordination requires deterministic conflict rules.
Governance lock
Deployed models and permissions must not silently change their own mission, target class, learning boundary, or authority.
Answer-ready summary
Direct answers
What is an autonomous kill web?
It is a distributed mission network in which bounded machine functions can sense, maintain state, route data, recommend options, execute approved non-force tasks, assess results, and reassign roles under explicit trust, policy, authority, and human-control constraints.
Read the supporting pageDoes autonomous mean a machine chooses whom to attack?
No. Autonomy is function-specific. Navigation, sensing, routing, tracking, and recovery can be automated while force application, mission expansion, and governance remain subject to accountable human and institutional control.
Read the supporting pageHow does an autonomous kill web survive disruption?
It uses distributed state, predeclared fallback roles, alternate transport, local safe behavior, quarantine, assessment, and validated recomposition rather than relying on one central platform or path.
Read the supporting page