# HAD Digital — Full Project Execution Plan

**Document status:** Draft v0.1
**Date:** 5 September 2026
**Prepared under:** AI Project Governance Standard v3.9
**Specification precedence:** HAD_Digital_Specifications.docx governs all decisions

---

## Table of Contents
1. Project Capabilities (What the MVP Delivers)
2. Full Build Steps (Every Action from Start to Finish)
3. Dependencies (Internal and External)
4. Risks (Comprehensive Register)
5. Assumptions and What Breaks If Wrong
6. Success Criteria

---

## 1. PROJECT CAPABILITIES — What the MVP Delivers

### 1.1 Clinical Capabilities

| # | Capability | Description | Spec Reference |
|---|---|---|---|
| CAP-01 | Patient Toxicity Self-Reporting | Patients and caregivers complete structured questionnaires mapped to CTCAE v5.0 domains (GI, hematologic, dermatologic, neurologic, constitutional). Mobile-friendly, large touch targets, minimal text. | FR-1, S7.2 |
| CAP-02 | Clinician Observation Entry | Home nurses and clinicians enter structured clinical findings: vital signs, skin/wound observations, directly observed toxicity signs. | FR-2 |
| CAP-03 | Automated CTCAE Grading | Rule engine maps structured inputs to CTCAE v5.0 grades 1-5 per adverse event term. Combines patient-reported and clinician-reported data. Grades >=2 flagged provisional until clinician confirmed. | FR-3, S7.3 |
| CAP-04 | Tiered Clinical Alerting | Automatic routing: Routine (timeline only), Urgent (notification to HAD nurse within defined delay), Emergency (immediate notification to on-call oncologist). Triggered by grade + AE type + physician-defined protocol. | FR-4, S7.4 |
| CAP-05 | Patient Guidance | Context-aware guidance shown after symptom report: self-care advice vs contact the team now vs go to emergency. Physician-validated content. | FR-10 |

### 1.2 Coordination Capabilities

| # | Capability | Description | Spec Reference |
|---|---|---|---|
| CAP-06 | Shared Care Timeline | Chronological, role-filtered feed of all events per patient episode: reports, observations, alerts, decisions, messages. | FR-5 |
| CAP-07 | Secure Messaging | Direct messaging between care-team members, attachable to specific alerts or timeline events. Audit trail maintained. | FR-6 |
| CAP-08 | Treatment Plan View | Read-facing display of current systemic therapy protocol, supportive-care prescriptions, home-visit/infusion schedule. | FR-7 |
| CAP-09 | Role-Based Access Control | Each actor sees only information appropriate to their role and relationship to the patient episode. 8 roles: oncologist, HAD coordinating nurse, community nurse, GP, pharmacist, patient, caregiver, admin. | FR-9 |

### 1.3 Documentation Capabilities

| # | Capability | Description | Spec Reference |
|---|---|---|---|
| CAP-10 | Toxicity Summary Export | On-demand generation of structured toxicity summary for insertion into hospital record and follow-up letters. Includes per-symptom grades, timeline, alert history. | FR-8 |
| CAP-11 | Audit Trail | Immutable log of who entered, viewed, modified or acted on each data point, with timestamps. Every clinically relevant action recorded. | FR-11 |

### 1.4 Technical Capabilities

| # | Capability | Description |
|---|---|---|
| CAP-12 | Standalone .exe | Single Windows executable; no installation; no external runtime; double-click to launch |
| CAP-13 | Zero Dependencies | No Python, no Docker, no pip, no npm, no external services required on end-user machine |
| CAP-14 | Portable Deployment | Copy to USB or network share; run from any Windows 10/11 machine |
| CAP-15 | Simple Patching | Drop-in file overwrite; database and config preserved; schema migrations automatic |
| CAP-16 | Local-First | Core functions work without internet; AI engine connector requires network |
| CAP-17 | AI Engine Connector | Pluggable adapter for GLM, Kimi, Gemini, Claude, GPT (per GOV-B7). Stub adapter for offline demo. |
| CAP-18 | Named-User Login | Password-hashed at scrypt; 5-fail lockout; session cookies (per GOV-B7.1) |
| CAP-19 | SQLite Database | Zero-config; file-based; portable; schema designed for PostgreSQL migration |
| CAP-20 | Demo Data | Auto-seeded on first run: 3 sample patients, pre-loaded CTCAE terms, sample reports and alerts |

### 1.5 User Experience Capabilities

| # | Capability | Description |
|---|---|---|
| CAP-21 | Mobile-First Patient UI | Responsive design; large touch targets; minimal text; works on phones and tablets |
| CAP-22 | Desktop Clinician Dashboard | Full-featured dashboard with timeline, alerts, entry forms, export functions |
| CAP-23 | Multi-Role Landing | Each role sees a customized home screen with relevant actions and data |
| CAP-24 | Guidance After Report | Patient receives immediate, actionable guidance based on reported symptoms |

