# Batch & OOS in the Pilot Docs — What It Actually Means (Engineer Clarity)

**Date:** 2026-06-01 · **For:** build team + PM (non-domain) · **By:** Head of QA (SME review)
**Companion to:** CC-PILOT-2026-001 (scope change control) · Phase-3 Expansion Scope Note

---

## The confusion (fair question)
"If batch records and OOS are OUT of scope, why do the words *batch* and *OOS* appear all over the pilot package and the engineering pack?"

**Answer: the same two words are used for three different things. Only ONE of them is the GMP module we deferred. The other two are normal and stay.**

## The three meanings

| # | Meaning | Example in the files | In the pilot? |
|---|---|---|---|
| **1. A reference label** | A deviation can *point at* a batch number or an OOS number — an optional text/ID field (`batch_id`, `linked_oos_id`). Nothing is built; it's just a label. | URS-16: `batch_id` (FK URS-23 **nullable**), `linked_oos_id` nullable | **YES — keep.** It's one optional field |
| **2. Code that already exists** | The repo *already has* `batch/service.ts` and `oos-oot/service.ts`. WP-4 fixes an e-signature gap on the existing `batch/service.ts`, and **copies** the existing `oos-oot` code as the "good example." | URS-39B WP-4 / DS-39-WP4; `oos-oot/service.ts:710` is the reference pattern | **Touching existing code only — not building the workflow** |
| **3. The GMP workflow itself** | The batch-disposition workflow (URS-23: hold → QP release/reject) and the OOS investigation workflow (URS-15). **This is what we deferred to Phase-3.** | The two uploaded flows (now re-labelled OUT); URS-16 §21 batch-hold trigger | **NO — Phase-3** |

**Plain version:** keeping a *phone number for a batch* (meaning 1) is not the same as *building the batch department* (meaning 3). And *fixing a lock on a door that's already there* (meaning 2) is not building a new wing.

## Good news: your build spec (URS-39B) is already correct
URS-39B does **not** build the batch or OOS workflow. Proof, from the file:
- **Line 77 — explicit OUT list:** "GMP batch disposition/release … OOS/OOT as a standalone in-scope workflow" are **OUT**.
- **WP-7 (Deviation) = critical executive co-sign ONLY** (URS-39-WP7-01..03). **No batch-hold trigger. No reportability clock. Reopen is OUT.** DS-39-WP7 touches `deviations/service.ts` closure only.
- **WP-4** hardens the **existing** `batch/service.ts` signature check (meaning 2) — it does not build batch disposition.

So nobody following URS-39B will build batch/OOS. 👍

## Where the contradiction actually lives (must be de-scoped)
Two **team source documents** still tell an engineer to build the batch-hold trigger. These are the real conflict and must be corrected:

| Source | The conflicting line | Action |
|---|---|---|
| **Package URS-16 §21 (Deviations)** | **DEC-16-27 (LOCKED):** "a deviation implicating a batch **shall** drive a batch hold/disposition linkage (URS-23), not merely store `batch_id`." Also **DEC-16-17 / URS-16-BE-013 / URS-16-INT-011 (MUST)** "batch flag trigger upon critical deviation," and **BR-16-HARDEN-01** "fire the batch-disposition trigger." | **De-scope for pilot.** Mark these "NOT built in pilot — Phase-3." Keep `batch_id` as an optional reference only. (URS Expert edits URS-16 §21; record in CC.) |
| **Master Build Issue** (`ISSUE_PILOT_MASTER_Build_and_Fix.md`) | Deviation-hardening build list includes "**batch-disposition trigger**" alongside reportability clock + containment. | **Remove "batch-disposition trigger" from the pilot build list.** Keep containment; reportability clock is Critical-only (confirm separately). |

## What to build / NOT build (engineer checklist)
✅ **Build:** the 6 workflows per URS-39B; keep `batch_id` / `linked_oos_id` as optional reference fields; WP-7 = critical co-sign only.
✅ **Build (existing-code fix):** WP-4 substrate-verify e-sig — **change-control + RCA only.** Do **not** touch the `batch/service.ts` path (batch module not deployed → deferred to Phase-3). Add a negative test proving batch/OOS routes are not reachable.
⛔ **Do NOT build:** batch-hold trigger / batch state machine / QP disposition (URS-23); OOS stub / OOS workflow / `oos:create_stub` (URS-15); any `batch_records`, `batch_holds`, `oos_investigations` tables.
⚠️ **Do NOT** turn `batch_id` into a foreign key into a batch module — keep it a plain optional reference, or it silently re-introduces URS-23.

## Resolved decision (Founder, 2026-06-01): batch module is NOT deployed in Phase-1 or Phase-2
Because the batch module is not deployed/reachable in the pilot build:
- **WP-4 pilot scope = change-control + RCA only.** Drop `batch/service.ts` from the pilot WP-4 (the e-sig substrate fix on the batch path is **deferred to Phase-3 with URS-23**).
- **Required guard (do not skip):** "not deployed" must be **enforced and evidenced**, not assumed. Dormant code can still be reachable by direct API if it ships. Engineering must provide deployment evidence that **batch routes are not mounted/registered** in the pilot build, plus a **negative test** (batch endpoint → route-not-found / 403). This replaces the old WP-4 batch test.
- **Same rule for OOS:** the OOS workflow (URS-15) is also out and `oos-oot/service.ts` is used only as a *read-only reference pattern* (it already verifies e-sig correctly, so nothing to fix). Confirm OOS write/disposition routes are likewise **not reachable** in the pilot deployment.
- **Net Part 11 §11.70 position:** with the batch/OOS routes proven non-reachable, there is **no live unverified-signature path** in the pilot — so deferring the batch fix carries no pilot exposure.

## QA disposition
| Item | Disposition |
|---|---|
| Reference fields (`batch_id`, `linked_oos_id`) | **Approved — in scope** (optional reference only) |
| WP-4 e-sig substrate fix | **Approved — scope = change-control + RCA only.** Batch path deferred to Phase-3 (batch module not deployed); OOS code is read-only reference. **Condition:** prove batch/OOS routes non-reachable (deployment evidence + negative test) |
| URS-16 §21 DEC-16-27/DEC-16-17 batch-hold trigger | **Rejected for pilot** — de-scope to Phase-3; correct URS-16 §21 + Master Build Issue |
| URS-23 / URS-15 workflows | **Rejected for pilot** — Phase-3 (per CC-PILOT-2026-001) |

**Verixa verifies; the design partner validates. No "validated" claim without executed evidence + QA disposition.**