A Reference Architecture for Autonomous Kill Web Simulation: Assuring Command, Control, and Bounded Execution in Synthetic Environments

Executive Summary

The proliferation of distributed sensors, advanced artificial intelligence, and network-centric warfare concepts has catalyzed a paradigm shift in military operations. Traditional, linear kill chains are rapidly evolving into dynamic, self-healing kill webs and algorithmically driven kill meshes. As global defense establishments explore the integration of machine learning and autonomous systems into safety-critical command and control (C2) architectures, the necessity for rigorous, non-operational environments to study these technologies becomes paramount.
This research report proposes a technology-neutral reference architecture for “KillWebs.com”—a hypothetical, public-safe, unclassified software platform dedicated to the research, simulation, and assurance of fully autonomous weapon-system concepts. The objective of this architecture is to provide a synthetic laboratory for systems engineers, safety researchers, and policy analysts to investigate the behaviors, failure modes, and governance mechanisms of complex System-of-Systems (SoS) architectures without generating executable weapon-control code or interacting with operational military networks.
Verified Public Fact: Global defense initiatives, such as the U.S. Department of Defense’s Joint All-Domain Command and Control (JADC2) and the Defense Advanced Research Projects Agency’s (DARPA) Mosaic Warfare, seek to disaggregate monolithic platforms into distributed, composable networks of sensors, C2 nodes, and effectors1. Concurrently, the incorporation of non-deterministic AI introduces unprecedented vulnerabilities, necessitating advanced safety frameworks such as Run-Time Assurance (RTA) and the Simplex architecture to guarantee bounded execution5.
Proposed Requirement: To safely simulate these dynamics in the public domain, KillWebs.com must enforce a strict, air-gapped abstraction at the force-application boundary. The system will model perception, state estimation, option generation, and bounded execution, but it will physically and logically abstain from possessing target libraries, operational coordinates, or the algorithmic capacity to initiate kinetic effects.
This document exhaustively decomposes the conceptual system into eight functional layers, defining the required software services, trust boundaries, data schemas, and human-in-the-loop governance gates. By leveraging public standards such as Cursor on Target (CoT) for geospatial messaging, W3C PROV-O for data provenance, and SPIFFE/SPIRE for Zero Trust workload identity, this report establishes a comprehensive blueprint for researching autonomous C2 safely, transparently, and rigorously.

Part I: Contextual Analysis of Distributed Command and Control

To establish a baseline for the KillWebs.com reference architecture, it is necessary to delineate the evolving terminology surrounding distributed military operations and the foundational concepts of a System-of-Systems. The historical context of command and control reveals a steady trajectory from highly rigid, hierarchical structures to fluid, software-defined networks.

Taxonomic Distinctions: From Chains to Meshes

Verified Public Fact: The evolution of tactical engagement processes is characterized by a transition from static chains to dynamic webs and complex meshes, driven by the need for resilience and speed in contested environments9.
The traditional “kill chain,” a term widely attributed to U.S. Air Force General John Jumper, describes a linear sequence of events—often summarized as find, fix, track, target, engage, and assess (F2T2EA)—required to deliver an effect on a target9. Analyst Inference: While conceptually clear, a linear kill chain is inherently brittle. The disruption of any single node or communication link causes the entire sequence to fail. This fragility is a significant vulnerability in modern environments characterized by advanced electronic warfare, anti-access/area denial (A2/AD) capabilities, and the rapid attrition of high-value monolithic assets.
The “kill web” concept, advanced prominently by DARPA’s Mosaic Warfare initiative, reimagines this sequence as a collection of multiple potential pathways and heterogeneous nodes3. In a kill web, if one sensor is compromised or one communications link is degraded, the network dynamically routes data through alternative nodes to complete the engagement sequence3. The objective is to overwhelm adversaries by generating immense operational complexity, turning individual platform vulnerabilities into asymmetric network advantages2. DARPA programs such as the Adapting Cross-domain Kill-webs (ACK) have demonstrated the ability to analyze thousands of routing and engagement options to form cross-domain solutions in real time, shifting operations away from predefined engagements toward fluid composability12.
The “kill mesh” represents a further abstraction, heavily featured in international research, including analyses of People’s Liberation Army (PLA) doctrinal shifts toward “intelligentized” warfare and “system-centric” conflict9. A kill mesh is defined as a highly dense, multidimensional collection of potential pathways that requires advanced algorithms to determine sequences and achieve outcomes9.
Analyst Inference: While a kill web implies a localized, mission-specific composability directed by human or AI orchestration, a kill mesh suggests a pervasive, ubiquitous sensory and effector environment where the act of movement by an adversary instantly triggers automated, algorithmic reallocation of defense resources. In advanced theoretical models of a kill mesh, predictive logic ensures that threats are engaged automatically based on intersecting kinematic envelopes, rendering traditional maneuver irrelevant and suppression the default state13.

JADC2, Mosaic Warfare, and Conventional C2

Verified Public Fact: Joint All-Domain Command and Control (JADC2) is the U.S. Department of Defense’s strategic concept to connect sensors and shooters from all military services—Air Force, Army, Marine Corps, Navy, and Space Force—into a unified data architecture1.
Conventional command and control applications, such as the historical Worldwide Military Command and Control System (WWMCCS), were characterized by independent development paths across military branches, leading to siloed, proprietary networks that struggled to interoperate14. These legacy systems rely on human-centric decision chains, static routing, and perimeter-based network security13. JADC2 aims to break down these silos, operating analogously to commercial ride-sharing algorithms that dynamically pair the optimal available asset to a specific requirement based on real-time variables1.
Mosaic Warfare, specifically pioneered by DARPA, serves as the tactical implementation philosophy for this networked future. It focuses on “monolith busting”—replacing expensive, multi-function platforms with large quantities of smaller, specialized, and expendable systems (the “tiles” of the mosaic)2. To integrate these disparate tiles on the fly, DARPA utilizes tools like STITCHES (System-of-Systems Technology Integration Tool Chain for Heterogeneous Electronic Systems), a software compiler that auto-generates low-latency middleware to translate between different data standards without requiring hardware upgrades or forcing universal global standards2.

