KillWebs.com Sister-Site Design and Implementation Report

KillWebs.com Sister-Site Design and Implementation Report

Planning baseline: August 1, 2026 Audience: Web developer, product owner, security owner, and compliance reviewer Target: KillWebs.com, implemented as a sister property to KillChains.com Required stack: PHP, browser-native JavaScript, HTML, and CSS; locally hosted open-source 3D JavaScript libraries are permitted External-service boundary: No content delivery network, remote analytics, advertising, hosted search, hosted fonts, external APIs, social widgets, authentication provider, cloud database, telemetry collector, or other runtime third-party integration

Executive summary

KillWebs.com should be built as a structural sibling rather than a visual clone of KillChains.com. It should preserve the parent site’s recognizable information architecture—server-rendered explanatory pages, an interactive synthetic learning environment, evidence and methodology sections, public source transparency, local browser progress, and strong limitations language—while changing the primary mental model from a sequence of stages to a graph of dynamically composable pathways.

The supplied KillChains.com v1.6.0 source package is the correct engineering baseline because it already provides a PHP shell, shared includes, reusable page components, local data files, deterministic simulations, machine-readable discovery files, tests, a /docs/long-term-memory/ hierarchy, and a substantial .uai/ project-memory package. The live KillChains.com site currently identifies itself as release v1.3.0 and exposes a simulation, Evidence Atlas, Human Control Lab, explanatory pages, methodology, sources, privacy, terms, local progress, synthetic-only scenarios, and text fallbacks. The difference between the supplied v1.6.0 package and the public v1.3.0 deployment should be treated as source-to-production drift, not resolved by downgrading the supplied source. citeturn7view0

The most important implementation decision is to fork the supplied source into a new repository or independent deployment root, then systematically replace KillChains-specific identity, route labels, data, simulations, palette, structured metadata, public discovery records, and .uai memory. Shared component patterns may be retained, but canonical URLs, browser-storage namespaces, service-worker caches, manifests, sitemaps, JSON-LD identifiers, local data keys, and release streams must be independent.

KillWebs.com should center its first release on five product capabilities:

The content model should preserve an important doctrinal distinction: a kill web does not abolish kill chains. It provides a graph of possible, authorized mission paths from which individual chains can be composed and recomposed. That distinction is strongly represented across the uploaded research corpus and should be the site’s canonical explanatory statement. fileciteturn0file0 fileciteturn0file12

The site should use PHP server rendering as the authoritative content layer and JavaScript only for progressive enhancement. Critical definitions, limitations, citations, scenario descriptions, controls, results, and fallback representations must be understandable without the 3D renderer. This matches UAIX AI-Ready Web guidance, which calls for semantic, human-visible canonical content and warns against hiding key answers behind canvas, scripts, images, tabs, or machine-only artifacts. citeturn9view0turn9view1

For 3D, the recommended launch dependency is Three.js, pinned to an approved version and stored under the site’s own /assets/vendor/ directory. Three.js is already used by KillChains.com, reducing migration and accessibility risk. Its official documentation supports ordinary JavaScript-module projects and static asset folders; the remote CDN example in the supplied KillChains configuration must be replaced by local module paths to satisfy the no-external-services requirement. citeturn7view8

The .uai design should follow a hot-and-durable memory model:

• Compact .uai files hold accepted current state, constraints, architecture, decisions, progress, and routing instructions.
• Full reports and long-form research remain under /docs/long-term-memory/reports/.
• Every report receives a stable ID, SHA-256 digest, review state, authority class, topic list, and pointer in .uai/long-term-memory.uai.
• Reviewed conclusions are distributed to the .uai file that owns the subject—such as architecture.uai, constraints.uai, or report-synthesis.uai—rather than duplicating entire reports across hot memory.
• Public AI-ready discovery files are generated from a public-safe projection and must never expose private .uai instructions, credentials, internal paths, or unpublished records.

UAIX describes .uai files as typed, bounded memory records rather than runtime execution or certification. Its universal launch baseline includes memory-maintenance.uai, identity.uai, world-context.uai, totem.uai, taboo.uai, talisman.uai, startup-packet.uai, and progress.uai; code-bearing packages additionally require architecture, coding standards, and continuation records. citeturn9view4turn7view1

Security should be designed around a public, unclassified educational site with no user accounts and no operational data ingestion. Zero trust in this context means every route, file, process, and state-changing action is authorized according to the resource involved rather than trusted because it originates on the same server or network. NIST’s zero-trust model rejects implicit trust based on network location and emphasizes protecting resources through explicit, continuously evaluated access decisions. citeturn7view5

The recommended delivery period is twelve weeks, subject to the assumptions that the supplied code may legally be reused, hosting supports PHP 8.2 or later, both domains have the same authorized owner, and the content remains public and unclassified. The first public release should not be approved until reciprocal links, local asset verification, performance budgets, accessibility fallbacks, .uai completeness, report indexing, security headers, offline behavior, and content-source review all pass automated and manual acceptance gates.

