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.

Source independence

Three documents can still represent one material source.

Corroboration depends on lineage, not document count. A news article, policy memo, and research brief may repeat the same manufacturer sentence, anonymous interview, official press release, or earlier secondary summary. The site traces the material proposition back to its earliest inspectable origin before counting sources as independent.

A source is treated as meaningfully independent only when it adds separately obtained evidence, such as a distinct official record, test document, authenticated image, court filing, technical measurement, or independently conducted analysis. Merely paraphrasing, syndicating, translating, or citing the same root claim does not create a new confirmation.

• Root source: the record from which the material proposition originates.
• Derivative source: a document that repeats or summarizes the root without adding separate evidence.
• Independent support: evidence created through a separate observation, record, method, or source relationship.
• Unresolved lineage: a source path that cannot be reconstructed confidently and therefore cannot be counted as independent corroboration.

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?

Technology-provider directory method

Companies are included for a bounded public role—not for reputation, market size, or sales claims.

The technology-provider directory covers organizations whose publicly documented products or services contribute to sensing, intelligence, tracking, command and control, decision support, defensive interception, autonomous mobility, resilient communications, space support, or cyber defense in real-world government or security operations.

Every company record identifies the public function, relevant kill-chain stages, representative technologies, a source-class label, operational evidence, a human-control boundary, unknowns, official links, and a review date. Official government or operator records are preferred for delivery, selection, fielding, and operational-use claims. Company pages establish what the provider says; they are not treated as independent proof of reliability, performance, safety, legality, or a specific operating mode.

The directory intentionally excludes prices, sales contacts, request-for-quote links, investment rankings, “best provider” scores, procurement recommendations, classified or sensitive program detail, technical employment procedures, and claims inferred only from branding. A company may appear in several functional categories because an integrated chain can span sensors, software, networks, and effectors.

• Inclusion is descriptive: it does not constitute endorsement, certification, approval, or a finding that every product is operational.
• Functions stay disaggregated: autonomous navigation, tracking, classification, and terminal guidance do not establish autonomous authority over force.
• Deployment remains configuration-specific: possession or delivery does not reveal which mode an operator enables in a named event.
• Unknowns remain visible: software versions, thresholds, permissions, intervention windows, and mission configurations are often proprietary or classified.
• External links are bounded: links point to official company, government, or operator sources and open in a separate browsing context.

Company-to-system relationship method

Relationships connect a provider to a named system or product family without turning association into proof of performance or authority.

The relationship explorer joins three separately owned records: a company from the provider directory, a bounded system or product-family record, and one or more source IDs from the public source registry. Every edge is typed as developer, manufacturer, integrator, software provider, sensor provider, or operator-support provider. The edge also records the relevant kill-chain functions, lifecycle state, evidence state, human-control boundary, public unknowns, review date, and a specific statement of what the relationship does not establish.

An association means only that reviewed public evidence supports the stated role. It does not establish that the provider controls the whole chain, that every customer uses the same configuration, that a named system uses machine learning, that a delivered product is currently operational, that manufacturer performance claims are independently verified, or that autonomous navigation, recognition, or tracking confers authority to use force.

• Subject identity is stable: each edge resolves to either a released Evidence Atlas system or a repository-owned product-family record with a durable identifier.
• Evidence remains attributed: government and operator records, manufacturer descriptions, independent analysis, demonstrations, allegations, and publicly unspecified facts retain different labels.
• Functions are not authority: Find, Fix, Track, Target, Engage, and Assess identify where a technology contributes; they do not reveal who authorizes force.
• Comparisons are descriptive: up to four selected relationships can be compared by role, lifecycle, evidence, function, source trail, human-control boundary, unknowns, and limitations. No overall score, ranking, buying recommendation, or investment judgment is produced.
• Interactive state is temporary: filtering and comparison run in page-local JavaScript and may be represented in an allowlisted query string. No account, database, persistent browser storage, analytics event, or server-side comparison record is created.