The System-of-Systems (SoS) Paradigm

Verified Public Fact: A kill web is fundamentally a System-of-Systems (SoS) rather than a single monolithic program16.
An SoS architecture integrates multiple, independent, and geographically distributed systems that maintain their own operational and managerial independence but collaborate to achieve capabilities that none could achieve alone19. The foundational bedrock of supporting an integrated SoS architecture is the establishment of a secure computing environment (SCE) that facilitates real-time tactical information exchange across decentralized domains21.
For example, the U.S. Army’s Integrated Battle Command System (IBCS) is a realized SoS that provides a common mission command capability and an Integrated Fire Control Network (IFCN) relay, allowing legacy and modern sensors and weapons to operate in a “Plug and Fight” architecture4. This component-based acquisition and integration approach explicitly moves away from traditional system-centric designs, ensuring that the loss of a single radar node does not blind the attached interceptor batteries, as the network automatically reconfigures to utilize data from adjacent sensors4.
Analyst Inference: In the context of the KillWebs.com research environment, the simulation platform cannot be designed as a single procedural codebase. It must be architected as a distributed microservices ecosystem representing distinct, containerized nodes (synthetic sensors, command centers, interceptors) communicating over simulated, constrained networks. Treating the simulator as an SoS ensures that researchers can observe emergent behaviors, latency cascades, and integration friction that accurately reflect real-world autonomous network challenges.

Part II: Distinguishing Flows, Trust, and Authority in Autonomous Networks

A critical requirement for analyzing autonomous command and control is recognizing that technical capability does not equate to operational authority. In a highly distributed kill web, data and permissions do not move in tandem; they must be evaluated across distinct, orthogonally enforced dimensions.
Analyst Inference: The primary vulnerability in hastily integrated C2 systems is the conflation of network reachability with legal authority. Because a sensor can pass targeting data to an autonomous weapon system over a TCP/IP connection does not mean the weapon possesses the doctrinal or legal authority to act upon it23. A rigorous reference architecture must separate these concerns.

The Five Dimensions of Distributed Operations

Proposed Requirement: The KillWebs.com reference architecture separates the evaluation of a synthetic engagement into five independent vectors. A failure at any vector results in a safe abstention by the autonomous agent.

1. Network Availability (Can I reach the node?): This relates strictly to the physical and transport layers of the network. In the simulation, this involves determining if UDP/TCP packets can transit between synthetic node A and synthetic node B, factoring in simulated atmospheric interference, jamming, or orbital disconnection25.
2. Technical Compatibility (Can I read the data?): If a packet arrives, can the receiving system parse it? This dimension involves translating schemas. In operational environments, this is managed by systems like STITCHES. In KillWebs.com, this involves validating XML or JSON payloads against expected schema definitions11.
3. Data Trust (Is the data legitimate?): A packet may be readable, but is it authentic? This requires evaluating cryptographic signatures (e.g., mTLS) and checking W3C PROV-O metadata to ensure the observation was generated by a trusted agent and has not been subjected to adversarial spoofing27.
4. Legal Authority (Am I allowed to act?): Does the autonomous agent hold a current, unexpired delegation of authority from a human commander? This involves Attribute-Based Access Control (ABAC) policies evaluating the agent’s clearance, the target’s classification, and the current rules of engagement (ROE)28.
5. Permission to Act (Is it safe to act?): Even with full legal authority, valid data, and network connectivity, does the proposed action violate fundamental physical or deterministic safety constraints? This is evaluated dynamically by a Run-Time Assurance (RTA) Action Governor just prior to execution7.

Data-Flow and Authority-Flow Diagram

To visualize the separation of these dimensions, the following text-based flow diagram represents the parallel movement of data and authority within the KillWebs.com architecture.

\================================================================================ KILLWEBS.COM DATA & AUTHORITY FLOWS

[DATA / OBSERVATION PATHWAY] Synthetic Sensor | |– (1. Observation Generated: CoT XML + PROV-O Metadata) v [Data Trust Gateway] -- Verifies Sensor SVID (SPIFFE/SPIRE) | |– (2. State Estimation & Inference: Fused Track Generated) v [Hypothesis Aggregator] | |– (3. Track Confidence & Evidence Provided) v [Decision Support (WTA Algorithm)] -- Generates Abstract Execution Option | |– (4. Proposed Option passed to Governor) v
\================================================================================
[AUTHORITY / POLICY PATHWAY] Human Commander (Governance Layer) | |– (A. Sets ABAC Policies & ROE) v [Policy Decision Point (OPA)] | |– (B. Evaluates Agent Attributes & Context) v [Identity Provider (SPIRE)] -- Issues Time-Bound Authority JWT | |– (C. Authority JWT passed to Governor) v
\================================================================================
[EXECUTION & BOUNDED SAFETY PATHWAY]

(4. Proposed Option) (C. Authority JWT)

| | v v +------------------------------------------+
| ACTION GOVERNOR (Layer 5) | | | | 1. Is Authority JWT Valid & Unexpired? | --> NO: Veto & Log | 2. Does Option violate Safety Bounds? | --> YES: Veto & Log | 3. Is Data Provenance trusted? | --> NO: Veto & Log +------------------------------------------+
| (All Checks PASS) v [SYNTHETIC NULL SINK]

Part III: The KillWebs.com Logical Component Architecture

To safely represent a distributed autonomous C2 network while neutralizing operational hazards, the KillWebs.com conceptual system is decomposed into eight highly distinct functional layers. This decomposition ensures that data processing, algorithmic optimization, and safety bounding are explicitly separated, allowing researchers to study systemic interactions without risking unauthorized escalation or generating actionable kinetic software.

Layer 1: Perception and Sensor Intake