Baseline audit and assumptions

Source audit. The public KillChains.com implementation establishes the behavioral model to preserve: synthetic-only simulations, no registration, local progress, deterministic scenarios, an evidence-led learning flow, visible methodological limitations, explanatory fallback text, and clear separation between military, cyber, and AI-system meanings of “kill chain.” citeturn7view0

A direct audit of the supplied KillChains.com-v1.6.0-root-deploy(2).zip found:

The source package’s current palette is dominated by dark navy, cyan, blue, violet, rose, and amber. KillWebs.com should retain the dark technical presentation and component rhythm but use an organic network palette that is plainly distinct:

These colors provide a visual relationship to KillChains.com’s dark interface while replacing its electric-cyan identity with lime and teal. Color must never be the only signal: every node and edge state should also use a label, icon, line pattern, or shape.

Layout compatibility. “Modeled on KillChains.com” should be interpreted as reuse of the following structural grammar:

• Sticky site header and compact mobile navigation.
• Full-width interactive hero with an adjacent or overlaid briefing panel.
• A constrained reading width for reports and definitions.
• Reusable cards for concepts, evidence, risks, and source quality.
• Persistent methodological and synthetic-data labels.
• A large footer divided into understanding, evaluation, and site-governance links.
• A text fallback immediately following every canvas-based experience.
• Consistent components for citations, source strength, review date, limitations, and release status.

It should not mean pixel-for-pixel copying. The graph topology, iconography, node cards, motion language, color, page titles, datasets, and primary calls to action must express a separate KillWebs identity.

Visual mockup guidance.

┌──────────────────────────────────────────────────────────────────────┐
│ KillWebs.com     Explore  ACK Lab  Atlas  Architecture  Security    │
│ [Compare the linear model at KillChains.com]                         │
├──────────────────────────────────────────────────────────────────────┤
│ A NETWORK IS FORMING                                                 │
│ Compose the mission. Test the failure. Preserve authorized options.  │
│                                                                      │
│ ┌──────────────────────────┐   ┌───────────────────────────────────┐ │
│ │                          │   │ Scenario brief                    │ │
│ │  3D / 2D network graph   │   │ Available capabilities           │ │
│ │  sensors ↔ data ↔ C2     │   │ Constraints and authorities      │ │
│ │  ↕ links ↔ effectors     │   │ [Inspect] [Degrade] [Recompose]  │ │
│ │                          │   │                                   │ │
│ └──────────────────────────┘   └───────────────────────────────────┘ │
├──────────────────────────────────────────────────────────────────────┤
│ Current pathway | Alternatives | Evidence age | Authority | Latency  │
├──────────────────────────────────────────────────────────────────────┤
│ Why chains still matter | How ACK works | Security | Human control   │
├──────────────────────────────────────────────────────────────────────┤
│ Source record • Methodology • Reports • Privacy • Sister site        │
└──────────────────────────────────────────────────────────────────────┘

Assumptions requiring owner confirmation.

The uploaded research should be treated as a research-input corpus, not automatically as publication-ready authority. Several files are paired duplicates with “(1)” filenames; these should be deduplicated by cryptographic hash before stable report IDs are issued. Long-form reports also contain varying levels of sourcing and confidence, so each must receive a review state and truth boundary before its conclusions are promoted into public pages or hot .uai memory. UAIX explicitly warns against treating raw intake or archived reports as current truth before review and promotion. citeturn9view5

Product structure and content migration

The proposed information architecture keeps KillChains.com’s learning sequence—experience, understand, evaluate, verify—but changes the interactive metaphor from “interrupt the sequence” to “compose and preserve valid pathways.”

Recommended public sitemap.

KillChains-to-KillWebs content mapping.

The uploaded KillWebs Concept Website Strategy already frames the desired property as a conceptual successor to KillChains.com and proposes interactive graph-based explanation, resilience demonstrations, JADC2 content, AI, edge computing, and mathematical-network concepts. It is a useful product input, but claims about particular systems, performance improvements, and military programs should be checked against primary sources before publication. fileciteturn0file1

Content inventory and routing.

The corpus should support a clear editorial hierarchy:

1. Official primary sources for doctrine, policy, program descriptions, standards, and technical specifications.
2. Reviewed analytical reports that synthesize those sources.
3. Interactive explanatory models that make the analysis understandable.
4. Synthetic scenarios that demonstrate tradeoffs without representing real operational outcomes.

The uploaded cybersecurity report correctly emphasizes that expanded connectivity increases interfaces, credentials, transformations, and trust relationships and that integrity attacks may be more consequential than visible outages. That should shape both the site’s subject matter and its own web-security posture. fileciteturn0file9