---

## 2. FULL BUILD STEPS — Every Action from Start to Finish

### Phase 0: Project Setup and Framing

| Step | Action | Deliverable | Owner | Estimated Effort |
|---|---|---|---|---|
| 0.1 | Ratify this execution plan with Dr Kais Aldabbagh and Zaid Al Dabbag | Signed-off plan | Master Brain | 1 day |
| 0.2 | Classify project as STANDARD per GOV-A1.8 | Classification record | Master Brain | 30 min |
| 0.3 | Create project folder structure per GOV-F3 | 00_Governance, 01_System, 02_Requirements, 03_Architecture, 04_Build, 05_Test, 06_Archive, 07_Deliverables | Registrar | 1 hour |
| 0.4 | Initialize all registers | Requirements Register, Interface Register, Risk Register, Defect Register, Change Log, Decision Log, Assumptions Register | Registrar | 2 hours |
| 0.5 | Register all requirements from MVP plan (REQ-SYS-01 through REQ-SYS-19, REQ-CON-01 through REQ-CON-08) with all 11 mandatory fields | Populated Requirements Register | Registrar | 3 hours |
| 0.6 | Register all interfaces (IF-01 through IF-12) | Populated Interface Register | Registrar | 1 hour |
| 0.7 | Register all risks (RSK-01 through RSK-15) | Populated Risk Register | Risk Agent | 1 hour |
| 0.8 | Create the Master Brain state file | Master_Brain_State.md with purpose, objectives, plan baseline, live status | Master Brain | 1 hour |
| 0.9 | Run GOV-B2.1 framing check | Framing artefact verified against all 10 items | Verifier | 30 min |

**Phase 0 Exit Gate:** All registers populated; framing artefact complete; project classified; Master Brain state initialized.

---

### Phase 1: Discovery and Requirements Refinement

| Step | Action | Deliverable | Owner | Estimated Effort |
|---|---|---|---|---|
| 1.1 | Identify and prioritize CTCAE v5.0 terms for MVP | CTCAE_Term_Subset.md — list of prioritized terms per domain (GI, hematologic, dermatologic, neurologic, constitutional) | Clinical Advisor + Architect | 2 days |
| 1.2 | Define escalation protocol defaults | Escalation_Protocol.md — grade-based routing rules (grade 1 = routine, grade 2 = urgent, grade 3+ = emergency) with overrides | Clinical Advisor | 1 day |
| 1.3 | Decompose requirements into user stories | User_Stories.md — each REQ broken into testable user stories with acceptance criteria | Architect | 2 days |
| 1.4 | Design UI wireframes for all screens | Wireframes/ folder — patient self-report flow, clinician dashboard, timeline view, alert management, treatment plan, export | UX Lead | 3 days |
| 1.5 | Define role-permission matrix | Role_Permissions.md — which roles can access which screens, data, and actions | Architect + Clinical Advisor | 1 day |
| 1.6 | Define data entities and relationships | Data_Model_Draft.md — Patient, Episode, Treatment Plan, Toxicity Report, Grade, Alert, Message, Timeline Event, User | Architect | 1 day |
| 1.7 | Review wireframes and user stories with stakeholders | Sign-off on wireframes and stories | Master Brain | 1 day |

**Phase 1 Exit Gate:** CTCAE terms prioritized; escalation protocol defined; user stories complete; wireframes approved; data model drafted.

---

### Phase 2: Architecture and Design

| Step | Action | Deliverable | Owner | Estimated Effort |
|---|---|---|---|---|
| 2.1 | Finalize database schema (SQLite) | schema.sql — all tables, columns, constraints, indexes, foreign keys | Architect | 2 days |
| 2.2 | Design API contract (all endpoints) | API_Contract.md — every HTTP endpoint with method, path, request/response schema, auth requirements | Architect | 2 days |
| 2.3 | Design CTCAE grading rule format | ctcae_rules_schema.json — JSON schema for rule definitions; sample rules for 3 terms | Architect + Clinical Advisor | 1 day |
| 2.4 | Design alert routing logic | Alert_Routing.md — how grades map to alert tiers; notification targets per tier; escalation delays | Architect + Clinical Advisor | 1 day |
| 2.5 | Design config.json schema | config_schema.json — all configurable parameters with defaults and descriptions | Architect | 0.5 day |
| 2.6 | Design schema migration system | Migration_Runner.md — how migrations are stored, ordered, executed, and rolled back | Architect | 0.5 day |
| 2.7 | Design build and packaging script | Build_Script.md — PyInstaller configuration, build modes (A/B/C), version stamping, smoke test | Architect | 0.5 day |
| 2.8 | Design AI adapter interface | AI_Adapter.md — base adapter class, required methods, error handling, credential management | Architect | 0.5 day |
| 2.9 | Create system breakdown (N-squared matrix) | SYSTEM_BREAKDOWN.md — all 20 components with dependencies mapped | Architect | 1 day |
| 2.10 | Baseline all architecture artifacts | Baselined architecture set | Change Controller | 0.5 day |