The foundational layer is responsible for ingesting environmental data from synthetic, heterogeneous sensors. In a real-world scenario, this involves processing radar returns, electro-optical imagery, and electronic support measures across land, sea, air, space, and cyber domains.
Verified Public Fact: To achieve interoperability among diverse sensors without requiring a central registry, the U.S. military relies heavily on the Cursor on Target (CoT) format11. CoT is a minimalistic, extensible XML (or JSON) schema that mandates a “what, when, where” structure11. Every CoT message contains an \<event> element with mandatory attributes: a unique identifier (uid), a hierarchical classification string (type), temporal validity parameters (time, start, stale), and geospatial coordinates enclosed in a \<point> element31. The type string utilizes a hierarchical format (e.g., a-h-A for “atom-hostile-air” or a-f-G for “atom-friendly-ground”) that allows disparate systems to rapidly classify entities31.
Proposed Requirement: In KillWebs.com, this layer is strictly simulated. The architecture will utilize a simulated CoT message bus where synthetic sensors publish XML or JSON payloads representing observations. To research the effects of adversarial spoofing and sensor degradation, this layer will intentionally inject Gaussian noise, missing data packets, and adversarial perturbations (e.g., hallucinated targets) into the CoT streams.
Required Components:

• Synthetic Sensor Generators: Microservices producing deterministic and stochastic CoT feeds based on a simulated environmental state.
• Message Brokers: Publish/subscribe event buses (e.g., Kafka or RabbitMQ) simulating the transport layer and enabling latency injection.
• Intake API Gateways: Edge components enforcing preliminary CoT schema validation and rejecting structurally malformed XML/JSON.

Layer 2: State Estimation and Track Maintenance

Raw, noisy observations from distributed sensors must be fused into continuous, reliable tracks. This layer resolves ambiguities when multiple sensors observe the same synthetic entity or when a single sensor produces fragmented returns.
Verified Public Fact: State estimation involves advanced kinematic behavior modeling and Markov chain techniques to determine track maintenance34. When integrating multiple sensor feeds, the system must differentiate between distinct entities and redundant observations of a single entity, requiring complex association algorithms.
Analyst Inference: For KillWebs.com, this layer will implement classical filtering algorithms—such as Extended Kalman Filters (EKF) and Particle Filters—to fuse synthetic CoT messages into a Unified Track Database. Crucially, this provides a research testbed for studying Byzantine failures in distributed environments, where compromised nodes send conflicting or malicious data to disrupt the network’s consensus35. The architecture must model Byzantine Fault Tolerance (BFT) mechanisms to maintain a coherent operational picture despite the presence of bad actors.
Required Components:

• Data Fusion Engine: Algorithms correlating track uid values and spatial proximity to merge redundant CoT events.
• Kinematic Predictors: Modules estimating future track states based on velocity, acceleration, and heading vectors to smooth intermittent sensor updates.
• Track Lifecycle Manager: A service that promotes observations to firm tracks, and aggressively prunes stale tracks based on the expiration of the CoT stale timestamp attribute31.

Layer 3: Interpretation and Competing Hypotheses

Once tracks are kinematically established, the system must interpret the intent, threat level, and precise classification of the entity.
Analyst Inference: This is the domain where modern Artificial Intelligence and Machine Learning (AI/ML) models are frequently deployed—and where they are most vulnerable to automation bias, adversarial perturbations, and probabilistic failure8. A neural network might classify a synthetic radar track as a hostile bomber with 95% confidence, but this classification is fundamentally stochastic and must be treated as a hypothesis, not absolute truth8.
Verified Public Fact: To address the “Garbage In” vulnerability of neural networks, advanced defense research proposes architectures like the “Perception Gatekeeper” within a larger Model Constraint Guardian framework8. The Perception Gatekeeper mathematically validates input integrity against adversarial or degraded sensor data in real-time, ensuring that incoming sensor measurements actually support a physically consistent object before the AI is allowed to classify it8.
Proposed Requirement: KillWebs.com will employ a multi-agent system where different interpretation algorithms generate competing hypotheses regarding target identity. A Bayesian belief network will aggregate these hypotheses. The Perception Gatekeeper will act as a semantic layer, filtering out hallucinated threats that lack geometric or physical validity.
Required Components:

• Inference Microservices: Mock AI models (using lightweight containerized algorithms) assigning classification probabilities.
• Hypothesis Aggregator: A service resolving conflicts between differing AI assessments to generate a composite confidence score.
• Perception Gatekeeper (Semantic Validator): A deterministic constraint engine that verifies if the classification logically aligns with the kinematic data (e.g., rejecting a classification of “Ground Infantry” traveling at Mach 2).

Layer 4: Decision Support and Option Generation

This layer bridges situational awareness and actionable engagement. It evaluates the environment and calculates the optimal allocation of defensive or offensive assets to mitigate threats.
Verified Public Fact: The Weapon-Target Assignment (WTA) problem is a fundamental optimization challenge in military operations research, mathematically classified as NP-complete38. It involves finding the optimal assignment of a set of weapons (with varying kill probabilities and costs) to a set of targets (with varying threat levels) to maximize expected damage or minimize surviving threats38. Advanced computational approaches utilize dynamic programming, Kuhn-Munkres algorithms, or heuristic searches (e.g., Genetic Algorithms, Ant Colony Optimization) to solve dynamic WTA problems under strict real-time constraints38.
Proposed Requirement: Because KillWebs.com must be treated as a research object and not as software that controls a weapon, it will implement abstract Resource-Task Assignment (RTA) algorithms instead of literal Weapon-Target algorithms. The system will optimize the pairing of abstract “Synthetic Effector Resources” to abstract “Synthetic Task Geometries.” Researchers can plug in various optimization algorithms to study computational efficiency, decision compression, and algorithmic latency without any reference to operational weapon parameters or classified kill probabilities.
Required Components:

• Cost-Function Evaluator: An algorithm calculating the mathematical cost/benefit of a pairing based on abstract threat matrices.
• Dynamic Programming Scheduler: A real-time engine generating sequences of optimal assignments over discrete time steps39.
• Option Presentation Gateway: An interface formatting generated options for human review (in HITL configurations) or forwarding them to the execution layer.

Layer 5: Bounded Execution Support

