Synthetic Kill Web Simulator Requirements and Architecture Specification

1. Simulator Requirements Specification

1.1 Architectural Philosophy and Abstract Constraints

The transition from traditional, linear operational sequences to dynamically composable, distributed architectures represents a fundamental paradigm shift in systems engineering. While legacy constructs operate on sequential dependencies—often modeled as rigid chains—modern distributed networks function as complex adaptive systems, commonly referred to as “webs”1. The objective of this specification is to define the rigorous architectural, mathematical, and data-schema requirements for a public, synthetic digital twin simulator representing these autonomous functions.
The core imperative of this simulator is to demonstrate how distributed, time-varying networks compose, degrade, recover, and remain bounded by strict human and systemic authority. To maintain absolute pedagogical safety and public boundaries, the simulator is mathematically and structurally prohibited from modeling actual targets, physical weapons, specific platforms, battlefields, military units, current operations, real geography, coordinate systems, physical ranges, payloads, sensor signatures, engagement thresholds, or classified capabilities. Instead, the system models a network purely as a dynamic, time-varying directed graph. Nodes represent abstract functional roles, edges represent constrained relationships, and data payloads represent mathematically arbitrary topological states.
The primary educational output of this engine is the deep analysis of network resilience, causality, distributed consensus, and authorization boundaries rather than tactical efficacy. The system does not calculate probability of success, target metrics, or operational optimization. Instead, it visualizes the mathematical friction of distributed systems operating under the constraints of the CAP theorem (Consistency, Availability, Partition Tolerance) during simulated adversarial or environmental degradation2.

1.2 Path Distinction and Orthogonal Graph Metrics

A foundational requirement of this simulation engine is the absolute prohibition of collapsing network states into a single, unified “readiness” or “health” score. In complex adaptive systems and distributed authority networks, connectivity does not imply trust, trust does not imply authority, and authority does not imply situational permission3. The simulator must algorithmically evaluate and visually distinguish four distinct types of network paths, calculated sequentially as subsets of one another. These paths form the core ontology of the simulation’s state engine.
The Technically Connected Path () A technically connected path exists if a topological route can be mathematically traced from a designated origin node to a terminal node across edges that support physical or logical data transmission. evaluates purely on technical compatibility, network partitioning, and physical hardware availability. It abstracts the underlying transport layer. The existence of simply answers the question: Can a packet theoretically propagate from Node A to Node B?
The Trusted Path () A trusted path is a strict subset of (). An edge only exists in if the technically connected link successfully passes cryptographic identity verification, evidence provenance checks, and data-semantic compatibility requirements. If Node A can successfully ping Node B, but Node B lacks the correct cryptographic signature or its data payload is malformed according to the semantic schema, the path is connected but untrusted. It answers the question: Is the data moving between Node A and Node B verifiable, cryptographically sound, and structurally interpretable?
The Authorized Path () An authorized path is a strict subset of (). An edge exists in only if the systemic rules, configuration registries, and automated authority gates explicitly grant permission for a specific mission thread to traverse that link. A path may be technically connected and perfectly trusted (cryptographically secure), yet mathematically unauthorized if the current configuration version, multi-attribute utility policy, or dependency domain restricts its use5. It answers the question: Does the systemic policy allow Node A to utilize Node B for this specific abstract task?
The Permissible Path () A permissible path is a strict subset of (). It represents the final, executable state of the network. An edge exists in only if all environmental, temporal, and human-in-the-loop constraints are currently satisfied. This includes checks for data freshness, maximum acceptable latency, and the explicit absence of human-supervision abstention, quarantine, or safe-hold states. A path may be authorized by systemic policy, but if the evidence age exceeds the latency threshold or the human supervisor has placed a temporary cognitive hold on the terminal node, the path is impermissible. It answers the question: Given the immediate temporal context and human supervisory state, is this action allowed to execute exactly at this logical tick?

1.3 Abstract Node Classes