The AI/autonomy report’s most useful publication boundary is that “best capability for the task” should be presented as a constrained recommendation problem, not as autonomous authorization to apply force. The public site should preserve uncertainty, provenance, legal constraints, authority, and human judgment rather than presenting AI optimization as automatic legitimacy. fileciteturn0file10

Reciprocal-link implementation.

KillWebs.com should contain three persistent links to KillChains.com:

KillChains.com should receive parallel links:

The sites should not share cookies, sessions, service workers, local-storage keys, authentication state, or analytics identifiers. Each domain should have its own canonical URL, manifest, sitemap, release stream, privacy notice, and browser-storage namespace. A user following a plain link should cross domains without silent state transfer.

Technical architecture and performance budgets

The target architecture should be deliberately simple: PHP renders authoritative pages and same-origin JSON; JavaScript progressively adds interaction; all content, libraries, reports, fonts, models, and images are served locally.

flowchart TD
    U[Human user or public agent] --> TLS[HTTPS web server]
    TLS --> ROUTER[PHP route bootstrap]

    ROUTER --> CONFIG[Site configuration and route registry]
    ROUTER --> PAGES[Server-rendered PHP pages]
    ROUTER --> API[Same-origin read-only PHP endpoints]
    ROUTER --> DOCS[Approved report controller]

    CONFIG --> COMPONENTS[Header, footer, SEO, citations, cards]
    PAGES --> COMPONENTS
    PAGES --> DATA[Local PHP and JSON content]
    API --> DATA

    DOCS --> INDEX[Generated public report index]
    INDEX --> REPORTS[/docs/long-term-memory/reports/]

    PAGES --> HTML[Semantic HTML and text fallbacks]
    HTML --> JS[Local ES-module JavaScript]
    JS --> THREE[Locally vendored Three.js]
    JS --> SW[Versioned service worker]
    THREE --> CANVAS[Optional WebGL/WebXR graph]
    SW --> CACHE[Browser-local public asset cache]

    MEMORY[Private project .uai memory] --> GENERATOR[CLI indexing and readiness scripts]
    REPORTS --> GENERATOR
    GENERATOR --> INDEX
    GENERATOR --> PUBLICAI[Public-safe AI-ready manifests]
    GENERATOR --> POINTERS[.uai long-term-memory pointers]

    PUBLICAI --> TLS

    POLICY[Security headers, CSP, permissions, input limits] --- TLS
    TESTS[PHP, JS, accessibility, links, security, UAIX tests] --- GENERATOR

Recommended repository shape.

/
├── index.php
├── scenarios.php
├── ack-lab.php
├── atlas.php
├── interoperability-lab.php
├── human-authority.php
├── what-is-a-kill-web.php
├── kill-chain-vs-kill-web.php
├── how-kill-webs-work.php
├── architecture.php
├── jadc2.php
├── ai-autonomy.php
├── security.php
├── procurement.php
├── risks-law.php
├── reports.php
├── methodology.php
├── sources.php
├── faq.php
├── glossary.php
├── privacy.php
├── terms.php
├── config/
│   ├── site.php
│   ├── routes.php
│   ├── security.php
│   └── publication.php
├── includes/
│   ├── bootstrap.php
│   ├── header.php
│   ├── footer.php
│   ├── seo.php
│   ├── components.php
│   ├── reports.php
│   └── security-headers.php
├── data/
│   ├── scenarios.php
│   ├── nodes.php
│   ├── capabilities.php
│   ├── programs.php
│   ├── sources.php
│   └── glossary.php
├── api/
│   ├── scenario.php
│   ├── graph.php
│   ├── reports.php
│   └── status.php
├── assets/
│   ├── css/
│   ├── js/
│   ├── img/
│   ├── models/
│   └── vendor/
│       └── three/
├── docs/
│   └── long-term-memory/
├── .uai/
│   ├── exports/
│   └── *.uai
├── scripts/
│   ├── index-docs.php
│   ├── build-discovery.php
│   └── verify-release.php
├── tests/
├── storage/
│   ├── cache/
│   └── logs/
├── robots.txt
├── sitemap.xml
├── llms.txt
├── manifest.webmanifest
└── .well-known/
    ├── security.txt
    └── ai-ready.json

The runtime web-server account should have read access to code, assets, public reports, and generated indexes, but write access only to explicitly designated storage/cache and storage/logs directories. Public requests should never be allowed to modify code, .uai memory, reports, manifests, or configuration.

PHP architecture rules.

JavaScript architecture rules.

UAIX recommends server-rendering or pre-rendering primary content, providing stable programmatic names for controls, and ensuring critical answers remain available outside canvas or post-load scripts. citeturn9view1turn9view3

Three-dimensional library decision.

Three.js should be selected because it minimizes divergence from the supplied source and is sufficient for nodes, edges, labels, camera controls, picking, animation, WebGL, and optional WebXR. The approved distribution files should be copied into the repository and served from paths such as:

import * as THREE from '/assets/vendor/three/build/three.module.min.js';
import { OrbitControls } from '/assets/vendor/three/examples/jsm/controls/OrbitControls.js';

The build record should store:

• Upstream project name and version.
• Upstream source commit or release tag.
• License file.
• Exact locally deployed files.
• SHA-256 checksums.
• Review date.
• Known security advisories or open exceptions.
• Upgrade and rollback procedure.

No module import may resolve to cdn.jsdelivr.net, unpkg.com, cdnjs, Google-hosted libraries, or any other runtime origin. Official Three.js guidance allows project assets to live in a public/static folder; the local deployment should use that model rather than the documentation’s CDN alternative. citeturn7view8

Graph interaction model. The initial graph should use a controlled number of node types:

Edges should distinguish physical reachability, data compatibility, authorization, and current selection. A visible line must not imply that a pairing is lawful, sufficiently trusted, or currently available. The interface should therefore expose at least four states: technically possible, data-compatible, authorized, and selected.

Performance and size budgets. These are project acceptance targets, not doctrinal military latency requirements.

Caching strategy.

Offline and edge behavior.

The service worker should be optional, versioned, and same-origin only. It should use:

• Cache-first for content-hashed static assets.
• Network-first for HTML.
• Stale-while-revalidate for previously visited public reports.
• No caching of administrative routes, session-bearing responses, security reports, or unpublished content.
• An explicit “Download this report for offline reading” control rather than automatically caching the entire research corpus.
• A visible offline state.
• No background synchronization to external services.
• A cache migration that deletes obsolete KillWebs cache versions but never touches KillChains.com, which is a separate origin.

The site must remain functional when WebGL, WebXR, service workers, local storage, or JavaScript are unavailable. The fallback should be an HTML/SVG graph summary, node table, selected pathway, alternatives, evidence table, and scenario transcript.

UAIX memory and /docs implementation

UAIX’s memory guidance is particularly compatible with this project because the supplied KillChains source already separates compact .uai state from durable /docs/long-term-memory/ records. UAIX states that hot .uai files should contain current accepted state rather than dated changelog material, while durable memory augments rather than replaces startup memory. citeturn7view1turn9view5

The required implementation principle is:

Every report lives under /docs; every report has one stable indexed identity; every report appears in the long-term-memory pointer ledger; reviewed conclusions are promoted into the appropriate current .uai record without copying full report bodies into startup memory.

Recommended /docs organization.

/docs/
├── README.md
├── reports-index.md
└── long-term-memory/
    ├── index.md
    ├── architecture/
    │   ├── current-architecture.md
    │   ├── route-and-component-map.md
    │   ├── offline-and-cache-design.md
    │   └── threat-model.md
    ├── decisions/
    │   ├── active-decisions.md
    │   ├── deferred-decisions.md
    │   └── decision-log.md
    ├── implementation-history/
    │   ├── release-line.md
    │   ├── source-fork-audit.md
    │   ├── uaix-validation.md
    │   └── launch-readiness.md
    ├── research/
    │   ├── research-boundaries.md
    │   ├── source-routing.md
    │   ├── terminology-authority.md
    │   └── duplicate-and-supersession-register.md
    ├── reports/
    │   ├── index.md
    │   ├── KW-RPT-001-transition-and-ack.md
    │   ├── KW-RPT-002-website-strategy.md
    │   ├── KW-RPT-003-architecture.md
    │   ├── KW-RPT-004-jadc2.md
    │   ├── KW-RPT-005-security.md
    │   ├── KW-RPT-006-ai-and-autonomy.md
    │   ├── KW-RPT-007-procurement.md
    │   ├── KW-RPT-008-chain-versus-web.md
    │   └── KW-RPT-009-site-design-and-implementation.md
    └── security/
        ├── public-content-boundary.md
        ├── data-retention.md
        ├── dependency-register.md
        └── incident-response.md

If multiple uploaded reports cover the same theme but are substantively different, preserve each with its own stable ID and record the relationship. If two files have the same SHA-256 digest, retain one canonical file and enter the other filename in an alias or intake-disposition field. Do not issue two stable IDs for byte-identical copies.

Required .uai package.

UAIX’s closed-file-state model requires each file to be classified as universal required, profile-required, content-triggered required, configuration-specific required, or out of scope. Code-bearing project packages require architecture, coding standards, and continuation records; .uai files are typed records for accepted context and evidence, not a substitute for human review or runtime controls. citeturn9view4

Distribution of KillWebs information across .uai memory.

This meets the requirement that KillWebs information be distributed throughout memory without turning every .uai file into a duplicate report archive.

Example .uai/identity.uai.

---
uai: "1.0"
type: identity
status: current
package_id: killwebs-com
package_family: project-developer-handoff
---

# KillWebs.com identity

name: KillWebs.com
namespace: killwebs-com
canonical_origin: https://killwebs.com
sister_site: https://killchains.com
declared_profiles:
  - project-handoff
  - code-bearing
  - long-term-memory
  - file-handoff
