# Change Control — Pilot Scope: Batch Disposition & OOS OUT of Phase-1

**CC ID:** CC-PILOT-2026-001 · **Date:** 2026-06-01 · **Raised by:** Founder / Head of QA
**Status:** Decided — for team awareness and action
**Audience:** build team + product manager (non-domain-friendly)

> This is a plain-language change record so everyone understands **what changed, why, and what to build (and not build)**. No Verixa repository code was changed by this CC — it edits planning/flow documents only.

---

## 1. What changed, in one sentence
Two of the four flow diagrams we received — **Batch Disposition** and **OOS** — describe features that are **not part of the pilot**. We've locked the pilot to the **6 core workflows + MIRA**, and re-labelled those two flows as **Phase-3 (future)** so nobody builds them by mistake.

## 2. Why
- Batch disposition (URS-23) and OOS (URS-15) are **GMP-critical** — the highest-risk, highest-validation features in the system.
- Adding them now would expand both the **build** and the **validation** load right when we need a fixed **Sep-01** go-live.
- They were creeping in as "thin slices," which is the worst option: high regulatory risk, low completeness. Decision: keep them OUT now, do them properly later (Phase-3).

## 3. The decision (what's in / out)
| Item | Status |
|---|---|
| 6 issue-#147 workflows (Document Control, Deviation, RCA, CAPA, AI Governance Evidence, Inspection Readiness) | **IN — Phase-1/2** |
| MIRA (advisory engine) | **IN — advisory only** |
| Batch disposition / batch hold / QP disposition (URS-23) | **OUT — Phase-3** |
| OOS stub / OOS workflow (URS-15) | **OUT — Phase-3** |
| `batch_id` as an optional free-text reference on a deviation | **IN** (text only — NOT a link into a batch module) |

## 4. What was edited in each of the 4 flow files
| File | Change made | Build meaning |
|---|---|---|
| `Deviation_Complete_User_Flow` | Closure checklist line changed: "Batch impact → linked_batches disposition" → **"batch reference = optional free-text only; no URS-23 gate in Phase-1."** | Keep as-is; do **not** wire a batch-disposition gate |
| `Dev_RCA_CAPA_End_to_End_Flow` | Wording strengthened from "batch disposition out of *this deliverable*" → **"OUT of Phase-1 (→ Phase-3)";** `batch_id` clarified as free-text scope-anchor only | Keep as-is; build the DEV→RCA→CAPA chain; no batch cascade |
| `Batch_Disposition_Arm_Flow` | Added a red **"OUT OF PHASE-1 — do not build"** banner; flipped all "IN" scope chips to **OUT → Phase-3**; corrected footer (WP-7 = critical co-sign only, no batch cascade) | **Do not build.** Reference only, for Phase-3 planning |
| `(Optional) Deviation_OOS_Cross_Reference` | Added the same red banner; flipped all "IN" chips to **OUT → Phase-3**; corrected footer | **Do not build.** Reference only, for Phase-3 planning |

## 5. One thing to watch (don't re-introduce the dependency)
The in-scope Deviation flow lets a user type a `batch_id` as a scope-anchor. Keep it a **plain optional text field**. Do **not** turn it into a foreign key into a batch-records table — that would quietly pull URS-23 back into the pilot.

## 6. Impact
- **WP-7 reverts to its narrow definition:** critical-deviation co-sign only. Drop any batch-hold cascade. (URS-39B already defines WP-7 this way — no change needed there.)
- **No new tables/permissions for the pilot:** do not create `batch_records`, `batch_holds`, `oos_investigations`, or `oos:create_stub`.
- **Validation load unchanged** — stays at the 6 workflows + MIRA.
- **No Verixa repo code changed by this CC.** Edits are to flow/planning documents only.

## 7. Companion document
Full Phase-3 detail is in **`Verixa_Phase3_Expansion_Scope_Note.md`** (what URS-23 + URS-15 become, their dependency on the pilot foundation, the AI/Annex 22 boundary, and the validation lift).

## 8. Sign-off
| Role | Name | Decision | Date |
|---|---|---|---|
| Founder | Vimal | Approve scope lock | |
| Head of QA | | Concur | |
| Product Manager | | Acknowledge build impact | |
| Eng Lead | | Acknowledge — no URS-23/URS-15 build | |

*Plain-language change record. Verixa **verifies**; the design partner **validates**. No "validated/production-verified" claim without executed evidence + QA disposition.*