The simulator represents the digital twin as a time-varying graph populated by fourteen abstract node classes. Each node class possesses distinct internal state machines, failure domains, memory limits, and recovery behaviors.
1. Observation Source: An abstract generator of dimensional data. It does not model sensors such as radar or optics. It simply injects localized, mathematically arbitrary state vectors into the graph, bounded by a specified evidence quality parameter and a freshness timestamp.
2. Time and Synchronization Service: Provides the baseline for logical and vector clocks6. In distributed systems where physical time is skewed by latency, this node facilitates the tracking of causality across the network, ensuring that sequence vectors append correctly to the state ledger.
3. Translation Gateway: Serves as a semantic bridge, converting payloads between different configuration versions or schema formats (e.g., converting legacy JSON structures into ontology-based JSON-LD via RML mappings)8. It heals paths that fail due to schema drift.
4. State-Estimation Service: Consumes raw dimensional data from Observation Sources and utilizes abstract filtering algorithms to produce a unified, probabilistic estimate of a fictional entity’s coordinates in a dimensionless space.
5. Evidence and Provenance Service: A cryptographic ledger node that appends historical metadata to state estimates. It ensures that the lineage of data—recording exactly which nodes contributed to an estimate—is preserved, verifiable, and immutable10.
6. Communications Relay: A purely topological node that extends the reach of . It possesses quantifiable metrics for channel capacity and availability but performs no data mutation or cryptographic validation.
7. Edge-Compute Node: A constrained processing environment that can temporarily take over state-estimation or semantic translation tasks if the broader network partitions. It represents the delegation of compute to the physical extremes of the graph.
8. Mission Coordinator: An algorithmic node that evaluates multiple abstract mission threads. Utilizing logic akin to non-dominated sorting algorithms, it proposes optimal topological routes through the graph based on available paths, managing race conditions and duplicate tasking11.
9. Authority Gate: A deterministic policy enforcement point. It reads the Audit Ledger and Configuration Registry to either grant or deny status to a proposed mission thread based on predefined boolean logic.
10. Human-Supervision Node: Represents the asynchronous, non-deterministic human-in-the-loop. It acts as a cognitive bottleneck, injecting stochastic delays (operator overload) and asserting overriding policy commands such as safe hold, quarantine, or return of control.
11. Bounded Task Executor: The terminal node in a mission thread. It requires a complete, unbroken path to transition from a “standby” to an “executed” state. It does not model physical weapons, payloads, or kinetic effects.
12. Assessment and Recovery Service: An autonomous diagnostic node that monitors the graph for state contradictions, vector clock anomalies, and node failures. It initiates automated reconciliation protocols, such as merging divergent state ledgers after a network partition heals.
13. Update and Configuration Registry: The central, version-controlled repository for semantic schemas (e.g., DTDL v3 definitions) and node identity keys12. It dictates the rules of engagement required for .
14. Audit Ledger: An immutable, append-only data structure (simulating a directed acyclic graph) that records all state transitions, authority grants, and human supervisions for post-mission forensic analysis and causality verification2.

1.4 Educational Simulation Outputs

The simulator is designed to output complex metrics that illustrate the friction of system-of-systems engineering3. The engine must continuously calculate and display the following outputs across the time-varying graph:

• Number of Technically Viable Paths: The raw count of routes from an Observation Source to a Bounded Task Executor.
• Number of Trusted Paths: The count of routes, highlighting the drop-off caused by cryptographic or semantic failures.
• Number of Authorized Paths: The count of routes, indicating how policy constraints limit technical capability.
• Shared Dependencies: Nodes that appear in more than a configurable percentage (e.g., 50%) of available paths, visually highlighting architectural bottlenecks.
• Single Points of Failure: Nodes whose removal analytically reduces the number of paths to zero.
• Evidence Age: The delta between the current logical clock tick and the timestamp of the oldest data packet required for a current state estimate.
• Unresolved Contradictions: The number of nodes currently holding divergent state estimates due to network partitioning, often resulting in split-brain scenarios2.
• Required Human Reviews: The queue depth of the Human-Supervision Node, demonstrating cognitive overload and latency injection.
• Recovery Steps: The algorithmic sequence required to heal a disrupted path, exported as semantic text.
• Residual Unknowns: Variables in the abstract state-estimation matrix that currently lack sufficient provenance or data density.

2. Synthetic Graph-Data Schema

2.1 JSON-LD and DTDL v3 Foundations

The synthetic graph-data schema must be constructed upon the Digital Twins Definition Language (DTDL) v3, which is natively based on JSON-LD and the Resource Description Framework (RDF)15. This format is mandated because it ensures semantic interoperability, allows for complex recursive schemas (such as Arrays, Maps, Enums, and Objects), and seamlessly handles property historization13. By utilizing the context identifier dtmi:dtdl:context;3, the schema natively supports the graph traversal algorithms required to calculate the nested path types12.
Unlike traditional relational schemas or intermediate mapping layers, employing a native JSON-LD approach allows the simulator to define the network as a Semantic Web ontology. This prevents schema drift—a failure mode where a translation layer’s internal triple schema evolves independently from the application’s context, leading to broken queries and lost provenance10. By operating natively in JSON-LD, machines and the simulator’s logic engine can unambiguously interpret the capabilities, constraints, and state of every node directly from the payload18.

2.2 Schema Definitions and Properties

The graph consists of Node Interfaces and Relationship Edges. The schema requires the explicit definition of highly specific operational attributes that dictate the flow of the network.

2.2.1 Technical Compatibility and Capacity

For to exist, the underlying properties of the nodes and edges must align.

• Technical Compatibility: A boolean flag on an edge indicating that the physical/virtual transport layer is functional. If an event injects a network partition, this flag switches to false.
• Capacity: An integer property on nodes (particularly Communications Relays and Human-Supervision Nodes) defining the maximum throughput of abstract tasks they can process per tick. Exceeding capacity results in exponential latency increases.
• Availability: A floating-point metric (0.0 to 1.0) representing the uptime probability of a node, used by the Mission Coordinator to calculate preferred routing paths.

2.2.2 Data-Semantic Compatibility and Configuration Version

For a path to achieve , nodes must understand each other.

• Configuration Version: An integer tracking the semantic version of a node’s internal logic.
• Data-Semantic Compatibility: If Node A operates on DTDL schema version 4 and Node B on version 3, the semantic compatibility fails unless a Translation Gateway is present in the path to execute an RML mapping8. This property prevents malformed data from triggering unintended actions.

2.2.3 Identity, Trust, and Evidence Quality

Cryptographic assurance is the second pillar of .

