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.
- What Next register: suggestion provenance, relevance, scope and disposition in
  docs/what-next.md; link to existing evidence gaps and outputs.
- 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.

Keep the reading order as UK Core Services Executive Summary → UK Core Services
Matrix → UK Healthcare Connectivity Landscape, followed by country detail. Keep
the summary independent and immediately before the matrix. Reconcile those three
pages and their supporting evidence in the same pass. Preserve source-review
dates, 43 unique matrix functions and 38 grouped summary rows. Keep six Current
Med IS markers synchronised by stable data-med-is keys in the mapped England
service cells, using the shared 21 September 2026 user-reported legend date.
The combined referrals/documents cell has separate e-RS and MESH ticks. The
pathology tick covers EDIFACT over MESH only, not the FHIR pilot. Access cells
stay neutral; the healthcare-network row uses Other for transport. Keep named
System/Portal/Local/Unverified distinctions and the existing right-hand Access
columns, regular Service/Access subheadings and table borders.
Unverified does not mean no integration exists.
The review gate fingerprints the summary body (excluding its marker) and 11
source pages, including the landscape. It checks five topic tables, a separate
DSIC explanation, a cross-border list/table and identical safeguarding repeats
within each page. It also checks the six paired Med IS keys, their England
service-cell mappings and legend date, blocking review recording on mismatch.
Semantic review remains manual. After that review run:
npm run check:core-services-summary -- --record-review
Never automatically acknowledge changes during a build or kb:update.
See docs/llm-wiki/maintenance.md for the reconciliation rule and dependency gate.

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. Before presenting them, record or reconcile each in docs/what-next.md and
link its stable WN entry. Explain purpose and completion in plain English; merge
overlap, park conditional items and retain completed/retired dispositions.
Suggestions do not select or authorise work. Keep detailed evidence targets in
the existing queue and completed-pass detail in the Research Log.

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.