sensitivity_boundary: public-unclassified-content-only
source_authority:
  code: current repository and verified runtime
  publication: reviewed public pages and approved reports
  memory: current .uai records plus routed durable evidence

## Actor boundary

- Public users may read approved pages, reports, and read-only APIs.
- Public users may not write project memory, reports, configuration, or code.
- Build operators may regenerate indexes only through reviewed local scripts.
- No .uai file may contain credentials, private keys, access tokens, classified data,
  CUI, operational coordinates, or private user data.

Example .uai/long-term-memory.uai.

---
uai: "1.0"
type: long-term-memory
status: current
package_id: killwebs-com
durable_root: ../docs/long-term-memory/
report_root: ../docs/long-term-memory/reports/
generated_export: exports/docs-index.json
---

# KillWebs.com long-term-memory pointer ledger

## Authority order

1. Current code, configuration, and observed runtime behavior.
2. Passing tests and current release proof.
3. Accepted decisions and current architecture.
4. Reviewed public reports and research synthesis.
5. Preserved research inputs, proposals, and superseded history.

## Report rules

- Every report must be below the configured report root.
- Every report must contain a unique `stable_id`.
- Every report must have a SHA-256 digest.
- Duplicate hashes must be deduplicated before release.
- Research-input status does not make a report current publication truth.
- Public exposure is controlled by `publication_status`.

<!-- GENERATED:REPORT-POINTERS:START -->
- KW-RPT-001
  - title: From Kill Chain to Kill Web
  - path: ../docs/long-term-memory/reports/KW-RPT-001-transition-and-ack.md
  - authority: reviewed-analysis
  - publication_status: public
  - routed_to: [context.uai, report-synthesis.uai]

- KW-RPT-005
  - title: Cybersecurity Vulnerabilities and Non-Kinetic Disruption
  - path: ../docs/long-term-memory/reports/KW-RPT-005-security.md
  - authority: research-input
  - publication_status: internal-review
  - routed_to: [constraints.uai, report-synthesis.uai]
<!-- GENERATED:REPORT-POINTERS:END -->

Example generated .uai/exports/docs-index.json.

{
  "schema": "killwebs-doc-index/v1",
  "package_id": "killwebs-com",
  "report_root": "docs/long-term-memory/reports",
  "reports": [
    {
      "id": "KW-RPT-001",
      "title": "From Kill Chain to Kill Web",
      "path": "docs/long-term-memory/reports/KW-RPT-001-transition-and-ack.md",
      "sha256": "REPLACE_WITH_GENERATED_DIGEST",
      "authority": "reviewed-analysis",
      "review_status": "approved",
      "publication_status": "public",
      "topics": ["transition", "architecture", "DARPA ACK"],
      "routed_to": ["context.uai", "report-synthesis.uai"]
    }
  ]
}

Active .uai files should not become dated progress logs. Generated JSON may contain a generation time as release evidence, but current-state memory should route to the release record rather than repeat changing version numbers and dates. UAIX expressly warns against leaving stale date-log material or secrets in active portable memory. citeturn9view5

PHP report-indexing example. This CLI script enforces stable IDs, rejects symbolic links and duplicates, creates the JSON export atomically, and refreshes the generated pointer block in .uai/long-term-memory.uai.

<?php

declare(strict_types=1);

/**
 * Usage:
 *   php scripts/index-docs.php
 *
 * Each Markdown report must contain metadata lines such as:
 *
 * stable_id: KW-RPT-001
 * authority: reviewed-analysis
 * review_status: approved
 * publication_status: public
 * topics: transition, architecture, DARPA ACK
 *
 * followed by a first-level Markdown heading.
 */

$projectRoot = realpath(dirname(__DIR__));

if ($projectRoot === false) {
    fwrite(STDERR, "Unable to resolve project root.\n");
    exit(1);
}

$reportsRoot = realpath(
    $projectRoot . '/docs/long-term-memory/reports'
);
$exportPath = $projectRoot . '/.uai/exports/docs-index.json';
$ledgerPath = $projectRoot . '/.uai/long-term-memory.uai';

if ($reportsRoot === false || !is_dir($reportsRoot)) {
    fwrite(STDERR, "Report directory is missing.\n");
    exit(1);
}

const MAX_REPORT_BYTES = 8_388_608;
const START_MARKER = '<!-- GENERATED:REPORT-POINTERS:START -->';
const END_MARKER = '<!-- GENERATED:REPORT-POINTERS:END -->';

function readField(string $content, string $name, bool $required = true): ?string
{
    $pattern = '/^' . preg_quote($name, '/') . ':\s*(.+?)\s*$/mi';

    if (preg_match($pattern, $content, $matches) === 1) {
        return trim($matches[1], " \t\n\r\0\x0B\"'");
    }

    if ($required) {
        throw new RuntimeException("Missing required field: {$name}");
    }

    return null;
}

