Project Status
This page is the visible handoff map for the wiki. It does not replace the evidence queue, research log, source register, or synthesis pages; it points to the canonical page for each status function.
Hosting boundary
The source repository is private. The public Cloudflare Pages edition includes the research wiki, LLM Wiki and Graphify views filtered to public files. IRTB(P) pages, drafts, Word files and history (including their LLM build context), revision tools, project operations and the research log remain private. The full local wiki retains them. The owner confirmed this boundary on 23 October 2026. See the public Graphify overview for the graph boundary.
Status Model
| Function | Canonical page | Use |
|---|---|---|
| Current answer | Guidance Decision Model | Guidance-facing status by cohort, feature, route, and evidence state. |
| Executive implementation view | NHS App Adoption and Implementation Executive Summary | Board-facing outcome summary: UK-wide Defence Primary Healthcare (DPHC) mobile access through NHS England, core national services, relevant England-provider appointments, bounded Firmbase reminders introduced alongside SMS, and separately funded later capability. Phase 0-6 appears only as a subordinate technical reference. |
| Capability catalogue and core national service baseline | Core National Services and Roadmap | Canonical user-facing NHS App capability map, current core and national services, route boundaries, and roadmap direction. |
| IRTB(P) decision brief | IRTB(P) Evidence Brief (internal reference) | Controlling Board-paper synthesis. It presents the decision and four neutral options before recommending one, with positive patient value leading and safety evidence supporting the appointment priority. |
| IRTB(P) editable working copy | IRTB(P) Editable Draft (internal reference) | Inline and Markdown editing with immutable local-server snapshots, explicit checkpoints and browser recovery. Word generation and evidence review remain separate. |
| IRTB(P) construction rules | IRTB(P) Construction (internal reference), Defence digital content and writing standard, and IRTB(P) Build Context (internal reference) | Human and machine-readable contract covering public MOD format evidence, retained A4/Arial 12 typography, continuous prose numbering with unnumbered labels, GOV.UK/MOD content and accessibility rules, options-before-recommendation discipline, assurance checks, and acceptance criteria. |
| IRTB(P) draft history | IRTB(P) Draft Version History (internal reference) | Per-version reading and comparisons across original Word revisions, recovered Git changes and new working snapshots. Full text and provenance are accessible to AI review. |
| To Do | Evidence Validation Queue | Evidence gaps, blockers, unresolved assumptions, and boundaries that prevent reliable guidance. |
| Prioritised work | Evidence Work Packages | Work packages tied to the decision each package would unlock. |
| Done | Research Log (internal reference) | Completed research, implementation, maintenance, and synthesis passes. |
| Detailed implementation synthesis | NHS App Adoption and Implementation | Delivery horizons and Phase 0-6 technical route references. The phases classify distinct capability problems and are not a mandatory chain. |
| Source provenance | Source Register | Source inventory and provenance. |
| Source volatility | Source Freshness | Recheck rules for roadmap, API, annual-report, supplier, and cross-deck evidence. |
| Claim confidence | Evidence Matrix | Claim-level support, confidence, and limits. |
| Cross-deck controls | Cross-Deck Evidence Carry-Over | Rules for carrying InterSystems sibling wiki evidence into this wiki. |
| Operating rules | Defence digital content and writing standard, LLM Wiki Maintenance, Starter Instruction, and Agent Rules (internal reference) | Durable content and workflow rules for future passes, including the MOD/GOV.UK writing standard and the stop/go rule before adding new pages, checklists, request packs, or evidence-domain layers. |
Before proposing new structure, use the operating-rule stop/go test first. If the gap can stay in the Evidence Validation Queue, link to an existing reusable pattern, or be handled by updating an anchor page, do that instead of adding another page or request pack.
What Next Rule
Every substantive response should end with a What Next section containing exactly three numbered next steps. This is a whole-project-aware triage, not just a continuation of the latest thread and not a full fresh audit every time.
Each step must be:
- discrete and non-overlapping;
- high-impact for evidence quality, synthesis clarity, implementation confidence, or navigation;
- actionable in one follow-up pass;
- tied to a wiki page or project artifact where possible;
- linked with rendered wiki URLs in user-facing responses.
What Next Assessment Frame
| Step type | Check before proposing it | Typical anchor |
|---|---|---|
| Closure | What evidence gap, implementation gap, validation item, or confidence limit from the current pass can be closed or narrowed next? | Evidence Validation Queue, Evidence Work Packages, Evidence Matrix. |
| Anchor model | Which synthesis, decision, architecture, status, or operational page must absorb the current work so the durable model stays coherent? | Guidance Decision Model, NHS App Adoption and Implementation, Architecture Index, this page. |
| Breadth | Which adjacent source/evidence domain should be rotated into view so the wiki does not over-focus on the freshest unresolved thread? | Source Freshness, Source Register, Cross-Deck Evidence Carry-Over, adjacent feature or component pages. |
Do not repeatedly deepen the newest unresolved thread unless new evidence arrives, a source response is received, a scheduled recheck is due, or the user explicitly asks to stay in that trail.
Cycle guard: if the latest trail is already bounded, parked, or blocked pending direct evidence, do not keep selecting it as the next closure step. Reassess the whole KB gap landscape across decision, architecture, evidence, source-freshness, and implementation pages, then rotate to the next decision-blocking gap. Continuing one topic is appropriate only when the next pass can close a concrete gap, change confidence, or update a controlling anchor.
Current Anchor
Guidance Decision Model is the current answer surface. Core National Services and Roadmap is the canonical user-facing capability catalogue and service-value anchor; component names such as NHS Service Search must not substitute for the capability label Find NHS services near you in user-facing synthesis. NHS App Adoption and Implementation Executive Summary is the decision-maker front door for the implementation argument. NHS App Adoption and Implementation is the detailed technical reference, not the controlling executive model.
IRTB(P) Evidence Brief (internal reference) is a separate Board-paper synthesis. It lists four comparable alternative decisions before selecting Option 3. Its narrative runs through UK-wide access through NHS England, core national services, relevant England-provider appointments and a controlled Firmbase reminder commitment. Firmbase App reminders begin alongside SMS; any later App-first delivery or routine-SMS replacement is a separate evidence-based decision. Internal wiki phase labels do not appear in the staffed document.
Diagram Maintenance Checklist
- Keep diagram source in the relevant architecture or synthesis page; generated graph views are discovery aids, not source truth.
- When a route, component, or implementation assumption changes, check Architecture Index, NHS App Service Architecture, and any affected synthesis page.
- After diagram edits, run
npm run check:mkdocs,npm run check:mermaid, and the wider project verification path before treating the change as complete. - Browser-check dense or changed diagrams at mobile width and record the result in the Research Log (internal reference).