**Phase 2 Exit Gate:** Database schema finalized; API contract complete; all interfaces defined; system breakdown created; artifacts baselined.

---

### Phase 3: Change Control Setup

| Step | Action | Deliverable | Owner | Estimated Effort |
|---|---|---|---|---|
| 3.1 | Establish change control process | Change_Control_Process.md — how CRs are raised, classified, approved, implemented, verified | Change Controller | 0.5 day |
| 3.2 | Initialize change log | Change_Log.md with empty template | Change Controller | 30 min |
| 3.3 | Create archive-before-change procedure | Archive_Procedure.md — how snapshots are taken before any change | Change Controller | 30 min |
| 3.4 | Baseline all planning artifacts | Baselined planning set | Change Controller | 0.5 day |

**Phase 3 Exit Gate:** Change control process established; all artifacts baselined; ready to build.

---

### Phase 4: Implementation (Build)

| Step | Action | Deliverable | Owner | Estimated Effort |
|---|---|---|---|---|
| **4A: Backend Core** | | | | |
| 4A.1 | Implement config manager (C19) | config_manager.py — reads/writes config.json; defaults; key documentation | Builder | 0.5 day |
| 4A.2 | Implement database manager and schema creation (C14) | database.py — SQLite connection; schema creation; migration runner (C18) | Builder | 1 day |
| 4A.3 | Implement audit logger (C13) | audit_logger.py — immutable log; timestamps; attribution | Builder | 0.5 day |
| 4A.4 | Implement user store and authentication (C3) | user_store.py — scrypt hashing; session management; 5-fail lockout | Builder | 1 day |
| 4A.5 | Implement role-based access control (C3) | rbac.py — permission checks per role; episode-scoped access | Builder | 0.5 day |
| **4B: Clinical Engine** | | | | |
| 4B.1 | Implement CTCAE grading engine (C4) | ctcae_engine.py — loads rules from JSON; maps inputs to grades; provisional flagging | Builder | 2 days |
| 4B.2 | Implement alert engine (C5) | alert_engine.py — grade-to-tier mapping; notification routing; escalation delays | Builder | 1 day |
| 4B.3 | Implement guidance engine (C12) | guidance_engine.py — symptom-to-guidance mapping; content loading | Builder | 1 day |
| 4B.4 | Create CTCAE rules data (sample set) | ctcae_rules.json — rules for prioritized terms; proprietary; not in public artifacts | Builder + Clinical Advisor | 2 days |
| 4B.5 | Create guidance content | guidance/ folder — per-symptom guidance text (self-care vs contact team vs emergency) | Clinical Advisor | 1 day |
| **4C: Backend API** | | | | |
| 4C.1 | Implement HTTP server and routing (C2) | server.py — request handling; static file serving; CSP headers; containment checks | Builder | 1 day |
| 4C.2 | Implement auth API endpoints | /api/login, /api/logout, /api/whoami | Builder | 0.5 day |
| 4C.3 | Implement patient API endpoints | /api/patients (CRUD), /api/episodes, /api/treatment-plans | Builder | 1 day |
| 4C.4 | Implement toxicity report API endpoints | /api/reports (submit, list, get), /api/grades | Builder | 1 day |
| 4C.5 | Implement alert API endpoints | /api/alerts (list, acknowledge, escalate) | Builder | 0.5 day |
| 4C.6 | Implement timeline API endpoint | /api/timeline (chronological events per episode, role-filtered) | Builder | 0.5 day |
| 4C.7 | Implement messaging API endpoints | /api/messages (send, list, link to event) | Builder | 0.5 day |
| 4C.8 | Implement export API endpoint | /api/export/summary (structured toxicity summary) | Builder | 0.5 day |
| 4C.9 | Implement AI adapter interface (C15) | adapters/base.py, adapters/stub.py, adapters/glm.py | Builder | 1 day |
| 4C.10 | Implement chat API endpoint | /api/chat (requires auth; routes to adapter) | Builder | 0.5 day |

