Skip to content

Maintenance protocol

Add or revise evidence

For each new candidate report:

  1. Add the discovery and screening decision to icmm/screening_log.csv.
  2. Add or revise a stable source record in evidence/sources.md with provenance, retrieval date, scope, type and reliability notes. Source IDs are persistent: never derive them from row position, renumber them or reuse retired IDs.
  3. If included, add one canonical structured row to icmm/included_cases.csv, populate source_id with that registered ID, and retain the primary source URL, qualification, controlled facets, non-exclusive mechanism codes, verification status and response-evidence status. Register each official response attachment under its own stable source ID and place the pipe-delimited IDs in response_source_ids; never combine multiple documents under one ID or infer implementation from a response.
  4. Add a CLM- row to evidence/claims.csv when a claim needs stable traceability, including its source, report and mechanism mappings, especially when it supports a Defence requirement. Do not create claim rows as empty ceremony for every extracted field; never edit the generated evidence/matrix.md directly.
  5. Update mechanism synthesis in findings/ only when the evidence changes the bounded cross-case interpretation, variation or limitations.
  6. Add or revise a representative narrative page under cases/ only when it materially improves human understanding. These pages do not define the corpus.
  7. Record unsupported assertions, rechecks and missing Defence evidence in evidence/validation-queue.md, and record the research change in evidence/research-log.md.
  8. Run npm run kb:update, then npm run verify.

Do not edit evidence-base/all-reports.md, evidence-base/case-mechanism-map.md or evidence-base/reports/*.md directly. They are regenerated from icmm/included_cases.csv; report pages also reverse-link the controlled case mappings in defence/requirements.csv. Freshness and row/page-count parity are checked automatically.

Maintain Defence traceability

The canonical candidate-control register is defence/requirements.csv; the canonical designed-test register is defence/assurance_tests.csv. Keep stable REQ- and AST- identifiers. A requirement must expose its case IDs, claim IDs, mechanism codes, applicability and validation status. A test must identify its requirement IDs, scenario, method, pass evidence and execution status.

Do not edit defence/requirements.md or defence/assurance-tests.md directly. They are regenerated from the two CSV registers and checked for exact freshness by scripts/generate-defence-pages.mjs.

Never upgrade candidate_*_defence_unvalidated or designed_not_executed on the strength of a literature analogy or drafted scenario. Status changes require the corresponding Defence evidence or executed-test result, with provenance and limitations recorded.

Runtime and generated boundaries

The normal human-site runtime is the registered LaunchAgent-backed service at http://127.0.0.1:8000/. Use npm run up, npm run status, and npm run urls. Use the foreground npm run serve command only for debugging.

Files under docs/evidence-base/reports/, generated pages carrying a GENERATED notice, docs/assets/generated/, graphify-out/, site/, site-sunset/, and root llms*.txt/json are generated boundaries. Change their generators or canonical inputs rather than hand-editing them.

The case–mechanism/evidence map is an analytical view of the included dataset. The Graphify 2D/3D repository graph is a technical orientation tool under About and tools. Neither adds evidence authority.

Production uses stock Zensical runtime chrome from zensical.toml. Keep zensical.sunset.toml frozen and off the always-on service; use npm run check:profiles to preserve shared navigation and content parity.

Ask Wiki runtime

The reader-facing Ask tool is about/ask-wiki.md. Its browser code searches the published Zensical index locally and sends only the reader's question plus up to six retrieved excerpts to /api/ask. The Pages Function in functions/api/ask.js uses the Workers AI binding named AI, the fixed ASK_WIKI_MODEL variable and the required encrypted ASK_WIKI_SHARED_SECRET. It does not read the private Git repository, create answer history or add any evidential authority.

The endpoint fails closed when the secret or AI binding is absent. It compares x-ask-wiki-key with the secret using SHA-256 digests and a constant-time byte comparison, rejects unbounded input, ignores any browser-supplied model choice and returns no-store responses. Never place the secret in Git, wrangler.jsonc, documentation, a URL, browser storage or logs. Use Wrangler's interactive Pages secret command for production and an ignored .dev.vars file only when local Function testing is genuinely required.

Generated answers are navigational synthesis. The system prompt preserves the source/report/claim/mechanism/requirement/test authority distinctions, requires numbered excerpt citations and prohibits clinical advice, patient-specific advice, unsupported product causation and conversion of corpus recurrence into prevalence or trend. These controls reduce foreseeable error but do not validate an answer. Readers must inspect retrieved pages and registered primary evidence.

Cloudflare Pages configuration does not accept the Workers ratelimits binding. This Pages implementation therefore relies on the required high-entropy key, fixed model and request/context/output caps for its in-repository abuse and cost controls. A WAF rule, identity-based Access, per-user quota or migration to a Worker is a separate infrastructure phase and must not be implied as present.

After any endpoint, prompt, retrieval, model, limit or interface change, run npm run check:ask, then npm run kb:update and npm run verify. Test unauthorized access, a supported question, an insufficient-evidence question and a prompt-injection attempt before production publication.