# Verixa Pilot — Phase 1 / 2 / 3 Build Map (what exists, what to build, why, and how it wins the client)

**Date:** 2026-06-01 · **Repo basis:** `Verixaai/Verixa @ dev-vimal-audit-2 / 3bd2fe47` · **Source:** deep code audit (see `Verixa_Deep_Code_Audit_Status_dev-vimal-audit-2.md`) + locked scope decisions (CC-PILOT-2026-001).
**Discipline:** Verixa **verifies**; the design partner **validates**. No "validated/Part 11-ready" claim without executed evidence + QA disposition.

## The three phases at a glance

| Phase | What it is | Timeline | Win condition |
|---|---|---|---|
| **Phase 1 — Demo (URS-39A)** | A safe, governed demo of the 6 workflows + MIRA on **synthetic data**. Non-GxP, not validated. | Jun–Aug (sales) | **Win the meeting** — a credible, differentiated demo that gets a design partner to say yes |
| **Phase 2 — Verified build (URS-39B)** | The same 6 workflows + MIRA, **hardened and verified**, that the partner validates for intended use. | → **Sep 01** go-live | **Win the validation** — partner validates → referenceable logo + case study |
| **Phase 3 — Expansion** | Batch disposition (URS-23) + full OOS + MBR-driven creation as **full validated modules**. | Post-go-live | **Win expansion revenue** — land-and-expand into the GMP-critical modules |

**Legend (exists in code today):** 🟢 strong/built · ✅ exists (usable) · 🟡 partial · 🔴 absent · ⛔ out of this phase.

---

## PHASE 1 — DEMO (URS-39A)  ·  *win the meeting*

Goal: show prospects a credible, governed product on synthetic data — without overclaiming. Most of this is **configuration of mechanisms that already exist**, plus 3 small builds.

| Item | Exists in code today | Eng action | Why | How it wins the client |
|---|---|---|---|---|
| Demo flag / environment | ✅ `environment_class='demo'` (`resolve-tenant-env.ts`, `regulated-pilot-mode.ts`) | **Connect** — stand up a demo environment | Demo must be non-GxP, not a system of record | Lets you demo safely with zero compliance claims |
| "Not a record" guard (QMS) | 🟢 `DEC-36-07` blocks GxP writes in demo for all QMS routes | **Test** — confirm block on the 6 workflows | Nothing in the demo becomes a real GxP record | "This is governed" credibility to a QA buyer |
| **AI/handover write hole** | 🔴 handover-bridge can write deviations/CAPAs bypassing the demo block | **Build/Fix** — force HITL-always + disable MIRA write-back in demo (or gate handover by `environment_class`) | Closes the one path that could create a real record in demo | Removes the only demo-safety risk; protects the trust story |
| Global demo banner/watermark | 🟡 export watermark only | **Build** — global "DEMO — not validated" banner | Visible so no one mistakes demo for production | Honesty signal that builds trust, not erodes it |
| Curated synthetic dataset | 🟡 seed infra exists (`db/seeds`) | **Build** — curated demo data for the 6 flows + MIRA + seeded batch/OOS refs | Realistic demo without real/PHI data | A demo on the buyer's actual pain (deviation→CAPA, inspection prep) |
| One-click demo reset | 🟡 tenant purge/retention jobs exist | **Build** — demo reset | Re-runnable sales demos | Clean, repeatable demos across prospects |
| Deviation / RCA / CAPA | ✅ built (gates present) | **Connect + seed** | The core QMS story end-to-end | Shows the workflow depth |
| Document Control (4 methods) | ✅ persist/lifecycle/upload built | **Connect + seed** | Authoring → review → effective | Foundational QMS credibility |
| MIRA AI generation (governed) | ✅ advisory, RAG-cited, Annex-22-constrained | **Demo the provenance** (model+prompt+sources+edit delta) | The differentiator, done right | **"AI you can take into an inspection"** — the wedge incumbents can't match |
| Inspection-readiness scorecard | 🟡 scoring/gap built; export absent | **Connect** (show scorecard read-only) | Shows the readiness story | Hits the buyer's most-hated chore |
| OOS as reference/display | ✅ OOS lifecycle built | **Connect** OOS display into deviation | Realistic investigation | Demonstrates the workflow crosses modules |

**Phase-1 net-new build is small:** AI-path demo fix · demo banner · curated seed · reset. Everything else is connect/configure.

---

## PHASE 2 — VERIFIED BUILD (URS-39B)  ·  *win the validation*

Goal: close the integrity and completion gaps the audit found, so the partner can validate. This is where the **audit gaps become the build list**.