| **4D: Frontend — Patient** | | | | |
| 4D.1 | Build login page | login.html — responsive; role selection; password field | Builder | 0.5 day |
| 4D.2 | Build patient self-report form (C6) | report.html — structured questionnaire; CTCAE domains; large touch targets | Builder | 2 days |
| 4D.3 | Build patient guidance display | guidance.html — context-aware guidance after report; clear action items | Builder | 1 day |
| 4D.4 | Build patient home screen | patient_home.html — recent reports, upcoming schedules, quick report button | Builder | 0.5 day |
| **4E: Frontend — Clinician** | | | | |
| 4E.1 | Build clinician dashboard | dashboard.html — summary cards, recent alerts, pending actions | Builder | 1 day |
| 4E.2 | Build clinician observation entry form (C7) | observation.html — vital signs, clinical findings, toxicity signs | Builder | 1.5 days |
| 4E.3 | Build care coordination timeline (C8) | timeline.html — chronological feed; event types; role filtering; detail view | Builder | 2 days |
| 4E.4 | Build alert management view | alerts.html — list of alerts; acknowledge; escalate; filter by tier | Builder | 1 day |
| 4E.5 | Build treatment plan view (C10) | treatment_plan.html — regimen, cycle schedule, supportive care | Builder | 1 day |
| 4E.6 | Build messaging interface (C9) | messages.html — thread view; attach to event; send/receive | Builder | 1 day |
| 4E.7 | Build export view (C11) | export.html — select date range; generate summary; download | Builder | 0.5 day |
| 4E.8 | Build admin/user management view | admin.html — user CRUD; role assignment; password reset | Builder | 1 day |
| **4F: Styling and Polish** | | | | |
| 4F.1 | Implement responsive CSS framework | app.css — mobile-first; breakpoints; role-based color coding | Builder | 1 day |
| 4F.2 | Implement client-side JavaScript | app.js — API calls; form handling; dynamic content; error states | Builder | 2 days |
| 4F.3 | Implement empty/loading/error states for all views | All views handle: no data, loading, error, permission denied | Builder | 1 day |
| **4G: Demo Data and Testing** | | | | |
| 4G.1 | Create demo data seed script | seed_demo.py — 3 patients, treatment plans, sample reports, alerts | Builder | 1 day |
| 4G.2 | Write unit tests for CTCAE engine | test_ctcae.py — test grading logic for each sample term | Builder | 1 day |
| 4G.3 | Write unit tests for auth and RBAC | test_auth.py — login, lockout, permission checks | Builder | 0.5 day |
| 4G.4 | Write unit tests for API endpoints | test_api.py — all endpoints; happy path + error cases | Builder | 1 day |
| 4G.5 | Write integration tests | test_integration.py — full flow: login -> report -> grade -> alert -> timeline | Builder | 1 day |

**Phase 4 Exit Gate:** All components implemented; all unit tests passing; demo data seeds correctly; application runs locally.

---

### Phase 5: Integration

| Step | Action | Deliverable | Owner | Estimated Effort |
|---|---|---|---|---|
| 5.1 | Integrate frontend with backend API | All API calls working from browser; error handling complete | Integrator | 1 day |
| 5.2 | Integrate CTCAE engine with report submission | Report submission -> grading -> alert -> timeline flow working end-to-end | Integrator | 0.5 day |
| 5.3 | Integrate alert engine with messaging and timeline | Alerts appear on timeline; notifications sent; messaging linked | Integrator | 0.5 day |
| 5.4 | Integrate export with timeline and grading data | Summary export pulls correct data; format is clinically useful | Integrator | 0.5 day |
| 5.5 | Integration testing — full patient journey | Complete flow: patient reports -> grading -> alert -> clinician reviews -> export | Integrator | 1 day |
| 5.6 | Integration testing — all roles | Each role logs in; performs their primary actions; sees correct data | Integrator | 1 day |
| 5.7 | Record integration test results | Integration_Test_Results.md — pass/fail per interface, per role | Integrator | 0.5 day |

**Phase 5 Exit Gate:** All interfaces tested; full patient journey works; all roles functional; integration defects logged.

---

### Phase 6: Verification and Validation

| Step | Action | Deliverable | Owner | Estimated Effort |
|---|---|---|---|---|
| 6.1 | Independent verification against all REQs | V&V_Report.md — every REQ checked against acceptance criteria; evidence cited | Independent Verifier | 2 days |
| 6.2 | Security review | Security_Review.md — password hashing, session management, RBAC, CSP, containment, audit trail | Risk Agent | 1 day |
| 6.3 | Usability review | Usability_Review.md — patient forms tested for readability; clinician dashboard tested for workflow | Validator | 1 day |
| 6.4 | Performance check | Performance_Check.md — grading response time; page load times; database query times | Verifier | 0.5 day |
| 6.5 | Run Part I compliance audit (all 55 checks) | Compliance_Audit.md — every line pass/fail with evidence | Verifier | 1 day |
| 6.6 | Fix any FAIL items | Defect fixes; re-verify | Builder | 1-3 days |
| 6.7 | Clinical validation of grading logic | Clinical_Validation.md — clinical advisor reviews grading rules and sample outputs | Clinical Advisor | 1 day |
| 6.8 | Stakeholder demo and feedback | Feedback_Log.md — recorded feedback from Dr Kais and Zaid | Master Brain | 1 day |

**Phase 6 Exit Gate:** All REQs verified; security passed; Part I audit passed (or FAILs documented with waivers); clinical validation complete; stakeholder feedback incorporated.

