Who publishes and maintains KillChains.com?
KillChains.com is the publication identity, and Michael Kappel is the named creator and maintainer. Public pages retain release, review, source, and correction information.
Read the supporting sectionWho · How · Why
Editorial policy, evidence review, AI assistance, and corrections
KillChains.com publishes evidence-led explanations and synthetic simulations. This page identifies the publisher, the review workflow, the role of AI assistance, the commercial boundary, and the process for correcting a claim.
Named creatorSource-state labelsAI assistance disclosedNo paid placement
Answer-first summary
Direct answers
How is AI used in publishing?
AI may assist research synthesis, drafting, code generation, and testing, but publication claims must remain tied to reviewed sources, visible evidence states, deterministic data, and human acceptance of the release.
Read the supporting sectionWhy does the site publish this material?
The purpose is public understanding of how military, cyber, and AI-system chains work, where they can be interrupted, and how evidence, authority, and uncertainty should be evaluated.
Read the supporting sectionWho
KillChains.com is the publication; Michael Kappel is the named creator and maintainer.
KillChains.com remains the publication identity. Michael Kappel is the named creator, software author, and maintainer of the site. His professional background and direct contact are published on the About the Author page using a source-bounded profile from MikeKappel.com.
That named identity does not silently assign Michael authorship of every external source or preserved research report. Public claims remain attributed to their original government, operator, manufacturer, standards, research, or reporting source. Every page still exposes the release version, content-review date, methodology, source library, and correction path.
Why
The purpose is public understanding, not operational advantage.
KillChains.com explains three distinct subjects: military decision and targeting chains, traditional cyber intrusion chains, and attacks against AI-enabled systems. It emphasizes where a sequence can be interrupted, how evidence changes as it moves through a system, and how human authority can move from real-time operation into design, policy, configuration, supervision, and review.
The site does not seek to optimize weapons, identify targets, expose vulnerabilities, reproduce attack procedures, predict real combat outcomes, or persuade readers to support a state, organization, policy, or weapon.
How
Publication follows an evidence-to-implementation workflow.
- Define the claim. Separate technical capability, operating mode, human authority, deployment status, performance, and legal interpretation.
- Locate the strongest public evidence. Prefer official policy, program records, standards, procurement material, and primary framework publications for the questions they can actually answer.
- Classify the source. Government, operator, manufacturer, standard, independent research, reporting, allegation, dispute, or unknown.
- Preserve uncertainty. Do not infer AI from “automatic,” autonomous target selection from terminal guidance, or meaningful control from a visible human approval step.
- Implement the bounded product claim. Public pages, data records, simulations, and structured data must agree with the visible evidence state.
- Validate the release. Run syntax, route, content, safety, responsive, metadata, structured-data, link, package, and memory checks before versioned packaging.
Read the complete methodology and inspect the source library.
AI assistance
AI can assist the work; it is not the publication authority.
AI systems may assist with research synthesis, drafting, code generation, refactoring, testing, source routing, accessibility review, and package preparation. AI-generated language is not accepted as evidence merely because it is fluent. Current implementation, automated tests, reviewed source records, and explicit human acceptance of a versioned release outrank generated narrative.
The public simulation does not ask an AI model to decide whether an event exists, mutate authoritative state, classify a real person, choose a real target, or create a live operational effect. Synthetic scenario outcomes are deterministic or governed by reviewed PHP data and bounded state transitions.
Evidence
Attribution and uncertainty are part of the content.
Manufacturer claims remain attributed to the manufacturer. Government descriptions establish what an institution publicly says, not every classified setting or real-world result. Independent analysis remains analysis. Disputed reports remain disputed. A missing public answer is labeled unknown or publicly unspecified.
Real-system examples are not silently transformed into simulation parameters. The site’s fictional timings, confidence scores, boundaries, evidence objects, and outcomes are teaching values, not estimates of system performance.
The Source Classification Evidence Lab is generated from the current public source registry and reviewed claim boundaries. It teaches source class, lineage, circular reporting, bounded support, and public unknowns; it does not create new factual claims or adjudicate legality, institutional intent, or classified behavior.
Review all claim states · Trace source independence · Define evidence state.
Provider links
Technology-provider inclusion is descriptive, not commercial endorsement.
The Kill Chain Technology Providers directory links to official company and product pages only when a bounded public source record supports a role in sensing, command and control, decision support, defensive interception, autonomy, communications, space, or cyber defense.
Every entry keeps its source class, human-control boundary, public unknowns, and review date. Typed company-to-system edges additionally identify the provider role, released subject, lifecycle, relevant chain functions, source trail, and what the relationship does not establish. The directory does not rank providers, accept paid placement, provide prices or sales contacts, recommend procurement, assess export eligibility, or independently certify ownership, safety, legality, performance, configuration, or operational mode.
Ecosystem scope
Connected sites preserve separate publication and product authority.
KillChains.com explains selected sequences, evidence, interruption points, automation, human control, and public institutional authority. KillWebs.com explains the wider governed option space from which compatible, trusted, available, and authorized sequences may be composed or recomposed. Evulgare.com is the separate destination for real software that captures operational evidence and makes deployed machine systems answerable.
The public bridge does not merge the three sites. KillChains and KillWebs remain educational and research environments. Evulgare’s production-software scope does not turn KillChains simulations into assurance evidence, and a link to Evulgare is not proof of a deployed integration, certification, customer, legal result, or operational performance.
Editorial routing rule: point to KillChains for one evidence-to-action sequence, KillWebs for multiple governed paths, and Evulgare for production evidence capture, model and software lineage, authority reconstruction, operator-view reconstruction, incident causality, and system answerability.
Anti-scapegoating rule: the publication does not infer responsibility from the nearest human, a final approval click, or a machine-generated explanation. It asks what evidence, time, alternatives, authority, and practical intervention capacity existed, while preserving the separate question of legal and institutional responsibility.
The Answerability Lab uses a fictional event to teach this boundary. It does not assign blame, calculate liability, certify Evulgare, or reconstruct a real deployed incident.
The Machine Answerability Replay distinguishes what records support, what they do not establish, which questions remain unknown, and which roles had responsibility-relevant influence. It never converts causal contribution into guilt, innocence, legal liability, exoneration, punishment, compensation, or a fault score.
The Remediation Lab tests bounded counterfactual safeguards without rewriting accepted history or claiming guaranteed prevention. A safeguard that only adds a late approval prompt or polished explanation is labeled as ceremonial when it leaves evidence, authority, timing, execution, and intervention capability unchanged.
Commercial boundary
The current release contains no advertising or paid ranking.
Release 1.38.0 contains no advertising network, affiliate links, sponsored system ranking, paid placement, user-tracking analytics, subscription funnel, or commercial score that presents one country, manufacturer, or system as “best,” “most lethal,” or morally superior.
Links to manufacturers and program offices are included as attributed evidence. Their inclusion is not endorsement, procurement advice, or independent validation of performance.
Search, answers, and generative discovery
Discovery layers must preserve the same evidence boundaries as the page.
KillChains.com provides descriptive titles, concise direct answers, semantic headings, visible breadcrumbs, structured data that matches visible content, a glossary, FAQ, content index, source index, RSS and JSON feeds, and a nonstandard llms.txt convenience map.
The llms.txt file is not an access-control mechanism, a web standard, or a guarantee of inclusion in any search or generative answer system. robots.txt, HTTP status, canonical URLs, on-page content, and each crawler’s published behavior remain authoritative for access and indexing.
Public pages permit ordinary crawling while internal code, data modules, durable memory, tests, handoff folders, and private repository guidance remain blocked from public routes. Search-oriented OpenAI crawling and user-requested ChatGPT page access are explicitly permitted for public content; search inclusion and citation remain decisions of the external service.
Source lifecycle
Freshness and reachability never silently change evidence class.
The Source Freshness & Correction Center publishes review dates, scheduled review intervals, supersession, historical retention, typed public dependencies, and correction pathways. The page performs no runtime crawl and does not automatically promote, demote, or remove a claim because an external page is reachable, redirected, or unavailable.
Corrections
A correction must identify both the claim and its evidence state.
A useful correction provides the page URL and heading, quotes or precisely identifies the claim, supplies a stronger source or explains the methodological defect, and states whether the issue is a factual error, changed program status, attribution problem, outdated source, broken link, or interpretive disagreement.
Material corrections should update the source record, affected pages, structured data, content indexes, release history, review date where warranted, and semantic version. Superseded evidence should be preserved when it remains useful for understanding how the assessment changed.
Contact
One public contact covers author, project, editorial, and security correspondence.
Contact Michael Kappel at mike@ns12.com. Personal site: MichaelKappel.com.
Security reports: follow SECURITY.md or the public security.txt. Do not test third-party systems or include raw credentials in a report.
Claim lineage and institutional authority
Every public claim should expose its transformation and correction path.
The Claim Lineage Explorer distinguishes what a source says from what a model infers, what an editor synthesizes, what an institution prioritizes, what a machine recommends, what a human authorizes, and what an automated controller executes. Those stages cannot be collapsed into a single statement that “the AI decided.”
Claim records are repository-authored and read-only. They may point to official, manufacturer, independent, historical, first-party, editorial, or synthetic evidence states, but the lineage layer cannot upgrade a source, assign legal responsibility, certify accuracy, or accept an anonymous edit.
Change impact and supersession
Dependency previews identify review work; they do not publish a verdict.
The Change Impact Explorer separates scheduled review, link unavailability, factual correction, withdrawal, supersession, and evidence reclassification. It preserves earlier records where they remain necessary for chronology and never treats a failed URL as proof that a bounded historical statement is false.
Only a reviewed repository change can update the once-only owner, affected public pages, discovery artifacts, durable pointers, and release history. The public browser has no edit, crawl, regeneration, or automatic-promotion authority.
Machine leadership
Titles and automation are not published as proof of authority.
The Machine Leadership Lab preserves the five supplied reports as research inputs while publishing only a bounded synthesis. Named company, market, legal, political, municipal, and program claims require separate primary-source review. The site distinguishes operational delegation from legal office, machine-generated explanation from evidence, and human presence from meaningful oversight.
Historical change ledger
Corrections remain versioned and auditable.
The Historical Change Ledger publishes only changes already accepted through repository review, tests, versioning, durable proof, and discovery regeneration. It keeps the earlier bounded state visible, identifies the first corrected release, and explains which public surfaces were reviewed.
Hypothetical Change Impact previews never become accepted history merely because a visitor opens, filters, compares, or shares them. The browser has no authority to accept a correction, withdraw a source, reclassify evidence, or rewrite a release.
Cross-lab concept matrix
Concept navigation must not become a second source of truth.
The Concept Matrix references the existing glossary, FAQ, Claim Lineage, Source Review, labs, case records, and canonical pages. It does not copy or upgrade their authority. Each concept states the public learning route, the KillWebs.com bridge for multi-path questions, and the specific live Evulgare area for production-accountability requirements.
Evulgare links are first-party product-scope records. They establish the public identity and described platform area, not independent evidence of customers, deployment, certification, legal sufficiency, or measured performance.
Ecosystem boundary
Learn the failure here. Make the deployed machine answerable at Evulgare.
KillChains.com remains a synthetic simulation and public-research environment. KillWebs.com remains the sister learning environment for governed network paths. Stop using software that makes the nearest human explain a decision they could not see, verify, or control. Real-system evidence capture, software and model lineage, authority reconstruction, operator-view reconstruction, incident causality, and deployed-system answerability belong at Evulgare.com.
The editorial policy governs publication truth and public corrections. Evulgare is a separate production-software destination for reconstructing real machine decisions and accountability evidence.
Assurance publication policy
A past approval does not become a permanent safety badge.
KillChains.com publishes assurance only as a bounded proposition tied to named evidence, versions, assumptions, authority, operating conditions, defeaters, and a review owner. Earlier states remain visible when a claim is suspended, withdrawn, or later revalidated.
The publication never equates evidence integrity with factual truth and never presents a synthetic supported state as certification, compliance, legal approval, absence of residual risk, operational effectiveness, or a final allocation of responsibility.
Assurance review packet policy
Current truth may supersede reliance without erasing prior publication state.
Every released assurance snapshot must remain independently reconstructable. Editors may publish a successor packet after model, software, configuration, interface, policy, authority, evidence, dependency, or environment changes, but must preserve the prior bounded statement and explain why its state changed.
The publication must not compress evidence integrity, factual support, assurance state, review completion, and operational release authority into one badge. The browser cannot approve a release, accept a correction, alter history, or create production evidence.
Evidence-contract publication policy
Many hands do not excuse missing ownership.
Each published evidence contract must identify who creates and preserves the record, who can independently verify and challenge it, and which competent institution can accept, suspend, correct, and retire reliance.
The publication must preserve prior packet hashes and must not infer missing authority, collapse review completion into operational release, or convert participation into a blame percentage.
Evidence-gap and dispute-escalation publication policy
Missing evidence and missing authority remain visible.
The publication distinguishes an evidence request from production, custody from factual support, an opened challenge from resolution, assurance qualification or suspension from operational release, correction from historical erasure, and contract remediation from legal responsibility.
Editors must not infer an absent owner, transfer the duty to the nearest operator, overwrite an immutable packet, or present a synthetic remediation branch as production proof, certification, legal judgment, or authorization.
Dispute-ledger publication policy
Correct the bounded statement without repairing history by deletion.
Every published dispute record must preserve the original packet, branch result, challenge grounds, evidence-request state, review owner, corrective action, current disposition, and residual unknowns. A later correction or retirement may supersede current reliance but may not erase the state that made the corrective action necessary.
The publication must keep evidence request, production, custody, factual support, challenge resolution, assurance state, operational release, closure, and legal responsibility separate. A missing owner remains no authority to infer.
Corrective-action effectiveness publication policy
Do not call an action effective because a ticket closed.
Every effectiveness record must distinguish planning, implementation, produced evidence, independent verification, bounded effect, later invalidation, retirement or replacement, and residual exposure. Editorial language must state exactly what the released synthetic evidence supports and what remains unknown.
The publication must not infer effectiveness from a final sign-off, operator confirmation, policy update, test artifact, or implementation claim alone. Earlier disputes and audit states remain independently reconstructable when a later control is invalidated, retired, replaced, or closed.
Monitoring, regression, and reopening publication policy
Publish later evidence as a new branch, not as a repaired past.
Every monitoring record must distinguish a scheduled review from a performed review, an observed signal from independently verified regression, temporary suspension from retirement, remediation from revalidation, and restored support from erasure of earlier invalidation.
Editors must preserve the source audit and hash, identify competent monitoring and review owners, retain residual exposure, and fail closed to effectiveness unknown or no authority to infer where the evidence or institutional authority is absent.
Monitoring coverage and alert-integrity publication policy
Do not publish silence as safety or process health as correct scope.
Every coverage record must identify which evidence, versions, authority states, operator-view conditions, dependencies, operating envelopes, and owners are actually observable. Alert generation, delivery, acknowledgement, competent review, and independent verification remain separate editorial states.
Editors must preserve suppressed alerts, stale baselines, inaccessible evidence, unmonitored dependencies, and missing authority rather than inferring a favorable result or assigning an unowned duty to the nearest operator.
Coverage validation publication policy
Do not publish a passed synthetic path as production safety or factual truth.
Every validation result must name the immutable source branch and hash, released remediation, selection and implementation state, changed condition, injected failures, all ten alert-path stage states, missing evidence, missing institutional owners, unsupported conclusions, residual blind spots, and exact production handoffs.
Selection, configuration, delivery, receipt, review, verification, qualification or suspension, correction or retirement, and legal responsibility remain separate editorial states. Missing implementation evidence or competent authority remains visible; it is never assigned to the nearest operator.