# Verixa — 6+1 Demo Playbook (Build · Rehearse · Present)

**Who this is for:** the product and demo team — including people who are **not** pharma/quality experts. You should be able to read this top to bottom and (a) understand what we're showing and why, (b) build the demo environment, (c) rehearse it, and (d) handle hard questions from the client's Head of Quality.

**Demo:** Acme Sterile Pharma (fictional) · Injectable Line 3 · synthetic data only · 6 workflows + MIRA (the AI copilot).
**Verified against:** code branch `dev-vimal-deploy` @ `cc6e6157` + the Target-State URS. Every claim in here is checked — if something isn't real yet, this playbook tells you to **narrate it as roadmap, not show it**.
**Golden rule for an FDA/QA audience:** *over-claiming a control is worse than saying "that's on our roadmap."* When in doubt, under-claim.

---

## PART 0 — How to use this playbook

- **Product/build team:** read Parts 1–5. Part 5 is your literal setup checklist.
- **Presenter/demo team:** read Parts 1–4 and 6–10, and memorise Part 11 (the Q&A).
- **Everyone:** Part 8 (the one-page "live vs narrate" cheat sheet) is the single most important page. Print it.

Three status words you'll see everywhere:
- **`[BUILT]`** = it works in the product today. Safe to click live.
- **`[VERIFY]`** = it should work, but confirm it on the actual demo build before the client sees it. If it fails in rehearsal, **cut it** and narrate instead.
- **`[TARGET]`** = roadmap. **Never click it live. Never fake it.** Describe it as "where we're heading."

---

## PART 1 — Plain-language primer (what the words mean)

You don't need to be a pharma person to run this demo, but you need to know what these terms mean, because the client's Quality lead will use them.

| Term | What it means in plain English | Why the client cares |
|---|---|---|
| **GxP** | "Good *x* Practice" — the umbrella for the rules pharma must follow (manufacturing, clinical, lab, etc.). | Everything in a pharma quality system must be GxP-compliant or the regulator can shut a product down. |
| **Deviation** | "Something didn't go to plan." A documented departure from an approved procedure. E.g., a step was done before the required training was on record. | Every deviation must be recorded, investigated, and closed under signature. Inspectors live here. |
| **RCA (Root Cause Analysis)** | The structured "why did this really happen?" investigation behind a deviation. | Regulators reject shallow root causes ("operator error"); they want the *systemic* cause. |
| **CAPA** | Corrective And Preventive Action — the fix (corrective) and the "stop it happening again" (preventive). | The single most-inspected workflow after the audit trail. Must be proven *effective* before it's closed. |
| **Document Control** | Managing controlled documents (SOPs = Standard Operating Procedures) through draft → review → approve → effective. | An out-of-date SOP in use is a classic inspection finding. |
| **Inspection Readiness** | The "are we ready for an auditor?" view — pulls the whole evidence chain together and scores readiness. | This is the "screen that closes deals" for a Head of Quality. |
| **Segregation of Duties (SoD)** | One person can't do every step. The person who *raises* an issue can't *investigate* it; the *author* can't *approve* their own work. | Prevents fraud and error. Inspectors specifically test this. |
| **E-signature (Part 11)** | An electronic signature that legally captures **who** signed, **what it means** (e.g., "approved"), **when** (timestamp), and **which record**. | Required by US FDA 21 CFR Part 11 and EU Annex 11. |
| **Audit trail** | An unchangeable log of every change: who, what, when, and the before/after values. | The #1 thing an inspector asks to see. Must be tamper-evident. |
| **ALCOA+** | Data must be **A**ttributable, **L**egible, **C**ontemporaneous, **O**riginal, **A**ccurate (plus complete, consistent, enduring, available). | The data-integrity yardstick regulators use. |
| **Advisory AI / "never-write"** | Our AI *suggests*; a qualified human *decides*. The AI is never allowed to write into a quality record. | This is Verixa's core AI-safety position. It's what makes the AI inspection-safe. |
| **Validated** | Formally proven, with documented evidence, that the system does what it's supposed to. | **We do NOT claim the demo is "validated."** Validation is a joint activity done in the customer's environment. |
| **21 CFR Part 11 / EU Annex 11 / EU Annex 22 / EU AI Act** | US e-records rule / EU computerised-systems rule / EU draft rule for AI in manufacturing / EU AI law. | The regulatory backdrop. We *design to* these; we don't claim legal certification. |
| **MIRA** | Verixa's AI copilot. It assists and drafts; it never makes the final regulated decision. | "AI assists, humans decide." |