---

### Phase 7: Packaging and Delivery

| Step | Action | Deliverable | Owner | Estimated Effort |
|---|---|---|---|---|
| 7.1 | Create build script (C20) | build.py — PyInstaller configuration; Mode A/B/C; version stamping | Builder | 1 day |
| 7.2 | Build Mode A (single .exe) | dist/HAD Digital.exe — single file, all embedded | Builder | 0.5 day |
| 7.3 | Build Mode B (folder bundle) | dist/HAD_Digital/ — .exe + data + static + config | Builder | 0.5 day |
| 7.4 | Smoke test Mode A on clean Windows VM | Launch .exe; open browser; login; submit report; verify grading | Verifier | 0.5 day |
| 7.5 | Smoke test Mode B on clean Windows VM | Same as 7.4; also test patching (overwrite .exe, preserve DB) | Verifier | 0.5 day |
| 7.6 | Smoke test USB portability | Copy Mode B to USB; run from USB on different machine | Verifier | 0.5 day |
| 7.7 | Create README.txt | Quick-start: how to run, how to patch, how to configure, demo credentials | Builder | 0.5 day |
| 7.8 | Create VERSION.txt | Version number, build date, git hash, component versions | Builder | 30 min |
| 7.9 | Create CHANGELOG.txt | What changed since last version | Builder | 30 min |
| 7.10 | Create Help Hub (GOV-G1) | Help_Hub/ folder — troubleshooting, glossary, deliverables map, FAQ | Builder | 1 day |
| 7.11 | Create deliverables map (GOV-G4) | Deliverables_Map.md — every file, its purpose, its location | Builder | 0.5 day |
| 7.12 | Archive all build artifacts | 06_Archive/ — dated snapshots of all deliverables | Change Controller | 0.5 day |
| 7.13 | Final Part I audit | Re-run all 55 checks on final deliverables | Verifier | 0.5 day |

**Phase 7 Exit Gate:** .exe builds successfully; smoke tests pass; USB portability confirmed; documentation complete; final audit passed.

---

### Phase 8: Handover and Close-Out

| Step | Action | Deliverable | Owner | Estimated Effort |
|---|---|---|---|---|
| 8.1 | Create handover file (GOV-F9.9) | Handover.md — purpose, governance, requirements, tools, registers, live state | Master Brain | 0.5 day |
| 8.2 | Create cold-start test | Cold_Start_Test.md — an operator with only the folder can state purpose, baseline, open items, next action | Verifier | 0.5 day |
| 8.3 | Run cold-start test | Verifier uses only the folder to answer all cold-start questions | Verifier | 0.5 day |
| 8.4 | Harvest reusable lessons | Lessons_Learned.md — what worked, what didn't, what to improve | Improvement Agent | 0.5 day |
| 8.5 | Close-out report | Closeout_Report.md — every request logged with % complete; every phase reconciled; zero Open items | Master Brain | 1 day |
| 8.6 | Transfer pack creation (GOV-F9.11) | Transfer_Pack/ folder — everything needed to hand the project to another team | Master Brain | 1 day |
| 8.7 | Final stakeholder sign-off | Signed acceptance from Dr Kais and Zaid | Master Brain | 1 day |

**Phase 8 Exit Gate:** Handover complete; cold-start test passed; lessons harvested; close-out report delivered; stakeholder sign-off received.

---

### Summary: Total Estimated Effort

| Phase | Days |
|---|---|
| Phase 0: Project Setup | 2 |
| Phase 1: Discovery | 8 |
| Phase 2: Architecture | 7 |
| Phase 3: Change Control | 1 |
| Phase 4: Implementation | 25-30 |
| Phase 5: Integration | 5 |
| Phase 6: Verification | 7-10 |
| Phase 7: Packaging | 6 |
| Phase 8: Handover | 5 |
| **Total** | **66-74 working days** |

This is approximately 3-4 months of focused work, assuming a single builder. With parallel agents (per GOV-C3.1), phases can overlap and the timeline compresses to approximately 2-2.5 months.

---

## 3. DEPENDENCIES — What the Project Needs to Succeed

### 3.1 External Dependencies (Outside the Project Team)

