How evidence, uncertainty, and simulation are kept separate

Claim states

Every important statement belongs to a category.

Source hierarchy

Primary sources answer some questions well and others poorly.

Official policies are strong evidence for what an institution publicly requires. Program offices are strong evidence for a program’s public purpose and status. Manufacturer pages establish product claims. They do not independently prove combat performance, operator practice, accuracy, reliability, or the absence of undisclosed modes.

1. Official law, policy, doctrine, standards, procurement records, and program descriptions.
2. Manufacturer-controlled technical material, clearly labeled as a supplier claim.
3. Independent research and legal analysis from institutions with transparent methods.
4. High-quality reporting with named documents, interviews, imagery, or multiple corroborating sources.
5. Secondary summaries used only for orientation or where stronger material is unavailable.

Source quality is multidimensional. A primary source can be authoritative about policy yet self-interested about performance. A secondary source can be independent but mistaken. The site therefore labels source class and preserves unknowns rather than assigning one universal credibility score.

Country and system analysis

Signals are not treated as proof of deployed lethal autonomy.

For every country or system, the analysis asks:

• Which exact function is described: sensing, fusion, recognition, ranking, navigation, guidance, target-profile matching, or engagement?
• Who made the claim, on what date, and about which version or configuration?
• Is the evidence policy, procurement, demonstration, operational use, manufacturer marketing, independent analysis, or allegation?
• What human action is required before force, and what intervention remains possible after activation?
• What target class, area, time, communications state, and mission bounds apply?
• What is unknown, classified, proprietary, disputed, or likely to vary by operator?

Evidence Atlas method

The map is an evidentiary interface, not a live operational picture.

The Atlas connects ten layers: country or alliance, doctrine and policy, system or program, kill-chain function, human control, deployment status, evidence and confidence, timeline, legal and governance context, and source. A record is useful only when those layers remain connected; a system name without the source, configuration, authority arrangement, date, and unknowns can create false certainty.

Thirteen evidence states keep materially different kinds of information from looking equivalent. Officially documented, court/treaty-recorded, and independently corroborated material receive stronger visual treatments. Manufacturer descriptions, operator accounts, and credible reporting remain attributed. Alleged, disputed, operationally unspecified, control-mode unspecified, AI-not-established, and outdated material remain visibly qualified.

The country map uses editorial layout percentages inside an abstract world illustration. Those values are not latitude or longitude, do not identify bases or deployments, and are never presented as tactical geography. The synchronized table contains the same public records for keyboard, screen-reader, low-motion, print, and no-JavaScript use.

Filters and comparisons operate on a read-only presentation copy of the curated PHP dataset. URL values are accepted only when they match released record IDs or taxonomy values. A comparison exposes functions, human control, lifecycle, evidence, source count, limitations, and review date; it does not calculate a capability, lethality, legality, or national-performance score.

Simulation method

Semantic events are the product; visual effects are derived.

Each scenario is a declarative directed graph containing stages, safe descriptive text, synthetic spatial coordinates, connections, and interruption controls. It contains no scripts, executable payloads, external target data, real coordinates, weapon-performance equations, casualty assumptions, or arbitrary URLs.

The PHP service stores an authoritative per-session state:

scenario + current stage + enabled controls + interrupted/completed state
+ monotonic sequence + append-only recent event log

The open analysis sandbox accepts four allowlisted intents: advance, back, reset, and toggle_control. The daily challenge has a separate allowlist for mode selection, evidence inspection, hypothesis and confidence submission, defensive-control selection, resolution, debrief, rewind, and counterfactual comparison. Neither API accepts arbitrary state, scripts, URLs, or executable content.

Every state-changing command carries the challenge or scenario identifier, deterministic seed where applicable, a CSRF token, and the expected monotonic sequence. A mismatch returns HTTP 409 with the authoritative snapshot rather than accepting the client’s claim.

Stage progress and control coverage are interface metrics only. They are not probability of success, expected harm, legality, combat effectiveness, or a performance model.

Technical architecture

Shared-host baseline with progressive immersion

• PHP 8.2 or later: sessions, validation, CSRF, sequence checks, rate limits, content delivery, and secure headers.
• Three.js r185: a pinned WebGL scene with spatial nodes, labels, particles, raycasting, and WebXR controller input.
• Canvas fallback: the same semantic state rendered in two dimensions if Three.js, WebGL, WebXR, a headset, or the module CDN is unavailable.
• Daily deterministic challenge: a date or shared seed selects an equivalent scenario layout, while PHP remains authoritative for evidence, decisions, scores, debrief state, and replay selection.
• Evidence Atlas: PHP renders the curated records and an escaped JSON presentation copy; local JavaScript applies allowlisted filters, comparison, timeline, explainers, and saved-view URL state without a state-changing API or remote map service.
• No database: release 1.2.1 stores no user accounts or server-side long-term learner telemetry. Authoritative run state uses the host’s normal PHP session mechanism; optional learning history remains in the visitor’s browser only.
• No daemon required: asynchronous fetch() commands work on ordinary PHP hosting. An SSE example is present but disabled by default.
• HTTPS for immersive mode: WebXR normally requires a secure context; desktop and 2D modes remain available without headset support.

Non-operational boundary

The public simulator cannot act on the outside world.

Non-negotiable controls in this release:

• No simulation target entry, exact operational coordinates, live units, vulnerable infrastructure, or personal target data. Public research pages may name countries, institutions, programs, and systems only with evidence labels and source attribution.
• No weapon selection, performance parameters, trajectories, yields, timing optimization, or casualty estimates.
• No executable malware, exploit code, credential material, command-and-control endpoints, arbitrary commands, or arbitrary URLs.
• No uploads, user-authored scenarios, external model loading, remote textures, live map feeds, geocoding, or cyber-range integration.
• No headset pose, hand, gaze, voice, room, or server-side learner-performance telemetry. The challenge may keep an explicitly local completion summary in browser storage; it is never transmitted by this release.
• No AI model determines whether an event exists, whether a visual effect appears, how numeric state changes, or what evidence state an Atlas record receives.

These boundaries make the site useful for conceptual instruction, architecture review, and public literacy without becoming a planning or attack-execution tool.

Versioning and review

Code and content are versioned together.

Release 1.2.1 was published on 2026-07-31 and reviewed through 2026-07-31. The release ZIP, checksum, VERSION file, CHANGELOG, source library, scenario definitions, and dependency notices form one reproducible publication unit.

Future material changes should increment semantic versioning:

• Patch: corrections, accessibility fixes, and compatible hardening.
• Minor: new pages, new synthetic scenarios, or backward-compatible features.
• Major: incompatible scenario/API changes, identity changes, or a substantially different hosting model.

Corrections

What a useful correction contains

Corrections should identify the exact page and claim, provide a stronger source or explain the methodological problem, distinguish factual correction from interpretive disagreement, and state whether the issue affects other pages or simulation labels. The configured contact is editor@killchains.com.

Security issues should follow the process in SECURITY.md and should not include testing against third-party systems.