• Identity: A cryptographic hash representing the node’s verifiable identity, issued by the Update and Configuration Registry.
• Trust Score: A dynamic floating-point value reflecting historical reliability and signature verification.
• Evidence Quality: A metadata tag (float 0.0 to 1.0) appended by the Evidence Service, denoting the statistical confidence in the dimensional data traversing the edge. Low evidence quality may prevent a path from achieving depending on the policy matrix.

2.2.4 Authority, Permitted Use, and Dependency Domains

Policy and context dictate and .

• Authority Level: An Enum (None, Standby, Granted, Expired) injected by Authority Gates.
• Permitted Use: A dynamic boolean flag toggled by automated rules of engagement or explicitly by Human-Supervision nodes.
• Dependency and Failure Domain: A string identifying the logical or physical partition to which the node belongs (e.g., Domain_Alpha). This allows the simulator to execute cascading failures where taking down a specific failure domain logically orphans all dependent nodes.
• Recovery and Reconciliation State: An Enum (Optimal, Degraded, Reconciling, Quarantined, Offline) that dictates how a node behaves after a failure event. A node in Reconciling state may accept data but will not forward it until its vector clock merges successfully.

2.2.5 Directed and Undirected Relationship Types

Relationships in DTDL v3 define the edges of the time-varying graph. The schema implements specific edge classes to govern data flow:

3. Deterministic Scenario Schema

To ensure that the simulator serves as a robust educational and verification tool rather than a random noise generator, scenarios must be perfectly deterministic. A deterministic scenario guarantees that given the same initial state, graph topology, and random seed, the progression of the time-varying graph—including all simulated failures, human delays, and automated recoveries—will execute identically across all client environments, regardless of CPU speed or rendering framerate.
A scenario is loaded into the engine via a JSON document conforming to a strict schema. The document contains three primary arrays:

1. InitialGraph: An array of DTDL digital twin instances (nodes) and their initial relationships (edges) at logical tick . This establishes the baseline topology.
2. EventTimeline: An array of predefined, chronologically ordered mutations. Each event specifies an exact logical tick, a targetNode or targetEdge DTMI, and a mutationType (e.g., InjectPartition, DowngradeCapacity, SimulateNodeCompromise).
3. StochasticParameters: Parameters that guide the pseudo-random number generator (PRNG) for simulating emergent phenomena, such as humanResponseDelayVariance, packetLossProbability, or sensorJitter.

By decoupling the deterministic event timeline from the stochastic parameters (which are immutably tied to a fixed seed), the simulator can replicate highly complex “butterfly effect” cascading failures predictably.

4. Reproducible Random-Seed Policy

Because the simulator operates locally in the browser and must support offline execution and precise verification (see Sections 12 and 15), relying on true environmental randomness (like user mouse movements or system clock micro-variations) is strictly prohibited. The simulator implements a deterministic Pseudo-Random Number Generator (PRNG), utilizing the robust Xoshiro256 algorithm, seeded precisely at the initialization of the scenario.

• Initial Seed Generation: When a user initializes a scenario, the engine generates a 256-bit hexadecimal seed (e.g., 0x4F8A9C…) using the browser’s crypto.getRandomValues() if starting a novel session, or accepts a user-pasted seed string for exact reproduction.
• Seed Isolation: The PRNG is strictly isolated from the UI rendering thread. It is exclusively owned by the simulation engine’s core logic loop. This ensures that UI lag or dropped animation frames do not misalign the random sequence.
• Deterministic Branching: When the graph forks—such as when a network partition creates two isolated sub-graphs—the PRNG state must be mathematically branched to prevent race conditions. The engine uses a cryptographic hash of the current seed and the node’s DTMI to generate a new, deterministic sub-seed for the partitioned domain. This ensures that even if the order of node processing changes slightly in a multi-threaded WebWorker environment, the random events applied to specific nodes remain strictly identical across re-runs.

5. Simulation Clock and Event Model

In a distributed, geographically dispersed network, physical time is an inherently unreliable metric due to network delays, clock drift, and isolated failure domains. Therefore, the simulator relies on a discrete logical clocking mechanism to track causality, enforce consistency, and drive state progression6.

5.1 Vector Clocks, Causality, and the CAP Theorem

The simulation clock is advanced using a discrete tick system, but state estimation, data provenance, and conflict resolution rely entirely on Vector Clocks to maintain causal consistency2. The architecture explicitly models the tradeoffs of the CAP theorem (Consistency, Availability, Partition Tolerance), prioritizing availability during partitions but utilizing vector clocks to force eventual consistency during reconciliation2.
A vector clock for a node in a graph of nodes is a vector of integers .

• When undergoes an internal state transition, it increments its own counter: .
• When sends a payload to , it appends its current vector clock to the message.
• When receives the message, it updates its own vector clock by taking the element-wise maximum: , and then increments its own counter 7.

This mathematical model allows the Assessment and Recovery Service to accurately detect concurrent, conflicting events. If a network partition occurs and an Edge-Compute Node updates a state estimate simultaneously with a Mission Coordinator, their vector clocks will diverge—meaning neither vector will be strictly greater than the other across all indices. The simulator uses this mathematical divergence to flag Conflicting State Estimates and initiate reconciliation protocols.

5.2 The Event Loop

The simulation executes a non-blocking event loop tightly decoupled from the rendering framerate. During each discrete tick, the engine sequentially performs the following phases:

1. Event Ingestion: The engine reads and processes deterministic events from the Scenario Schema slated for the current tick.
2. State Mutation: Nodes process their internal logic (e.g., Authority Gates evaluate boolean policies against the schema).
3. Message Passing: Data payloads are pushed across available edges, utilizing sloppy quorums and hinted handoffs if primary target nodes are unresponsive20.
4. Path Evaluation: The graph recalculates the availability of , , , and for all abstract mission threads using an graph traversal algorithm.
5. Ledger Commit: The current state vector of the entire graph is hashed and appended to the State-Transition Ledger.

6. State-Transition Ledger

The Audit Ledger node models a distributed, append-only log that enforces the immutability of the network’s history and preserves strict provenance2. In the simulator, the State-Transition Ledger is an in-memory data structure functioning as a Merkle-linked hash chain.

• Block Structure: Each transition block contains the logical tick, an array of state mutations (e.g., “Node A changed status from Optimal to Quarantined”), the aggregated vector clock state of the graph, and the SHA-256 hash of the previous block.
• Reconciliation State: Following a network partition, isolated domains will independently accept writes, generating divergent ledger forks (split-brain). When the physical network heals (re-establishing ), the Assessment and Recovery Service node reads the divergent ledgers. It applies a deterministic conflict-resolution algorithm to merge the ledgers into a reconciled state6. If the data is purely commutative, it automatically merges; if the data is conflicting (e.g., contradictory coordinate estimations), it requires a human-in-the-loop escalation.

7. Fictional Failure and Recovery Scenarios

The simulator must ship with a minimum of twelve meticulously crafted, deterministic scenarios designed to demonstrate how the dynamic graph degrades, recovers, and maintains authority. These scenarios manipulate the complex transitions between , , , and .
Scenario 1: Network Partitions and Failed State Reconciliation

• Trigger: A catastrophic failure of a central Communications Relay severs between Domain A (Observation and Edge-Compute) and Domain B (Authority Gate and Mission Coordinator).
• Degradation: The graph splits. Domain A continues generating state estimates but lacks the Authority Gate to transition paths to . Domain B has authority but its data freshness rapidly decays. Upon network healing, the two domains present mutually exclusive state ledgers. The automated reconciliation algorithm fails because the vector clocks are irreconcilably divergent without a tie-breaker.
• Recovery: The Assessment and Recovery Service places the network into a Safe Hold, routing the divergent ledgers to the Human-Supervision Node for manual deconfliction. Only after human selection does the ledger merge and paths restore7.

Scenario 2: Relay Failure and Alternative Mission Threads

• Trigger: A high-capacity Communications Relay goes offline abruptly.
• Degradation: The preferred mission thread loses status.
• Recovery: The Mission Coordinator’s routing algorithm dynamically recalculates alternatives. Data is rerouted through a secondary, lower-capacity relay, activating an alternative mission thread. Latency increases significantly due to capacity constraints, pushing the path near the boundaries of , but connectivity is maintained.

Scenario 3: Stale Observations and Latency Breaches

• Trigger: An Observation Source experiences severe bandwidth throttling, dropping its transmission rate.
• Degradation: The state-estimation node continues functioning, but the freshness property of the data decays beyond the acceptable threshold defined in the DTDL schema. The path remains (authorized by policy) but drops out of because the data is deemed too old for permissible execution.
• Recovery: The Mission Coordinator instructs the Edge-Compute node to apply predictive algorithms to the stale data, artificially inflating the evidence quality until fresh observations resume, temporarily restoring under a “Degraded” flag.

Scenario 4: Clock Drift and Vector Divergence

• Trigger: The Time and Synchronization Service undergoes a Byzantine failure, broadcasting erratic logical timestamps to a subset of nodes.
• Degradation: Vector clocks become wildly skewed. The Evidence and Provenance Service rejects payloads because their vector indices appear to originate from the future, destroying .
• Recovery: The Assessment node detects the temporal anomaly (vector clock inconsistencies), quarantines the primary Time Service, and promotes a secondary node to master clock status, forcing a network-wide clock sync.

Scenario 5: Lost Provenance and Node Compromise

• Trigger: A simulated cyber-intrusion alerts the Update and Configuration Registry that an Edge-Compute node’s cryptographic keys have been compromised.
• Degradation: The Registry revokes the node’s identity. Simultaneously, all historical data originating from that node loses its provenance. Instantly, any paths traversing this node drop from down to . The network is physically connected but mathematically untrusted.
• Recovery: The Assessment and Recovery Service flags the node with a Quarantined recovery state and forces the Mission Coordinator to calculate a novel route bypassing the compromised hardware, ensuring is rebuilt from clean nodes.

Scenario 6: Conflicting State Estimates

• Trigger: Following a temporary micro-partition, two redundant State-Estimation Services produce conflicting coordinate arrays for the same abstract entity.
• Degradation: The Mission Coordinator receives two identical mission threads with valid but conflicting payloads. The path halts at , refusing to transition to due to logical ambiguity.
• Recovery: The system routes the contradiction to a Human-Supervision Node. The operator selects the correct state estimate, updating the vector clock to supersede the conflict.

Scenario 7: Unsigned Updates and Trust Boundaries