| # | Dependency | Why Needed | Risk If Missing | Owner |
|---|---|---|---|---|
| DEP-01 | Dr Kais Aldabbagh — clinical input | CTCAE term prioritization; escalation protocol validation; grading rule review; clinical validation | No clinically valid grading logic; cannot pass validation | Dr Kais |
| DEP-02 | Zaid Al Dabbag — project owner decisions | Plan ratification; change approvals; requirement clarifications; sign-off | No authority to proceed; decisions blocked | Zaid |
| DEP-03 | Windows 10/11 test machines (clean VMs) | Smoke testing .exe portability; antivirus testing; clean-environment verification | Cannot verify zero-dependency claim | Builder |
| DEP-04 | PyInstaller (build-time) | Packaging Python into .exe | Cannot build .exe | Builder |
| DEP-05 | Python 3.11+ (developer machine) | Development runtime | Cannot develop | Builder |
| DEP-06 | Git (version control) | Version tracking; build stamping; rollback | No version history; no traceability | Builder |
| DEP-07 | CTCAE v5.0 reference document | Grading rules must be based on the official CTCAE standard | Grading logic not clinically grounded | Dr Kais / NCI |
| DEP-08 | Sample patient data (anonymized) | Demo data for testing and demonstration | Cannot demonstrate the system | Dr Kais |
| DEP-09 | Regulatory counsel (post-MVP) | SaMD qualification assessment before clinical pilot | Cannot deploy beyond demo | Project Owner |
| DEP-10 | HDS-certified hosting (production) | Health data hosting compliance for production | Cannot go live with real patient data | Project Owner |

### 3.2 Internal Dependencies (Between Components)

| # | Dependency | From | To | Nature |
|---|---|---|---|---|
| DEP-11 | Database schema must be finalized before any backend code | Phase 2 (Architecture) | Phase 4A (Backend Core) | Blocking |
| DEP-12 | CTCAE rules must be defined before grading engine implementation | Phase 1 (Discovery) + Clinical Input | Phase 4B.1 (CTCAE Engine) | Blocking |
| DEP-13 | Escalation protocol must be defined before alert engine | Phase 1 (Discovery) + Clinical Input | Phase 4B.2 (Alert Engine) | Blocking |
| DEP-14 | Auth system must work before any protected endpoint | Phase 4A.4 (User Store) | Phase 4C.2-4C.10 (All API Endpoints) | Blocking |
| DEP-15 | API contract must be defined before frontend development | Phase 2 (Architecture) | Phase 4D + 4E (Frontend) | Blocking |
| DEP-16 | CTCAE engine must work before alert engine | Phase 4B.1 (CTCAE Engine) | Phase 4B.2 (Alert Engine) | Blocking |
| DEP-17 | Backend API must work before frontend integration | Phase 4C (Backend API) | Phase 5 (Integration) | Blocking |
| DEP-18 | All components must pass unit tests before integration | Phase 4G (Testing) | Phase 5 (Integration) | Blocking |
| DEP-19 | Integration must pass before verification | Phase 5 (Integration) | Phase 6 (Verification) | Blocking |
| DEP-20 | Verification must pass before packaging | Phase 6 (Verification) | Phase 7 (Packaging) | Blocking |

### 3.3 Knowledge Dependencies

| # | Dependency | Why Needed | How Addressed |
|---|---|---|---|
| DEP-21 | Understanding of CTCAE v5.0 grading system | Grading rules must be clinically accurate | Dr Kais input; CTCAE reference document |
| DEP-22 | Understanding of French HAD model | Workflow must match real clinical practice | Spec document; Dr Kais input |
| DEP-23 | Understanding of governance standard v3.9 | Every decision must comply | This plan; governance document |
| DEP-24 | Python packaging knowledge | PyInstaller configuration; bundling; troubleshooting | Builder expertise; PyInstaller docs |
| DEP-25 | Health data regulations (GDPR, CNIL, HDS) | Data handling must comply | Spec document; regulatory counsel (post-MVP) |

### 3.4 Infrastructure Dependencies

| # | Dependency | Purpose | MVP Approach | Production Approach |
|---|---|---|---|---|
| DEP-26 | Database | Persistent storage | SQLite (file-based, zero config) | PostgreSQL (HDS-certified host) |
| DEP-27 | Web server | Serve application | Bundled in .exe (stdlib http.server) | Dedicated server/container |
| DEP-28 | File storage | Static assets, config, logs | Local filesystem (relative paths) | Cloud storage |
| DEP-29 | AI engine | Chat/assistant feature | Stub adapter (offline) or GLM (with API key) | Production adapter with real key |
| DEP-30 | Network | Client-server communication | localhost (no network needed) | HTTPS with valid certificate |

---

## 4. RISKS — Comprehensive Register

### 4.1 Clinical Risks

| RSK | Risk | Likelihood | Impact | Mitigation | Contingency | Owner |
|---|---|---|---|---|---|---|
| RSK-01 | CTCAE grading logic produces incorrect grades | High (MVP without full clinical validation) | High — patient safety | Conservative defaults; all grades >=2 provisional; clinician review mandatory; use official CTCAE reference | Revert to manual grading; flag system as decision-support only | Clinical Advisor |
| RSK-02 | Escalation protocol defaults are inappropriate | Medium | High — missed emergencies | Use widely-accepted oncology triage defaults; clinical advisor review; make rules configurable | Allow physician override per patient | Clinical Advisor |
| RSK-03 | Patient self-report data is incomplete or inaccurate | High | Medium — grading quality affected | Structured questionnaire reduces free-text variability; clinician confirmation for grades >=2; guidance prompts honest reporting | Cross-reference with clinician observations | UX Lead |
| RSK-04 | Guidance content leads to wrong patient action | Low | High — patient safety | Physician-validated content; conservative advice (err on side of contact team); clear disclaimers | Immediate content update via patch | Clinical Advisor |