---

## PART 2 — The pitch (memorise this)

**One sentence:** *"Verixa runs your deviation → root cause → CAPA → document → inspection chain end-to-end, with AI that assists but never decides — and the record always proves who did."*

**The three things a Head of Quality should remember (say these, in these words):**
1. *"AI cannot set or write a critical quality value. A qualified human decides, and the record proves who."*
2. *"The system refuses what it must — it won't let one person mark their own homework, and it won't let AI touch a regulated record."*
3. *"One click gives an inspector the sealed evidence chain — every decision, every signature, tamper-evident."*

**The short sales line:** *"AI assists. Humans decide. Critical AI use needs a signed customer exception. Fully autonomous AI on a critical decision is a non-relaxable product prohibition."*

---

## PART 3 — Cast of characters (the demo personas)

Three people, because **segregation of duties** means no one person can do everything. (Two extra "QA-only" logins exist purely to prove the negative cases — they are **never shown to the client as part of the story**.)

| Persona | Login (seeded) | Plain-English role | Can do | Cannot do (this is the point) |
|---|---|---|---|---|
| **Ravi** | `reviewer@acme.com` | The **Reporter** — the person on the floor who spots the problem. | Raise a deviation; set its severity. | Investigate it, approve anything, close anything. |
| **Meera** | `lead@acme.com` | The **Investigator / Author** — does the RCA, writes the CAPA, drafts the SOP, uses MIRA. | Investigate, author RCA + CAPA, edit the SOP. | Approve or close her **own** work. |
| **Anand** | `admin@acme.com` *(confirm exec authority)* | The **Approver / Closer** — the quality authority who signs off. | Approve, close, e-sign, generate the evidence pack, run inspection readiness. | Author or investigate the things he approves. |
| *(QA-only)* No-permission | `viewer@acme.com` | A user with no rights — used only to show buttons greyed out. | View. | Anything else. |
| *(QA-only)* Cross-tenant | `admin@beta.com` | A different company's admin — used only to prove data isolation. | — | See Acme's data. |

> **Build note:** passwords are not in the code — set them at deploy and keep them in a controlled place, never in this file. Confirm **Ravi ≠ Meera ≠ Anand** on every record, or the "watch it refuse" beats won't fire. The exact authority-profile names must be filled from the seed files before the run (see Part 5).

---

## PART 4 — The story (plain English, in run order)

One continuous thread. An SOP step on Line 3 was executed before the operator's training evidence was on record.

1. **Deviation (Ravi).** Ravi raises the deviation and picks its severity himself. *We show: the human owns severity; the AI is off and can't set it.*
2. **Triage + assignment (Anand).** A different qualified person confirms triage and assigns **Meera** as investigator. *We show: the reporter can't investigate his own deviation.*
3. **RCA (Meera).** Meera investigates, asks **MIRA** for help; MIRA suggests themes (advisory, labelled). Meera writes the real systemic cause. *We show: AI suggested, human decided, and the system kept both.*
4. **CAPA (Meera → Anand).** Meera writes the corrective actions and effectiveness criteria. *We show: Meera can't approve or effectiveness-check her own CAPA — Anand does, and it can't close until it's proven effective.*
5. **Document Control (Meera → Anand).** Meera uploads the revised SOP, asks MIRA to review it (advisory), fixes it herself; Anand approves and e-signs. *We show: author can't approve their own SOP; AI review never touches the document.*
6. **Evidence pack (Anand).** One click assembles the sealed, tamper-evident evidence chain.
7. **Inspection readiness (Anand).** The readiness scorecard + the full deviation→RCA→CAPA chain, ready for an auditor.
8. **MIRA recap (Meera).** The copilot: helpful, advisory, and it never writes a quality record.

---

## PART 5 — BUILD (deterministic setup checklist)

Do these in order. Tick each. Don't improvise data — use the seeded records below so the demo is repeatable.