| WP | Item | Exists in code today | Eng action | Why | How it wins the client |
|---|---|---|---|---|---|
| WP-4 | E-sig substrate verify on terminal decisions | 🔴 verifier exists (1 caller); CAPA/finding/RCA/change-control **store-only** | **Connect** — route terminal decisions through `validateEsignatureForRecord` | 21 CFR Part 11 §11.70/§11.100 — a signature must be **verified**, not just stored | **#1 thing a pharma QA buyer checks** — Part 11 defensibility |
| WP-13b | Fail-closed AI audit | 🔴 `llmAudit?` optional; inference can run un-audited | **Build** — require LLM hash-chain audit in regulated mode | Annex 22 / EU AI Act Art. 12 — no AI inference un-audited | The AI-governance evidence pack that closes the deal |
| WP-12 | Inspection-readiness **export package** | 🔴 absent (no manifest/hash/export route) | **Build** — selection→gap→disposition→sealed manifest+hash export | An auditor-ready evidence bundle | The differentiator that removes weeks of inspection prep |
| WP-7 | Critical-deviation exec co-sign + SoD fix | 🟡 single approver; SoD is reporter≠closer (not investigator≠closer) | **Build** — exec co-sign for critical; fix SoD basis | GMP critical-deviation governance + segregation of duties | Real GxP rigor a QA head respects |
| WP-2 | Linkage consumers | 🟡 ~95 events emitted, ~10 consumed | **Connect** — deviation/OOS→CAPA, finding→CAPA, document_effective→training | The QMS "nervous system" — workflows must connect | The end-to-end automation story (closed-loop QMS) |
| WP-9/10 | Closure/disposition e-sig + finding→CAPA link | 🟡 store-only / reverse-link only; no `finding_capa_links` | **Build/Connect** — substrate-verify; add finding→CAPA link+event | Integrity + traceability | Closed-loop CAPA an auditor can follow |
| WP-6 | Hash-persist + distribution/read-ack decision | 🟡 hash transient; no distribution/read-ack | **Build or formally defer** (decide scope) | ALCOA+ data integrity; controlled distribution | Document-control completeness |
| WP-11 | Training on document-effective | 🔴 `document_effective` orphaned; assignment manual | **Connect** (wire consumer) **or accept manual** for pilot | Training-on-effective is a GxP expectation | Closed-loop training story |
| WP-1 | Tenant/scope isolation | 🟢 TDAL + RLS + `dedicated_db` | **Test** (regression) | Tenant isolation / data segregation | The trust foundation under everything |
| WP-5 | Audit trail / hash-chain | 🟢 SHA-256 chain + append-only triggers + startup gate | **Test** (regression) | 21 CFR 11.10(e), Annex 11 — tamper-evident records | "Your data is inspection-grade" |
| — | AI/handover gate in prod | 🔴 same bypass as demo | **Build** — gate/audit handover writes | AI must not create records outside governance | Consistent AI governance prod + demo |
| §7C | Validation pack execution | 🔴 not executed | **Test** — run IQ/OQ/PQ; QA disposition | Verification evidence for the partner | The validation-enablement pack that lets the partner validate (G-7) |

**Phase-2 priority order:** WP-4 → WP-13b → WP-12 → WP-7 → WP-2 → WP-9/10 → WP-6/11. (WP-1, WP-5 already strong — protect via regression.)

---

## PHASE 3 — EXPANSION  ·  *win expansion revenue*

Goal: extend to the GMP-critical modules on the proven foundation. Full validated modules, not thin slices.

| Item | Exists in code today | Eng action | Why | How it wins the client |
|---|---|---|---|---|
| Full URS-23 batch disposition (create→MBR→IPC→release→QP cert) | 🟡 `createMBR`/`createBatchRecord` exist; not validated; e-sig gaps | **Build + validate** full lifecycle | GMP batch release is the highest-stakes GMP decision | Completes the GMP story; expansion revenue |
| MBR-driven batch creation UI | 🔴 (out of pilot) | **Build** | Native batch creation (vs pilot seeding) | Removes the pilot's seeded-data workaround |
| Batch-hold trigger (DEC-16-27) | 🔴 (de-scoped from pilot) | **Build** — deviation→batch hold cascade | Realizes "a deviation holds the batch" control | The workflow-crosses-modules vision, fully wired |
| Full OOS operate-and-dispose validation | ✅ OOS lifecycle built | **Validate** as in-scope (+ OOT) | OOS classification is GMP-critical | Deepens the GMP coverage |
| OOT alert / trend register | 🔴 | **Build** | Trend detection | Predictive quality story |
| Equipment / EM / stability / APQR | ⛔ later | — | Broader GxP | Future TAM expansion |

**Phase-3 guardrails:** EU AI Act high-risk + Annex 22 prohibit GenAI in batch/OOS critical decisions — MIRA stays advisory-only, human-signed. Each module gets its own URS + risk assessment + validation.

---

## The client-win thread (one line per phase)
- **Phase 1 wins the meeting** by showing a *credible, governed, differentiated* product (AI-with-provenance + inspection-readiness) on synthetic data — restraint reads as credibility to a QA buyer.
- **Phase 2 wins the validation** by closing the Part 11 e-sig gap, the fail-closed AI audit, and the inspection-export — the three things that let a pharma partner *validate intended use* and become a referenceable logo by Sep-01.
- **Phase 3 wins expansion** by extending into batch/OOS as full validated modules — the land-and-expand that turns one partner into account growth.

## Honest notes
- "Exists in code today" = code present at `3bd2fe47`. **Built ≠ validated** — existing modules carry the e-sig/linkage gaps in Phase 2's list; for demo/reference use they're fine, for controlled GxP use they must be hardened first.
- Batch master data for the pilot lands via a **controlled synthetic seed** (reference-only), not native creation (CC-PILOT-2026-001).
- Two items still need an Engineering yes/no that feeds this map: distribution/read-ack scope (WP-6) and training automation vs manual (WP-11).