function readTitle(string $content): string
{
    if (preg_match('/^#\s+(.+?)\s*$/m', $content, $matches) !== 1) {
        throw new RuntimeException('Missing first-level Markdown title.');
    }

    return trim($matches[1]);
}

function atomicWrite(string $path, string $content): void
{
    $directory = dirname($path);

    if (!is_dir($directory) && !mkdir($directory, 0750, true) && !is_dir($directory)) {
        throw new RuntimeException("Unable to create directory: {$directory}");
    }

    $temporary = tempnam($directory, '.tmp-');

    if ($temporary === false) {
        throw new RuntimeException("Unable to create temporary file for {$path}");
    }

    try {
        if (file_put_contents($temporary, $content, LOCK_EX) === false) {
            throw new RuntimeException("Unable to write temporary file.");
        }

        chmod($temporary, 0640);

        if (!rename($temporary, $path)) {
            throw new RuntimeException("Unable to replace {$path}");
        }
    } finally {
        if (is_file($temporary)) {
            @unlink($temporary);
        }
    }
}

$iterator = new RecursiveIteratorIterator(
    new RecursiveDirectoryIterator(
        $reportsRoot,
        FilesystemIterator::SKIP_DOTS
    )
);

$reports = [];
$seenIds = [];
$seenHashes = [];

foreach ($iterator as $file) {
    if (!$file instanceof SplFileInfo || !$file->isFile()) {
        continue;
    }

    if ($file->isLink()) {
        throw new RuntimeException(
            'Symbolic links are not permitted: ' . $file->getPathname()
        );
    }

    if (strtolower($file->getExtension()) !== 'md') {
        continue;
    }

    if ($file->getSize() > MAX_REPORT_BYTES) {
        throw new RuntimeException(
            'Report exceeds size limit: ' . $file->getFilename()
        );
    }

    $absolutePath = $file->getRealPath();

    if (
        $absolutePath === false
        || !str_starts_with(
            $absolutePath,
            $reportsRoot . DIRECTORY_SEPARATOR
        )
    ) {
        throw new RuntimeException('Report escaped the approved root.');
    }

    $content = file_get_contents($absolutePath);

    if ($content === false) {
        throw new RuntimeException("Unable to read {$absolutePath}");
    }

    $id = readField($content, 'stable_id');
    $title = readTitle($content);
    $authority = readField($content, 'authority', false) ?? 'research-input';
    $reviewStatus = readField($content, 'review_status', false) ?? 'unreviewed';
    $publicationStatus = readField(
        $content,
        'publication_status',
        false
    ) ?? 'internal-review';
    $topicString = readField($content, 'topics', false) ?? '';
    $topics = array_values(
        array_filter(
            array_map('trim', explode(',', $topicString))
        )
    );

    if (!preg_match('/^KW-RPT-[0-9]{3,6}$/', $id)) {
        throw new RuntimeException("Invalid stable ID: {$id}");
    }

    if (isset($seenIds[$id])) {
        throw new RuntimeException(
            "Duplicate stable ID {$id}: {$seenIds[$id]} and {$absolutePath}"
        );
    }

    $hash = hash_file('sha256', $absolutePath);

    if ($hash === false) {
        throw new RuntimeException("Unable to hash {$absolutePath}");
    }

    if (isset($seenHashes[$hash])) {
        throw new RuntimeException(
            "Duplicate report content: {$seenHashes[$hash]} and {$absolutePath}"
        );
    }

    $relativePath = 'docs/long-term-memory/reports/'
        . str_replace(
            DIRECTORY_SEPARATOR,
            '/',
            substr(
                $absolutePath,
                strlen($reportsRoot) + 1
            )
        );

    $reports[] = [
        'id' => $id,
        'title' => $title,
        'path' => $relativePath,
        'sha256' => $hash,
        'bytes' => $file->getSize(),
        'authority' => $authority,
        'review_status' => $reviewStatus,
        'publication_status' => $publicationStatus,
        'topics' => $topics,
    ];

    $seenIds[$id] = $absolutePath;
    $seenHashes[$hash] = $absolutePath;
}

usort(
    $reports,
    static fn(array $left, array $right): int =>
        strcmp($left['id'], $right['id'])
);

$export = [
    'schema' => 'killwebs-doc-index/v1',
    'package_id' => 'killwebs-com',
    'generated_at' => gmdate(DATE_ATOM),
    'report_root' => 'docs/long-term-memory/reports',
    'report_count' => count($reports),
    'reports' => $reports,
];

$json = json_encode(
    $export,
    JSON_PRETTY_PRINT
    | JSON_UNESCAPED_SLASHES
    | JSON_UNESCAPED_UNICODE
    | JSON_THROW_ON_ERROR
) . PHP_EOL;