### 5.1 Environment
- [ ] Deploy the build. Record the **URL**, the **deployed commit SHA**, and the **migration high-water mark**. *(Authoring SHA was `cc6e6157` — capture the SHA actually deployed.)*
- [ ] Confirm region setting: the EU AI gate is **narrated only** for this demo — do **not** toggle any region/AI setting (the underlying field isn't fully built; see Q&A).

### 5.2 Users
- [ ] Set passwords for `reviewer@acme.com` (Ravi), `lead@acme.com` (Meera), `admin@acme.com` (Anand), `viewer@acme.com`, `admin@beta.com`.
- [ ] **Fill the authority map** — for each persona, confirm the exact seeded authority-profile name and that the positive/negative rights are right (Ravi can't approve; Meera can't approve own; viewer can't do anything). *Seed migrations: 310 (deviation), 319 (RCA), 334/336 (document), 329 (inspection), 274/207 (closure/MBR).*
- [ ] Confirm which account holds **executive** authority for the critical-close co-sign (candidate `admin@acme.com`) — or seed one.

### 5.3 Seed data (named records — all from real demo seed migrations)
- [ ] Deviations (mig 263): **Aseptic Fill Line Temperature Excursion**; **LIMS Data Entry Error**; **SOP-MFG-047 Out-of-Date Revision** (critical).
- [ ] CAPAs (mig 263): **Fill Line Temperature Control Improvement**; **LIMS Batch Number Validation Rule**.
- [ ] RCAs (mig 323): **RCA: Aseptic Fill Line Temperature Excursion**; **RCA: LIMS Batch Number Transposition**.
- [ ] Documents (mig 072): SOP-001, WI-042, REG-005, POL-012; demo SOP **[DEMO] SOP-MFG-047 Aseptic Fill Operation** (mig 323).
- [ ] Inspection event (mig 323) + workflow templates (mig 264/306/303).
- [ ] **Out-of-scope route present but hidden** (mig 378 OOS/batch) — must be unreachable for the demo persona.

### 5.4 Negative/edge records (needed for the "watch it refuse" beats)
- [ ] A **closed** deviation (for the "can't edit a closed record" beat).
- [ ] A **critical deviation + a linked closed CAPA** (for the critical-close beat).
- [ ] A **title-only** document (for the "AI won't fake a review of an empty doc" beat).
- [ ] A **batch record / MBR** (for the "AI review refused for batch records" beat).

### 5.5 Pre-flight (the make-or-break checks — run before rehearsal)
Confirm each of these fires live, or put it on the cut list:
`DC-7` (author can't approve own doc) · `DC-10` (empty-doc honesty) · `DV-4a` (AI severity off) · `DV-7` (reporter can't be investigator) · `CA-7`/`CA-8` (author can't approve/effectiveness-check own CAPA) · `EV-1a` (evidence pack assembles + hashes) · `EV-4` (tamper breaks the hash) · `IR-5` (out-of-scope unreachable).

### 5.6 Idempotency / reset (for repeat rehearsals)
- [ ] **BE confirms the demo seeds are idempotent** (safe to re-run) — or use a **snapshot restore** between rehearsals. Never hand-delete records (they're immutable by design); reset by snapshot or re-seed.

---

## PART 6 — REHEARSE (the run script)

Run order (this matches the story): **Deviation → RCA → CAPA → Document Control → Evidence → Inspection → MIRA.** ~31 minutes.

**How to read each step:** *Who* logs in · *Click* (where to go) · *Audience sees* · **Say this** (narration) · *Watch-out*. The ✕ rows are the "watch it refuse" beats — **lead with these; they're what convince Quality.**

### Segment 1 — Deviation (Ravi) · ~6 min
| Who | Click | Audience sees | **Say this** | Watch-out |
|---|---|---|---|---|
| Ravi | Deviations → New | Form opens (greyed for a no-rights user) | "His role enables the button. Someone without create rights simply can't click it — control is driven by authority, not hidden by hope." | `[BUILT]` |
| Ravi | Fill form, set severity | Unique ID + audit entry | "The human owns severity. That field is his decision, fully attributed." | `[BUILT]` |
| Ravi | (severity AI) | No "let AI decide" option | **✕ Watch it refuse:** "Notice there's no 'AI, set the severity.' Generative classification is **off by default** — turning it on would need a signed customer exception. AI never sets a critical value." | `[VERIFY]` — confirm off in pre-flight |

### Segment 1b — Triage (Anand) · ~2 min
| Who | Click | Audience sees | **Say this** | Watch-out |
|---|---|---|---|---|
| Anand | Deviation → Triage → assign investigator | Assigns Meera | "Ravi raised it, but he doesn't decide what's next. A separate qualified person confirms triage and assigns the investigator." | `[BUILT]` — *don't* say "the reporter can't triage"; say "the reporter can't be the **investigator**" |
| Anand | Try to assign **Ravi** as investigator | **Blocked** | **✕ Watch it refuse:** "Try to make the reporter the investigator — blocked. Segregation of duties fires live, right here." | `[VERIFY]` — load-bearing |

### Segment 2 — RCA (Meera) · ~4 min
| Who | Click | Audience sees | **Say this** | Watch-out |
|---|---|---|---|---|
| Meera | Deviation → Start RCA | RCA opens, linked to the deviation | "The RCA is born linked to its deviation — traceability by construction." | `[BUILT]` |
| Meera | RCA → MIRA assist | Advisory suggestions, labelled; record unchanged | "Everything MIRA offers is labelled advisory, and nothing is written yet. The AI proposed; the human hasn't decided." | `[BUILT]` |
| Meera | Edit to the real cause, save | Stores MIRA's original **and** Meera's final | "The AI suggested one thing; Meera concluded another. The system keeps **both** — what AI proposed and what the human decided. That's provenance." | `[BUILT]` |
| Meera | Try to approve her own RCA | **Blocked** | **✕ Watch it refuse:** "The author can't sign off her own conclusion. A separate reviewer is mandatory." | `[BUILT]` |
| Anand | Approve the RCA (e-sign) | Approval recorded | "A separate authority approves. Drafter and approver are different people, and the record proves it." | `[BUILT]` · **Do NOT** present a separate 'close' as a second signed step — see Part 8 |

### Segment 3 — CAPA (Meera → Anand) · ~5 min
| Who | Click | Audience sees | **Say this** | Watch-out |
|---|---|---|---|---|
| Meera | RCA → Create CAPA | CAPA linked to deviation + RCA | "The CAPA inherits its lineage — both links carried automatically." | `[BUILT]` |
| Meera | Author actions + effectiveness criteria | Saved under Meera | "Meera writes the corrective actions herself. The AI can't draft them — it isn't even an option." | `[BUILT]` |
| Meera | Ask MIRA to draft/prioritise/close | **Not available** | **✕ Watch it refuse:** "Drafting a CAPA action, setting priority, closing a CAPA — none of those exist as AI actions. This is the never-write floor." | `[BUILT]` |
| Meera | Try to approve / effectiveness-check own CAPA | **Both blocked** | **✕ Watch it refuse:** "The author can neither approve nor effectiveness-check her own CAPA." | `[VERIFY]` — load-bearing |
| Anand | Effectiveness check, then close (e-sign) | Close blocked until effective + all actions done | "Anand closes with a Part 11 e-signature — but only after effectiveness is proven and every action item is done." | `[BUILT]` |

### Segment 4 — Document Control (Meera → Anand) · ~4 min
| Who | Click | Audience sees | **Say this** | Watch-out |
|---|---|---|---|---|
| Meera | Document Control → New → upload SOP | Controlled v1 + audit | "Versioned and audited from the first save." | `[BUILT]` |
| Meera | Document → MIRA Review | Advisory findings; document unchanged | "MIRA flags gaps — findings only. It hasn't touched the document." | `[BUILT]` |
| Meera | Decide on each finding, edit SOP | Each decision logged; new version | "She decides finding by finding; the system logs the AI suggestion next to her call." | `[BUILT]` |
| Meera | (try on a batch record) Document → MIRA Review | **Refused before any AI runs** | **✕ Watch it refuse:** "For a batch record, AI review is refused before any AI call — per EU Annex 22." *(internal beat; optional for client)* | `[BUILT]` |
| Meera | Try to approve own SOP | **Blocked** | **✕ Watch it refuse:** "The SOP author cannot approve her own SOP." | `[VERIFY]` — load-bearing |
| Anand | Approve + e-sign; then make-effective (e-sign) | Version history: author / reviewer / approver | "Anand approves and e-signs. Approval and 'effective' are two separate signed events." | `[VERIFY]` · **Do NOT** claim a 4th person *must* set the effective date — see Part 8 |

### Segment 5 — Evidence pack (Anand) · ~5 min
| Who | Click | Audience sees | **Say this** | Watch-out |
|---|---|---|---|---|
| Anand | AI Governance Evidence → Generate | Pack assembles live, hash-sealed | "One click. The pack assembles from the real records and is hash-sealed." | `[BUILT]` |
| Anand | Open the audit trail | Actor, role, time, before/after | "This is the beat Quality remembers — a live audit trail with before-and-after across the whole chain." | `[BUILT]` |
| (QA) | Tamper test | Hash no longer matches | "Change one byte and the hash breaks. Tamper-evident." | `[VERIFY]` |
| Anand | (narrate) | — | "To be precise: **complete** per-suggestion AI provenance is target-state. I'm describing the roadmap, not claiming it live." | `[TARGET]` — narrate only |

### Segment 6 — Inspection Readiness (Anand) · ~6 min
| Who | Click | Audience sees | **Say this** | Watch-out |
|---|---|---|---|---|
| Anand | Inspection Readiness → dashboard | Upcoming inspection + readiness summary | "An auditor arrives in two weeks. Anand's job is to prove the quality system closes its loops." | `[VERIFY]` |
| Anand | Generate readiness scorecard | Overall score + formula version (immutable snapshot) | "This score comes from a **versioned, explainable formula** (`readiness-formula-v1.2`), and it's an immutable snapshot — regenerating tomorrow makes a new record; today's is preserved." | `[VERIFY]` · **Do NOT** say "the on-screen breakdown reconciles to the decimal" — see Part 8 |
| Anand | Walk CAPA → RCA → Deviation | Each link signed | "Deviation → root cause → CAPA → verified closure. One unbroken thread, every link signed." | `[VERIFY]` |
| Anand | Export the pack | Controlled, audited export | "Even exporting is a controlled, audited event." | `[VERIFY]` |
| Anand | (try out-of-scope) | Unreachable | **✕ Watch it refuse:** "Out-of-scope modules are unreachable here. We demo only what's in scope — no scope leaks." | `[VERIFY]` — load-bearing |

### Segment +1 — MIRA (Meera) · ~3 min
| Who | Click | Audience sees | **Say this** | Watch-out |
|---|---|---|---|---|
| Meera | MIRA chat → ask a concept question | Advisory answer | "MIRA as a copilot — explain a concept, summarise themes. Helpful, advisory, stays out of the record." | `[BUILT]` |
| Meera | Ask MIRA to modify a record | **Cannot** | **✕ Watch it refuse:** "The floor under everything: MIRA never writes a quality record. It suggests, the human decides, both are logged." | `[BUILT]*` — "verified by code scan; negative-test lock is on our validation plan" |
| Meera | (narrate) | — | "To enable AI on a critical-adjacent path, a customer raises a signed, scoped, expiring exception — QA + Regulatory + Executive sign, hard-blocked for EU. Target-state — I'm describing the control." | `[TARGET]` — narrate only |

---

## PART 7 — Rehearsal discipline

- **Lead with the refusal and the audit trail in every segment** — not the happy path. Refusals are what sell GxP software to Quality.
- **Hand off logins deliberately.** Ravi → Meera → Anand. Never approve/close as the person who authored.
- **Never click a `[TARGET]` item.** If asked, describe it.
- **If a `[VERIFY]` item fails in rehearsal, cut it** and narrate as roadmap. QA owns the cut; Founder owns the date.
- **Capture evidence** (screenshots) as you go if this rehearsal doubles as a test record.

---

## PART 8 — Live vs Narrate-only cheat sheet (PRINT THIS PAGE)

| Demo with confidence (live) | Narrate only — do NOT click or claim as live |
|---|---|
| Human sets severity/classification | AI setting severity (it's off — show that it's off, don't enable it) |
| Reporter can't be investigator (SoD) | A *separate triage authority* is **required** — code lets the reporter run triage; only say investigator ≠ reporter |
| RCA: drafter can't approve own; separate approver e-signs | RCA "three distinct people," and RCA **close** as a second signed step — not enforced; close has no e-sig |
| CAPA: author can't approve/effectiveness-check own; close needs effectiveness + all actions done; e-sign | CAPA **per-item** reviewer signing each action item — not built |
| Doc: author can't approve own; approve e-sign; separate make-effective e-sign | The effective date **must** be set by a *different person than the approver* — not enforced |
| Critical deviation → executive co-sign | Major deviation practice-lead co-sign (the screen isn't wired yet) |
| Evidence pack assembles live + hash-sealed; audit trail before/after; tamper breaks hash | "Complete per-suggestion AI provenance is live" — that's target-state |
| Readiness score = versioned, explainable formula; immutable snapshot; signed evidence chain; out-of-scope unreachable | "The on-screen score breakdown reconciles to the decimal" — the UI breakdown is being aligned to the formula |
| MIRA never writes a quality record (verified by code scan) | "Independently validated / proven" — say "verified by code scan; OQ negative-tests on the validation plan" |

---

## PART 9 — If something breaks (fallback)

| If this fails in pre-flight… | Do this |
|---|---|
| A "watch it refuse" beat doesn't fire | Cut it; narrate as roadmap. Never fake a refusal. |
| Evidence pack won't assemble live | Don't show a pre-made pack as if live — narrate. (This is a go/no-go flag.) |
| Out-of-scope module is **reachable** | **Stop** — hide it before any client sees it. Hard blocker. |
| Inspection module isn't live | Narrate the concept using the closed chain + audit trail; don't mock a pack. |

---

## PART 10 — Go / No-Go (sign before the demo)

- [ ] Deployed URL + SHA recorded; demo data seeded; out-of-scope hidden.
- [ ] Passwords set; Ravi ≠ Meera ≠ Anand; viewer has no rights.
- [ ] Load-bearing beats pre-flighted (Part 5.5) — each PASS or on the cut list.
- [ ] `[TARGET]` items confirmed **narrate-only**.
- [ ] Audit-trail beat works (the QA-convincing moment).
- [ ] **No-Go if:** out-of-scope leaks, the evidence pack can't assemble live, or any `[TARGET]` item is staged as live.
- [ ] Signed: QA (execution) · Founder (date).

---

## PART 11 — CLIENT QA Q&A BANK (anticipate + answer)

The client's Head of Quality **will** push. For each question: a **short answer** (say this first), a **fuller answer** (if they want detail), and **never say** (the trap). Answers are honest about what's live vs roadmap — that honesty is what builds trust with Quality.

### A. Compliance, validation & scope

**Q1. Is this system validated?**
- **Short:** "No — and we wouldn't claim it is. This is a co-design build on **synthetic data**. Validation is a joint activity we do in *your* environment."
- **Fuller:** "We follow a GAMP 5 Category-5 / FDA CSA risk-based assurance approach. We provide the validation evidence pack; you validate your intended use. Today is about showing the controls and the workflow, not asserting a validated state."
- **Never say:** "Yes, it's validated/compliant."

**Q2. Is it 21 CFR Part 11 and EU Annex 11 compliant?**
- **Short:** "It's **designed to** Part 11 and Annex 11 — e-signatures with identity/meaning/timestamp/record link, tamper-evident audit trail, access controls. Compliance is something *you* establish through validation; we give you the controls and the evidence."
- **Fuller:** "I can show you the e-signature manifestation and the audit trail right now. Legal 'compliance' is a property of your validated process in your environment, not a checkbox a vendor ticks."
- **Never say:** "We are certified Part 11 compliant."

**Q3. Is this the real product or a mock-up?**
- **Short:** "Real product code, on branch `dev-vimal-deploy`, with synthetic data. Nothing in this demo is faked."
- **Fuller:** "Anything not production-ready we **tell you is roadmap** rather than show it. We'd rather under-claim."

**Q4. What standards does this map to?**
- **Short:** "21 CFR Part 11, EU GMP Annex 11, FDA CSA (2025), GAMP 5 Cat 5, ALCOA+/MHRA data integrity, and — for AI — EU GMP Annex 22 (draft) and the EU AI Act, which we adopt as forward-looking internal controls."

### B. Audit trail & data integrity (ALCOA+)

**Q5. Show me the audit trail. Is it tamper-proof? Can an admin edit it?**
- **Short:** "Here's the live audit trail — actor, role, UTC timestamp, before/after, reason. It's append-only; **no application user, including a platform admin, can modify it.**"
- **Fuller:** "Only infrastructure-level database access can touch raw audit tables, and that's outside the application. The evidence pack also hash-seals the chain — change one byte and the hash breaks. I can show you that tamper test."

**Q6. How do you guarantee records aren't backdated (contemporaneous)?**
- **Short:** "Timestamps are server-generated at the moment of action; the application can't set or backdate them."

**Q7. Can records be deleted?**
- **Short:** "No hard deletes of quality records. Removal is a soft-delete with reason, authority, and an audit entry — the original is preserved and stays available for inspection."

**Q8. Is each record attributable to a person?**
- **Short:** "Yes — every record carries who created and last changed it, from the authenticated user. Anonymous writes are rejected."

### C. Segregation of duties (SoD)

**Q9. Can one person do everything?**
- **Short:** "No. The reporter can't investigate; the author can't approve or effectiveness-check their own work; the closer can't be the author. Let me show you a block fire live." *(Show DV-7 or CA-7.)*
- **Fuller:** "It's enforced at the service layer, not just hidden in the UI — so it can't be bypassed by calling the API directly."

**Q10. Is SoD enforced for the *reviewer* who closes my CAPA action items individually?**
- **Short (honest):** "At the **CAPA level**, yes — approver, effectiveness reviewer and closer are all segregated from the author. **Per individual action item**, item-level reviewer-signing is on our roadmap; today action items carry an owner and due date but not a separate item-level signed review."
- **Never say:** "Every action item is independently reviewer-signed." *(It isn't yet.)*

**Q11. Does your RCA require three different people?**
- **Short (honest):** "Today the system enforces that the **drafter cannot approve** the RCA — a separate qualified reviewer is mandatory. A stricter three-person separation (a distinct closer as well) is on our roadmap; I won't claim it's enforced today."

### D. AI governance (the big one for a 2026 QA audience)

**Q12. Does AI make GxP decisions?**
- **Short:** "No. AI is **advisory only**. It suggests; a qualified human decides and signs. The AI never writes a quality record."
- **Fuller:** "We verified this by code scan — no AI path writes to deviations, RCAs, CAPAs, controlled documents, findings, signatures, or the readiness scorecard. AI writes only to its own suggestion/audit tables. The negative-test lock is on our validation plan."
- **Never say:** "Proven/validated that AI can never write" — say "verified by code scan; OQ negative-tests pending."

**Q13. Does generative AI classify deviations or set severity?**
- **Short:** "Generative classification is **off by default** and fail-closed — it also requires a separately validated model to run at all. Severity is a human decision."

**Q14. How do you handle EU Annex 22 / the EU AI Act for AI in GMP?**
- **Short:** "We treat them as forward-looking internal controls. Under them, generative AI is **prohibited** from critical decisions — classification disposition, severity escalation, closure. AI stays advisory; the human's signed decision is the system of record."

**Q15. Can we turn AI on for a critical decision if we want to?**
- **Short:** "Only through a **controlled exception** — a signed electronic record (QA + Regulatory + Executive), scoped, time-limited, audit-trailed, and hard-blocked for EU-aligned tenants. Even then, AI still never writes the record. Fully autonomous AI on a critical decision is a **non-relaxable prohibition**. *(This exception mechanism is roadmap; I'm describing the control.)*"

**Q16. What happens when the AI is wrong, or unavailable?**
- **Short:** "Every AI suggestion is human-reviewed before it can affect a record, and every workflow has a full manual path — if AI is down, you keep working. The human is always the decider and the accountable signer."

**Q17. How do you control AI model/prompt changes?**
- **Short:** "Model and prompt changes go through change control with impact assessment and approval; prompts are version-controlled controlled documents. *(Parts of this are roadmap — I can show you the governance design.)*"

**Q18. Show me the AI's provenance — model, version, what it suggested vs what the human did.**
- **Short (honest):** "The evidence pack shows the AI suggestions, the human's accept/edit/reject, and the final signed record. **Complete** per-suggestion provenance — model ID/version and prompt/output hash on *every* call, fail-closed — is target-state; I'll show you what's there today and be clear about what's roadmap."

### E. Inspection readiness & the scorecard

**Q19. How is the readiness score calculated? Could you justify it to an inspector?**
- **Short:** "It's a **versioned, explainable formula** (`readiness-formula-v1.2`) with documented component inputs — open deviations, open CAPAs, training, and more — and each generation is an **immutable snapshot**, so today's readiness is preserved forever."
- **Fuller (honest):** "I can walk you through the formula version and the input counts. One transparency note: we're finalising the on-screen component breakdown so it shows all the formula's components — so I'll explain the score from the formula inputs rather than claim the current tile breakdown reconciles to the last decimal."
- **Never say:** "The number on screen reconciles exactly to the visible component tiles." *(UI/formula alignment is being fixed.)*

**Q20. Can you pull a complete inspection evidence pack for one event?**
- **Short:** "Yes — one controlled, audited export assembles the deviation → RCA → CAPA → signatures → effectiveness → audit trail for the event. It's hash-sealed and carries its own provenance out the door."

### F. Security & multi-tenancy

**Q21. Is our data isolated from other customers?**
- **Short:** "Yes — tenant isolation is enforced at the database level (row-level security), not just in the application. I can show that another tenant's admin can't see Acme's data."

**Q22. Who can see what — how is access controlled?**
- **Short:** "Role + authority-profile based, checked on every action after authentication. A user with no rights sees the actions greyed out — I can show that live."

### G. Roadmap / honesty

**Q23. What's NOT built yet?**
- **Short:** "Happy to be specific. On our near-term build list: the controlled-exception record for critical AI use, complete per-suggestion AI provenance with fail-closed audit, item-level CAPA reviewer signing, the major-deviation co-sign screen, and aligning the scorecard's on-screen breakdown to its formula. We track these as engineering tickets."
- **Why this answer wins:** a Head of Quality trusts a vendor who names their gaps far more than one who claims perfection.

**Q24. How do we validate this in our environment?**
- **Short:** "We give you a validation support pack — intended-use statements, the evidence pack, traceability. You run your IQ/OQ/PQ against your intended use. It's a partnership; we don't claim to validate your process for you."

### H. Logistics

**Q25. Is this live data?**
- **Short:** "No — entirely synthetic demo data for a fictional company. Nothing here is real patient or product data."

**Q26. Can we get hands-on / a pilot?**
- **Short:** "Yes — that's exactly the design-partner pilot path. We scope a paid pilot on your real workflows with success metrics and an evidence pack." *(Route to the GTM pilot conversation.)*

---

## PART 12 — Red lines (never cross these, on stage or in answers)
1. Never say "validated," "certified," or "compliant" as a property of the product.
2. Never click or stage a `[TARGET]` item as if it's live.
3. Never claim AI provenance is *complete*, or that "no AI write" is *proven* (say "verified by code scan").
4. Never claim a control forces more separation than the code enforces (RCA 3-person, per-item CAPA reviewer, doc publisher ≠ approver, major co-sign).
5. Never claim the on-screen scorecard breakdown reconciles to the decimal.
6. Never show real/production data.

---

## PART 13 — Quick glossary (hand to anyone mid-rehearsal)
**Deviation** = something didn't go to plan · **RCA** = why it happened · **CAPA** = the fix + prevention · **SOP** = standard procedure document · **SoD** = no one person does every step · **e-signature** = who/what-it-means/when/which-record · **audit trail** = unchangeable who-did-what log · **ALCOA+** = data-integrity yardstick · **advisory AI / never-write** = AI suggests, human decides, AI never touches the record · **MIRA** = the AI copilot · **Built/Verify/Target** = works today / confirm-before-showing / roadmap.

---

*Source of truth: Verixa 6+1 Scenario + Execution Test Pack + Claim-vs-Code-vs-URS verification (dev-vimal-deploy @ cc6e6157, Target-State URS). Synthetic-data demo. No "validated/compliant" claim is made or implied.*