The most critical layer for safety-critical autonomy research is the enforcement of bounded execution. How does a command and control architecture prevent a highly capable but opaque AI from taking an action that violates physical laws, safety perimeters, or rules of engagement?
Verified Public Fact: The U.S. Air Force Research Laboratory (AFRL) and NASA heavily research Run-Time Assurance (RTA) and the Simplex architecture for complex autonomous systems6. The Simplex architecture ensures safety by utilizing an unverified, high-performance “advanced controller” (e.g., deep reinforcement learning AI) in conjunction with a formally verified, deterministic “baseline safety controller”7. If the advanced controller attempts to drive the system outside a pre-calculated safe envelope, a supervisory logic module immediately revokes its authority and switches to the baseline safety controller to execute a recovery maneuver6.
Analyst Inference: In modern AI/ML lifecycle assurance, this concept is implemented as an “Action Governor”8. While the Perception Gatekeeper solves the “Garbage In” problem, the Action Governor solves the “Garbage Out” problem8. It sits directly between the AI and the effector, utilizing strict, rule-based logic to enforce a final veto over stochastic glitches or physics-violating commands8.
Proposed Requirement: KillWebs.com will implement a robust, highly visible Simplex architecture. Every synthetic autonomous decision generated in Layer 4 must pass through the Action Governor in Layer 5. Researchers will configure declarative safety bounds (e.g., “No synthetic resource shall be assigned to a task geometry within 10 km of a non-combatant node”). If the autonomous scheduler violates this, the RTA module blocks the command, logs the failure, and triggers a safe fallback state.
Required Components:

• Action Governor (Veto Layer): A deterministic monitor enforcing hard-coded spatial, temporal, and semantic bounds8.
• Simplex Supervisory Controller: The switching logic that manages the transition between autonomous generation and the safety baseline7.
• Deterministic Safety Baseline: A highly conservative, rule-based fallback controller that returns the simulated node to a passive state.

Layer 6: Separately Enforced Force-Application Boundary

To guarantee that KillWebs.com cannot be repurposed as operational weapons software, the architecture must include an unbridgeable logical and physical abstraction at the point of simulated force application.
Proposed Requirement: This layer will be fundamentally air-gapped from any real-world hardware interfaces or tactical data links (e.g., Link 16, VMF). All outputs from Layer 5 are routed to a “Null Sink” or a purely graphical visualization module. The schema for engagement commands will be intentionally malformed relative to any known military standards. It will use arbitrary units of measurement and non-Euclidean coordinate spaces, rendering the outputs mathematically useless for real-world targeting.
Required Components:

• Output Sanitizer: A filter that scrubs any accidental real-world coordinate structures from the data payload.
• Synthetic Actuator API: A mock software interface that accepts commands, returns a standard 200 OK HTTP status, and updates an internal state machine without triggering any external network calls.
• Visualization Dashboard: A web-based front-end rendering the abstract outcome of the simulated engagement for researcher analysis.

Layer 7: Governance, Configuration, Update, and Authority Control

This layer manages identity and policy, determining who—or what—is legally and technically allowed to participate in the kill web.
Verified Public Fact: Static network enclaves are insufficient for dynamic, coalition-based military operations. Modern C2 architectures are shifting toward Zero Trust Identity, Credential, and Access Management (ICAM) using Attribute-Based Access Control (ABAC)28. In a microservices ecosystem, workload identity for automated software agents is frequently managed using the SPIFFE (Secure Production Identity Framework for Everyone) and SPIRE (SPIFFE Runtime Environment) framework28. SPIRE issues short-lived cryptographic identity documents (SVIDs) that allow nodes to authenticate via mutual TLS (mTLS)28.
Proposed Requirement: KillWebs.com will utilize SPIFFE/SPIRE to manage trust boundaries among synthetic nodes. A synthetic sensor node cannot simply send data to a decision node; it must establish mTLS using a valid SVID. Furthermore, ABAC policies managed by an Open Policy Agent (OPA) will dictate whether an autonomous agent has the authority to generate options based on its current trust posture. This enables researchers to study how access policies behave at the tactical edge.
Required Components:

• SPIRE Server and Agents: Infrastructure for issuing and rotating cryptographic identities to synthetic microservices48.
• Policy Decision Point (OPA): An ABAC engine evaluating rules based on node attributes (e.g., clearance, environment) against requested actions28.
• Configuration Repository: A GitOps-driven database managing declarative deployments of the network topology.

Layer 8: Assessment, Reconciliation, Audit, and Recovery

Autonomous systems operating lethal or safety-critical functions must be strictly accountable. This requires an immutable, queryable record of exactly why a decision was made.
Verified Public Fact: The W3C PROV-O ontology and PROV-JSONLD schemas provide a standardized, domain-agnostic method for expressing the provenance of data27. Provenance maps the Entities (data objects), Activities (processes), and Agents (human or machine actors) involved in generating a result27. Provenance is distinct from fixity; a checksum verifies a file hasn’t changed, while provenance explains the sequence of algorithmic transformations that produced the file50.
Analyst Inference: By utilizing W3C PROV-O, KillWebs.com can generate a cryptographically signed chain of custody for every synthetic decision. This satisfies the requirement for legal and operational auditability, enabling post-simulation analysis of failure states, automation bias, and algorithmic accountability.
Required Components:

• Provenance Graph Database: A repository storing W3C PROV-O JSONLD files linked to specific simulation events.
• Audit Log Aggregator: An immutable storage solution (e.g., a localized blockchain or append-only ledger) recording every RTA intervention and Governor veto.
• Reconciliation Engine: A service comparing expected synthetic outcomes against actual synthetic outcomes to detect algorithmic drift.

Part IV: System Context, Nodes, and Data Objects

To operationalize the layers defined above, the architecture must define the boundaries of the system, the types of synthetic nodes permitted, and the schemas utilized for data exchange.

System-Context Diagram