atomicWrite($exportPath, $json);

$ledger = file_get_contents($ledgerPath);

if ($ledger === false) {
    throw new RuntimeException("Unable to read {$ledgerPath}");
}

$pointerLines = [START_MARKER];

foreach ($reports as $report) {
    $pointerLines[] = sprintf(
        "- %s\n  - title: %s\n  - path: ../%s\n"
        . "  - sha256: %s\n  - authority: %s\n"
        . "  - review_status: %s\n  - publication_status: %s",
        $report['id'],
        $report['title'],
        $report['path'],
        $report['sha256'],
        $report['authority'],
        $report['review_status'],
        $report['publication_status']
    );
}

$pointerLines[] = END_MARKER;
$generatedBlock = implode("\n", $pointerLines);

$pattern = '/'
    . preg_quote(START_MARKER, '/')
    . '.*?'
    . preg_quote(END_MARKER, '/')
    . '/s';

if (preg_match($pattern, $ledger) !== 1) {
    throw new RuntimeException(
        'The long-term-memory ledger is missing generated markers.'
    );
}

$updatedLedger = preg_replace(
    $pattern,
    $generatedBlock,
    $ledger,
    1
);

if (!is_string($updatedLedger)) {
    throw new RuntimeException('Unable to update pointer ledger.');
}

atomicWrite($ledgerPath, $updatedLedger);

fwrite(
    STDOUT,
    sprintf("Indexed %d reports.\n", count($reports))
);

The public /reports.php controller should read only the generated index, reject records whose publication_status is not public, resolve the indexed path below the approved report root, and render Markdown through a project-owned limited parser or a deliberately restricted subset. It should never accept a raw filename or include arbitrary PHP based on a query parameter.

AI-ready public projection. UAIX expects a concrete evidence set including a public manifest, .well-known discovery, route inventory, readiness result, robots.txt, sitemap, advisory llms.txt, structured data, visible support boundaries, and targeted checks. These records should agree with human-visible canonical pages and must not expose private routes, secrets, or unsupported capabilities. citeturn9view0turn9view2turn9view3

Recommended generated outputs are:

/.well-known/ai-ready.json
/ai-ready-manifest.json
/route-inventory.json
/readiness-result.json
/content-index.json
/source-index.json
/llms.txt
/robots.txt
/sitemap.xml

The public records should state that KillWebs.com supports reading public content and public-safe JSON, but does not provide authentication, arbitrary tool execution, content mutation, targeting services, credential validation, operational planning, or automatic authority. Unsupported actions should produce a no-op response or a clear human-review instruction, not a fabricated capability. UAIX explicitly states that AI-ready records do not themselves authorize scraping, bypass policy, execute workflows, validate credentials, certify vendors, or prove safety. citeturn9view2

Security, privacy, compliance, and deployment

The site’s security objective is not military-system certification. It is to build a resilient public educational property whose implementation reflects the principles it discusses: least privilege, explicit trust boundaries, integrity, provenance, graceful degradation, local operation, and defensible publication controls.

Zero-trust application model.

NIST describes zero trust as protecting resources rather than trusting network segments and recommends security and privacy controls covering access, audit, configuration, incident response, communications, integrity, supply chain, and privacy. citeturn7view5turn7view6

Security-header baseline.

<?php

declare(strict_types=1);

$nonce = rtrim(
    strtr(base64_encode(random_bytes(18)), '+/', '-_'),
    '='
);

header("Content-Security-Policy: "
    . "default-src 'none'; "
    . "script-src 'self' 'nonce-{$nonce}'; "
    . "style-src 'self'; "
    . "img-src 'self' data:; "
    . "font-src 'self'; "
    . "connect-src 'self'; "
    . "worker-src 'self'; "
    . "manifest-src 'self'; "
    . "media-src 'self'; "
    . "object-src 'none'; "
    . "base-uri 'none'; "
    . "form-action 'self'; "
    . "frame-ancestors 'none'; "
    . "upgrade-insecure-requests"
);

header('Strict-Transport-Security: max-age=31536000; includeSubDomains');
header('X-Content-Type-Options: nosniff');
header('Referrer-Policy: strict-origin-when-cross-origin');
header('Cross-Origin-Opener-Policy: same-origin');
header('Cross-Origin-Resource-Policy: same-origin');
header('Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=()');

The exact permissions policy may be relaxed only on an explicitly approved WebXR route. A strong CSP should restrict remote scripts, inline execution, framing, object loading, and external form submission. OWASP recommends delivering CSP as an HTTP response header, using nonce- or hash-based policies where inline scripts are unavoidable, and using frame-ancestors, form-action, object-src, and same-origin fetch restrictions as defense-in-depth controls. citeturn8search0turn8search1

Session policy. The public launch should not need PHP sessions. If a future administrative area uses them, PHP’s official security guidance supports cookie-only sessions, strict mode, HTTP-only cookies, secure transport, and an appropriate SameSite setting. citeturn7view7