KillWebs.com sister-site method

First-party sister-site pages describe the publication—not independently verified military capability.

The KillWebs.com guide is built from a typed sister-site registry and eleven reviewed pages on the official KillWebs.com origin. Those pages establish how the sister site defines a kill web, describes its own routes and synthetic experiences, explains the relationship between a web and a selected chain, and publishes its evidence and safety policy.

Because the evidence is first-party, it is attributed as KillWebs.com’s public description. It does not independently prove a real program’s performance, deployment, interoperability, engagement authority, or legal adequacy. Observed release numbers, feature counts, runtime statements, and route inventories carry a review date and must be rechecked before they are reused as current facts.

• Once-only ecosystem owner: data/ecosystem.php owns the KillChains, KillWebs, and Evulgare identities, roles, routing rules, boundaries, and official origins. data/sister-sites.php remains a compatibility view for the KillWebs guide.
• Visible guide: /kill-webs/ compares the selected chain with the wider governed option space and preserves a direct source trail.
• Runtime boundary: KillChains.com does not iframe, proxy, execute, or fetch KillWebs.com content; visitors leave only after activating a normal HTTPS link.
• Claim boundary: a visible network edge is never treated as proof of compatibility, trust, availability, capacity, or authority.

Ecosystem and product-scope method

Public education, network research, and production accountability remain separate layers.

The ecosystem guide defines when a question belongs on KillChains.com, KillWebs.com, or Evulgare.com. KillChains owns public research and synthetic evidence-to-action learning. KillWebs owns public research and synthetic network-path resilience. Evulgare is the destination for real-system accountability software.

KillChains.com does not claim to capture production telemetry, model or software versions, live authority state, operator-visible evidence, or incident causality from a deployed system. The Machine Answerability and Accountability Handoff Lab demonstrates why those records matter and where the next question belongs; it is not the production evidence layer that preserves them.

Machine-speed action requires machine-held evidence. A final username and timestamp are not enough. Technical answerability requires a connected record of source evidence, transformations, exact model and software state, uncertainty, policy, authority, interface presentation, human judgment, action, outcome, and later invalidating changes.

The Machine Answerability Replay holds one fictional event and its ground truth fixed while progressively revealing chronology, provenance, authority, operator-view, software, configuration, assurance, and change-impact evidence. It demonstrates that evidence completeness changes the defensible explanation—not the historical event—and that causal contribution is not a blame percentage or legal verdict.

The Machine Answerability Remediation Lab preserves that fixed event and creates separate counterfactual branches. Safeguard effects are labeled as prevention, earlier detection, containment, recovery, answerability, no demonstrated effect, or unknown without more evidence. These labels are synthetic teaching classifications—not certification or product-performance claims.

• KillChains pointer: definitions, synthetic simulations, evidence classification, human control, public institutional analysis, source lineage, and accepted publication history.
• KillWebs pointer: distributed option spaces, path diversity, compatibility, trust, availability, common dependencies, graceful degradation, and controlled recomposition.
• Evulgare pointer: production evidence capture, version and model lineage, authority reconstruction, operator-view reconstruction, incident causality, auditability, and real-system answerability.
• No liability shortcut: the ecosystem does not turn a final human click into automatic blame, nor does it automatically exonerate a deployer, vendor, operator, designer, institution, or machine.

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.

Human Control Lab method

Human presence, machine function, and practical control are measured separately.

The Human Control Lab treats autonomy as a property of particular functions rather than a single label attached to a platform. Navigation, sensing, fusion, classification, ranking, authorization, engagement, supervision, abort, and assessment may be allocated differently. A public record that establishes one function does not establish the others.

Every real-world case card separates documented function, where the human role moves, assessed control mode, unknowns, and a “what this does not establish” boundary. Official and operator statements establish what those organizations publicly say; manufacturer descriptions remain manufacturer claims; independent analysis remains interpretation; disputed or absent evidence remains visibly qualified.

