Skip to content

LLM Wiki entry point

Read first

  1. Repository AGENTS.md.
  2. .wiki-standard.yaml.
  3. knowledge/index.md.
  4. Context map.
  5. Project status.
  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 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. 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 and applicability map. Use the glossary for consistent terms and the architecture for canonical and generated boundaries. The portable knowledge index is knowledge/index.md. Read the maintenance protocol before changing sources or claims.

Use “purposes beyond individual care” in explanatory prose, while preserving the canonical question, quotations and source-specific definitions. For NHS information or system access, treat DSPT as an early assurance decision. Keep its scope, current period, entity coverage and evidence separate from legal permission and DTAC.

For every new or revised record-request passage, apply the requester responsibility rules in the mapped authoring policy. Use requester readiness. 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: recommend mandatory DSPT in the service contract without claiming that an unreviewed contract already requires 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.