• Trigger: A Translation Gateway attempts to push an unverified firmware update to a Bounded Task Executor.
• Degradation: The Evidence and Provenance Service detects the lack of a cryptographic signature on the payload. The link is technically connected () but violently rejected for trust ( fails).
• Recovery: The Authority Gate logs a security violation in the Audit Ledger, severs the edge to the Translation Gateway entirely, and reverts the Task Executor to its last known good configuration state.

Scenario 8: Mixed Model Versions and Semantic Drift

• Trigger: Half of the network is upgraded to DTDL Schema version 4, while the other half remains on version 3.
• Degradation: When a v4 Observation Source sends data to a v3 State-Estimation Service, the dataSemanticCompatibility check fails. The JSON-LD parser throws a context error due to unrecognized vocabulary13. The path loses .
• Recovery: A Translation Gateway is dynamically injected into the path. It maps the v4 JSON-LD output back to v3 RDF triples, restoring semantic compatibility and healing 8.

Scenario 9: Duplicate Task Ownership

• Trigger: During a hinted handoff event triggered by extreme latency20, two Mission Coordinators simultaneously claim ownership of the same abstract execution task.
• Degradation: The Authority Gate detects a race condition. If both paths were granted , the Bounded Task Executor would fire twice, violating strict policy.
• Recovery: The Authority Gate utilizes a deterministic tie-breaker (e.g., selecting the Coordinator with the lower DTMI value) to grant to one path and issue a forced stand-down command to the other.

Scenario 10: Expired Authority

• Trigger: The Authority Gate grants a 30-tick authorization window for a specific mission thread.
• Degradation: Due to severe network congestion, the packet does not reach the Bounded Task Executor until tick 32. The edge property authorityLevel downgrades to Expired. The path loses and cannot proceed to .
• Recovery: The Mission Coordinator must initiate a new request to the Authority Gate, submitting updated state estimates to secure a fresh authorization token.

Scenario 11: Human-Supervision Loss, Abstention, and Safe Hold

• Trigger: A required Human-Supervision node disconnects due to a localized network failure, placing all supervised edges into an “Abstention” state.
• Degradation: The rules of engagement mandate explicit human oversight. Without it, the permittedUse flag is set to false. Paths halt at and cannot achieve . The system enters a Safe Hold.
• Recovery: The system waits for a defined timeout period. If the human does not return, the system triggers a Return of Control protocol, elevating the authority requirement to a higher-echelon automated policy node, or abandoning the thread entirely if policy dictates.

Scenario 12: Operator Overload

• Trigger: 50 distinct abstract tasks simultaneously route to a single Human-Supervision Node for review.
• Degradation: The human operator has a defined cognitive capacity of 5 tasks per tick. The queue overflows. Latency spikes massively. Paths achieve but stall waiting for validation.
• Recovery: The Mission Coordinator algorithmically prunes low-priority threads, shifting them to alternate Human-Supervision nodes in different failure domains, balancing the cognitive load and re-establishing flow.

8. Expected Results for Each Scenario

For each scenario executed, the simulator’s logic engine guarantees the following educational outputs, clearly demonstrating the distinction between the four path types:

9. Renderer-Independent Presentation Model

The core architecture of the simulator mandates a strict, unyielding decoupling between the mathematical state engine and the graphical presentation layer. The Simulation Engine (the Model) operates entirely on headless data structures—calculating vector clocks, parsing DTDL schemas, calculating path traversals, and updating the ledger in an isolated memory space.
The Presentation Model acts solely as a ViewModel. Once per logical tick, the engine outputs a serialized JSON snapshot of the graph (Nodes, Edges, and Path Classifications). The rendering layer consumes this purely mathematical representation and maps it to visual components. This architecture guarantees that UI lag, rendering dropped frames, or browser hardware constraints have absolutely zero impact on the determinism and integrity of the simulation. If the renderer crashes or the browser tab stutters, the simulation continues advancing flawlessly in memory, preserving mathematical truth.

10. 2D, Optional 3D, and Semantic-Text Requirements

10.1 2D Visual Representation (Primary)

The default visualization is a 2D force-directed or hierarchical graph (e.g., utilizing D3.js or a lightweight WebGL equivalent).

• Nodes: Represented by abstract geometric primitives (e.g., hexagons for Authority Gates, circles for Observation Sources).
• Edges: Represented by dynamic splines or vectors.
• Path Distinction: The path types must be visually distinct without relying solely on color, accommodating colorblind users. For example: (solid gray line), (dashed blue line), (double solid purple line), (glowing animated green line with directional chevrons).

10.2 3D Visual Representation (Optional)

An optional WebGL/Three.js mode allows users to view the graph in three dimensions. This mode is explicitly used to map different Failure Domains to different Z-planes. By stacking the domains vertically, users can better visualize spatial network partitioning, topological depth, and the vulnerability of cross-domain relays.

10.3 Semantic-Text Requirements

For every visual state change, a corresponding, highly structured semantic text output must be generated in real-time. This takes the form of an active log detailing graph mutations in plain, unambiguous language. Example: “Tick 45: Communications Relay Beta has experienced a simulated failure. Path XYZ downgraded from Permissible to Trusted. Awaiting new Authority routing from Mission Coordinator.”

11. Accessibility Requirements

To ensure broad educational access and compliance with strict usability mandates, the simulator must adhere strictly to WCAG 2.1 AA standards and accommodate multiple accessibility needs, treating accessibility as a core engineering requirement rather than a cosmetic overlay.

