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. docs/project/status.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 query results when Graphify is selected.

Subject and scope

The central question is what information healthcare and social care organisations must legally send digitally or make digitally available across all four UK nations. Publicly funded healthcare organisations are primary; private healthcare is compared. Individual care receives the most attention. Planning, research and public health are also in scope; the earlier care-only boundary has been superseded.

Start with the home answer, then the comparison and worked exchanges. Use the digital requirements register for exact records. Read its information, sender, recipient, method/standard, deadline, authority and applicability together. Then use the responsibility, legal-framework and national views to explain that row. Preserve the distinction between statutory or prescribed-contract duties, adopted contractual terms, saved have-regard standards, administrative mandates, guidance and operational evidence. A model contract does not prove an unseen local contract.

Use the three worked cases: SCR/equivalent records, blood tests/results and hospital discharge. The capacity and representation map supports the relevant care, disclosure and proxy decisions. It does not create a universal interoperability dataset.

Protection concerns can arise at any point in care. The child/adult protection examples use hospital discharge as one worked setting; that setting does not limit the general protection account.

The baseline contains 268 registered sources. Canonical concepts include digital requirements and capacity/representation alongside the national and cross-cutting accounts. Local project wikis remain discovery leads; they cannot replace primary legal authority. Retained product-regulation context and history remain labelled by their actual relevance.

The national service-report comparison defines “return” as a report and keeps legal reporting duties, extraction availability, claim conditions and operational targets distinct. Do not reopen the completed four-example comparison or promote the qualified NI/SMR findings without their recorded evidence trigger.

Reader priority: boards/senior decision-makers, then specialists, with general readers supported by definitions. Preserve answer → comparison → application → national/legal detail → exact reference → evidence. Review semantics manually; do not claim an automated narrative or prose-quality score.

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.

Complete the requested scope before recommending more work. At the end of every development cycle, assess the Wiki's continuing subject, governing question when declared, evidence and content maturity. Prioritise subject content and evidence work; address a failed or unrun required check before optional content work. Include no more than three prioritised Next Steps. Each must fit one follow-up pass and state Proposed update:, Why it matters: and Done when:. Suggestions are recommendations, not continuation authority. Use project status, the validation queue and relevant handoff evidence to exclude completed work. Do not reopen bounded, parked or evidence-blocked work without new evidence, a due scheduled recheck or explicit user instruction. Parked work retains blocked_by, reopen_when and last_checked. If no grounded content update or required follow-up qualifies, state No further grounded content update is available. Never invent filler. Check captured drafts with response:next-steps:check when available; format checks do not prove grounding or intercept uncaptured responses.