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. When a registered response materially clarifies, disputes or identifies a counter-risk in a report account—or has a documentary anomaly—add a stable DIS- record to evidence/disagreements.csv. Keep its scope neutral, link only row-registered primary/response sources and never adjudicate by preference.
  5. 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.
  6. Update mechanism synthesis in findings/ only when the evidence changes the bounded cross-case interpretation, variation or limitations.
  7. Add or revise a representative narrative page under cases/ only when it materially improves human understanding. These pages do not define the corpus.
  8. Record unsupported assertions, rechecks and missing Defence evidence in evidence/validation-queue.md, and record the research change in evidence/research-log.md.
  9. Run npm run kb:update, then npm run verify.

Do not edit evidence-base/all-reports.md, evidence-base/corpus-profile.md, evidence-base/assurance-and-uncertainty.md, evidence-base/counter-positions.md, evidence-base/case-mechanism-map.md, evidence-base/response-evidence.md, about/data-and-citation.md or evidence-base/reports/*.md directly. They are regenerated from canonical CSV/Markdown inputs; report pages also reverse-link controlled case mappings and counter-positions. 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, defence/assurance-tests.md or defence/finding-requirement-test-crosswalk.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. Its complete 2D and force-directed 3D views share one enriched dataset, but its document, source-reference, navigation and filesystem edges remain operational metadata. Neither graph adds evidence authority. See the Graphify maintenance contract.

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, access password and 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_PASSWORD_PEPPER and ASK_WIKI_PASSWORD_DIGEST values. It does not read the private Git repository, create answer history or add any evidential authority.

The endpoint fails closed when either verifier value or the AI binding is absent. It derives HMAC-SHA-256 from x-ask-wiki-password using the 64-character server-only pepper and compares the result with the configured digest in constant time. The browser clears the password after every submission and creates no session or cookie. The endpoint rejects unbounded input, ignores any browser-supplied model choice and returns no-store responses. Never place the plaintext password or pepper in Git, wrangler.jsonc, documentation, a URL, browser storage or logs. Use Wrangler's interactive Pages secret commands 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. The shared human password is not high entropy and the server-side pepper protects the stored verifier rather than preventing online guessing. The fixed model, request/context/output caps and Workers AI account allowance are the current in-repository cost controls; no per-user or WAF rate limit is claimed. 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.