• Keyboard Navigation: Users must be able to traverse the complex graph using only the keyboard. The Tab key will cycle focus through the nodes using a logical Depth-First Search (DFS) order based on current graph topology. Pressing Enter on a focused node opens a side panel detailing its properties (capacity, vector clock, recovery state, failure domain).
• Screen-Reader Support: The 2D SVG canvas must implement exhaustive WAI-ARIA roles. The parent SVG must have role=”graphics-document”22. Each node must be grouped in a \<g> tag with role=”graphics-symbol” and an aria-label describing its exact current state, updated dynamically (e.g., “Node, Human-Supervision, State: Overloaded, Queue Depth: 45”).
• Reduced Motion: If the user’s operating system specifies prefers-reduced-motion: reduce, all glowing edge animations, physics-based force-directed bouncing, and transition interpolations must be immediately disabled. The graph must render statically, snapping instantly between logical ticks.
• Print Requirements: Applying @media print CSS must completely reformat the application. It must hide all UI controls, background gradients, and animations, outputting a clean, high-contrast, black-and-white static snapshot of the current graph topology, followed by a tabular matrix of the State-Transition Ledger text.
• No-JavaScript Fallback: If JavaScript is disabled by the client, the server must provide a static HTML/CSS representation of the initial scenario state alongside explicit text explaining that JavaScript is required for active simulation execution.

12. Local-Only Progress and Export Requirements

The simulator is designed to be a zero-infrastructure, serverless web application that respects strict privacy constraints and operates seamlessly in completely disconnected or air-gapped environments23.

• State Persistence: Local progress is saved directly in the browser utilizing the asynchronous IndexedDB API. After every 10 logical ticks, the engine serializes the current graph state, the exact PRNG seed, and the State-Transition Ledger, committing it to an IndexedDB object store.
• Export Requirements: Utilizing the modern File System Access API, users can manually export the entire, exact state of the simulation as a .json payload23. This payload encapsulates the DTDL digital twin graph, the historical ledger, and the vector clock matrices.
• Resumption: A user can drag-and-drop an exported JSON file into the simulator on a completely different, disconnected machine. The engine will parse the payload, rehydrate the DTDL schema, re-seed the PRNG to the exact historical point, and resume the simulation identically where it left off. No user accounts, authentication tokens, or cloud syncing engines are required or permitted23.

13. Same-Origin API Contracts

To protect against cross-site request forgery (CSRF), malicious script injections, and unauthorized data exfiltration within the browser environment, the architecture enforces strict boundaries using Same-Origin policies and Cross-Origin Resource Sharing (CORS) configurations24.

13.1 WebWorker Isolation and PostMessage

The simulation logic engine runs entirely inside a dedicated WebWorker, rigidly isolated from the main Document Object Model (DOM) thread.

• The main thread (UI) and the WebWorker communicate exclusively via the postMessage API.
• The API contract dictates that the WebWorker only accepts specific, structured JSON command objects that conform to a strict schema (e.g., { type: “PAUSE”, payload: null }).
• The main thread validates the structural schema of the messages received from the worker before applying them to the view. This creates a secure, bidirectional sandbox preventing cross-contamination and preventing the DOM from interfering with the mathematical state26.

13.2 CORS, Iframes, and External Schemas

If the simulator allows importing custom scenario schemas or DTDL context extensions from external repositories (e.g., GitHub or a localized enterprise server), the application relies on strict CORS validation27.

• The application will only process fetch() requests for external JSON-LD definitions if the remote server explicitly returns Access-Control-Allow-Origin headers that match the simulator’s domain.
• To prevent ambient authority attacks or malicious iframe embedding (clickjacking), the application sets the X-Frame-Options: DENY HTTP header and uses standard SameSite=Strict policies for any local storage parameters24.

14. Performance Budgets for Mobile and Desktop

Given the mathematical intensity of calculating vector clocks, parsing nested JSON-LD schemas, and computing graph permutations every tick, strict performance budgets are enforced to maintain smooth operation across heterogeneous devices.

14.1 Desktop Budget

• Target Framerate: 60 FPS for rendering the UI and animating edges.
• Simulation Tick Rate: The logic engine must process a single scenario tick—including graph traversal, path classification for through , and ledger hashing for a 200-node graph—in under 16 milliseconds.
• Memory Limit: Maximum heap allocation of 256 MB. The engine must heavily optimize garbage collection, specifically reusing objects during JSON-LD parsing to prevent GC pauses that stutter the simulation.

14.2 Mobile Budget

• Target Framerate: 30 FPS.
• Simulation Tick Rate: The logic engine is allowed up to 33 milliseconds per tick. To achieve this on constrained ARM processors, the engine will batch DTDL validations, only verifying schema semantics during explicit state transitions (e.g., node recovery) rather than redundantly verifying on every tick.
• Memory Limit: Maximum heap allocation of 128 MB. The presentation model will automatically detect mobile constraints and drop to a simplified, low-fidelity rendering mode (removing complex SVG drop-shadow filters, disabling glowing animations, and reducing text label density) to preserve DOM performance and battery life.

15. Verification Plan: Provable State via WebAssembly