The six interactive modules use only synthetic teaching values. Their clocks, thresholds, confidence scores, objects, boundaries, bandwidth units, outcomes, and policy fingerprints are invented to expose trade-offs—not to estimate a real system. Model confidence, evidence quality, source independence, review time, comprehension, rejection authority, abort capability, and reversibility remain separate because one percentage cannot express meaningful control.

Human Control interactions stay in page-local JavaScript memory and reset on reload. The page has no state-changing API, account, persistent result, remote data loader, analytics event, or external action. Copy controls generate fixed text summaries only after explicit action.

Human Control replay method

Replay codes preserve a released decision architecture—not arbitrary page state.

The HC1 schema has one typed contract for each of the six Human Control modules. A code contains a version prefix, compact module type, fields in a fixed order, allowlisted values, and an eight-character integrity checksum. Unknown fields, duplicate fields, malformed values, unsupported prefixes, invalid checksums, oversized codes, and cross-field states outside a module’s released constraint fail closed to the module defaults.

Only bounded educational choices and result dimensions are serializable. Freeform text, identity, contact data, IP-derived location, raw timing, pose, gaze, voice, private notes, real targets or coordinates, weapon parameters, casualty values, and real-system performance claims are structurally absent from the registry. The page does not serialize arbitrary DOM state or hidden answers.

Encoding, decoding, comparison, accessible text, and the 1200×630 result image run in page-local JavaScript. The feature uses no result API, server write, persistent browser storage, cookie, analytics event, remote asset loader, or external action. A valid replay URL restores only released synthetic choices; an invalid code is rejected and removed from the displayed URL where browser permissions allow.

Query-state replay URLs remain shareable but are marked noindex,follow,noarchive and canonicalized to /human-control.php. The clean page remains session-free and publicly cacheable. One bounded alternative uses the same module contract for a counterfactual comparison; it does not claim that a real system would be deterministic.

Anticipatory Intelligence Lab method

The lab classifies analytical operations before evaluating their consequences.

The Anticipatory Intelligence Lab is derived from twenty-two newly supplied research reports: seventeen reports on predictive enforcement, watchlisting, traveler-risk analysis, behavioral threat assessment, and international policing practice, plus five reports proposing GAITE-like anticipatory-intelligence architectures, bias controls, federated data-sharing, and counterfactual testing. The reports remain preserved research inputs. Their current-status, legal, procurement, performance, and operational claims are not silently added to the public source registry.

The exercise separates ten operations: observation, identity resolution, correlation, place-time forecasting, physical-capacity forecasting, systemic-event forecasting, person-risk inference, machine-generated explanation, operational recommendation, and publicly unknown. The classification is descriptive. It does not declare that systemic forecasting is automatically accurate, lawful, proportionate, or ethically sufficient, and it does not treat every person-focused assessment as one technology.

The lab’s six synthetic modules expose different control problems:

• Analytical demarcation: identify what the system actually does and what it does not establish.
• Triage Trap: record an initial judgment before seeing machine confidence, then reveal filtered alternatives, contrary evidence, and source dependence.
• Explanation Laundering: compare fluent prose with a claim that can be reconstructed from evidence, lineage, contradictions, and unknowns.
• Structured Cognitive Loop: separate probabilistic Retrieval and Cognition from deterministic Control, bounded Action, and auditable Memory.
• Federated Intelligence Network: preserve local raw-data custody while showing that update exchange still creates privacy, poisoning, source-dependence, and accountability risks.
• Counterfactual Forecasting Chamber: use a synthetic environment with known ground truth to test whether the learner generates alternatives and updates probability rather than pretending historical counterfactuals can be proved.

GAITE is an editorial umbrella for a conceptual synthesis, not a verified integrated program. The supplied reports use more than one expansion of the acronym. The site preserves that conflict and labels all architecture, metrics, scenarios, and outcomes conceptual or synthetic unless a separately reviewed public source establishes a narrower component claim.