### 4.2 Technical Risks

| RSK | Risk | Likelihood | Impact | Mitigation | Contingency | Owner |
|---|---|---|---|---|---|---|
| RSK-05 | PyInstaller .exe flagged by antivirus as suspicious | Medium | Medium — blocks deployment | Test on clean VMs; code signing certificate; whitelist instructions for IT departments | Provide folder bundle (Mode B) as alternative; submit to AV vendors for whitelisting | Builder |
| RSK-06 | .exe file size is too large (>200MB) | Low | Low — distribution delay | Optimize PyInstaller excludes; use --onefile for single exe; compress | Accept larger size; use folder bundle mode | Builder |
| RSK-07 | SQLite concurrent access issues | Low (single-site demo) | Medium — data corruption | WAL mode; single-writer design; connection pooling | Migrate to PostgreSQL for multi-user | Architect |
| RSK-08 | Database schema migration fails on patch | Low | High — data loss | Additive-only migrations; test migrations on copy before applying; backup before patch | Restore from backup; manual schema fix | Builder |
| RSK-09 | Browser compatibility issues | Low | Medium — UI broken | Vanilla HTML/CSS/JS; test on Chrome, Edge, Firefox; no framework dependencies | Provide browser-specific CSS fixes | Builder |
| RSK-10 | PyWebView adds unexpected complexity | Medium | Medium — delays | Prefer browser mode for MVP; PyWebView as optional enhancement | Drop PyWebView; use browser mode only | Builder |
| RSK-11 | AI adapter integration fails | Medium | Low — non-core feature | Stub adapter for offline demo; AI connector is optional for MVP core functions | Ship without AI chat; add in V2 | Builder |
| RSK-12 | Portability issues on different Windows versions | Low | Medium — deployment blocked | Test on Windows 10 (1903+) and Windows 11; document minimum version | Provide version-specific workarounds | Builder |

### 4.3 Regulatory and Compliance Risks

| RSK | Risk | Likelihood | Impact | Mitigation | Contingency | Owner |
|---|---|---|---|---|---|---|
| RSK-13 | SaMD qualification required before any clinical use | High | High — timeline impact | MVP is demo/pilot only; engage regulatory counsel early; document intended use carefully | Limit to demonstration; no real patient data until qualification | Project Owner |
| RSK-14 | GDPR non-compliance in demo environment | Low (demo only) | High — legal exposure | No real patient data in demo; anonymized sample data only; clear demo disclaimers | Remove all data; restart with fresh demo data | Risk Agent |
| RSK-15 | Governance standard non-compliance | Medium | Medium — project rejection | Follow GOV-C1.5 stage cycle; run Part I audit; document all deviations | Waiver process (GOV-A1.3) for documented exceptions | Master Brain |

### 4.4 Project and Resource Risks

| RSK | Risk | Likelihood | Impact | Mitigation | Contingency | Owner |
|---|---|---|---|---|---|---|
| RSK-16 | Clinical advisor unavailable for input | Medium | High — blocks grading logic and validation | Schedule regular input sessions; prepare questions in advance; document assumptions for later validation | Use conservative defaults; flag for later clinical review | Master Brain |
| RSK-17 | Scope creep beyond MVP | High | High — timeline blowout | Strict adherence to Spec S4.1 scope; every new request goes through change control; out-of-scope list enforced | Defer to V2; log as improvement proposal | Change Controller |
| RSK-18 | Single builder is a bottleneck | High | Medium — timeline impact | Modular architecture allows parallel work; use sub-agents per GOV-C3.1; prioritize critical path | Extend timeline; add builder resource | Master Brain |
| RSK-19 | Requirements misunderstanding | Medium | High — rework | Requirements register with acceptance criteria; stakeholder review at every gate; wireframes approved before build | Change request process; re-baseline | Architect |
| RSK-20 | Demo environment not convincing | Medium | Medium — stakeholder confidence | Realistic demo data; complete patient journey; all roles functional; pre-seeded scenarios | Prepare scripted demo flow; backup static screenshots | Builder |

### 4.5 Operational Risks (Post-Delivery)