A critical risk in client-side simulation is the vulnerability of traditional JavaScript engines to floating-point mathematical discrepancies, varied browser implementations, or manual manipulation via browser developer tools. To guarantee that the educational outputs (especially the path availability calculations) match the authoritative design, the core mathematical engine is compiled to WebAssembly (WASM)30.

15.1 Deterministic WASM Execution and Security

The logic engine—comprising the graph traversal algorithms, DTDL schema validation, PRNG, and State-Transition Ledger—is written in a strictly typed systems language (e.g., Rust) and compiled to a .wasm binary31.

• State Encapsulation: The graph state lives exclusively within the linear memory buffer of the WASM module30. The JavaScript frontend is only permitted to read this buffer to render the screen; it cannot write to it directly.
• Verification Proof: At the conclusion of a scenario (or at any arbitrary tick), the WASM engine calculates a Merkle root of the State-Transition Ledger.
• Auditability: Because WASM provides a highly sandboxed, standardized, and perfectly deterministic execution environment regardless of the underlying operating system or browser architecture, an external auditor (or an automated CI/CD pipeline) can take the initial JSON scenario file and the random seed, and feed them into a headless WASM runtime on a secure server. The server will output an identical Merkle root, mathematically proving the fidelity of the simulation.
• Cryptojacking Prevention: While WASM is highly performant, it is frequently exploited for in-browser cryptomining33. To prevent the simulator from being hijacked or repurposed, the engine implements strict WASI (WebAssembly System Interface) cycle limits and monitors execution times. If the WASM module attempts to execute continuous, unyielding compute loops indicative of mining hashes rather than processing discrete graph ticks, the JavaScript wrapper will forcefully terminate the WebWorker and halt the simulation30.

16. Developer Backlog Ordered by Dependency

To build this architecture systematically, the engineering teams must execute the following product backlog in strict dependency order. Foundational elements (the math and data schemas) must be finalized, unit-tested, and verified before any presentation or accessibility layers are built.

• Epic 1: The Deterministic Engine (WASM Foundation)
• Task 1.1: Implement the Xoshiro256 PRNG, deterministic seed injection, and partition branching logic.
• Task 1.2: Build the core Time-Varying Graph data structures in Rust (Nodes, Edges, Adjacency Lists).
• Task 1.3: Implement the Vector Clock module for causal consistency tracking and conflict detection.
• Task 1.4: Build the State-Transition Ledger (append-only Merkle hash chain).
• Epic 2: Semantic Web and DTDL Schemas
• Task 2.1: Design the explicit DTDL v3 JSON-LD models for the 14 abstract Node Classes.
• Task 2.2: Design the DTDL relationships and attribute constraints (Freshness, Capacity, Identity).
• Task 2.3: Implement a lightweight, WASM-based JSON-LD validator for scenario ingestion that enforces schema compliance.
• Epic 3: Graph Pathing Algorithms (The Core Loop)
• Task 3.1: Implement the routing algorithm to calculate (Technical Compatibility).
• Task 3.2: Implement the cryptographic and semantic filter for (Trusted Path).
• Task 3.3: Implement the rules-engine filter for (Authorized Path).
• Task 3.4: Implement the temporal/supervision filter for (Permissible Path).
• Epic 4: Event Scenarios and Logic Hooks
• Task 4.1: Build the deterministic Event Timeline processor to ingest JSON scenario mutations.
• Task 4.2: Code the 12 specific failure/recovery scenario state machines (e.g., split-brain, human abstention, clock drift).
• Task 4.3: Develop exhaustive unit tests verifying the expected outputs for all 12 scenarios against the headless WASM engine.
• Epic 5: API Contracts and Storage
• Task 5.1: Establish the WebWorker isolation boundary and strict postMessage serialization protocols.
• Task 5.2: Implement IndexedDB state persistence and retrieval mechanisms.
• Task 5.3: Implement the File System Access API for local JSON export/import of state payloads.
• Epic 6: Presentation Model and UI
• Task 6.1: Develop the 2D layout engine (ViewModel mapper) to consume the headless WASM state.
• Task 6.2: Build the SVG/D3.js rendering layer, mapping the four path types to distinct visual styles.
• Task 6.3: Build the real-time Semantic Text output generator.
• Task 6.4: (Optional) Build the Three.js 3D visualization layer for Failure Domain stacking.
• Epic 7: Accessibility and Optimization
• Task 7.1: Implement exhaustive WAI-ARIA DOM mapping for screen readers across the SVG canvas.
• Task 7.2: Build the keyboard navigation DFS traversal logic.
• Task 7.3: Implement reduced-motion CSS constraints and high-contrast print stylesheets.
• Task 7.4: Conduct performance profiling and garbage collection optimization to strictly meet the 16ms/33ms tick budgets on target hardware.

Works cited