All interaction state remains in page-local JavaScript and clears on reload. The lab accepts no live intelligence, identifiable person data, coordinates, uploads, external URLs, user-authored operational text, or outside-system action. The only export is a fixed, privacy-safe text summary created after explicit visitor action.

Source Classification Evidence Lab method

The exercise asks what a source establishes before asking whether a claim sounds plausible.

The Evidence Lab uses nine reviewed cards derived only from the existing public source registry. Each card preserves the exact claim boundary, publication or review date, source IDs, source-lineage path, correct evidence class, public unknowns, and a “what this does not establish” statement. It does not create a second factual registry or silently promote research-report language into accepted public fact.

The seven exercise classes are verified public fact, government or operator statement, manufacturer-described, independent analysis, disputed or alleged, publicly unspecified, and fictional simulation value. A single proposition may have several surrounding sources, but the answer is based on the role of the source that actually supports the wording at issue.

Challenge codes alter only the deterministic presentation order. Answers, lineage inspections, and result metrics remain in page-local JavaScript memory and clear on reload. No account, PHP session, network request, persistent browser storage, behavioral profile, or server-side result record is created. Copy and PNG controls run only after explicit visitor action and contain no identity, location, raw timing, target data, or real-system performance claim.

JavaScript progressively converts the server-rendered card set into a one-card-at-a-time exercise. Without JavaScript, every card, source link, classification key, answer explanation, unknown, and limitation remains available as semantic HTML.

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.
• Human Control Lab: PHP renders semantic modules, curated case records, and one typed replay registry; local JavaScript runs six bounded teaching state machines and privacy-safe HC1 replay/share output without a write API, persistent result, or network telemetry.
• Source Classification Evidence Lab: PHP renders nine source-bound cards and their no-JavaScript explanations; local JavaScript manages deterministic order, classification feedback, replay, and explicit copy/download actions without persistence or network access.
• Anticipatory Intelligence Lab: PHP renders a typed ten-category analytical vocabulary, twelve synthetic classification cases, six interactive teaching modules, the conceptual GAITE boundary, and no-JavaScript explanations; local JavaScript manages page-only state, bounded comparisons, quarantine, counterfactual reveal, and explicit clipboard output without a write API or persistent storage.
• Predictive Enforcement Program Explorer: PHP renders eight source-bounded program records, allowlisted server-side filters, source trails, and max-four descriptive comparison; optional local JavaScript filters existing markup, rebuilds the same comparison, and runs one synthetic feedback-loop lesson without a write API, runtime crawling, accounts, or persistent state.
• Source Freshness & Correction Center: PHP derives review state and public dependency paths from the source and feature registries; optional local JavaScript filters existing markup and copies stable review links without crawling external destinations, accepting public edits, or changing factual state.
• 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.38.0 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.

Device and viewport compatibility

One semantic experience, progressively enhanced for each screen.

Release 1.38.0 treats responsive behavior as a product requirement rather than a desktop layout that merely shrinks. The same evidence, labels, decisions, controls, and limitations remain available across compact phones, phone landscape, tablets, laptops, large desktops, ultrawide displays, high-density screens, keyboard-only use, reduced motion, forced colors, and no-WebGL fallback.

The release is automatically checked at representative CSS viewports from 240 × 320 through 3840 × 2160. The matrix includes compact 240/280/320-pixel widths, common 360–430-pixel phones, short landscape screens, 600–912-pixel tablets, 1024–1920-pixel desktop widths, 2560-pixel ultrawide displays, and a 4K presentation. Browser checks verify page-level horizontal overflow, navigation state across breakpoint changes, touch-target sizing, mobile text-input sizing, semantic no-JavaScript access, reduced-motion behavior, high-contrast fallback, and the responsive challenge, Atlas, Human Control, and analysis interfaces.