The following represents a logical context diagram of the KillWebs.com research environment, demonstrating the interaction between external researchers, the synthetic simulation space, and the air-gapped visualization layer.
[External Researchers / Analysts]
| (Configures Scenarios, Sets ABAC Policies, Reviews W3C PROV-O Audit) v +-------------------------------------------------------------------------+
| KillWebs.com Platform | | | | +--------------------+ +-------------------+ +----------+ | | | Synthetic Scenario | -—> | SPIFFE/SPIRE | \<—> | ABAC / | | | | Injector (Noise) | | Identity Provider | | OPA | | | +--------------------+ +-------------------+ +----------+ | | | | | | | v v v | | +--------------------+ +-------------------+ +----------+ | | | Layer 1: Sensors | -—> | Layer 2 & 3: | -—> | Layer 4: | | | | (CoT Generation) | | State & Inference | | WTA Gen. | | | +--------------------+ +-------------------+ +----------+ | | | | | | v v | | +--------------------+ +-------------------+ +----------+ | | | Layer 8: W3C PROV | \<---- | Layer 5: Simplex | \<---- | Layer 7: | | | | Audit & Assessment | | Action Governor | | Controls | | | +--------------------+ +-------------------+ +----------+ | | | | |=|=| | STRICT AIR-GAP / SYNTHETIC BOUNDARY (Layer 6) | |=|=| | v | | +-----------------------+ | | | Abstract Null Sink & | | | | 3D Simulation Viewer | | | +-----------------------+ | +-------------------------------------------------------------------------+

Trust-Boundary Map

Zero Trust Architecture (ZTA) assumes no inherent trust within the network perimeter46. In KillWebs.com, trust boundaries are established at the microservice level, mapped closely to the layers of the system.

Catalog of Public-Safe Synthetic Node Types

KillWebs.com will feature a library of node types that researchers can instantiate in a simulation. These nodes are purely synthetic abstractions designed to test network resilience and algorithm performance, intentionally devoid of classified parameters.

Conceptual Data-Object Schema

The core schema of KillWebs.com marries the tactical brevity of the Cursor on Target (CoT) format with the rigorous auditability of W3C PROV-JSONLD and the policy enforcement of Zero Trust architectures.
Verified Public Fact: CoT schemas prioritize rapid transmission of spatial data, while PROV-O models the relationships between entities and activities to ensure traceability27.
Proposed Requirement: Every state change in the KillWebs.com environment generates a composite JSON payload. This payload acts as a unified record of the event, its provenance, and its authorizing policies.

JSON
{
“@context”: “http://www.w3.org/ns/prov#“,
“killweb_event”: {
“cot_header”: {
“version”: “2.0”,
“uid”: “synthetic-target-001”,
“type”: “a-u-A”,
“time”: “2026-08-04T10:24:10Z”,
“start”: “2026-08-04T10:24:10Z”,
“stale”: “2026-08-04T10:25:00Z”,
“point”: { “lat”: 0.0, “lon”: 0.0, “hae”: 10000.0, “ce”: 10.0, “le”: 10.0 }
},
“provenance_metadata”: {
“wasGeneratedBy”: {
“activity_id”: “fusion-process-alpha”,
“algorithm”: “KalmanFilter-v1.2”
},
“wasAttributedTo”: {
“agent_id”: “spiffe://killwebs.test/sensor/beta-04”
},
“uncertainty_score”: 0.15,
“classification_sensitivity”: “UNCLASSIFIED_SIMULATION”
},
“authority_and_policy”: {
“permitted_use”: [“TRACK”, “EVALUATE”],
“execution_authority_jwt_hash”: “a1b2c3d4…”,
“expiry”: “2026-08-04T11:00:00Z”,
“revocation_endpoint”: “https://policy.killwebs.local/revoke”
}
}
}

Schema Justification:

• Identity & Time: Inherited directly from the standard CoT definitions (uid, type, time, stale) ensuring compatibility with tactical processing workflows31.
• Provenance & Uncertainty: Adheres to the W3C PROV structure (wasGeneratedBy, wasAttributedTo), satisfying the need for machine-readable auditability27.
• Permitted Use & Authority: Explicitly links the data object to an ABAC policy token. This ensures that a receiving node (e.g., an Omega-Effector) instantly knows what actions are legally and doctrinally authorized for that specific payload.

Part V: Autonomy, Failure Modes, and Resilience

A primary goal of researching autonomous architectures is understanding how they behave in extremis. Network-centric systems face constant degradation from electronic warfare, kinetic disruption, and software faults.

Functional-Autonomy Matrix

To research autonomous behaviors effectively, KillWebs.com utilizes a functional autonomy matrix aligned with the classic OODA loop (Observe, Orient, Decide, Act). This matrix allows researchers to dial autonomy levels up or down for specific simulated nodes, enabling comparative studies on human cognitive load versus algorithmic speed.

Failure-State and Recovery-State Model

Analyst Inference: Linear systems simply halt during failure. Kill webs, however, must degrade gracefully, utilizing algorithmic resilience to maintain bounded execution even when disconnected from central command. The architecture must account for the fact that stale evidence is worse than no evidence, and compromised nodes pose a greater threat than destroyed nodes.

Part VI: Governance, Command Responsibility, and Non-Delegable Functions

As autonomous capabilities expand, international legal frameworks and ethical doctrines mandate that certain responsibilities remain strictly within human purview.
Verified Public Fact: Under the Law of Armed Conflict (LOAC) and doctrines such as U.S. DoD Directive 3000.09, commanders bear non-delegable “command responsibility” for the forces and systems under their control23. Failing to exercise proper control, or deploying systems whose failure modes are unexamined and unverified, constitutes a violation of this responsibility23.
Analyst Inference: In an autonomous kill web, sovereignty and command responsibility are maintained not by micromanaging every high-speed algorithmic calculation, but by exercising meaningful human control over the bounds of the system and the precise delegation of authority55. If an AI cannot be fully predicted, its operational envelope must be strictly curtailed.
Proposed Requirement: KillWebs.com will model “Non-Delegable Functions” as hardcoded, externally governed policy gates. These gates operate at the infrastructure level and cannot be overridden, bypassed, or modified by the internal AI algorithms, no matter their perceived optimization benefits.

1. Setting Rules of Engagement (ROE) / ABAC Policies: The parameters defining the safety margins in the Action Governor and the attributes in the OPA engine must be set by a simulated “Human Commander” profile using multi-factor authentication30.
2. Issuing Cryptographic Authority Tokens: The generation of the JWTs that permit a node to act autonomously must be manually authorized by a human. An AI cannot cryptographically grant itself or another AI permission to execute an action57.
3. Article 36 Review Abstraction: Representing the international legal requirement to review new weapons for LOAC compliance56, KillWebs.com will require researchers to manually “certify” an AI model’s test-coverage metrics and RTA bounds before it can be deployed into the simulation environment.
4. Target Library Modification: The parameters classifying what constitutes a valid “Synthetic Task Geometry” cannot be dynamically altered by a machine learning algorithm during runtime.