1. Probabilistic Models for Military Kill Chains - VTechWorks, https://vtechworks.lib.vt.edu/bitstreams/c555f683-a732-4b30-a1a3-2b980be4d020/download
2. Resolving CAP Through Automata-Theoretic Economic Design: A Unified Mathematical Framework for Real-Time Partition-Tolerant Systems - arXiv, https://arxiv.org/html/2507.02464v1
3. Systems of Systems Analytic Approaches - SEBoK, https://sebokwiki.org/wiki/Systems_of_Systems_Analytic_Approaches
4. Construction of kill webs with heterogeneous UAV swarms in dynamic contested environments, https://d-nb.info/1354579755/34
5. Advances in Mission Engineering Tools DARPA SAFE-SiM - C5I Center, https://c5i.gmu.edu/wp-content/uploads/Dan-MaxWell-C5I-Anniversary-2024.pdf
6. 5. Replication: weak consistency model protocols - Distributed systems for fun and profit - Mikito Takada, https://book.mixu.net/distsys/eventual.html
7. Data Consistency in Distributed Systems | by Mahantesh Ambali - Medium, https://medium.com/@mahantesh378/data-consistency-in-distributed-systems-b31c528a0338
8. MetaConfigurator: AI-Assisted RDF Authoring from JSON Data - arXiv, https://arxiv.org/html/2606.07094v2
9. “Just-in-time” generation of datasets by considering structured representations of given consent for GDPR compliance - PMC, https://pmc.ncbi.nlm.nih.gov/articles/PMC7327958/
10. Fluree in Production: Why JSON-LD Native Beats JSON-LD Compatible for Enterprise AI, https://flur.ee/blog/rdf-jsonld-production-enterprise
11. A Prospect-Theory-Based Operation Loop Decision-Making Method for Kill Web - MDPI, https://www.mdpi.com/2227-7390/10/19/3486
12. Creating a Digital Twin Model - Oracle Help Center, https://docs.oracle.com/en-us/iaas/Content/internet-of-things/create-digital-twin-model.htm
13. Digital Twins Definition Language (DTDL) updates - Microsoft Community Hub, https://techcommunity.microsoft.com/blog/iotblog/digital-twins-definition-language-dtdl-updates/3751705
14. Restoring Consistency after Network Partitions - ida.liu.se - Linköpings universitet, https://www.ida.liu.se/\~mikas34/lic/mikael_lic_070904.pdf
15. Review of Existing Tools for Software Implementation of Digital Twins in the Power Industry, https://www.mdpi.com/2411-5134/9/5/101
16. Azure/opendigitaltwins-dtdl: Digital Twins Definition Language - GitHub, https://github.com/Azure/opendigitaltwins-dtdl
17. Digital Twins Definition Language (DTDL) | opendigitaltwins-dtdl - Azure documentation, https://azure.github.io/opendigitaltwins-dtdl/DTDL/v3/DTDL.v3.html
18. LDkit: Linked Data Object Graph Mapping Toolkit for Web Applications - ISWC 2023, https://iswc2023.semanticweb.org/wp-content/uploads/2023/11/142660192.pdf
19. Understanding Digital Twin Models in OCI IoT Platform | cloud-infrastructure - Oracle Blogs, https://blogs.oracle.com/cloud-infrastructure/understanding-oci-iot-digital-twin-models
20. Understanding Amazon Dynamo: A Deep Dive into Distributed System Design, https://dev.to/piyushjajoo/understanding-amazon-dynamo-a-deep-dive-into-distributed-system-design-5a49
21. CAP Theorem in Practice (Structured Overview) | by Oleksandr, https://sysdespro.com/oleksandr-andrushchenko/cap-theorem-in-practice-structured-overview
22. Accessible SVGs - The University of Melbourne, https://www.unimelb.edu.au/accessibility/techniques/accessible-svgs
23. How are you persisting data in tiny personal apps? : r/react - Reddit, https://www.reddit.com/r/react/comments/1v7mkpr/how_are_you_persisting_data_in_tiny_personal_apps/
24. Web Security: an Overview of SOP, CORS, and CSRF - Mad Devs, https://maddevs.io/blog/web-security-an-overview-of-sop-cors-and-csrf/
25. Backend from First End Principles: Deepdive into HTTP | by Kavisha Mathur | Medium, https://medium.com/@KavishaMathur/backend-from-first-end-principles-deepdive-into-http-2d90b487f200
26. IFrames, CORS, and postMessage: Why This Still Feels Broken - Jay McBride, https://jaystechbites.com/posts/2026/iframes-cors-postmessage-why-this-still-feels-broken/
27. CWS/8/2 - WIPO, https://www.wipo.int/edocs/mdocs/cws/en/cws_8/cws_8_2.pdf
28. REST API: Cross-Origin Resource Sharing (CORS) - Broadcom TechDocs, https://techdocs.broadcom.com/us/en/ca-enterprise-software/business-management/clarity-project-and-portfolio-management-ppm-on-premise/16-4-2/reference/Clarity-REST-APIs/rest-api-cross-origin-resource-sharing-cors.html
29. Understanding The Web Security Model, Part IV: Cross-Origin Resource Sharing (CORS), https://educatedguesswork.org/posts/web-security-model-cors/
30. WebAssembly and Security: a review - arXiv, https://arxiv.org/html/2407.12297v1
31. WebAssembly and Security: a review - arXiv, https://arxiv.org/pdf/2407.12297
32. (PDF) WebAssembly and Security: a review - ResearchGate, https://www.researchgate.net/publication/382332042_WebAssembly_and_Security_a_review
33. SoK: Cryptojacking Malware - Cyber-Physical Systems Security Lab |, https://csl.fiu.edu/wp-content/uploads/2023/06/SoK_cryptojacking.pdf
34. SoK: Cryptojacking Malware | Request PDF - ResearchGate, https://www.researchgate.net/publication/349880356_SoK_Cryptojacking_Malware