Recommended settings are:

session.use_only_cookies = 1
session.use_strict_mode = 1
session.cookie_httponly = 1
session.cookie_secure = 1
session.cookie_samesite = "Strict"
session.cookie_lifetime = 0
session.use_trans_sid = 0

Local-only privacy model.

The privacy page should name every storage key, its purpose, approximate size, expiration behavior, and clear mechanism. It should explicitly state that no learning record is synchronized between KillChains.com and KillWebs.com.

OWASP advises excluding session identifiers, tokens, credentials, keys, sensitive personal data, and higher-classification material from logs, and applying deletion, masking, sanitization, hashing, or encryption where identifiers are unnecessary. citeturn8search3

File and publication controls.

No public file-upload feature should exist in the first release. Reports should enter through a controlled source repository or local administrative process. If uploads are added later, they should be stored outside the web root, renamed to server-generated identifiers, size-limited, type-allowlisted, scanned, protected against CSRF, and made public only through an indexed retrieval handler. OWASP specifically recommends storing uploaded files outside the web root where possible and mapping public access through application-controlled identifiers. citeturn8search2turn8search9

The /docs directory may remain in the repository root while the web server applies one of two models:

.uai/, config/, scripts/, tests/, .git/, storage logs, source maps, backup archives, environment files, and internal /docs subtrees must be denied at the web-server level.

Content-sensitivity boundary.

KillWebs.com should publish only material approved for unrestricted public release. The following must be prohibited from reports, scenario data, .uai, JSON indexes, logs, and source control:

• Classified information.
• Controlled unclassified information unless the hosting environment is specifically authorized.
• Real-time or tactically precise force locations.
• Real target packages or operational target data.
• Credentials, keys, tokens, or private endpoints.
• Nonpublic vulnerability details that enable exploitation.
• Weapon-design parameters or instructions.
• Operational rules of engagement.
• Personally identifiable information not required for public authorship.
• Unreviewed claims presented as official doctrine or fielded capability.

If future requirements include CUI, classified data, partner-restricted information, or real operational feeds, the proposed public PHP website is not an acceptable continuation environment. That would require a separate system boundary, authorization process, identity architecture, logging policy, data handling rules, and likely an accredited hosting environment.

DoD data guidance emphasizes architecture, standards, governance, and making data visible, accessible, understandable, linked, trustworthy, interoperable, and secure. Those principles are useful publication analogies, but KillWebs.com must not imply that adopting them makes the site a DoD system or grants compliance certification. citeturn5search1

Dependency and supply-chain controls.

Build and deployment checklist.

Delivery roadmap and acceptance criteria

A twelve-week delivery is realistic for a disciplined first release that reuses the supplied PHP shell while rebuilding the content, graph model, identity, security configuration, and memory records.

gantt
    title KillWebs.com implementation roadmap
    dateFormat  YYYY-MM-DD
    axisFormat  %b %d

    section Foundation
    Ownership and source audit              :a1, 2026-08-03, 5d
    Requirements and architecture decisions :a2, after a1, 5d
    Repository fork and identity reset      :a3, after a2, 5d

    section Product and content
    Information architecture and route map  :b1, 2026-08-10, 10d
    Report deduplication and source review   :b2, 2026-08-10, 15d
    Canonical content drafting              :b3, after b1, 20d

    section Engineering
    Shared PHP shell and theme               :c1, 2026-08-17, 10d
    Graph data model and local Three.js      :c2, after c1, 15d
    Explorer and resilience scenarios        :c3, after c2, 15d
    ACK and interoperability labs            :c4, 2026-09-07, 15d

    section Memory and discovery
    Docs hierarchy and stable report IDs     :d1, 2026-08-17, 10d
    UAIX memory rebuild                      :d2, after d1, 15d
    AI-ready public artifacts                :d3, after d2, 10d

    section Assurance
    Security and privacy hardening           :e1, 2026-09-21, 10d
    Accessibility and performance testing    :e2, 2026-09-28, 10d
    Editorial and source verification        :e3, 2026-09-28, 10d

    section Release
    Staging and reciprocal links             :f1, 2026-10-12, 5d
    Acceptance and remediation               :f2, after f1, 5d
    Production release                       :milestone, f3, 2026-10-26, 1d

Milestones and exit criteria.

Minimum launch acceptance criteria.

The governing product principle should remain visible throughout the implementation:

KillChains.com explains how a selected sequence progresses and where it can be interrupted. KillWebs.com explains how multiple authorized sequences can be composed, compared, degraded, and recomposed without confusing connectivity with authority, confidence, or legality.

That distinction gives the two properties a coherent relationship while preventing KillWebs.com from becoming a renamed duplicate. It also aligns with the uploaded research consensus that the chain remains the execution path while the web supplies the changing option space around it. fileciteturn0file7 fileciteturn0file11