| RSK | Risk | Likelihood | Impact | Mitigation | Contingency | Owner |
|---|---|---|---|---|---|---|
| RSK-21 | Users cannot apply patches | Low | Medium — cannot update | Simple drop-in process; README with screenshots; patch notes clear | Provide remote support; create video walkthrough | Builder |
| RSK-22 | Data loss during patching | Low | High — clinical data lost | Database never overwritten by patch; backup instructions in README; schema migration tested | Restore from backup; manual data recovery | Builder |
| RSK-23 | Application crashes on startup after patch | Low | Medium — cannot use | Smoke test before release; version rollback procedure documented; previous version archived | Revert to previous .exe; report defect | Builder |
| RSK-24 | Users exceed intended scope (real patients in demo) | Medium | High — safety/legal | Clear disclaimers in application; demo mode label; no HDS certification for demo | Immediate stop; data purge; legal review | Project Owner |

---

## 5. ASSUMPTIONS AND WHAT BREAKS IF WRONG

| # | Assumption | Confidence | What Breaks If Wrong |
|---|---|---|---|
| ASM-01 | Python 3.11+ runs on all target Windows machines when bundled by PyInstaller | High | Cannot build .exe; need alternative packaging (Nuitka, cx_Freeze) |
| ASM-02 | SQLite handles the concurrent load of a single-site pilot | High | Need PostgreSQL earlier than planned; adds complexity |
| ASM-03 | CTCAE v5.0 terms can be mapped to structured questionnaire questions | High | Need different input approach; may affect grading accuracy |
| ASM-04 | Vanilla HTML/CSS/JS is sufficient for the UI | High | Need framework (Vue/React); adds build step and complexity |
| ASM-05 | Clinician users have modern browsers (Chrome/Edge/Firefox) | High | Need to support IE11 or older browsers; significant effort |
| ASM-06 | PyInstaller produces a .exe that passes Windows Defender | Medium | Need code signing certificate; additional cost and process |
| ASM-07 | The governance standard's stage cycle is achievable within the timeline | Medium | Need to compress stages; document waivers for skipped steps |
| ASM-08 | Dr Kais can provide clinical input within the discovery phase timeline | Medium | Blocks grading engine and escalation protocol; delays build |
| ASM-09 | The MVP will be used for demonstration only, not with real patients | High | Need HDS hosting, GDPR compliance, regulatory qualification earlier |
| ASM-10 | Drop-in patching is sufficient for the pilot phase | High | Need installer-based update mechanism; adds complexity |
| ASM-11 | The CTCAE grading rules are deterministic (no ML/AI needed for MVP) | High | Need different approach; may affect grading accuracy |
| ASM-12 | Users will read the README.txt for patching instructions | Medium | Need in-app update mechanism; adds V2 feature |
| ASM-13 | The application runs entirely on localhost for MVP demo | High | Need hosting infrastructure; adds deployment complexity |
| ASM-14 | Role-based access control can be implemented with simple session tokens | High | Need OAuth/SAML; adds authentication complexity |
| ASM-15 | The governance standard allows STANDARD-class merging of roles | High | Need full 9-agent staffing; increases overhead |

---

## 6. SUCCESS CRITERIA

### 6.1 MVP Delivery Success Criteria

| # | Criterion | How Verified |
|---|---|---|
| SC-01 | .exe launches on clean Windows 10/11 with no Python installed | Smoke test on clean VM |
| SC-02 | All 12 core features (F1-F12) functional | Feature checklist; demo walkthrough |
| SC-03 | CTCAE grading produces correct grades for sample inputs | Unit tests; clinical validation |
| SC-04 | Alert routing works for all three tiers (routine/urgent/emergency) | Integration test; demo scenario |
| SC-05 | All 8 user roles can log in and perform their primary actions | Role-based test matrix |
| SC-06 | Database survives patching (overwrite .exe, preserve data) | Patch test on copy |
| SC-07 | Application runs from USB stick on different machine | Portability test |
| SC-08 | Zero pip dependencies at runtime | Dependency scan of bundled .exe |
| SC-09 | Part I compliance audit passes (or FAILs documented with waivers) | Audit table |
| SC-10 | Stakeholder demo received positive feedback | Feedback log |

### 6.2 Clinical Validation Success Criteria

| # | Criterion | How Verified |
|---|---|---|
| SC-11 | Grading rules cover prioritized CTCAE terms | Clinical advisor sign-off |
| SC-12 | Escalation protocol matches clinical best practice | Clinical advisor sign-off |
| SC-13 | Patient guidance content is clinically appropriate | Clinical advisor sign-off |
| SC-14 | Export summary is suitable for clinical record insertion | Clinical advisor review |

### 6.3 Governance Success Criteria

| # | Criterion | How Verified |
|---|---|---|
| SC-15 | All requirements traced bidirectionally | RTM orphan counts = 0 |
| SC-16 | All changes classified before implementation | CR log review |
| SC-17 | Builder != Verifier on every artifact | RACI matrix |
| SC-18 | All registers maintained and current | Register completeness check |
| SC-19 | Handover file enables cold-start by new operator | Cold-start test |
| SC-20 | Lessons harvested and documented | Knowledge folder |

---

END OF EXECUTION PLAN