Starter Instruction

Copy this prompt into a new AI session when continuing the project.

Continue the source-linked MkDocs Material knowledge wiki for InterSystems.

Purpose and direction:
This wiki informs guidance, decisions, delivery, research, and assurance for
InterSystems healthcare evidence, with a strong UK/NHS digital-health focus. Do
not treat the end guidance itself as a research priority. Treat research
priorities as evidence gaps, synthesis gaps, implementation gaps, and confidence
limits that prevent reliable guidance.

Separate:
- Source Register: provenance and source inventory.
- Evidence Matrix: claim-level support, confidence, and limitations.
- Evidence Validation Queue: To Do items, unresolved evidence gaps, blockers,
  assumptions, and boundaries.
- Research Log: Done items, completed passes, findings, and decisions made.
- Synthesis Pages: human-readable conclusions and current working position.
- Architecture / Model Pages: system, process, policy, domain, or implementation
  structure.
- Glossary: maintained terms, acronyms, aliases, and definitions.
- Operational / LLM Wiki: maintenance rules, project conventions, starter
  instructions, and agent guidance.
- Generated indexes / graph views / tool outputs: navigation and discovery aids,
  not source truth.
- Optional OKF exports: portability and interchange layers over the canonical
  wiki, not evidence authority or replacement structure.

Anchor-page discipline:
Check each related pass against the current model anchors recorded in
docs/llm-wiki/context-map.md. If a new source changes the model, update the
anchor page, affected synthesis pages, evidence records, validation queue,
research log, glossary, and operational notes as needed.

Evidence and architecture discipline:
Put direct evidence first, adjacent implementation evidence second, and wider
contextual evidence only where it changes interpretation. Keep user-facing
outcomes, source systems, integration routes, policy constraints, data
dependencies, assurance requirements, and implementation status separate. Name
the specific system, interface, policy, cohort, process, role, supplier,
jurisdiction, or implementation stage when a claim depends on it. Distinguish
confirmed facts, inferred relationships, open questions, assumptions, and future
validation options.

Reusable assurance mechanics:
Use the standards-conformance evidence request pattern in
docs/evidence-domains/standards-interoperability.md when a certificate, register,
validation row, supplier-progress row, standards claim, or product conformance
statement could be over-read as deployment proof. Apply it to one live assurance
claim at a time, starting from docs/evidence-validation-queue.md. Do not create
another request pack when a link to the reusable pattern is enough; add a pack
only when the claim is actively used for assurance, procurement, delivery,
research decisions, or implementation planning and needs materially different
evidence. Before creating any new page, checklist, request pack, or
evidence-domain layer, run the stop/go check in
docs/source-evidence-domain-map.md; promote structure only when repeated
traversal across module pages, sources.md, evidence-matrix.md, and the queue is
blocking clear synthesis or when an active assurance claim needs a concrete
evidence request. Keep single-source gaps, unresolved source targets,
supplier-response targets, FOI targets, and generic concerns in
docs/evidence-validation-queue.md until a real assurance decision, new source,
response trigger, or repeated traversal pressure justifies new structure.

Use strict builds, source IDs, explicit uncertainty labels, DESIGN.md as the styling source of truth, `npm run kb:update` for generated wiki/Graphify artifacts, and browser-local revision tooling only when learning workflows are in scope. The local workstation wiki is served persistently at `127.0.0.1:8002` by the `com.andrew.intersystems-wiki` LaunchAgent.

If Open Knowledge Format (OKF) compatibility is reopened, prefer a generated
sidecar export from `docs/` before an in-place conversion. An in-place OKF
profile is mechanically feasible but needs an explicit stop/go decision because
OKF frontmatter, `index.md`, and `log.md` semantics can blur this project's
existing page-role model. Keep OKF output out of Graphify and MkDocs ingestion
unless those rules are deliberately changed and verified.

After every substantive response, include a `What Next` section with exactly
three numbered, high-impact, actionable follow-up steps tied to wiki pages or
project artifacts where possible. Include rendered wiki URLs when the local wiki
URL is available.

Balance `What Next` recommendations across closure, synthesis, and breadth
unless the user explicitly asks to stay inside one evidence trail: one step to
advance the current gap, one to update or challenge the affected anchor model,
and one to broaden the next pass into an adjacent source/evidence domain. Do not
keep deepening the same queue item without new evidence, a response trigger, or
a direct user instruction. Treat Source and Evidence Domain Map, Evidence
Validation Queue, and Context Map as background controls, not default follow-up
recommendations, unless the next step is a concrete edit, gate decision, or
validation action on that artifact.

Do not count passive trigger conditions, "wait until a source appears" items, or
generic maintenance reminders as `What Next` steps. Parked boundaries belong in
the summary, Evidence Validation Queue, Research Log, or affected synthesis page.
The three numbered steps must be work that can actually be performed in the next
pass.

Sibling-Project Equivalent Prompt

Use this shorter prompt in a sibling project's root agent instructions or starter wiki artifact before the next evidence pass.

Maintain the knowledge base as evidence plus synthesis, not as accumulating
checklists. Reuse a canonical conformance-request pattern only when a named
assurance claim needs certificate, scope, exclusions, component coverage,
adjacent-standard, or deployment proof. Keep single-source gaps in the Evidence
Validation Queue. Before creating a page, checklist, request pack, or evidence
domain, apply the structure gate: does it reduce repeated traversal or make an
active decision actionable? If not, update the existing page, queue, context map,
and log instead. In `What Next`, use the numbered steps only for work that can be
performed in the next pass; record passive triggers and parked trails as
boundaries, not as next steps.