On compact screens, the Daily Challenge and analysis sandbox change from layered heads-up displays to content-driven reading order. The Atlas replaces its absolute-position world abstraction with a synchronized evidence list. Text inputs use mobile-safe sizing, controls expose touch-sized hit areas, safe-area insets are respected, and dynamic viewport units prevent browser chrome or virtual keyboards from trapping navigation.

Three.js and WebXR remain enhancements. Canvas and semantic HTML provide the same essential learning content when a module CDN, WebGL, WebXR, a headset, or a resize observer is unavailable. Rendering resolution adapts to the visible canvas area so high-density and 4K displays do not create an unbounded GPU-memory requirement.

Search, answer, and generative discovery

One public claim architecture serves human readers, search engines, and answer systems.

Release 1.38.0 uses unique descriptive titles, page-specific summaries, clean canonical URLs, visible breadcrumbs, concise direct-answer blocks, stable glossary anchors, a source-linked FAQ, and structured data that is generated from the same page registry as the visible HTML. Query-state challenge, Atlas, Evidence Lab, and Human Control replay URLs remain shareable but are marked noindex,follow and canonicalized to the clean route to avoid duplicate search results.

Structured data identifies the publisher, website, page, primary image, breadcrumb trail, and visible page-specific resource such as a LearningResource, Dataset, ItemList, FAQPage, or DefinedTermSet. Structured data does not introduce claims that are absent from the page, create fake authors, or promise a rich result.

Answer-engine optimization is implemented through extractable question-and-answer language, early definitions, semantic headings, visible dates, evidence-state wording, direct source links, and explicit “what this does not establish” boundaries. Generative discovery uses the same material plus content-index.json, source-index.json, RSS, JSON Feed, and a nonstandard llms.txt map.

The llms.txt file is a convenience index, not an access-control standard or a ranking mechanism. Public crawler access remains governed by HTTP status, robots.txt, canonical HTML, and the receiving service’s own published behavior. Search-oriented OpenAI crawling and user-requested ChatGPT access are explicitly allowed for public routes while internal code, tests, data modules, durable memory, and handoff records remain denied.

The derived discovery files are generated from repository-owned page, FAQ, glossary, and source registries. php tests/build-discovery.php --check fails when the sitemap, feeds, indexes, or llms.txt no longer match those sources.

Cross-lab concept method

One concept registry connects existing owners instead of duplicating them.

The Cross-Lab Concept Matrix uses data/concept-matrix.php as the once-only owner for thirteen editorial concept routes. Each record references existing glossary terms, FAQ answers, Claim Lineage claims, canonical public surfaces, the appropriate KillWebs.com bridge, and one specific live Evulgare platform area.

The matrix does not copy source bodies, claim text, source-review status, program records, or simulation state. Those remain owned by their existing typed registries. Its purpose is educational navigation: start with a concept, compare where it appears, see when a multi-path question belongs on KillWebs.com, and route real-system evidence requirements to Evulgare.com.

The clean route is indexable. Search, surface-type, selected-concept, and comparison query states are presentation state only, receive noindex,follow, and canonicalize to the clean page. Compare state is local and non-persistent.

Source freshness and corrections

A reviewed record, a reachable link, and a verified claim are not the same state.

The Source Freshness & Correction Center stores only editorial lifecycle fields that are not already owned by data/sources.php: last review date, next scheduled review, review state, link-check state, historical retention, supersession, verification triggers, and non-destructive correction notices.

Public dependency paths are derived from typed Atlas, Human Control, Evidence Lab, provider, company-system, FAQ, glossary, sister-site, Predictive Enforcement, and Claim Lineage registries. A separate hand-written dependency list is not maintained. This allows a reader to trace a source ID to the public records that rely on it without allowing a source-review label to change the underlying evidence class.

The production page performs no runtime crawling and does not treat link availability as factual truth. A reachable manufacturer page remains a manufacturer description; an unavailable historical source may remain valuable; and a disputed claim remains disputed until stronger evidence changes the editorial assessment.

Claim lineage and institutional authority

Trace each public claim as a governed transformation.

