Each step of Verixa_Demo_User_Journey.html verified against dev-vimal-deploy (file:line) and the Target-State URS (clause). Verdict distinguishes a true demo risk (HTML claims more than the system does) from a build gap (the URS wants it, code hasn't built it).
| Step (AC) | HTML flow claim | Current code (dev-vimal-deploy) | URS (target) | Verdict |
|---|---|---|---|---|
| Segment 1 — Deviation (Ravi, Reporter) | ||||
| DV-1/3 | Ravi raises a deviation and selects classification + severity himself; unique ID + audit on submit. | Human-set severity persisted + audited. deviations/service.ts (create), workflow.ts | "severity (minor/major/critical)… the human investigator's signed decision is the system of record." URS-16 §0.4, §1 | Aligned |
| DV-4a | Generative classification/severity is OFF by default; no LLM call; would need a signed exception. | Fail-closed gate; off by default and requires a validated model. ai/classification.service.ts:48; mig 227:129 DEFAULT false; feature-gate.ts:77 | "Generative/probabilistic AI is PROHIBITED in classification disposition, severity-driven escalation… closure-disposition." URS-16 Arch-Bindings, §0.4; Annex 22 | Aligned |
| DV-7 | Assigning the reporter as investigator is blocked (investigator ≠ reporter). | Enforced at 4 boundaries (create, dedicated field, transition, picker). service.ts:437,537,1023,3054 — SoD-16-01 | "The named investigator (independent of discoverer per SoD-16-01)." URS-16 §0.4, §0.6 | Aligned |
| Segment 1b — Triage (second authority) | ||||
| DV-8 | A separate person with "classification/triage authority" (not the reporter) confirms triage as a distinct step, then assigns Meera. | Triage is a real routed step (claim-triage, eligible-investigators) but rides on open/pending — no distinct triage state, and code comment notes "the actor running triage may be the reporter." service.ts:1020,2970; routes.ts:548 |
Lifecycle is draft → investigating → closed | voided — no "triage" state; the named SoD is investigator ≠ discoverer, not triager ≠ reporter. URS-16 §0.5 state machine |
HTML overclaims |
| Segment 1 — Deviation closure (later in chain) | ||||
| DV-12 | Critical close needs executive co-sign + a linked closed CAPA. | Critical executive co-sign fully routed; CAPA-closed gate enforced. routes.ts:1139; service.ts:1808,3334 — SoD-16-07 | "Critical deviations… require executive authority co-sign. SoD-16-04: investigator ≠ closure authority." URS-16 §0.4 | Aligned |
| DV-11 | Major close adds practice-lead co-sign + independent QA reviewer. | majorCoSign service method exists but is not wired to any HTTP route (only critical-cosign routed). service.ts:1911; routes.ts (no major route) |
"major: + practice_lead_* co-sign at closure." URS-16 §0.6 | Code behind URS |
| Segment 2 — RCA (HTML: 3 users — Meera draft → Priya conclude → Anand close) | ||||
| RC-3/4/5 | MIRA advisory only; accept/edit/discard all human; original retained on reject. | Confirmed; AI original + human final stored; no RCA-table write by AI. rca/service.ts; URS-17 mapping | "no AI service writes to rcas, rca_contributing_factors, rca_conclusions… signed conclusion is system of record." URS-17 §0.4 |
Aligned |
| RC-6/7 | Three distinct users required: drafter ≠ concluder ≠ closer; "no single person carried it end to end." | drafter ≠ approver ✓ (service.ts:853) and drafter ≠ closer ✓ (:1258), but approver ≠ closer is NOT enforced — a 2-user flow passes every check. createConclusion has no SoD. service.ts:614,819,1229 |
Only SoD-17-01: creator ≠ approver ("reviewer independence") is required. URS does not mandate a third distinct closer. URS-17 §0.4, glossary | HTML overclaims |
| RC-7 | Anand "closes" the RCA as a separate controlled signed disposition; approver authority rca_lead. |
RCA close has no authority check and no e-signature (route comment: "administrative cleanup") — it is not a signed disposition. The e-sign gate is at approval, not close. (Also: approve checks literal 'rca_lead' while mig 319's seeded rca_approval_authority/rca_close_authority keys are unused.) service.ts:896,1229; routes.ts:488 |
Conclusion/approval is the e-signed gate (SoD-17-01); authority profiles named are investigation_lead_authority, final_quality_approver, executive_authority. URS-17 §0.3, §0.4 |
HTML overclaims |
| — | CAPA is created "from the approved RCA" (implies approval gates CAPA). | CAPA creation does not require an approved/closed RCA; the gate runs the reverse (RCA can't close without an effective linked CAPA or justification). capas/service.ts:296; rca/service.ts:1270 | RCA emits rca_conclusion_created as a downstream CAPA recommendation handoff — a handoff, not a hard precondition. URS-17 §0.2 |
Cosmetic |
| Segment 3 — CAPA (HTML: 5 users — author → assignee → item-review → effectiveness → close) | ||||
| CA-3 | Meera authors plan + effectiveness criteria; action items have assignee + due date. | Confirmed; capa_action_items.owner_id, due_date, status. Status enum is pending/in_progress/completed/cancelled (HTML says "Open→Done"). mig 076; service.ts:1495 |
Action-item lifecycle "open/in_progress/completed/cancelled with assignment, due-date, closure evidence." (URS says open; code says pending.) URS-18 §1 |
Drift (status names) |
| "Rohan" | Per-item: a reviewer (≠ assignee) reviews each action item and closes it Completed/Cancelled. | Not implemented. capa_action_items has only owner_id — no reviewer field, no item-level SoD; any permitted user can flip an item to completed. mig 076; service.ts:1495 |
URS requires "reviewer-signed completion" of action items. URS-18 §1 (action-item lifecycle) | Code behind URS |
| CA-8 | Divya does the effectiveness check (≠ author). | Enforced at the effectiveness_check/verified transitions (verifier ≠ creator AND ≠ assignee) + e-sig. service.ts:553,566 |
"SoD-18-03: effectiveness reviewer ≠ CAPA owner." URS-18 glossary, §0.3 | Aligned |
| CA-7/10/12 | Author can't approve/eff-check own; Anand closes with e-sig; close blocked until effectiveness verified + all items closed. | All enforced: approver/closer ≠ creator/assignee; close needs verification_result='effective' AND all items terminal; closure e-sig mandatory. service.ts:638,666,787,1026 — SoD-18-01/04, DEC-18-16 |
"closure requires verified… bound e-signature on closure (DEC-18-16/13); SoD-18-01 approver ≠ owner." URS-18 §0.4 |
Aligned |
| CA-4/5/11/6 | MIRA can't draft/prioritise/close; no AI write to CAPA tables. | Confirmed; capa-ai advisory-only, writes only its own ai_requests. capa-ai.service.ts:14,115,224 |
"no AI service writes to capas, capa_action_items, capa_effectiveness_checks… generative AI prohibited in prioritisation/closure." URS-18 §0.4 |
Aligned |
| Segment 4 — Document Control (HTML: 4 users — author ↔ reviewer → approver → effectivity) | ||||
| DC-1/3/6 | Upload SOP v1, versioned + audited; each edit a new version attributed to editor. | Confirmed; version increments, created_by, append-only versions. documents/service.ts:1668; mig 325/346 |
"Documents are versioned… every transition electronically signed." URS-12 §0.4, §0.5 | Aligned |
| DC-4/9 | MIRA review advisory; refused for batch/MBR before any AI call. | Deterministic gate before any LLM call; blocked list incl. MBR/batch-release. document-review-ai.service.ts:88; constants.ts:19 | "AI review suggestions advisory… no AI service is the sole path to approve/publish." URS-12 Arch-Bindings, §0.4 (ARCH-AI-001) | Aligned |
| "Karthik" | Reviewer records remarks and sends back; author corrects; round-trip loop; reviewer ≠ author. | Fully confirmed: reviewer_note + request_changes → in_review→draft send-back loop; reviewer ≠ author (SoD-12-01). document-review/service.ts:156,1277,1861 |
Document-Review lifecycle in_progress → revision_requested → in_progress; "DOC-009… review initiator cannot also be the approver." URS-12 §0.4, §0.5 |
Aligned |
| DC-7/8 | Author can't approve own SOP; Anand approves + e-signs (identity/meaning/time/version). | Enforced; approver ≠ author + mandatory e-sig; prior reviewer barred from signing approval. documents/service.ts:3365,3384; esig-sod-check.ts:383 | "named approver(s) sign… every transition electronically signed; initiator ≠ approver (DOC-009)." URS-12 §0.4, §0.5 | Aligned |
| "Priya" | A document controller (≠ approver) sets the effective date as a 4th distinct person. | Separate makeEffective step + own e-sig under document_publisher ✓ — but publisher ≠ approver is NOT enforced, and there is no document_controller authority. documents/service.ts:3933,3970; routes.ts:1764 |
URS: approved → effective "from the effective-from date" — date-driven; URS does not require a controller distinct from the approver. URS-12 §0.4, §0.5 |
HTML overclaims |
| Segment 5 — AI Governance Evidence (Anand) | ||||
| EV-1a/3/4 | Pack assembles live + hash-sealed; live audit trail (before/after); tamper → hash mismatch. | Confirmed; sha256 per-artifact + whole-package hash; export audited. export.service.ts:48; pack.service.ts:972,1019 | Inspection-readiness export consolidated read-only (DEC-22-19); audit trail hash-chain (URS-06). URS-22 §1; URS-06 | Aligned |
| EV-1b/7 | Full per-suggestion provenance + fail-closed LLM audit narrated as target-state. | Correctly target: llmAudit optional; model-id/model-name mapping bug. ai-gateway.service.ts; evidence-pack.service.ts:450 |
Per-suggestion provenance is the URS-32 governance intent (handover/outcome-label) — not yet fully built. URS-32 DEC-32-07/14 | Aligned (honest) |
| Segment 6 — Inspection Readiness (Anand) | ||||
| IR-3 | Readiness scorecard: overall + component scores, formula_version, component_inputs, immutable snapshot. |
Confirmed: readiness-formula-v1.2, 8 weighted components, supersede-then-insert + input hash. (Lives in modules/inspection, not inspection-readiness.) scorecard-formula.ts:5; inspection/service.ts:4400; mig 381 |
"readiness-scorecard… immutable versioned snapshots per DEC-22-09 with explicit formula version, component inputs, explainable component scores." URS-22 §1, glossary; DEC-22-09 | Aligned |
| IR-3 | "If an auditor asks why it says 0.88, we can answer to the decimal" — the on-screen breakdown explains the score. | UI shows only 5 legacy components @ old weights 25/20/25/15/15; the score is computed from 8 v1.2 components. The rendered breakdown does not reconcile to the headline number. InspectionCalendarDetail.tsx:397; mig 242 vs scorecard-formula.ts:7 | DEC-22-09 / INS-DR-009 explicitly requires "frontend contract alignment" with the formula. URS-22 §6 decision table | URS non-conformance |
| IR-1/2 | Dashboard readiness tiles: documentation, CAPA, deviation, training readiness. | Partial: backend dashboard returns active/overdue counts only; tiles are computed client-side from list hooks (training tile real; doc/CAPA/deviation not driven by v1.2 scores). inspection-readiness/service.ts:1564; InspectionDashboard.tsx:60 | URS-38 AN-003: aggregate Inspection-Readiness score/drill-down — explicitly "= build" (not yet complete). URS-38 AN-003 | Code behind URS |
| IR-1 | Calendar tabs: self-inspections, checklists, drills, readiness scorecard, export. | Actual tabs: Self-Inspections, Checklists, Mock Drills, Deficiencies, Back-room, Lessons. Scorecard = a button (not a tab); export = separate flow. InspectionCalendarDetail.tsx:486 | URS-22 lifecycles: self-inspection, checklist, SME, mock-drill, back-room, deficiency, commitment, lessons. URS-22 §0.4 | Cosmetic |
| IR-3/4 | Evidence chain CAPA→RCA→Deviation, every link signed; controlled audited export. | Confirmed; escalation links + e-signed responses; export audited (ie_evidence_pack). export.service.ts:111,288; pack.service.ts:1019 |
"deficiency-response… reviewer-signed evidence; export consuming evidence from every URS module (DEC-22-19)." URS-22 §0.4, §1 | Aligned |
| IR-5 | OOS/batch route unreachable in the demo tenant. | Permission-gated (oos:read/batch:read in Sidebar), hidden only when the persona lacks the permission — not a hardcoded removal. Sidebar.tsx:287,291 |
Scope/RBAC matter (URS-02 permissions), not a deviation/inspection control requirement. URS-02 | Setup (persona perms) |
| Segment +1 — MIRA (Meera) | ||||
| MI-2 | MIRA never writes a controlled domain record; suggests only; suggestions logged. | Static scan across all AI modules: no write to any core register (deviations / rca / capa+children / document_versions / findings / electronic_signatures / readiness_scorecards). AI writes only ai_* / mira_* / prediction / draft tables. But OQ negative tests are thin (only 3 relevant .test.ts) — so this is design-intent + scan evidence, not negative-test-locked proof. mira.service.ts; capa-ai.service.ts:224; AI-module write scan |
"MIRA suggestion-only, non-authoritative… AI output never directly binds a GxP field (ARCH-AI-001 AC-6; DEC-32-01)." URS-32 §0.4, Arch-Bindings | Aligned* — scan-evidenced; OQ tests pending |
| MI-3/6/7/8 | Chat sanitizer, controlled-exception drafting, EU hard-gate = target-state; default OFF for critical. | Correctly target; default off is the real posture. mira.service.ts (no sanitizer) | Handover-task + outcome-label + HITL governance is the URS-32 target; controlled-exception path is forward-looking. URS-32 DEC-32-06/07/08 | Aligned (honest) |
Aligned (green) — most of the spine: deviation SoD, generative-classification-off, doc-control review round-trip + approval e-sig + batch/MBR AI refusal, CAPA-level SoD + effectiveness-gated closure, evidence-pack hashing, the v1.2 immutable scorecard. Demo these with confidence. MIRA never-write is also aligned but carries an asterisk: static-scan-evidenced (no AI write to any core register), not yet negative-test-locked — phrase it as "verified by code scan; OQ negative-test lock on the validation plan," not "proven."
HTML overclaims (red) — fix before anyone rehearses: (1) RCA "three distinct users" + "close as a signed disposition" — code/URS only require drafter ≠ approver; approver ≠ closer is not enforced and RCA close has no e-sig (it's "administrative cleanup"). (2) Doc "controller ≠ approver" effectivity — separate step is real, but the distinct-person rule isn't in code or URS. (3) Triage as a separate authority — code allows the reporter to run triage; the enforced control is investigator ≠ reporter. (4) Scorecard "answer to the decimal" — the UI breakdown doesn't match the formula; this one is also a URS non-conformance (DEC-22-09 requires frontend contract alignment), so it's a real fix, not just narration.
Code behind URS (amber) — build gaps, not HTML errors: CAPA item-level reviewer-signed completion, deviation major practice-lead co-sign route, and dashboard aggregate readiness tiles are all things the URS wants and the HTML stages — but the code hasn't built them. Mark these [TARGET] in the walkthrough; don't show them as live.
Drift (purple): RCA approve checks literal 'rca_lead' while seeded keys (rca_approval_authority/rca_close_authority) are unused; CAPA action-item status is pending not the URS open; calendar tab labels differ. Low-stakes, but fix the AuthorityMap so QA isn't misled.