Part VII: Implementation Strategy for the Synthetic Research Environment

To transition the reference architecture from theory to a usable software platform, KillWebs.com requires structured educational modules, a developer-ready backlog, and rigorous acceptance testing.

Proposed KillWebs.com Educational Modules

To maximize its utility as a research and educational platform for systems engineers and policy analysts, KillWebs.com will include guided curriculum modules demonstrating the dynamics of autonomous C2.

1. Module 1: The Fragility of Chains vs. The Resilience of Webs.
   * Objective: Demonstrate how removing a central node collapses a linear chain, while a kill web dynamically reroutes CoT data using abstract middleware routing.
2. Module 2: Byzantine Faults in Distributed Perception.
   * Objective: Inject compromised synthetic sensors into the mesh that output false CoT tracks. Students configure the Perception Gatekeeper to mathematically detect and isolate the rogue nodes.
3. Module 3: Run-Time Assurance and the Simplex Architecture.
   * Objective: Deploy a highly erratic Reinforcement Learning algorithm for synthetic resource allocation. Observe the Action Governor veto unsafe commands at the edge and force the system to fall back to the deterministic baseline.
4. Module 4: Zero Trust and Cryptographic Delegation.
   * Objective: Learn to configure SPIFFE/SPIRE SVIDs and OPA policies to ensure that autonomous agents only interact within explicitly defined trust boundaries and cannot execute without a valid JWT.
5. Module 5: Forensic Analysis using W3C PROV-O.
   * Objective: Following a simulated failure state (e.g., an autonomous agent violating a synthetic ROE boundary), students query the JSONLD provenance graph to determine which specific AI model and sensor feed combination triggered the error.

Developer-Ready Requirements Backlog

The following is an abstract backlog for the initial development sprints of KillWebs.com. No executable weapon-control code is present, requested, or implied.

Acceptance Tests for a Future Prototype

Using Behavior-Driven Development (BDD) Gherkin syntax, the following acceptance tests ensure the architecture adheres to safety and functional requirements.
Scenario 1: Simplex Architecture successfully vetoes unsafe AI command

Gherkin
Given the Action Governor is configured with a synthetic exclusion zone at coordinates [X, Y]
And the Advanced AI Controller generates a synthetic action order targeting [X, Y]
When the order reaches Layer 5 (Bounded Execution Support)
Then the Action Governor must VETO the order
And the Simplex Controller must transition state to the Deterministic Safety Baseline
And the W3C PROV-O log must record the veto event and the hash of the AI model

Scenario 2: Zero Trust network isolates a node with expired authority

Gherkin
Given a synthetic Delta-Relay node possesses a SPIFFE SVID
And the ABAC policy requires an active execution JWT for autonomous option generation
When the execution JWT expires at time T
And the Delta-Relay attempts to publish a decision package at time T+1
Then the API Gateway must return 403 Forbidden
And the package must not enter the Hypothesis Aggregator

Scenario 3: System fails safely upon network disconnection

Gherkin
Given an Omega-Effector node is operating in fully autonomous mode
When the network heartbeat from the Gamma-C2-Node is lost for 5000ms
Then the Omega-Effector must immediately halt processing
And the Omega-Effector must clear all locally cached authority tokens
And the Omega-Effector must enter “Fail-Safe Abstain” status

Unknowns and Decisions Requiring Qualified Human Owners

Building a robust simulation platform for autonomous C2 highlights several unresolved architectural and theoretical challenges within the defense technology space. These “unknowns” require dedicated human owners (e.g., Lead Systems Engineer, Chief Legal Counsel, Lead Data Scientist) to resolve prior to finalizing the platform operations.

1. Metric Definition for “Meaningful Human Control”:
   * Unknown: How do we mathematically quantify “meaningful human control” in the functional-autonomy matrix? Is it measured in latency (seconds to veto), in cognitive load (amount of data presented versus human bandwidth), or in system predictability?
   * Owner: Human Systems Integration (HSI) Lead.
2. Resolution of Conflicting ABAC Policies in Disconnected State:
   * Unknown: If a network partitions, and a locally cached security policy conflicts with a pre-planned baseline engagement strategy, which takes precedence during the disconnection? Does the edge node default to extreme conservatism, or execute the last known good plan?
   * Owner: C2 Architecture Lead.
3. AI Distribution Shift Detection:
   * Unknown: How rapidly can the Perception Gatekeeper detect that an AI model is suffering from a statistical distribution shift due to novel environmental noise, rather than adversarial spoofing?
   * Owner: Chief Data Scientist.

Part VIII: Architectural Design Constraints for Public Safety

To ensure KillWebs.com remains strictly an educational, research, and simulation platform, and completely insulated from generating operational military capabilities, a development team must implement the following non-negotiable design constraints:

1. Abstracted Coordinate Systems: The platform shall utilize a non-standard, flat-plane arbitrary coordinate system (e.g., grid units 0-1000) for all internal logic and visualizations, rather than standard WGS-84 or Military Grid Reference System (MGRS). This ensures generated outputs cannot be accidentally or maliciously applied to real-world geography.
2. No Interface to Operational Hardware: The system architecture shall contain no API drivers, protocol adapters, or middleware capable of formatting messages for real-world tactical data links (e.g., Link 16, VMF, J-Series messages, or actual IBCS A-Kit/B-Kit integrations)4.
3. Synthetic Sink Terminus: All algorithmic processing for resource allocation (WTA) and bounded execution (Action Governor) shall terminate in a localized, graphical “Null Sink.” The system shall have no outbound ports configured to transmit execution commands outside the simulation boundary.
4. Simulated Kinematics Only: The mathematical models used for state estimation and kinematic prediction shall be generic physics abstractions (e.g., simple Newtonian point-mass models) and shall strictly forbid the inclusion or requirement of classified or proprietary performance parameters of actual military airframes or munitions.
5. Overt Watermarking: All JSON payloads, CoT messages, and PROV-O logs generated by the system shall contain immutable, overt cryptographic watermarks designating the data as “SYNTHETIC_SIMULATION_DATA,” preventing it from being accidentally ingested by an operational fusion engine or intelligence database.