The Claim Lineage & Institutional Authority Explorer uses data/claim-lineage.php as the typed owner for ten claim stages: observation, source statement, editorial synthesis, model inference, policy or objective, prioritization, recommendation, human authorization, automated action, and correction or supersession.

Every record has a stable ID, evidence state, public source IDs where evidence exists, parent claims, an owning route, a transformation statement, assumptions, human decisions, machine functions, authority owner, unknowns, a non-establishment statement, review date, reuse paths, and a correction path. Source identity and support remain owned by data/sources.php; source freshness and dependencies remain owned by data/source-review.php.

The public page derives forward reuse from the current source-dependency graph instead of treating repeated use as independent corroboration. Query-state filtering and claim selection are presentation state only. The clean route remains indexable, while query variants are noindex,follow and canonicalize to the clean page.

Institutional Authority Casebook

Compare function, permission, interruption, correction, and retirement separately.

The Institutional Authority Casebook uses data/authority-casebook.php as the typed owner for six source-reconciled cases. It reuses the existing public source, Source Review, and Claim Lineage owners rather than copying source identity or freshness metadata.

Each record defines a stable case ID, domain, lifecycle status, exact source and claim IDs, allowlisted machine functions, eight institutional authority roles, a transformation chain, migrated and retained authority, intervention and correction paths, public unknowns, non-establishment language, and a review date.

Source Review derives each case as another public dependency. Query-state filtering and maximum-three comparison are presentation state only; they do not alter evidence, source review, or claim status.

Change impact and supersession

Preview dependency obligations without mutating publication truth.

The Change Impact and Supersession Explorer derives its subjects and dependency graph from the existing source, Source Review, Claim Lineage, Institutional Authority Casebook, page, FAQ, glossary, and discovery owners. It does not maintain a second source or claim database.

The method separates six events: scheduled review, external link unavailability, factual correction, withdrawal, supersession or program replacement, and evidence reclassification. Each event has a distinct effect. For example, a broken URL triggers preservation and location review but does not automatically reverse the supported proposition; supersession moves current-state ownership while preserving the historical record.

Direct source and claim edges, descendant claims, authority cases, public dependencies, declared reuses, feed participation, discovery artifacts, and durable owners are derived into a human review queue. Cyclic or stale claim references fail validation. The browser can filter and copy a stable preview URL, but no browser action can edit a registry, accept a correction, crawl an external source, regenerate an artifact, or publish a new release.

Predictive enforcement method

Audit the full decision chain, not only the model.

The Predictive Enforcement Program Explorer treats collection, identity resolution, inference or prioritization, human interpretation, state attention, retention, and review or redress as one sociotechnical chain. A place forecast, a person-risk category, a watchlist record, an identity match, a traveler-screening instruction, and a multidisciplinary threat assessment are therefore presented as different functions rather than one generic “AI policing” category.

Every public record must state the responsible authority, operational period and current status, input classes, method, output, affected decision, human-review process, notice and redress, retention or removal, evaluation evidence, equality findings, source trail, public unknowns, and what the evidence does not establish. A discontinued program is not presented as current, a restructured successor is not assumed to be identical, and a current official page is not treated as independent effectiveness evidence.

The synthetic feedback-loop lesson holds underlying prevalence constant while changing observation exposure. Its purpose is to show that patrol, screening, visits, or review can produce additional records that enter the next analysis. It does not claim that every recorded event is invalid or that every focused intervention creates bias.

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. Human Control and Evidence Lab interactions remain in page memory only and reset on reload; Human Control replay URLs serialize only allowlisted synthetic choices.
• No AI model determines whether an event exists, whether a visual effect appears, how numeric state changes, or what evidence state an Atlas, Human Control, or Evidence Lab 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.38.0 was published on 2026-08-07 and reviewed through 2026-08-07. 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

The current source lifecycle, dependencies, supersession, and accepted public correction notices are published in the Source Freshness & Correction Center.

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 mike@ns12.com.

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