<!-- Derived Markdown alternate of llm-wiki/index.md; canonical repository sources and registered evidence retain authority. -->


# LLM Wiki entry point

## Read first

1. Repository `AGENTS.md`.
2. `.wiki-standard.yaml`.
3. `knowledge/index.md`.
4. [Context map](https://healthcare-data-management-wiki.pages.dev/llm-wiki/context-map/index.md).
5. [Project status](https://healthcare-data-management-wiki.pages.dev/project/status/index.md).
6. The manifest's `roles.authoring_policy` path, or `AUTHORING.md` when no path is mapped, before writing new original English prose.
7. `DESIGN.md` for rendered changes.
8. [Knowledge graph](https://healthcare-data-management-wiki.pages.dev/graph/index.md) query results when Graphify is selected.

## Operating model

- **Ingest**: register a target source, preserve its identity, add its stable exact-row anchor, update the relevant concept and evidence state, add links, and record the change.
- **Query**: select the smallest authoritative target context, expose uncertainty, and cite registered evidence through individual internal source-row links.
- **Lint**: find contradictions, stale claims, unsupported authority, ungoverned exact repetitions of the declared canonical question, bare or misdirected source identities, unregistered named-authority URLs, missing links, and generated-output drift.
- **Propose**: after a user-authored reusable improvement is implemented, verified, and committed locally, preserve it in a tracked [Standard proposal](https://healthcare-data-management-wiki.pages.dev/llm-wiki/standard-proposals/index.md). Validate direct states and terminal transitions offline, prepare a disposable scrubbed payload, and bind approval to the exact digest and governed form revision. The user submits; intake, Standard decision, exact registry/release evidence, and optional adoption remain separate authorities. Never reuse the Standard's sole historical bridge.

Never treat an LLM answer, rendered page, or graph edge as new evidence.

Apply the DenchCo ASD-STE100-inspired 80% house style in the mapped authoring policy (`AUTHORING.md` when no path is mapped) to all new original English Wiki prose. 80% is a pragmatic aim, not a computed score or a claim of ASD-STE100 compliance. Review meaning and source fidelity before style, preserve protected text and necessary technical terms, and record material exceptions with their scope and reason. Follow explicit user instructions and stricter applicable local policy. Do not bulk-rewrite existing prose or change consumer pins to apply the default.

In a Standard Production maintenance workspace, a file-changing development turn remains incomplete until its persistent changes are recorded in the required end-of-turn JJ commit under `DKBWS-PROV-001`.

Use the tracked proposal workflow for a governed upstream handoff. If the form, label, marker search, provenance, or digest evidence is unavailable or ambiguous, preserve the record and stop; filing does not amend the pinned Standard or authorize migration.

Development responses route Human or LLM Wiki destinations through the configured live canonical HTTP(S) origin under `DKBWS-PROMPT-002`. File, editor, absolute-path, and repository-relative Markdown links do not substitute for Wiki navigation; plain repository paths identify only implementation artifacts with no rendered route. Captured drafts check Markdown, HTML links, and plain GFM-autolinked URLs. Managed local drafts add `--managed-live` to require exact service identity, canonical URL equality, and HTTP 200 for every displayed route; `STD-VAL-007` remains the host boundary for uncaptured output.

Persistent preview handoff uses `npm run service:preview` only after all twelve registry fields, the exact installed/loaded job, canonical URL, and marker identity pass. Live service evidence belongs to maintainer verification; distribution/CI leaves `DKBWS-RUNTIME-002` not checked.

Use project status for zero to three current priorities and the validation queue for parked work. Apply the `AGENTS.md` completion and cycle guard before recommending any follow-up; a completed answer does not need a Next Steps section.

## Subject context

Start with [the research map](https://healthcare-data-management-wiki.pages.dev/research-map/index.md) and [applicability map](https://healthcare-data-management-wiki.pages.dev/applicability/index.md). Use the [glossary](https://healthcare-data-management-wiki.pages.dev/glossary/index.md) for consistent terms and the [architecture](https://healthcare-data-management-wiki.pages.dev/architecture/index.md) for canonical and generated boundaries. The portable knowledge index is `knowledge/index.md`. Read the [maintenance protocol](https://healthcare-data-management-wiki.pages.dev/llm-wiki/maintenance/index.md) before changing sources or claims.

Use “purposes beyond individual care” in explanatory prose, while preserving the canonical question, quotations and source-specific definitions. Under NHS policy, organisations processing NHS patient information must complete and publish annual [DSPT assessments](https://healthcare-data-management-wiki.pages.dev/dspt/index.md). NHS supplier guidance places the purchaser's check of the supplier's latest published status before contract award. Keep annual submission, supplier checking and any contract or access deadline distinct. [SRC-056](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-056), [SRC-081](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-081), [SRC-107](https://healthcare-data-management-wiki.pages.dev/sources/index.md#src-107)

Name the organisation that supplies evidence and the purchaser that checks it. Specify the legal entity, assessment year, status, service coverage and required audit evidence. A fresh assessment is not universally due before procurement starts. DSPT evidence does not supply legal permission or complete DTAC. Apply the actor, basis and deadline rules in the mapped authoring policy.

For every new or revised record-request passage, apply the requester responsibility rules in the mapped authoring policy. Use [requester readiness](https://healthcare-data-management-wiki.pages.dev/requester-assurance/index.md). The requester receives the information; the provider receives the request. Preserve the recruitment DPIA finding as a reasoned application of the published opportunity/special-category trigger. Do not infer that the recipient is the GP's processor or that the GP automatically receives the full DPIA.

For direct GP recruitment records, retain the [worked decision](https://healthcare-data-management-wiki.pages.dev/recruitment-assurance/index.md). The commissioner should require published Standards Met or Standards Exceeded status before the contractor first receives identifiable NHS GP information. The proposed condition maintains that assurance throughout processing. Do not claim that an unreviewed contract already contains it. Identify the exact authority for each use of “mandatory”. The public NDG example concerns an access route, not a DSPT exemption or a finding about an actual supplier.