By rigorously enforcing these constraints, KillWebs.com will serve as a vital, public-safe laboratory. It will allow the systems engineering and policy communities to advance the science of Run-Time Assurance, study the vulnerabilities of distributed networks, and establish robust governance models for the future of autonomous systems, entirely outside the realm of operational weaponry.

Works cited

1. Joint All-Domain Command and Control: Background and Issues for Congress - EveryCRSReport.com, https://www.everycrsreport.com/reports/R46725.html
2. DARPA STO Talks “Architecture on Demand” – Mosaic Warfare Concept, https://www.naylornetwork.com/jed-showDaily/articles/index.asp?aid=587520\&issueID=76039
3. mosaic warfare across domains: imperatives for future conflict by maj gen ashok kumar srivastava - CENJOWS, https://cenjows.in/wp-content/uploads/2026/05/Maj-Gen-AK-Srivastavas-lecture.pdf
4. Arms Sales Notification - Federal Register, https://www.federalregister.gov/documents/2026/06/01/2026-10950/arms-sales-notification
5. Test & Evaluation of AI-enabled and Autonomous Systems: A Literature Review, https://testscience.org/wp-content/uploads/formidable/20/Autonomy-Lit-Review.pdf
6. Analysis of the Ground Collision Avoidance System Within NASA’s Expandable Vehicle Autonomy Architecture - ROSA P, https://rosap.ntl.bts.gov/view/dot/82861/dot_82861_DS1.pdf
7. 1 Real-Time Reachability for Verified Simplex Design - Taylor Johnson, https://www.taylortjohnson.com/research/johnson2016tecs.pdf
8. Architecting Trust: A Modular Framework for the Operational Deployment of Autonomous Systems - Harvard DASH, https://dash.harvard.edu/bitstreams/1510aa60-37df-4272-9a9c-28df6a25a9d7/download
9. Exploring PRC Research on Kill Chains and Kill Webs: How Might it Help the PLA? | CNA, https://www.cna.org/analyses/2026/07/exploring-prc-research-on-kill-chains-and-kill-webs
10. The LOWDOWN - 28 July 2026 - Deciphering PLA Kill Webs, Shifting Air Campaigns, and Global Frontlines - DVIDS, https://www.dvidshub.net/audio/92963/lowdown-28-july-2026-deciphering-pla-kill-webs-shifting-air-campaigns-and-global-frontlines
11. Data Schemas for Net-Centric Situational Awareness - dodccrp.org, http://www.dodccrp.org/events/2006_CCRTS/html/papers/073.pdf
12. Creating Cross-Domain Kill Webs in Real Time - DARPA, https://www.darpa.mil/news/2020/cross-domain-kill-webs
13. Atmospheric Interdiction and Hypersonic Defense Modeling, https://genesysdefense.com/intl/atmospheric-interdiction-and-hypersonic-defense-modeling/
14. Command and Control: An Introduction - Wikimedia Commons, https://upload.wikimedia.org/wikipedia/commons/d/d2/Command_and_control-_an_introduction_%28IA_commandcontrolin00beth%29.pdf
15. DARPA Seeks “Always On” Interconnected Networks for Multidomain Missions - DSIAC, https://dsiac.dtic.mil/articles/darpa-seeks-always-on-interconnected-networks-for-multidomain-missions/
16. 202040130 Unclas PEO Soldier Reference Architecture v1.0, https://cpeground.army.mil/Portals/53/Documents/soldier_systems/UNCLAS_PEO_Soldier_Reference_Architecture_v1_0.pdf
17. The Road to Information Dominance: “System of Systems” Concept for the United States Armed Forces. - DTIC, https://apps.dtic.mil/sti/tr/pdf/ADA343508.pdf
18. Selected Acquisition Report (SAR) Integrated Air and Missile Defense (IAMD) - Executive Services Directorate, https://www.esd.whs.mil/Portals/54/Documents/FOID/Reading%20Room/Selected_Acquisition_Reports/17-F-0571_FY2009_SARS/IAMD_SAR_Dec_2009.pdf
19. Mission Architecture Style Guide, https://ac.cto.mil/wp-content/uploads/2025/01/U-Mission-Architecture-Style-Guide-Final_07Jan2025.pdf
20. Modernized Selected Acquisition Report (MSAR) Integrated Air and Missile Defense (IAMD) - Executive Services Directorate, https://www.esd.whs.mil/Portals/54/Documents/FOID/Reading%20Room/Selected_Acquisition_Reports/FY_2023_SARS/IAMD%20MSAR%20Dec%202023%20V4.pdf
21. AFLCMC/HBN C5ISR and IAMD Overarching System of Systems Construct (SoSC) Compendium - Volume 3 Secure Computing Environment (SCE) - AWS, https://imlive.s3.amazonaws.com/Federal%20Government/ID164208465367043527426446033992933540267/C5ISR%20and%20IAMD%20Overarching%20SoS%20Construct%20Compendium%20Volume%203%20-%20Secure%20Computing%20Environment.pdf
22. A–Comman Integrated Air and Missile Defense (IAMD) Battle Command System (IBCS) Design, Development, Integration and Test Request for Information (RFI) - SAM.gov, https://sam.gov/opp/22731f0a7a2d246b8493d27d35858195/view
23. New technologies and warfare - ICRC, https://www.icrc.org/sites/default/files/external/doc/en/resources/international-review/review-886-new-technologies-warfare/review-886-all.pdf
24. Thresholds & Technologies - Internet & Information - Southwestern Law School, https://www.swlaw.edu/sites/default/files/2020-02/Panel%202%20-%20Thresholds%20%26%20Technologies%20-%20Internet%20%26%20Information.pdf
25. Aces-high frontier: space war in 2053 | The Strategist, https://www.aspistrategist.org.au/aces-high-frontier-space-war-in-2053/
26. Aces-High Frontier - The Strategy Bridge, https://thestrategybridge.org/the-bridge/2019/1/21/aces-high-frontier
27. The PROV-JSONLD Serialization - W3C, https://www.w3.org/submissions/2024/SUBM-prov-jsonld-20240825/
28. Tactical Data Sharing: Solving Coalition Interoperability with Zero Trust ICAM | Ataz Labs, https://atakuzi.com/2026-07-26-tactical-data-sharing-coalition-icam/
29. Secure and Scalable IoT Networks: Optimizing Blockchain and SDN for Smart Environments | Request PDF - ResearchGate, https://www.researchgate.net/publication/387396017_Secure_and_Scalable_IoT_Networks_Optimizing_Blockchain_and_SDN_for_Smart_Environments
30. FastTrack CISSP Reference By Jobyer Ahmed | PDF - Slideshare, https://pt.slideshare.net/slideshow/fasttrack-cissp-reference-by-jobyer-ahmed/284100645
31. Cursor on target (CoT) format: developer reference - Corvus Intelligence, https://corvusintell.com/blog/c2-systems/cursor-on-target-cot-format/
32. STANAG Recorder: Cursor on Target MISB EG 0805 metadata processing - ImpleoTV, https://www.impleotv.com/content/strecorderapp/help/page_co_t.html
33. CoT Messages - FreeTAKServer, https://freetakteam-freetakserver.mintlify.app/concepts/cot-messages
34. Definition of a Performance Evaluation Methodology for … - DTIC, https://apps.dtic.mil/sti/tr/pdf/ADA327899.pdf
35. UNIVERSIDADE DE LISBOA INSTITUTO SUPERIOR T … - Scholar, https://scholar.tecnico.ulisboa.pt/api/records/2IB5vUhMaAJch7tDsGxKXbMv8tqyYNPho2I4/file/756a0bf89baa26354df23c290dbf6ae5988c2399ab48d994dafb4e4cbe80db5b.pdf
36. Security Properties Outline What is security? 2002: MS-SQL Slammer worm, https://www.cs.uoregon.edu/research/summerschool/summer04/lectures/myers.pdf
37. Publication: Architecting Trust: A Modular Framework for the Operational Deployment of Autonomous Systems - Harvard DASH, https://dash.harvard.edu/entities/publication/82927c82-2c52-4b35-ad34-c73b3bf70986
38. Fast and Simple Method for Weapon Target Assignment in Air Defense Command and Control System - EUDL, https://eudl.eu/pdf/10.1007/978-3-030-77424-0_33
39. Dynamic Weapon-Target Assignment Problems with Vulnerable C2 Nodes - ResearchGate, https://www.researchgate.net/publication/235185699_Dynamic_Weapon-Target_Assignment_Problems_with_Vulnerable_C2_Nodes
40. Dynamic Programming for Weapon Target Assignment | PDF | Mathematical Optimization | Time Complexity - Scribd, https://www.scribd.com/document/723577955/AD1004145
41. Real-time Allocation of Firing Units To Hostile Targets, https://www.foi.se/download/18.7fd35d7f166c56ebe0b10065/1542623791861/Real-time-allocation_FOI-S–3982–SE.pdf
42. AIR FORCE (AF) 22.1 Small Business Innovation Research (SBIR) Phase I Proposal Submission Instructions, https://rt.cto.mil/wp-content/uploads/AF_SBIR_221.pdf
43. Workshop on Assurance for Autonomous Systems for Aviation - NASA Technical Reports Server, https://ntrs.nasa.gov/api/citations/20170000385/downloads/20170000385.pdf
44. The Black-Box Simplex Architecture for Runtime Assurance of Multi-Agent CPS - Stanley Bak, https://stanleybak.com/papers/sheikhi2024isse.pdf
45. A Component-Based Simplex Architecture for High-Assurance Cyber-Physical Systems - arXiv, https://arxiv.org/pdf/1704.04759
46. A Survey: ZTA Adoption in Cross-Domain Solutions—Seven-Pillar Perspective - MDPI, https://www.mdpi.com/2079-9292/15/3/563
47. Command & Control Systems Platform and Infrastructure Engineer job in Hampton at Booz Allen Hamilton | Lensa, https://lensa.com/job-v1/booz-allen-hamilton/hampton-va/infrastructure-engineer/0159367e2f12d137f1f03410f3795702
48. GitHub - iakat/stars: iakat/stars - An awesome list of my starred repositories, https://github.com/iakat/stars
49. How Packet-Derived Telemetry Feeds the Zero Trust Architecture, https://aviznetworks.com/resources/guides/how-packet-derived-telemetry-feeds-zero-trust-architecture-nist-defines/download
50. Data Provenance: Definition & Standards - CASRAI, https://casrai.org/guides/data-provenance
51. 5. Provenance information - FAIR Cookbook, https://faircookbook.elixir-europe.org/content/recipes/reusability/provenance.html
52. Mitigating Risks at the Intersection of Artificial Intelligence and Chemical and Biological Weapons - RAND Corporation, https://www.rand.org/content/dam/rand/pubs/research_reports/RRA2900/RRA2990-1/RAND_RRA2990-1.pdf
53. DoD Directives - Executive Services Directorate, https://www.esd.whs.mil/Directives/issuances/dodd/
54. Operational Law Handbook > Chapter 6: NATIONAL SECURITY STRUCTURE & JOINT OPERATIONS - The Judge Advocate General’s Legal Center and School, https://tjaglcs.army.mil/Periodicals/Deskbooks-Handbooks/Operational-Law-Handbook?topic=Chapter+6%3A+NATIONAL+SECURITY+STRUCTURE+%26+JOINT+OPERATIONS
55. The 90-Second War: What Venezuela and Iran Mean for Every ADF Professional | The Cove, https://cove.army.gov.au/article/90-second-war-what-venezuela-and-iran-mean-every-adf-professional
56. autonomous weapon systems under international law by berkant akkus a thesis submitted to aberystwyth - PURE, https://pure.aber.ac.uk/ws/portalfiles/portal/43654324/Akkus_Berkant.pdf
57. The Death of Static Identity. Why AI Agents Break Everything You, https://medium.com/@nelsonsema82/the-death-of-static-identity-d5d221892ec8