# Verixa — User Requirements Specification

# Module 40: Self-Validation / Validation-Automation Engine

| Field | Value |
|---|---|
| Document ID | VRX-URS-40 |
| Version | 1.3-harness-grade (`Draft — not validation-ready`) |
| Document Type | User Requirements Specification (URS) |
| GAMP 5 Category | Category 5 — Custom Application (generates GxP validation evidence; uses advisory AI) |
| Origin | Competitive / pilot differentiator ("F8 Self-Validation Engine"). No URS previously existed for the self-validation / validation-automation capability. Documents an existing, partially-built backend module and defines its target state. |
| Primary code module | `competitive` (self-validation surface): `self-validation.service.ts`, `validation.routes.ts`, `plugin.ts`; job `jobs/validation-change-detection.job.ts` (F8, every 30 min); migration `db/migrations/052_competitive_differentiators.sql` (tables `system_changes`, `validation_plans`, `validation_runs`, `validation_screenshots`, `validation_packages`); frontend `pages/admin/ValidationDashboard.tsx`; `shared/.../competitive-differentiators.schema.ts`. Ownership is target binding, subject to repository verification. |
| Regulatory Classification | **Two-layer.** (a) Validation runs/packages produced here are **GxP-supporting controlled records**. Part 11 applies **only** to records determined to be required by a predicate rule, relied upon for a regulated activity, or submitted to FDA — a **predicate-rule applicability map shall be documented per record type** (SV-COR-028); Part 11 is **not** asserted blanket-wide. Where in scope: ALCOA+, Annex 11, and Part 11 controls apply. (b) The **dual-model AI cross-check (Anthropic Claude + OpenAI GPT)** is **advisory** — a verification aid, never the system-of-record pass/fail or release decision. |
| Code baseline (RC freeze) | Repo `Verixaai/Verixa` (`https://github.com/Verixaai/Verixa.git`) · branch **`dev-vimal-audit-2`** · commit **`3bd2fe47ba703301ffea4abd3d4bc4a8f12d2df4`** (`3bd2fe47`, 2026-05-28). All code line references in this URS are taken from this commit. Re-verify line numbers if the baseline is re-pointed. |
| Approving Authority | Founder / Chairman; QA Head; Validation Head |

---

## 0. Document Framing

### 0.0A v1.3 corrective note — ARCH-AI-001 pinning
This v1.3 bundle incorporates the supplied architecture record **ARCH-AI-001 "AI Optionality and Manual Continuity" v1.0 (DRAFT)**. The reference is now pinned by document ID, title, version, target QMS path, owner set, and URS-40 binding subset (AC-5 / AC-6 / AC-7). This is a document-reference closure only. Because ARCH-AI-001 remains DRAFT and unapproved, URS-40 remains **DRAFT — not validation-ready** and is not approved for freeze.


### 0.1 Purpose of this document
Defines the target state for Verixa's **Self-Validation / Validation-Automation Engine** — the capability that detects a platform change, classifies its validation impact, generates a risk-based IQ/OQ/PQ validation plan, executes the tests, captures objective evidence, cross-checks accuracy with two independent AI models (Claude + GPT), assembles an integrity-stamped validation package, and routes it for human review and electronic-signature approval. This is the capability behind the "pre-built IQ/OQ/PQ + continuous revalidation" differentiator.

### 0.2 Audience
Non-domain frontend and backend engineers; QA testers; validation engineers; product managers; QMS SMEs; QA approvers; auditors and inspectors.

### 0.3 How to read this document
§0.4 is a plain-language primer for readers with no GxP background. §0.5–0.7 give the lifecycle diagram, glossary, and architectural picture. §1–§7 are the target-state requirements (purpose, scope, roles, user journeys, front-end, back-end, cross-module wiring). §8 is the atomic requirements register (`SV-REQ-###`). §9 is AI Intended-Use & Governance; §10 is Data Integrity / ALCOA+; §11 is cross-module reconciliation; §12 is validation readiness; §13 is the developer handoff with a deployable Claude Code build block. Anything not evidenced in code or an approved source is marked **`Unknown — evidence required`**.

### 0.4 Plain-language primer for non-domain readers
In a regulated pharmaceutical software system, **you are not allowed to just "trust" that the software works** — you must *prove* it works, with documented evidence, and re-prove it whenever it changes. The traditional way to prove it is **Computer System Validation (CSV)**: you write requirements, then run a set of scripted tests grouped into three stages — **IQ** (Installation Qualification: "is it installed and configured correctly?"), **OQ** (Operational Qualification: "do its functions behave correctly?"), and **PQ** (Performance Qualification: "does it work correctly for the real business use, with real users?"). **PQ shall demonstrate fitness for intended use** through representative user, workflow, data, role, negative, and boundary scenarios (not generic function checks); **UAT evidence may support PQ where the validation strategy defines and controls that relationship** (PQ and UAT are not universally interchangeable). The *acceptance* is always a **human's** decision, never the engine's: the engine runs the scenarios and captures evidence, but a qualified person — and, for user-facing changes, a real user — is the one who accepts and signs (SV-REQ-028/029). You capture screenshots and results as objective evidence, a qualified person reviews them, and they sign off. This is slow and resource-intensive (any cost figure belongs in an approved commercial analysis, not in this controlled URS).

Module 40 is the **target-state** engine for automating the repetitive parts of that work for the Verixa platform itself. **Current state (this is a target-state URS): the implementation is a database-backed skeleton that does NOT yet perform the steps below — it currently auto-passes runs without executing tests (see §0.6 and the verified gaps in §8 and §12).** In the target state, it **will**, in everyday terms:

1. **It watches for change.** Whenever something in the platform changes — a new deployment, a database migration, a configuration change, a change to an AI model or prompt, an access-control change — the engine records that change as a **change record** (`system_changes`). A background job checks every 30 minutes.
2. **It decides how much validation is needed.** Not every change needs the same rigor. The engine classifies each change (how risky, how big, which parts of the system are touched) and picks a **validation scope** — full, partial, regression-only, or documentation-only. A tiny low-risk change gets a light touch; a high-risk change gets the full IQ/OQ/PQ.
3. **It writes a validation plan.** Based on the classification, it generates a **validation plan** (`validation_plans`) containing the specific IQ/OQ/PQ test cases to run, drawn from a pre-built library, plus the pass/fail acceptance criteria.
4. **It runs the tests and keeps proof.** It **executes** those tests and records the *actual* results (`validation_runs`), and it captures **screenshots/artifacts** as objective evidence (`validation_screenshots`). The result must reflect what really happened — the engine must never just say "everything passed."
5. **Two AIs double-check the work.** This is the accuracy safeguard. The engine sends the generated content and the executed results to **two independent AI models — Anthropic's Claude and OpenAI's GPT** — and asks each, separately, to review them for accuracy and completeness. If both agree, that is a confidence signal. If they **disagree**, the engine raises a **separate AI review flag** and routes it to a human to resolve — but the disagreement **does not change the test result itself** (a real pass stays a pass, a real fail stays a fail); only the human decides what to do about it. The AIs are **advisers only** — they never decide pass/fail and never approve anything, and their disagreement is never recorded as the validation outcome.
6. **It packages the evidence.** It assembles a **validation package** (`validation_packages`) — the plan, the run, the screenshots, the AI review report — with an integrity hash so nobody can alter it unnoticed.
7. **A qualified human reviews and signs.** A validation/QA approver reviews the package and **electronically signs** the disposition. Only the human signature makes it official. The person who authored the plan cannot be the person who approves it (segregation of duties).
8. **Everything is logged.** Every step writes to the **audit trail** (who, what, when, before/after), and every AI call is logged with the exact model name and version.

Two regulatory guardrails sit on top of this. First — the **primary rationale** — the records this engine produces are intended to support regulated validation activities, so they must satisfy applicable **electronic-record and data-integrity controls** (FDA **21 CFR Part 11** where a predicate rule applies; **EU Annex 11**; **ALCOA+**): honest, complete, attributable, and unalterable once approved. An auto-pass with no real test evidence is **prohibited by this URS and creates an inaccurate, unsupported validation record** — exactly the failure mode this URS exists to prevent. Second, the engine uses **generative AI (Claude + GPT)**, so the design keeps AI **advisory only** — it may assist and cross-check but may **not** be the decision of record; the result is deterministic (rules against acceptance criteria) and the approval is a human e-signature. This is governed internally by **ARCH-AI-001**. **EU GMP Annex 22 is a draft (not on EudraLex's in-force annex list) and is treated only as an internal anticipatory reference; EU AI Act legal classification of this advisory use case is `Unknown — required`** — neither is asserted as in-force binding here, and the advisory-only AI control holds regardless of their status.

One honest caveat the engineer must know up front: **today the execution is a placeholder.** The current code writes a hardcoded "1 test, passed, 100%" with no evidence (`self-validation.service.ts:458–477`) and the test cases are three stubs. This URS defines the *target state* that replaces that stub with real execution, real evidence, and the dual-model cross-check.

### 0.5 Validation lifecycle diagram

```mermaid
stateDiagram-v2
  state "Self-Validation Lifecycle" as SVLC {
    [*] --> change_detected : F8 job / deploy / migration / config / model-or-prompt change
    change_detected --> classified : classify GAMP cat + impact + risk + scope
    classified --> plan_draft : generate validation plan (IQ/OQ/PQ test cases + acceptance criteria)
    plan_draft --> plan_agent_reviewed : dual-model AI advisory review (Claude + GPT)
    plan_agent_reviewed --> plan_pending_approval : routed to validation/QA
    plan_pending_approval --> plan_approved : approver e-signs (author != approver)
    plan_pending_approval --> plan_rejected : approver e-signs rejection (terminal)
    plan_approved --> run_running : executeValidation (real IQ/OQ/PQ)
    run_running --> run_passed : results meet acceptance criteria
    run_running --> run_failed : results fail acceptance criteria
    run_running --> run_blocked : precondition/runner error
    note right of run_running : Factual run results only (passed / failed / blocked / skipped / aborted). 'conditional' is NOT a run result — it is a human disposition (below). AI cross-check runs in parallel as an advisory ai_review_status hold and NEVER sets run state or validation_result (SV-REQ-009/018/030).
    run_passed --> package_draft : assemble package from real evidence + hash
    run_failed --> package_draft : reviewable record of failure
    run_blocked --> package_draft
    package_draft --> package_agent_reviewed : dual-model AI advisory review
    package_agent_reviewed --> package_pending_approval : routed to QA
    package_pending_approval --> disp_validated : QA e-signs VALIDATED (no mandatory failure)
    package_pending_approval --> disp_conditional : QA e-signs CONDITIONAL (linked approved deviation, URS-16)
    package_pending_approval --> package_rejected : QA e-signs rejection / not-accepted
    disp_validated --> archived : retained, immutable (package_hash)
    disp_conditional --> archived
    plan_rejected --> [*]
    package_rejected --> [*]
    archived --> [*]
  }
```
Diagram 0.5-A — Self-validation lifecycle. AI review steps (`*_agent_reviewed`) are **advisory**; the two decision boundaries (`plan_pending_approval → plan_approved`, `package_pending_approval → disp_validated`/`disp_conditional`) are **human e-signature** actions with author≠approver SoD. **CONDITIONAL is a disposition (not a run result) and requires a linked approved deviation (URS-16).** A new change always creates a new run; prior runs are retained (continuous revalidation). The per-record `status` enums shown are the migration-052 CHECK values. **`validation_result`, `ai_review_status`, signed disposition, transition history, deviation linkage, and release-readiness are target-state additions NOT in migration 052.** Target state moves **CONDITIONAL out of the run-result layer into the human-disposition layer** (factual run results: passed / failed / blocked / skipped / aborted) per SV-COR-015.

### 0.6 Glossary of key terms used in this document
| Term | Plain-English meaning | Why it matters in Verixa |
|---|---|---|
| CSV / CSA | Computer System Validation / Computer Software Assurance — proving the software works, risk-based | This engine automates the repetitive parts |
| IQ / OQ / PQ | Installation / Operational / Performance Qualification — the three test stages | The `validation_runs.iq/oq/pq_results` |
| Validation plan | The document of what will be tested and the pass criteria | `validation_plans` |
| Validation run | The record of executing the plan and the actual results | `validation_runs` |
| Validation package | The bundled, hashed evidence set routed for sign-off | `validation_packages` |
| Change-triggered revalidation | Re-running validation automatically when the system changes | F8 job + `system_changes` |
| Dual-model cross-check | Two independent LLMs (Claude + GPT) reviewing the same content | `agent_review_*`; accuracy safeguard |
| Advisory AI | AI that suggests/reviews but never decides or signs | Annex 22 / EU AI Act Art. 14; ARCH-AI-001 |
| HITL | Human-in-the-loop — a person reviews and approves | `esignature_id`, `approver_esignature_id` |
| ALCOA+ | Attributable, Legible, Contemporaneous, Original, Accurate (+Complete, Consistent, Enduring, Available) | The records here must satisfy this |
| SoD | Segregation of Duties — author ≠ approver | Enforced on plan/package approval |
| e-signature | Legally-meaningful electronic signature | Part 11; on plan/package approval |
| package_hash | Integrity fingerprint of an approved package | Tamper-evidence (ALCOA+ Original) |

### 0.7 Module 40 architectural picture

```mermaid
graph LR
  subgraph M40 [Module 40 — Self-Validation / Validation-Automation Engine]
    DET[Change Detection<br/>validation-change-detection.job.ts F8 / 30 min]
    CHG[Change Register<br/>system_changes]
    CLS[Classification<br/>GAMP / impact / risk / scope]
    PLAN[Validation Plan<br/>validation_plans]
    RUN[Execution + Results<br/>validation_runs]
    EVID[Objective Evidence<br/>validation_screenshots]
    AICK[Dual-Model Cross-Check<br/>Claude + GPT - advisory]
    PKG[Validation Package + hash<br/>validation_packages]
    ESIG[HITL E-Signature Gate<br/>SoD author != approver]
    DASH[Validation Dashboard<br/>ValidationDashboard.tsx]
  end

  M35[URS-35 Infrastructure / deploy] --> DET
  M13[URS-13 Change Control] --> CHG
  DET --> CHG --> CLS --> PLAN --> RUN --> EVID
  PLAN --> AICK
  RUN --> AICK
  AICK --> PKG
  RUN --> PKG --> ESIG --> DASH
  M02[URS-02 RBAC<br/>resource: validation] --> ESIG
  M03[URS-03 Context Gate / scope] --> CHG
  M04[URS-04 Workflow / HITL / E-Sign] --> ESIG
  M05[URS-05 Authority Profiles] --> ESIG
  M06[URS-06 Audit Substrate] <-- PKG
  M32[URS-32 MIRA-AI / AI Provider Gateway<br/>llm_audit_log] --> AICK
  M30[URS-30 Notifications] --> AICK
  M22[URS-22 Inspection Readiness] <-- PKG
  M38[URS-38 Dashboards] <-- DASH
  ANNEX22[Internal Annex 22 control — GenAI advisory-only in validation evidence] -.governs.-> AICK
  ARCHAI[ARCH-AI-001 advisory-AI governance] -.governs.-> AICK
  ESIG -.decision of record.-> PKG
```
Diagram 0.7-A — Module 40 architectural picture. The dual-model cross-check (Claude + GPT) routes through the existing AI provider gateway (URS-32) and logs to `llm_audit_log`; it **governs nothing of record** — the decision of record is the human e-signature gate. Ownership is target binding, subject to repository verification.

---

## 1. Module Purpose
Module 40 shall provide a change-triggered, risk-based engine that prepares, executes, evidences, AI-cross-checks, packages, and routes for human approval the IQ/OQ/PQ validation of the Verixa platform, producing inspection-defensible validation evidence while keeping all final dispositions as human, e-signed actions.

## 2. Scope

### 2.1 In scope
- **Change detection + register** (`system_changes`) — code: `validation-change-detection.job.ts`, `detectChanges()`.
- **Validation impact classification** (GAMP category, impact level, risk level, validation scope) — code: `classifyChange()`.
- **Validation-plan generation** with a pre-built, versioned IQ/OQ/PQ test-case library + acceptance criteria (`validation_plans`) — code: `generateValidationPlan()`.
- **Real test execution** with per-stage actual results + pass rate (`validation_runs`) — code: `executeValidation()` (target-state; currently stubbed).
- **Objective evidence capture** (`validation_screenshots`).
- **Dual-model AI cross-check** (Anthropic Claude + OpenAI GPT) as advisory agent review (`agent_review_scores/findings/report`).
- **Validation-package assembly** with integrity hash (`validation_packages`).
- **HITL e-signature approval** of plans and packages (SoD enforced).
- **Change-triggered revalidation**; **audit trail**; **tenant isolation (RLS/TDAL)**; **validation dashboard**.

### 2.2 Out of scope
- The source GxP modules being validated (owned by URS-01…38).
- The customer's own validation lifecycle and QA approval (customer-owned — CSV/CSA handoff).
- Final QA release disposition for the Verixa platform (Head of QA).
- Detailed IQ/OQ/PQ protocol authoring (Validation Test Architect).
- Any autonomous AI decision (prohibited — SV-REQ-008).

### 2.3 Closed launch decisions
| ID | Decision |
|---|---|
| DEC-40-01 | The AI cross-check uses **two** independent providers (Anthropic Claude + OpenAI GPT); single-model review is insufficient for the accuracy guarantee. |
| DEC-40-02 | AI is **advisory only**; the validation pass/fail is deterministic (rules vs. acceptance criteria) and the disposition is a human e-signature. Generative AI is prohibited from the decision of record. **(a) Internal design decision:** the ARCH-AI-001 advisory-only control. **(b) External regulatory basis:** EU GMP Annex 22 (draft) and EU AI Act Art. 14 are cited as an **anticipatory** mapping, pending the legal classification at §9.2 — not asserted as in-force binding here. |
| DEC-40-03 | Execution must record **real** per-test results and objective evidence; hardcoded/auto-pass is prohibited and is a data-integrity defect. |
| DEC-40-04 | Plan/package **author ≠ approver** (segregation of duties), non-bypassable. |
| DEC-40-05 | A detected change creates a **new** run/package; prior runs/packages are retained, never overwritten. |
| DEC-40-06 | Validation evidence is labelled **supplier self-validation evidence that reduces, not replaces,** customer validation responsibility. |
| DEC-40-07 | Model/provider/prompt changes are themselves controlled changes (`model_version_change`/`agent_prompt_update`) and trigger revalidation of the engine. |

## 3. User Roles and Permissions
Permission resource: **`validation`** (code: route `config.permission.resource = 'validation'`).

| Role | View | Register change | Classify | Author/generate plan | Execute run | Capture evidence | Approve plan/package (e-sign) | Configure |
|---|:--:|:--:|:--:|:--:|:--:|:--:|:--:|:--:|
| Engine / system account (F8 job) | – | ✔ | ✔ | ✔ | ✔ | ✔ | ✘ | – |
| Validation Engineer | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✘ | – |
| QA / Validation Approver | ✔ | – | – | – | – | – | ✔ (e-sign) | – |
| Reviewer | ✔ | – | – | – | – | – | ✘ | – |
| Inspector (read-only) | ✔ | – | – | – | – | – | ✘ | – |
| Admin | ✔ | – | – | – | – | – | ✘ | ✔ |

**SoD (DEC-40-04):** the plan/package author and the F8 engine account may never be the approver; enforced at the service layer.

**Role evidence (`Unknown — evidence required`).** The roles above are *functional personas*. Validation-specific roles, approval-authority profiles, and the mapping from these personas to **supported tenant roles/permissions (URS-02/05)** are **not demonstrated in the repo at `3bd2fe47`** and **shall** be reconciled to the canonical permission/authority model before approval (SV-COR-012). Do not assume these roles exist as named platform roles.

## 4. End-to-End User Journeys
- **J-01** — F8 job detects a deployment → creates a `system_changes` record (git commit/branch, changed files/tables). 
- **J-02** — Engine classifies the change → GAMP category, impact/risk level, validation scope.
- **J-03** — Engine generates a validation plan with IQ/OQ/PQ cases from the library + acceptance criteria (`plan_draft`).
- **J-04** — Dual-model AI cross-check reviews the plan (Claude + GPT) → advisory scores/findings (`plan_agent_reviewed`); logged to `llm_audit_log`.
- **J-05** — Validation Engineer routes the plan; a different QA Approver e-signs approval (SoD enforced) → `plan_approved`.
- **J-06** — Engine executes the plan → real IQ/OQ/PQ results + pass rate; captures screenshots (`run_running → run_passed/failed/blocked`). CONDITIONAL is **not** a run result — it is a human disposition (SV-REQ-034 / URS-16).
- **J-07** — Dual-model AI cross-check reviews the executed results; **divergence > threshold → AI review hold (`ai_review_status`)** + reviewer notification. The deterministic run result (`validation_result`) is **unchanged** by the AI; the human resolves the hold (SV-REQ-009/030).
- **J-08** — Engine assembles the validation package from real evidence + `package_hash` (`package_draft → package_agent_reviewed`).
- **J-09** — QA Approver reviews the package and e-signs a **disposition** (separate from the factual run result; canonical disposition values: **VALIDATED**, **CONDITIONAL**, **REJECTED**). A run with **no mandatory failure** may be dispositioned **VALIDATED**, or **CONDITIONAL** only via a linked, approved deviation (URS-16) — *"accepted-with-deviation"* is the same concept as **CONDITIONAL** (one canonical term, SV-REQ-034). A **failed** run is e-signed as a **reviewed record of failure (REJECTED / not-accepted)** — it **does not** authorize release and **shall not** become VALIDATED or CONDITIONAL. Accepted dispositions (`disp_validated`/`disp_conditional`) → `archived` (immutable).
- **J-10** — Inspector opens the validation dashboard and drills from a package to its run, evidence, AI-review report, and audit trail.
- **J-11 (exception)** — Execution produces a failing test → `run_failed`; package result FAILED; no approval; change remains un-revalidated and is flagged.
- **J-12 (exception)** — AI provider unavailable → cross-check marked incomplete (advisory), run not blocked from human review, but absence of cross-check is recorded; reviewer decides.
- **J-13 (negative)** — A user who is the plan author attempts to approve it → blocked by SoD (DEC-40-04), audited.
- **J-14 (change control)** — A `model_version_change` (e.g., new GPT/Claude version) is detected → new `system_changes` row → engine revalidation triggered (DEC-40-07).

## 5. Front-End Expected State
### 5.1 Routes
- Validation dashboard (existing): `GET /validation/dashboard` → `ValidationDashboard.tsx` (changes, plans, runs, packages, statuses, divergence flag).
- Plan/run/package detail views with: advisory-AI banner ("AI cross-check is advisory; requires human review"), AI agreement/divergence indicator, evidence (screenshots) gallery, e-sign approval action, audit-trail panel.
### 5.2 Component requirements
Loading / error / empty states on every async view (QS-17); approval button disabled until reviewer confirms and re-authenticates; irreversible/regulated actions confirmed; AI output visually distinguished from system-of-record fields (QS-21).
### 5.3 Accessibility and i18n
WCAG where in scope; controlled export of package evidence; inspector-readable record view.

## 6. Back-End Expected State

### 6.1 Domain entities and diagrams
Entities (all from migration 052, all RLS-enabled): `system_changes`, `validation_plans`, `validation_runs`, `validation_screenshots`, `validation_packages`.

#### 6.1-A Entity-relationship overview
```mermaid
erDiagram
  system_changes ||--o{ validation_plans : "change_id"
  validation_plans ||--o{ validation_runs : "plan_id"
  system_changes ||--o{ validation_runs : "change_id"
  validation_runs ||--o{ validation_screenshots : "run_id"
  validation_runs ||--o{ validation_packages : "run_id"
  validation_plans ||--o{ validation_packages : "plan_id"
  system_changes ||--o{ validation_packages : "change_id"
  system_changes {
    uuid id PK
    uuid tenant_id FK
    varchar change_type
    text change_diff
    jsonb affected_modules
    varchar gamp_category
    varchar impact_level
    varchar risk_level
    varchar validation_scope
    varchar git_commit_hash
  }
  validation_plans {
    uuid id PK
    uuid change_id FK
    varchar status
    jsonb test_cases
    jsonb acceptance_criteria
    jsonb agent_review_scores
    uuid esignature_id
    uuid approved_by
  }
  validation_runs {
    uuid id PK
    uuid plan_id FK
    varchar status
    jsonb iq_results
    jsonb oq_results
    jsonb pq_results
    numeric pass_rate
  }
  validation_screenshots {
    uuid id PK
    uuid run_id FK
    varchar stage
    varchar image_hash
    text image_path
  }
  validation_packages {
    uuid id PK
    uuid run_id FK
    varchar status
    varchar overall_result
    varchar package_hash
    uuid approver_esignature_id
  }
```
Diagram 6.1-A — Entity relationships (FK constraints per migration 052; `ON DELETE CASCADE` on tenant/parent).

#### 6.1-B Plan / run / package state machines
```mermaid
stateDiagram-v2
  state "validation_plans.status" as P {
    [*] --> draft
    draft --> agent_reviewed : dual-model AI advisory
    agent_reviewed --> pending_approval
    pending_approval --> approved : e-sign (author!=approver)
    pending_approval --> rejected
    approved --> superseded : new plan version
  }
  state "validation_runs.status (factual result — TARGET)" as R {
    [*] --> pending
    pending --> running : executeValidation
    running --> passed : meets acceptance_criteria
    running --> failed : fails acceptance_criteria
    running --> blocked : precondition/runner error
    note right of running : Factual run results ONLY (passed / failed / blocked / skipped / aborted). 'conditional' is NOT a run result. migration-052's run enum currently still includes 'conditional' — a defect to be removed (SV-COR-015 / SV-REQ-018).
  }
  state "ai_review_status (separate, advisory)" as AIR {
    [*] --> ai_none
    ai_none --> ai_hold : divergence > threshold OR unavailable
    ai_hold --> ai_resolved : QA/Validation reviewer resolves, with reason + audit; e-sign if it affects disposition — validation_result unchanged (SV-REQ-009/030)
  }
  state "validation_packages — disposition (human)" as K {
    [*] --> draft
    draft --> agent_reviewed
    agent_reviewed --> pending_approval
    pending_approval --> validated : QA e-signs VALIDATED (no mandatory failure)
    pending_approval --> conditional : QA e-signs CONDITIONAL (linked approved deviation, URS-16)
    pending_approval --> rejected : QA e-signs rejection / not-accepted
  }
```
Diagram 6.1-B — Lifecycle state machines. The plan/run/package `status` values are the migration-052 CHECK enums (the run enum currently includes `conditional` — a defect: per SV-COR-015, target state moves CONDITIONAL to the human-disposition layer; factual run results are passed / failed / blocked / skipped / aborted). `ai_review_status`, `validation_result`, transition history, deviation linkage, and release-readiness are **target-state additions NOT yet in migration 052**.

#### 6.1-C Dual-model AI cross-check (sequence)
```mermaid
sequenceDiagram
  participant ENG as Engine
  participant GW as AI Provider Gateway (URS-32)
  participant CL as Anthropic Claude
  participant GP as OpenAI GPT
  participant LOG as llm_audit_log
  participant QA as QA Approver (human)
  ENG->>GW: review(plan/run/package, acceptance_criteria)
  GW->>CL: independent review request
  GW->>GP: independent review request
  CL-->>GW: score + findings
  GP-->>GW: score + findings
  GW->>LOG: log provider, model+version, prompt version, input hash, output
  GW-->>ENG: two advisory reviews + agreement/divergence
  alt divergence > threshold OR AI unavailable
    ENG->>ENG: set ai_review_status = hold + notify (URS-30) — validation_result UNCHANGED
  end
  ENG-->>QA: advisory report (labelled) + real run evidence
  QA->>QA: human decision + e-signature (decision of record)
```
Diagram 6.1-C — The AI cross-check is advisory; the QA e-signature is the decision of record (DEC-40-02; EU AI Act Art. 14; Annex 22).

### 6.2 Data model requirements
The system **shall** use the existing tables and their CHECK-constrained status enums; new fields **shall** be added only via a new numbered migration with `IF NOT EXISTS`, `ENABLE ROW LEVEL SECURITY`, a `tenant_isolation` policy, and a `-- ROLLBACK:` comment (QS-6/QS-13). `iq/oq/pq_results.details` **shall** be populated with per-test evidence (not empty).

#### 6.2.1 Target-migration DDL (draft design spec — Product/Engineering Architect + Data Integrity own final)
The new fields/tables required by Critical requirements (SV-REQ-023/030/034, SV-COR-009/010/015/019/020) have a target DDL below so two developers cannot diverge. This is a **draft design specification** to be ratified by the Product/Engineering Architect and Data Integrity owner before build; it follows migration-052 conventions (idempotent, RLS, rollback). Exact migration number is assigned at build time.

```sql
-- ROLLBACK: drop the columns/tables/policies added below.
-- (a) ALCOA+ attribution (SV-REQ-023 / SV-COR-020) — service-principal UUID, never NULL post-backfill
ALTER TABLE validation_plans      ADD COLUMN IF NOT EXISTS created_by UUID, ADD COLUMN IF NOT EXISTS updated_by UUID;
ALTER TABLE validation_runs       ADD COLUMN IF NOT EXISTS created_by UUID, ADD COLUMN IF NOT EXISTS updated_by UUID;
ALTER TABLE validation_packages   ADD COLUMN IF NOT EXISTS created_by UUID, ADD COLUMN IF NOT EXISTS updated_by UUID;
ALTER TABLE validation_screenshots ADD COLUMN IF NOT EXISTS created_by UUID, ADD COLUMN IF NOT EXISTS updated_by UUID;

-- (b) Deterministic run result separated from AI review (SV-REQ-018/030, SV-COR-009) — 'conditional' REMOVED from run layer
ALTER TABLE validation_runs ADD COLUMN IF NOT EXISTS validation_result VARCHAR(10)
  CHECK (validation_result IN ('passed','failed','blocked','skipped','aborted'));
ALTER TABLE validation_runs ADD COLUMN IF NOT EXISTS ai_review_status VARCHAR(20)
  CHECK (ai_review_status IN ('ai_none','ai_hold','ai_resolved'));
ALTER TABLE validation_runs ADD COLUMN IF NOT EXISTS ai_review_resolution TEXT;
ALTER TABLE validation_runs ADD COLUMN IF NOT EXISTS ai_review_resolved_by UUID;     -- QA/Validation reviewer
ALTER TABLE validation_runs ADD COLUMN IF NOT EXISTS ai_review_resolved_at TIMESTAMPTZ;
-- migration to correct the legacy run enum: drop 'conditional' from validation_runs.status after data fix (separate controlled change).

-- (c) Human disposition layer (SV-REQ-034, SV-COR-015) — CONDITIONAL lives here, with a linked URS-16 deviation
ALTER TABLE validation_packages ADD COLUMN IF NOT EXISTS disposition VARCHAR(12)
  CHECK (disposition IN ('validated','conditional','rejected'));
ALTER TABLE validation_packages ADD COLUMN IF NOT EXISTS deviation_link UUID;          -- FK → URS-16 deviation (conditional only)
ALTER TABLE validation_packages ADD COLUMN IF NOT EXISTS release_readiness VARCHAR(16)
  CHECK (release_readiness IN ('not_ready','ready','blocked'));

-- (d) Append-only transition history (SV-COR-010/023)
CREATE TABLE IF NOT EXISTS validation_transition_history (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  tenant_id UUID NOT NULL REFERENCES tenants(id) ON DELETE RESTRICT,
  entity_type VARCHAR(20) NOT NULL CHECK (entity_type IN ('change','plan','run','package')),
  entity_id UUID NOT NULL,
  record_version INTEGER,
  from_state VARCHAR(30), to_state VARCHAR(30) NOT NULL,
  reason TEXT, transitioned_by UUID NOT NULL, transitioned_at TIMESTAMPTZ NOT NULL DEFAULT now(),
  signature_id UUID, evidence_snapshot_hash VARCHAR(64)
);  -- append-only: no UPDATE/DELETE (enforce by grant + trigger)
ALTER TABLE validation_transition_history ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_isolation ON validation_transition_history
  USING (tenant_id = current_setting('app.current_tenant_id')::uuid);

-- (e) Evidence deletion protection (SV-COR-019) — replace CASCADE with RESTRICT on the evidence chain
--     (rebuild the child FKs from validation_plans/runs/screenshots/packages → parent as ON DELETE RESTRICT;
--      tenant offboarding / legal hold uses controlled archive-export, never cascade delete.)
```
**Open items for the Architect/DI ratification:** exact migration number; backfill plan for `created_by` on existing rows; whether `validation_result`/`disposition` use VARCHAR+CHECK (shown) or native ENUM; the immutability-guard mechanism (DB trigger vs app-layer) for approved runs/packages; and the data-fix sequence for removing `conditional` from the legacy `validation_runs.status` enum (F-17).

### 6.3 API requirements
Existing route surface (`validation.routes.ts`, resource `validation`): register change; list/get changes; classify change; generate plan; list/get plans; agent-review plan; **approve plan (e-sig)**; reject plan; execute validation; get run; **capture screenshot**; generate package; get package; agent-review package; **approve package (e-sig)**; reject package; `GET /validation/dashboard`. Every route **shall** enforce `requirePermission('validation:<action>')` and Zod validation (QS-7/QS-8).

### 6.4 Workflow / lifecycle requirements
Status transitions **shall** follow §6.1-B; run `status` **shall** be derived from acceptance criteria (SV-REQ-018), never constant; AI review **shall not** transition a record to `approved`/`passed` (SV-REQ-008).

### 6.5 Business rules
DEC-40-01…07 (§2.3) are enforced rules. Auto-pass is prohibited (DEC-40-03). Author≠approver (DEC-40-04).

### 6.6 Audit trail requirements
Every mutation **shall** write `auditTrailService.log` (tenantId, userId/named-system-account, action, resourceType, resourceId, before/after) per §4 events; append-only (QS-1). Every AI call **shall** log to `llm_audit_log`/`ai_requests` with model + version + prompt version (QS-21/QS-24).

### 6.7 Architecture binding — Annex 22 + ARCH-AI-001
Unlike modules that prohibit generative AI in any decision path, Module 40 **uses** generative AI (Claude + GPT) **but strictly as advisory cross-check**: it must not write a pass/fail or an approval, must be visibly labelled, must be fully logged, and is overridden by the deterministic acceptance-criteria evaluation and the human e-signature. This implements an **internal design decision** — the ARCH-AI-001 advisory-only control. Any mapping to EU GMP Annex 22 (draft) or EU AI Act Art. 13/14 (transparency + human oversight) is an **anticipatory internal posture only**; external enforceability and legal classification are pending the assessment at §9.2 and are **not** asserted as binding here. **The AI cross-check binds the URS-32 AI canon** (§9.3): all model calls transit the URS-32 AI Gateway `/api/v1/ai/*`; every call logs to `ai_governance_events` + `llm_audit_log`; each AI-influenced record carries an `outcome_label` (DEC-32-07); models are qualified per GMLP + URS-13 change control; prompts are URS-12 controlled documents; ARCH-AI-001 AC-5/AC-6/AC-7 apply.

> **ARCH-AI-001 controlled reference is now identified but remains DRAFT.** URS-40 binds to **ARCH-AI-001 "AI Optionality and Manual Continuity" v1.0** (target QMS location: `docs/architecture/ARCH-AI-001_AI-Optionality-and-Manual-Continuity.md`). For URS-40, the binding subset is **AC-5** (AI errors shall not be silently swallowed), **AC-6** (AI output shall never directly bind a GxP field), and **AC-7** (AI-influenced artifacts shall carry outcome provenance). Because ARCH-AI-001 v1.0 is still `DRAFT — not approved`, URS-40 freeze remains blocked until ARCH-AI-001 is filed at the controlled QMS location and approved under URS-13 change control.

### 6.8 Human review & edit rules
What a human reviewer may and may not edit is governed by *what* the item is and *when* it is edited. Four cases:

1. **Drafts (plans/packages) before approval — editable.** A reviewer may edit a draft plan or package freely; every edit is captured (actor, before/after, and a reason where required). (SV-REQ-024)
2. **AI advisory output — editable.** The Claude + GPT cross-check is advisory; the human may accept, edit, or reject it, and the human's disposition is recorded. The AI never has the final word (SV-REQ-008).
3. **Machine-captured test results & evidence — NOT editable.** Objective run results and captured evidence (screenshots/artifacts) **cannot** be overwritten — a `failed` may not be turned into `passed`, and an artifact may not be silently replaced. Correction is only by **re-run**, a **documented investigation**, or **reject**. (SV-REQ-025) This is the core ALCOA+ (Original/Accurate) protection; it is also why the current auto-pass stub is prohibited.
4. **Signed records — locked.** Once a plan or package is e-signed, it is immutable; any change requires a **new controlled version**, re-review, and re-signature, with the original preserved. A change to a signed record **invalidates** the signature. (SV-REQ-026)

Cross-cutting: a **reason-for-change** is captured for edits to controlled records where required and for all post-approval corrections (SV-REQ-027); and **segregation of duties** applies throughout — the author of a plan/package may not be its approver (SV-REQ-016).

## 7. Cross-Module Wiring and Change-Impact

### 7.1 Cross-module wiring
| Module | Relationship |
|---|---|
| URS-35 Infrastructure | Deployments/migrations are change sources for `system_changes`. |
| URS-13 Change Control | A controlled change may register/trigger a `system_changes` record + revalidation. |
| URS-02 RBAC / URS-03 Context Gate / URS-05 Authority | Permission (`validation`), scope, and authority for execution/approval. |
| URS-04 Workflow / HITL / E-Sign | E-signature contract for plan/package approval. |
| URS-06 Audit Substrate | Receives all engine audit events. |
| URS-32 MIRA-AI / AI Provider Gateway | Hosts the Claude + GPT calls; `llm_audit_log` linkage. |
| URS-30 Notifications | Divergence / overdue / failure notifications. |
| URS-22 Inspection Readiness | Validation packages feed the inspection evidence pack. |
| URS-38 Dashboards | Surfaces engine state. |

### 7.2 Change-Impact Matrix
| If this changes | Engine effect |
|---|---|
| Platform code / migration / config | New `system_changes` → classify → plan → run → package. |
| AI model / provider / prompt | `model_version_change`/`agent_prompt_update` → engine revalidation (DEC-40-07). |
| Acceptance criteria / protocol library | Controlled change; new plan version (`superseded`). |

## 8. Target-state requirements register

| Req ID | Type | Requirement (`shall`) | Risk | Acceptance | Reg/QS trace | Evidence |
|---|---|---|---|---|---|---|
| SV-REQ-001 | Functional | Detect + record platform changes in `system_changes` (type, diff, affected modules/files/tables, git commit/branch, deployment id). | High | One row per change with required provenance fields | Annex 11 §10 | **PARTIAL (verified 3bd2fe47):** `registerChange()` nulls `changed_files/tables`, `deployment_id`, `migration_number`, `git_commit/branch` (132–143); job scans existing rows only → SV-COR-001 |
| SV-REQ-002 | Functional | Classify each change (GAMP cat, impact, risk, validation scope) — risk-based, not hardcoded. | High | High-risk changes do not default to medium/partial | FDA CSA; ICH Q9(R1) | **CONFLICT (verified):** `classifyChange()` hardcodes `4b/medium/medium/partial` (161–164) → SV-COR-002 |
| SV-REQ-003 | Functional | Generate a plan with IQ/OQ/PQ cases from a pre-built versioned library mapped to affected URS functions + acceptance criteria. | High | Cases trace to affected functions; not placeholders | GAMP 5; Annex 11 §4 | Built skeleton; **Gap**: placeholders `:247–270` |
| SV-REQ-004 | Validation | Execute IQ/OQ/PQ; record real per-stage results + pass rate; never auto-pass. | High | `details` non-empty; status reflects real outcome | QS-1; ALCOA+ | **Gap (high)**: hardcoded `:458–477` |
| SV-REQ-005 | Data | Capture objective evidence per step in `validation_screenshots` (hash + path + test_case_id + step). | High | ≥1 artifact per executed step, with integrity hash | Annex 11 §7 | **PARTIAL (verified):** table has `image_hash`/`image_path` but `captureScreenshot()` stores `image_hash: null` (548) → SV-COR-006 |
| SV-REQ-006 | AI | Cross-check accuracy with **Anthropic Claude + OpenAI GPT** independently, **routed through the URS-32 AI Gateway (`/api/v1/ai/*`)** (not a private provider call); store advisory scores/findings/report; label advisory; bind ARCH-AI-001 AC-5/AC-6/AC-7. | High | Two provider reviews per artifact via the Gateway; labelled advisory; `outcome_label` set | EU AI Act Art. 13; Annex 22; URS-32 DEC-32-04/07; QS-8/21 | Built skeleton (`agent_review_*`); **dual-provider via Gateway = build** |
| SV-REQ-007 | AI | Log every AI call (provider, model name+version, prompt-template version, input hash, output, agreement) to the URS-32 **`ai_governance_events`** substrate **and** `llm_audit_log`; attach `outcome_label` (URS-32 DEC-32-07) to each AI-influenced record. | High | One AI-governance entry + one audit entry per call; `outcome_label` present | 21 CFR 11.10(e); URS-32 DEC-32-04/07; QS-21/24 | Build (bind to URS-32 substrate) |
| SV-REQ-008 | AI | AI **shall not** approve/pass/fail/release; disposition requires human e-signature. | High | No AI write to status=approved/passed | EU AI Act Art. 14; Annex 22 §7; QS-23 | HITL gate exists; enforce + test |
| SV-REQ-009 | AI | Divergence > configured threshold → raise a separate **AI review hold** (`ai_review_status`) + human review; the disagreement **shall not** change the deterministic `validation_result` and **shall not** itself set `conditional`. | High | Divergence → `ai_review_status` hold + notify; result unchanged | EU AI Act Art. 14 | Build — **corrects prior contradiction** (SV-COR-009) |
| SV-REQ-010 | Functional | A detected change triggers a new plan + new run with fresh evidence; prior runs retained. | High | New change → new run; old runs retained | Annex 11 §4.4 | Built (trigger); re-execution = build |
| SV-REQ-011 | Functional | Assemble package linking change+plan+run with documents, AI report, `overall_result`, `package_hash` from real evidence. | High | Package reproduces run evidence; hash verifies | Annex 11 §12; GDocP | Built table+route; content = build |
| SV-REQ-012 | E-Signature | Plan + package approval require a **validated e-signature ceremony** bound to record+version (signer, time, meaning). | Critical | Missing/wrong/reused signature + post-sign mutation all fail | 21 CFR Part 11 §11.50/11.70; Annex 11 §14 | **CONFLICT (verified):** `approvePlan()` ignores `_esignatureId` → stores `esignature_id: null` (291/377–381); conditional approval doesn't persist signature (747); routes accept empty signature → SV-COR-005 |
| SV-REQ-013 | Audit Trail | Every mutation writes `auditTrailService.log` with before/after; append-only. | High | One audit entry per mutation | 21 CFR 11.10(e); QS-1 | Partial; extend to all |
| SV-REQ-014 | Data | Approved runs/packages immutable + retained (`archived_at`). | Med | No post-approval mutation | Annex 11 §17; QS-4 | Build/verify |
| SV-REQ-015 | Security | RLS + TDAL `withTenant` on all five tables. | High | Cross-tenant blocked; isolation test passes | QS-5/6; Annex 11 §12 | Built: RLS on all five |
| SV-REQ-016 | Security | Gate **every** validation route by `validation` permission; approver ≠ author (SoD). | Critical | Every route permission-gated; wrong-role denied | Annex 11 §12; 21 CFR 11.10(d)/(g); QS-7 | **PARTIAL (verified):** SoD present, but **four** routes lack route permission config — register-change POST (22), list-changes GET (33), list-plans GET (74), conditional-approval POST (213); and protected routes use `action:'create'` only (no approve/execute/manage) → SV-COR-012 (RBAC vocabulary + authority). SoD is further bypassable where `created_by` is NULL (migration gap, ADD-VER-03) and absent from conditional approval. |
| SV-REQ-017 | Functional | Validation dashboard of changes/plans/runs/packages + statuses, scoped per tenant. | Med | Scoped engine state renders | Annex 11 §12 | Built: `/validation/dashboard`, `ValidationDashboard.tsx` |
| SV-REQ-018 | Validation | The factual **run result** **shall** be derived from measurable acceptance criteria and limited to **`passed` / `failed` / `blocked` / `skipped` / `aborted`** — `conditional` is **not** a run result (it is a human disposition, SV-REQ-034). | High | Run result is one of the five factual values; never constant; `conditional` absent from the run layer | GAMP 5; FDA CSA | **Build — corrects prior contradiction** (migration-052 run enum still has `conditional`; SV-COR-015) |
| SV-REQ-034 | Validation / E-Signature | **CONDITIONAL** is a **human-disposition** value (not a run result), permitted **only** when no mandatory test failed **and** a linked, approved deviation (URS-16) exists; it **shall** be set by a human e-signature, never by the engine. | Critical | No CONDITIONAL without a linked approved deviation; human e-signs | 21 CFR Part 11; ICH Q10 | Build (SV-COR-015) |
| SV-REQ-019 | AI | Documented AI **Intended-Use statement** (§9) + **QA-approved monitoring thresholds**; cross-check models qualified per GMLP + URS-13 CR; prompt templates stored as URS-12 controlled documents. | High | IU documented (§9); thresholds approved by QA; models qualified; prompts versioned | Annex 22 §5; GMLP; URS-32 DEC-32-09/10; QS-22 | **IU filled (§9)**; thresholds candidate — QA approval pending |
| SV-REQ-020 | Change Control | Model/provider/prompt changes are controlled changes triggering engine revalidation. | High | Such change → `system_changes` + revalidation | Annex 22 §5; QS-22 | Built enum; wire |
| SV-REQ-021 | Functional | Label evidence as supplier self-validation that reduces, not replaces, customer validation. | Med | Label on package + UI | Annex 11 §4.8; FDA CSA | Build |
| SV-REQ-022 | Performance | **DEFERRED — not yet a testable requirement.** No measurable performance targets are defined; this row is an explicit deferral of performance qualification, **not** a freeze-ready requirement. Concrete thresholds (e.g., F8 detection-cycle time; per-run execution time; AI-cross-check latency) **shall** be set by Engineering + QA before this is included in any OQ. | Med | Targets defined + measured, OR documented decision to defer PQ | — | `Performance threshold Unknown — evidence required` (Owner: Engineering + QA) |
| SV-REQ-023 | Data | Every engine record (`validation_plans`, `validation_runs`, `validation_packages`, `validation_screenshots`) **shall** populate `created_by`/`updated_by` with a UUID; engine-generated records **shall** use a stable **service-principal UUID** (least-privilege; **cannot** approve), never an email-in-UUID-column or NULL. | High | No NULL attribution; engine writes attributed to a service-principal UUID; runtime schema defines the columns | 21 CFR 11.10(a); ALCOA+ Attributable; QS-2 | **Gap (verified):** `created_by`/`updated_by` absent in migration 052; `triggered_by` is UUID — do not store an email (FDA-INS-014 → SV-COR-020) |
| SV-REQ-024 | Functional | Before approval, draft plans/packages and AI advisory output **may** be edited (accept/edit/reject); every edit **shall** be captured with actor, before/after, and reason where required. | High | Edits logged with before/after | 21 CFR 11.10(e); ALCOA+ | Build (§6.8 case 1–2) |
| SV-REQ-025 | Data | Machine-captured test results and evidence **shall not** be editable or overwritable; correction is only by re-run, documented investigation, or reject (a `failed` result **shall not** become `passed`). | Critical | No update path to run results/evidence; result immutable | ALCOA+ Original/Accurate; 21 CFR 211.194 | Build — **current auto-pass stub violates** (§6.8 case 3) |
| SV-REQ-026 | E-Signature | After e-signature, the record **shall** be locked; any change **shall** require a new controlled version, re-review, and re-signature, preserving the original; a change to a signed record **shall** invalidate the signature. | Critical | Post-sign edit blocked; new version + re-sign; original retained | 21 CFR Part 11; Annex 11 §14/§17 | Build (§6.8 case 4; SV-COR-005/008) |
| SV-REQ-027 | Data | A reason-for-change **shall** be captured for edits to controlled records where required and for all post-approval corrections. | High | Reason persisted on edits/corrections | Annex 11 §9; GDocP | Build |
| SV-REQ-028 | Validation | The **PQ** stage **shall** exercise realistic, intended-use scenarios — representative data, real workflow paths, and negative / boundary / role cases — reflecting fitness for the user's task; generic function checks or placeholder "UAT sign-off" cases are prohibited. | High | PQ cases trace to intended-use scenarios; no placeholder PQ | GAMP 5 (PQ); Annex 11 §4.7 | **CONFLICT (verified 3bd2fe47):** sole PQ case is placeholder `pq-1` "User acceptance / UAT sign-off / Review with business → Approved" (263–268) → SV-COR-003 |
| SV-REQ-029 | E-Signature | The **acceptance decision** (PQ/UAT sign-off and run/package disposition) **shall** be a human electronic signature; the engine and the AI cross-check **shall not** auto-accept, auto-pass, or set a `passed`/`approved`/`VALIDATED` state. For **user-facing workflow** changes, PQ **shall** include a real user performing and accepting the scenario — the engine captures evidence only. | Critical | No engine/AI path to passed/approved; human e-sign accepts; user-facing PQ has a real-user acceptance record | EU AI Act Art.14; Annex 22; 21 CFR Part 11; QS-23 | **CONFLICT (verified):** `executeValidation()` sets `status:'passed'`/`passRate=100` itself (464/474); `approvePlan()` ignores `_esignatureId` (`esignature_id: null`) → SV-COR-005/006 |
| SV-REQ-030 | AI / Data | The system **shall** store the deterministic `validation_result` separately from `ai_review_status`; AI review **shall not** set or modify `validation_result`, package result, approval, or release; a result **shall not** be derived from model agreement. | Critical | Distinct fields; no AI write path to result | EU AI Act Art.14; Annex 22 (anticipatory); QS-21/23 | Build (SV-COR-009) |
| SV-REQ-031 | Validation | `pass_rate` and `pass_rate_minimum` **shall** use the **same unit**, and the run **shall** be evaluated against the plan's acceptance criteria in matching units. | **Critical** | Units identical; evaluation unit-consistent | GAMP 5; data integrity | **CONFLICT (verified) — latent silent false-pass:** plan `pass_rate_minimum: 0.95` (fraction, 286) vs run `pass_rate: 100` (percent, 464); a naive `100 ≥ 0.95` is always-true — a false-pass path independent of the auto-pass stub → SV-COR-027 |
| SV-REQ-032 | Validation | A **predicate-rule / Part 11 applicability map** **shall** be documented per record type (required-by-predicate-rule / relied-upon / submitted-to-FDA) before approval; Part 11 controls apply only where in scope. | High | Applicability map exists; Part 11 scope justified per record | FDA Part 11 Scope & Application guidance | Build → SV-COR-028 |
| SV-REQ-033 | Validation | Unit tests that accept `passed`/`pass_rate:100`/empty evidence/null hashes/empty documents **shall** be replaced; automated unit tests **shall not** be presented as executed OQ; OQ **shall** include forced-false-pass, empty-evidence, and null-hash negative cases. | Critical | Defective tests removed; OQ proves a forced failure is `failed` | GAMP 5 verification | **Gap (verified):** current tests assert object existence only → SV-COR-029 |

> **Independent review incorporated (2026-06-04).** An external review (`urs 40 review gpt.docx`) was verified at `3bd2fe47` and accepted. It added **18 hardening requirements (SV-COR-009 … 026)** — now in `URS-40_Drift_Register_and_Corrected_Spec.md` §8 — covering: AI-result/AI-review separation (SV-COR-009), non-bypassable lifecycle (010), canonical API + FE/BE wiring (011), canonical RBAC verbs `read/manage/execute/approve` not `create` (012), executable protocol model (013), independent qualification boundary (014), result/review/disposition separation + no failed→VALIDATED (015), platform-master-change + tenant-impact (016), idempotency/concurrency/recovery (017), dual-provider gateway + fail-closed AI audit (018), manifest hashing + **no cascade-deletion of evidence** (019), attribution + schema/migration reconciliation (020), release-gate separation (021), environment/dataset baseline (022), rejection/transition history (023), ops monitoring (024, P1), document-numbering + regulatory-claim governance (025), AI-provider redaction/secret controls (026).
>
> **Second (FDA-inspector) review incorporated (2026-06-04), verdict `Reject for approval`** — `URS-40_Drift_Register_and_Corrected_Spec.md` §9 (FDA-INS-001…018, verified at `3bd2fe47`). It (a) **resolved the AI-divergence contradiction that was still present in the lifecycle diagram, run state machine, sequence diagram, monitoring rule, developer handoff, and HTML workflow** — now corrected so divergence raises a separate `ai_review_status` hold and never changes `validation_result`; (b) confirmed **SV-COR-011 (FE/BE contract)** and **SV-COR-018 (AI-gateway injection)** as real defects, not "Unknown"; (c) corrected **SV-REQ-023/SV-COR-020** to a service-principal **UUID** (not an email); and (d) added **SV-COR-027** (pass-rate unit integrity — 0.95 vs 100), **SV-COR-028** (predicate-rule/Part 11 applicability map), **SV-COR-029** (replace defective tests; unit tests ≠ executed OQ).
>
> The engineering corrected spec is now **SV-COR-001 … 029**. **Completeness caveat:** only SV-COR-001…008 are full implementation-grade PECRA; SV-COR-009…029 are summary-level (009…012 revised 2026-06-04) and **must be fully expanded before URS freeze** — the corrected spec is **not yet** complete enough to be the sole engineering source of truth.

> **Current-state verification (vs `dev-vimal-audit-2 @ 3bd2fe47`).** The Evidence column above was re-verified against the pinned code; over-optimistic "Built/OK" cells were corrected to **PARTIAL/CONFLICT** with line numbers (e.g., SV-REQ-002 classification hardcoded `4b/medium/medium/partial`; SV-REQ-012 plan-approval e-signature ignored → `esignature_id: null`). The full verified drift matrix, gap summary, and corrected P0 engineering spec (SV-COR-001…008) are in **`URS-40_Drift_Register_and_Corrected_Spec.md`**. Net current state: a database-backed skeleton — **not executed, not approved.**

### 8.1 Atomic decomposition of bundled requirements (resolves F-15)
SV-REQ-006, 019, 023, 029 each bundled several independently-testable concerns. They are decomposed into atomic sub-requirements below; each sub-row is the testable unit (own acceptance + OQ). The parent rows above remain as the umbrella reference.

| Req ID | Atomic requirement (`shall`) | Acceptance |
|---|---|---|
| SV-REQ-006a | Two independent providers (Claude + GPT) are each invoked | Two distinct provider calls evidenced |
| SV-REQ-006b | All calls transit the URS-32 AI Gateway `/api/v1/ai/*` | No direct provider call from the engine |
| SV-REQ-006c | Advisory outputs stored only in `agent_review_*` fields | No AI write to result/disposition fields |
| SV-REQ-006d | Each AI-influenced record carries an `outcome_label` (DEC-32-07) | `outcome_label` present |
| SV-REQ-006e | Binds ARCH-AI-001 AC-5/AC-6/AC-7 | AC-5/6/7 behaviours demonstrated |
| SV-REQ-019a | Documented AI Intended-Use statement (§9.1) | IU statement approved |
| SV-REQ-019b | QA-approved monitoring thresholds | Thresholds documented + QA-approved |
| SV-REQ-019c | Cross-check models qualified per GMLP + URS-13 CR | Model qualification records exist |
| SV-REQ-019d | Prompt templates stored as URS-12 controlled documents | Prompts versioned in URS-12 |
| SV-REQ-019e | Binds ARCH-AI-001 AC-5/AC-6/AC-7 | AC-5/6/7 bound |
| SV-REQ-023a | `created_by`/`updated_by` (UUID) populated on every engine record | No NULL attribution |
| SV-REQ-023b | Engine writes use a stable service-principal UUID (cannot approve) | System-principal UUID; not an email; SoD holds |
| SV-REQ-023c | Migration/schema/types/runtime reconciled; schema drift blocks release | IQ schema-reconciliation check passes |
| SV-REQ-029a | Acceptance decision is a human e-signature | No engine/AI auto-accept |
| SV-REQ-029b | Engine/AI never set `passed`/`approved`/`VALIDATED` | No such code path (negative OQ) |
| SV-REQ-029c | User-facing changes: a real user performs+accepts PQ | Real-user acceptance record exists |
| SV-REQ-029d | Engine captures evidence only (does not accept) | Evidence captured; human signs |

## 9. AI Intended-Use & Governance (AI Validation & Governance review)

This section resolves SV-REQ-019. The dual-model cross-check is **Acceptable with conditions** within the AI-governance boundary; final acceptance is the Head of QA's.

**9.1 Intended-Use statement (Claude + GPT cross-check)**
| Field | Content |
|---|---|
| Intended use | Two independent LLMs **assist** QA/validation reviewers by independently reviewing engine-generated validation content (plans, executed run results, draft packages) for accuracy and completeness, reporting agreement/divergence as a confidence signal. |
| Allowed inputs | Generated plan/run/package content; acceptance criteria; non-PHI engine metadata. **No customer GxP/PHI/PII data in prompts.** |
| Allowed outputs | Advisory scores + findings + agreement/divergence → `agent_review_scores/findings`, `agent_review_report` only. |
| Prohibited uses | Setting `run.status`/`package.status`/`validation_result`; approving, passing/failing, releasing, signing, closing; sole basis for `overall_result = VALIDATED`; writing any **factual result, evidence, signed disposition, release-readiness, or approval** field. **AI may write only its designated, visibly-labelled advisory fields** (`agent_review_scores`/`findings`/`report`, `ai_review_status`) — never anything else. |
| Reviewer / decider | Human QA/Validation approver reviews and is the **decision of record** (e-signature). |
| GxP impact | GxP-supporting/advisory; influence path treated as **high-process-risk** (FDA CSA), kept out of the decision of record by HITL. |

**9.2 EU AI Act & Annex 22 position (corrected per independent review — language must not overclaim).**
- **EU AI Act:** the Act is **risk-based**. The legal classification of this advisory validation-review use case is **not yet established** → `Unknown — legal classification required` (`Handoff required` to legal). The design *supports* transparency (Art. 13) and human oversight (Art. 14) via the advisory label + HITL e-signature, but this **shall not be asserted as "compliant" or "met"** until classification is documented.
- **EU GMP Annex 22:** Annex 22 is a **draft** and is **not** on EudraLex Volume 4's in-force annex list (as of 2026-06). It is adopted here **only as an internal anticipatory posture**, not cited as an in-force binding requirement. (Repo `CLAUDE.md` likewise treats it as Draft 2025, enforcement expected 2027–2028.)
- **The control that does not depend on legal classification:** Claude/GPT are generative/dynamic and are permitted **only as advisory cross-check**; the deterministic acceptance-criteria evaluation (SV-REQ-018) + human e-signature are the decision of record. **Wiring an LLM verdict to `validation_result`/`run.status`/`overall_result` is prohibited** (SV-REQ-008/009/030) — this holds regardless of the Annex 22 / AI Act legal status.
- **Annex 22 is not endorsement — the advisory classification is the escape hatch.** Annex 22's draft substance restricts *critical-application* AI to **static, deterministic** models and is, on its face, **adverse to generative LLMs** in critical GMP use. Verixa does not rely on Annex 22 as cover. The reason this LLM use is permissible is precisely that it is classified **advisory / non-critical** (no GxP decision authority; deterministic result + human e-signature), which keeps it **outside** Annex 22's static-deterministic critical-use restriction. If the advisory classification were ever lost, Annex 22's draft position would weigh **against** generative-AI use here.

**9.3 Model/prompt governance (binds URS-32 canon).** All calls via the URS-32 AI Gateway `/api/v1/ai/*`; logged to `ai_governance_events` + `llm_audit_log` (provider, model name+version, prompt-template version, input hash, output); `outcome_label` (DEC-32-07) on each AI-influenced record; models qualified per GMLP + URS-13 CR (DEC-32-09); prompts stored as URS-12 controlled documents; binds ARCH-AI-001 AC-5 (no silent AI-error swallow → DLQ), AC-6 (AI never binds a GxP field), AC-7 (outcome provenance).

**9.4 Monitoring (candidate thresholds — require QA approval; not approved as final).** Track: model divergence rate; AI-finding human-override rate; hallucinated/unsupported-finding rate; AI-review unavailability rate; model/prompt drift. Thresholds: `Unknown — to be set and approved by QA`. Candidate routing rule for QA to ratify: any material disagreement on a pass/fail-relevant finding → raise an `ai_review_status` hold + human review. This **never** changes the deterministic `validation_result`/run status (SV-REQ-009/030).

## 10. Data Integrity / ALCOA+ adequacy (Data Integrity / Part 11 / Annex 11 review)

This section resolves the ALCOA+ item. Records assessed: `system_changes`, `validation_plans`, `validation_runs`, `validation_screenshots`, `validation_packages`. **Decision: Not acceptable as currently built; Acceptable with conditions at target state.** Final acceptance is the Head of QA's.

| ALCOA+ | Status | Evidence / Gap |
|---|---|---|
| Attributable | **Gap** | No `created_by`/`updated_by` on plans/runs/packages → SV-REQ-023 (named system account). |
| Legible | **Partial** | JSONB results readable via dashboard, **but no controlled export is implemented at `3bd2fe47`** — reclassify to Partial until a controlled export exists. |
| Contemporaneous | Supported (schema); broken by stub | server `TIMESTAMPTZ` defaults; hardcoded results not contemporaneous to a real test. |
| Original/True copy | **Gap** | `image_hash`/`package_hash` only meaningful over real artifacts; approved-record immutability not enforced (SV-REQ-014). |
| Accurate | **Critical gap** | auto-pass stub asserts `passed/100%` with `details:[]` → SV-REQ-004/018. |
| Complete | **Gap** | empty `details` → no per-test results/failures/AI metadata → SV-REQ-004/005/007. |
| Consistent | **Partial** | FK chain + status enums + ordered timestamps, **but transitions are not enforced** (`approvePlan`/`rejectPlan` do not check source state) — Partial until non-bypassable gating (SV-REQ-021) is implemented. |
| Enduring | `Unknown — evidence required` | Retention period + backup/restore of these tables is owned by **URS-35 (Infrastructure / Backup-Restore)** — open dependency; retention period **TBD by QA/DI** per Part 11 §11.10(c) / Annex 11 §17. Cannot be evidenced until URS-35 owner + retention schedule are assigned (freeze blocker). |
| Available | **Partial** | RLS retrieval exists, **but the FE/BE API contract is broken on multiple routes (§12)** so dashboard/export availability is not demonstrated — Partial until the contract is reconciled. |

**Audit trail (SV-REQ-013):** every mutation → `auditTrailService.log` (before/after) into the **URS-06 tamper-evident, hash-chained** substrate; append-only (QS-1). **E-signature (SV-REQ-012):** bind to the **URS-04** contract — signer + meaning + UTC time + record-and-**version** link + manifestation in UI **and** export + **invalidation if the record changes after signing**. **Metadata:** persist rejection `reason`; carry AI model+version+prompt-version on AI-influenced records. **DI conditions = SV-REQ-004, 005, 007, 011, 012, 013, 014, 023** + retention/backup evidence (BCDR).

### 10.1 Predicate-rule / Part 11 applicability map (starter — SV-REQ-032 / SV-COR-028)
SV-REQ-032 requires this map to exist before approval. Below is a **starter determination** per record type; it is a **draft requiring Data Integrity + QA (and Legal where flagged) confirmation** — **owner: Head of QA / Data Integrity Lead**. Part 11 applies to a record only if it is *required by a predicate rule, relied upon for a regulated activity, or submitted to FDA*.

| Record type | Required by predicate rule? | Relied upon for a regulated activity? | Submitted to FDA? | Starter Part 11 determination |
|---|---|---|---|---|
| `system_changes` | No (engineering change log) | Indirect (triggers validation) | No | Likely **supporting**, not a Part 11 record on its own — confirm |
| `validation_plans` | If used as the validation protocol of record | Yes, if relied upon for release | Possibly | **In scope if relied upon** — needs determination |
| `validation_runs` | If used as validation evidence of record | **Yes** (the evidence) | Possibly | **In scope (likely)** — Part 11 controls apply |
| `validation_screenshots` | As attached objective evidence | Yes (supports runs) | Possibly | **In scope if part of the evidentiary record** |
| `validation_packages` | The signed validation report of record | **Yes** (disposition + e-sign) | Possibly | **In scope (likely)** — Part 11 controls apply |

`Unknown — evidence required`: the actual customer intended-use and whether any of these are submitted to FDA (varies by customer/use) → **Legal + customer-intended-use determination required** before the map is finalised. This starter map **does not** by itself satisfy SV-REQ-032; the controlled map must be completed and approved.

## 11. Cross-module reconciliation (vs URS 1–38)

| Check | Result |
|---|---|
| Scope collision with any 1–38 module | **None.** Only hit (URS-07) is incidental — `document_role` enum value `validation_plan`/`qualification_protocol` in study master-file documents, not the self-validation engine. |
| AI-governance ownership | **URS-32 (MIRA-AI)** is the canonical AI owner (AI Gateway `/api/v1/ai/*`, `ai_governance_events`, `outcome_label`, ARCH-AI-001 AC-1…7, model qualification via URS-13, prompts via URS-12). URS-40 **binds** to this canon (§9.3, SV-REQ-006/007) rather than inventing a gateway. |
| Cross-reference titles | Verified correct: URS-02 RBAC, 03 Context-Gate, 04 Workflow-HITL-ESig, 05 Authority-SoD, 06 Audit-Trail-HashChain-TamperEvident, 13 Change-Control, 22 Inspection-Management, 30 Notifications, 32 MIRA-AI, 35 Infrastructure, 38 Dashboards. |
| IQ/OQ/PQ usage elsewhere | URS-07/09/37 use IQ/OQ/PQ for study/site/equipment qualification; per-module "IQ/OQ/PQ evidence" lines = Verixa's own validation. No conflict with the self-validation **engine** scope. |
| Code baseline | Pinned: `Verixaai/Verixa @ dev-vimal-audit-2, 3bd2fe47`. |

## 12. Validation readiness (this URS)
| Gate | Result |
|---|---|
| Requirements atomic + testable | **Partial** — SV-REQ-### atomic; **SV-COR-009…029 are summary-level, not yet implementation-grade** (must be expanded before freeze) |
| Flow diagrams present (lifecycle, ER, state machines, AI sequence) | Pass |
| Non-domain plain-language primer present | Pass |
| No invented behavior (tables/routes/fields evidenced) | **Qualified** — existing tables/routes/enums are evidenced; **new target fields (`validation_result`, `ai_review_status`, transition history, deviation linkage, release-readiness) are target-state additions NOT in migration 052** and are labelled as such |
| Roles → tenant-role/authority mapping evidenced | **`Unknown — evidence required`** — validation-specific roles/authority profiles not demonstrated in the repo at `3bd2fe47` |
| FE/BE API contract | **Fail (verified)** — FE calls routes the backend does not implement (SV-COR-011 / FDA-INS-010) |
| Run-result vs human-disposition terminology resolved | **Partial** — `conditional` still in the run enum (migration 052); target moves it to the disposition layer (SV-COR-015) |
| AI advisory + human-oversight explicit | **Pass (principle)** — but the persisted field model (`ai_review_status`/`validation_result`/resolution record/authority/signature/AI-unavailable rule) is target-state, not yet in migration 052 |
| Current-state stubs disclosed | Pass |
| Cross-module reconciliation vs 1–38 (no collision; URS-32 binding) | Pass (§11) |
| AI Intended-Use statement | **Filled (§9)** |
| AI monitoring thresholds | Candidate proposed — **QA approval pending** |
| ALCOA+ / Part 11 adequacy assessed | **Assessed (§10)** — conditions = SV-REQ-004/005/007/011/012/013/014/023 |
| Performance targets | `Unknown — evidence required` |
| Retention / backup-restore of engine records (Enduring) | `Unknown — evidence required` (BCDR handoff) |
| Reviews incorporated (2026-06-04) | **Two** — (1) hardening review → SV-COR-009…026 (drift §8); (2) FDA-inspector review → FDA-INS-001…018 + SV-COR-027/028/029 (drift §9), verdict **`Reject for approval`**. AI-divergence contradiction now fixed in **all** artifacts (diagram, state machine, sequence, monitoring, handoff, HTML); FE/BE + AI-gateway confirmed defects; numbering (DEC-40-*) + regulatory wording corrected; SV-REQ-023 → service-principal UUID. |
| Corrected-spec completeness | **SV-COR-001…008 implementation-grade; SV-COR-009…029 summary-level** (009…012 revised) — must be fully expanded before URS freeze. The corrected spec is **not yet** the sole engineering source of truth. |
| **Named open blocker — Self-validation independence (SV-COR-014)** | The engine produces validation evidence for the platform that *contains* the engine — a **circular-evidence risk**. **Receiving document:** a **CSV/CSA Validation Strategy annex (to be created; owner: Validation Lead / Head of QA)** **shall** define the independence threshold (what counts as independent qualification of the engine, its test harness, and its protocol library) and the requalification trigger for major engine changes. **Until that annex exists and is approved, the headline differentiator ("pre-built IQ/OQ/PQ + continuous revalidation") shall be withdrawn from all product/marketing materials.** No QA approval of this URS is possible while the threshold is undefined. |
| Sequencing — attribution is a prerequisite | `created_by`/`updated_by` as a stable **service-principal UUID** (SV-REQ-023 / SV-COR-020) is foundational (ALCOA+ Attributable) and **shall be built BEFORE real execution**, not in parallel. |
| Overall | **`Reject for approval` — the document is NOT close to freeze** (not merely "blockers open"): `Draft — not executed — not approved — not validation-ready`. Requires QMS SME + CSV/CSA + Data Integrity + Security/Privacy + AI Governance + Engineering Architecture + Head of QA review. Engineering source of truth = approved URS-40 **plus fully-expanded SV-COR-001…029**. Many controls remain `Unknown — evidence required` (performance, retention/BCDR, role mapping, runtime schema, AI-gateway records, FE route inventory). Residual blockers: independence boundary (above), real execution + evidence, executable protocol model, lifecycle/API/RBAC reconciliation, cascade-deletion protection, release-gate, environment baseline, predicate-rule/Part 11 map, pass-rate units, replace defective tests. |

## 13. Developer handoff — Claude Code build block

> Paste into **Claude Code** at the Verixa repo root. Converts the existing stub into the SV-REQ-001…022 target state with **no missed wiring**. Constrained by `CLAUDE.md` quality standards (QS-1…QS-24) and the Verification Gate.

```text
!!!! INCOMPLETE TARGET — DO NOT BUILD VERBATIM AS THE SOLE SOURCE OF TRUTH. !!!!
!!!! This block covers SV-REQ-001..022 only. It does NOT yet implement the hardening requirements:
!!!! SV-COR-013 (executable protocol model), 017 (idempotency/concurrency/recovery), 019 (manifest hash + no
!!!! cascade-delete of evidence), 021 (release-gate separation), 022 (environment/dataset baseline), 027 (pass-rate
!!!! units), 028 (predicate-rule/Part 11 map), 029 (replace defective tests), nor SV-REQ-023..033. Build only AFTER
!!!! SV-COR-009..029 are expanded to implementation-grade and the result-vs-disposition + FE/BE contract are reconciled.
ROLE: Senior GxP full-stack engineer on the Verixa AI eQMS (GAMP 5 Cat 5).
TASK: Build the Self-Validation / Validation-Automation Engine to URS-40 target state.
AUTHORITATIVE SPEC: .../modules/URS-40_Self-Validation-Validation-Automation-Engine.Target-State.md
CODE BASELINE: Verixaai/Verixa @ branch dev-vimal-audit-2, commit 3bd2fe47. Build on this branch; verify line refs against this commit.
NON-NEGOTIABLE: obey CLAUDE.md QS-1..QS-24 + Verification Gate. No `any`. No auto-pass. No LLM decision-of-record.

CONTEXT (already exists — DO NOT recreate):
- Tables (052_competitive_differentiators.sql, all RLS): system_changes, validation_plans, validation_runs,
  validation_screenshots, validation_packages.
- Service: packages/backend/src/modules/competitive/self-validation.service.ts
- Routes:  packages/backend/src/modules/competitive/validation.routes.ts  (permission resource 'validation')
- Wiring:  packages/backend/src/modules/competitive/plugin.ts (registerValidationRoutes + F8 job)
- Job:     packages/backend/src/jobs/validation-change-detection.job.ts (every 30 min)
- FE:      packages/frontend/src/pages/admin/ValidationDashboard.tsx
- Shared:  packages/shared/src/schemas/competitive-differentiators.schema.ts

BUILD (each step = one focused change + tests, in order):
0. PREREQUISITE — RUN THIS BEFORE STEP 1 (SV-REQ-023 / SV-COR-020, ALCOA+ Attributable): add a numbered migration
   that defines created_by/updated_by (UUID) on validation_plans/runs/packages/screenshots, plus the new target
   fields validation_result, ai_review_status, transition_history, deviation_link, release_readiness (see §6.2
   target-migration DDL), and reconcile schema/types/runtime. Execution MUST NOT run before attribution columns
   exist — otherwise the first run writes attribution-null records (uncorrectable ALCOA+ defect).
1. REAL EXECUTION (SV-REQ-004): replace executeValidation() stub (~lines 458-477). Execute plan.test_cases;
   record per-test {id,stage,expected,actual,status,evidence_ref} into iq/oq/pq_results.details; compute
   totals + pass_rate from ACTUAL outcomes; set run.status from acceptance_criteria (SV-REQ-018). Never constant.
2. PROTOCOL LIBRARY (SV-REQ-003): replace placeholder iq-1/oq-1/pq-1 with a versioned IQ/OQ/PQ library keyed by
   system_changes.affected_modules/affected_features, each case mapped to the affected URS-01..38 function.
3. EVIDENCE CAPTURE (SV-REQ-005): wire validation_screenshots to execution (image_hash, image_path,
   test_case_id, step_number, url) via existing POST /runs/:id/screenshots.
4. DUAL-MODEL AI CROSS-CHECK (SV-REQ-006/007/008/009): new advisory service calling BOTH Anthropic Claude AND
   OpenAI GPT THROUGH THE URS-32 AI GATEWAY (/api/v1/ai/*) — NOT a private provider call, NOT modules/ai directly.
   Store both reviews in agent_review_scores/findings + agent_review_report. Log EVERY call to the URS-32
   ai_governance_events substrate AND llm_audit_log (provider, model name, model VERSION, prompt-template VERSION,
   input hash, output). Set outcome_label (URS-32 DEC-32-07) on each AI-influenced record. Bind ARCH-AI-001
   AC-5 (no silent AI-error swallow -> DLQ), AC-6 (AI never binds a GxP field), AC-7 (outcome provenance).
   ADVISORY ONLY: never set run/package status or validation_result. Store ai_review_status in a SEPARATE field.
   Divergence>threshold OR AI unavailable -> set ai_review_status = hold + notify (URS-30); validation_result UNCHANGED
   (SV-REQ-009/030). 'conditional' is a DETERMINISTIC run result (partial acceptance criteria) ONLY — never from AI.
   Models qualified per GMLP + URS-13 CR; prompts stored as URS-12 controlled documents.
5. PACKAGE FROM REAL EVIDENCE (SV-REQ-011): validation_packages.documents + overall_result
   (VALIDATED/CONDITIONAL/FAILED) + package_hash strictly from real run/screenshot evidence. No static text.
6. HITL E-SIG (SV-REQ-012) + SoD (SV-REQ-016): plan/package approve require valid esignature_id /
   approver_esignature_id bound to record+version; enforce approver != author; block otherwise.
7. AUDIT TRAIL (SV-REQ-013): auditTrailService.log on EVERY mutation in steps 1-6 with before/after. Append-only.
8. CHANGE-TRIGGERED REVALIDATION (SV-REQ-010/020): on detect, generate plan + NEW run; retain prior runs;
   model_version_change/agent_prompt_update register a system_changes row + trigger revalidation.
9. IMMUTABILITY/RETENTION (SV-REQ-014): block updates to approved runs/packages; set archived_at per retention.
10. FRONTEND (SV-REQ-017): extend ValidationDashboard.tsx — changes/plans/runs/packages + statuses + divergence
    flag + advisory-AI banner + e-sign approval action + evidence gallery + audit panel.
11. LABELLING (SV-REQ-021): package + UI "Verixa supplier self-validation evidence — reduces, does not replace,
    customer validation responsibility."

WIRING CHECKLIST (confirm each — no missed wiring):
[ ] new migration only ADDs (IF NOT EXISTS + ENABLE RLS + tenant_isolation policy + `-- ROLLBACK:`), never edit 052.
[ ] all DB access via tdal.withTenant (QS-5); no raw pool.query.
[ ] every route: requirePermission('validation:<action>') + Zod safeParse (QS-7/8); shared schemas in packages/shared (QS-12).
[ ] auditTrailService.log on every mutation -> URS-06 tamper-evident substrate (QS-1); ai_governance_events + llm_audit_log on every AI call (QS-21).
[ ] created_by/updated_by (UUID) populated on every engine record; engine writes use a stable service-principal UUID (NOT an email; cannot approve), never NULL; columns added in migration + reconciled with runtime schema (SV-REQ-023 / SV-COR-020 / QS-2).
[ ] AI calls transit URS-32 AI Gateway /api/v1/ai/* only; outcome_label set on AI-influenced records (URS-32 DEC-32-04/07).
[ ] no AI write path to run/package status passed/approved (SV-REQ-008 test); e-sig bound to record+version + manifestation + post-sign invalidation; author!=approver (SV-REQ-012/016 tests).
[ ] unit tests/service: happy / validation-fail / permission-denied / not-found / tenant-isolation / audit-written /
    AI-advisory-only / no-auto-pass (QS-15); integration test/route incl. status + Zod + audit + permission (QS-16).
[ ] FE ErrorBoundary + loading/error/empty (QS-17).

VERIFICATION (CLAUDE.md Verification Gate before done):
- tsc --noEmit --strict (BE+FE); eslint --max-warnings 0; vitest run (all pass);
  Gate 4 (no mutation w/o audit); Gate 5 (RLS); Gate 6 (no any); Gate 7 (no AI direct write to GxP fields);
  Gate 8 (no GenAI in critical GMP modules — this engine is advisory + non-GMP-critical; confirm).
DONE = all gates green + SV-REQ-004/005/006/008/011/012/013 demonstrated on a test tenant with real (non-stub) evidence.
```

---

| Boundary Check | Result |
|---|---|
| Primary skill used | verixa-full-gxp-ai-eqms-urs-expert |
| Owned deliverable | Target-state URS (VRX-URS-40) in core-module house style: framing + primer + mermaid diagrams + roles + journeys + front/back-end + requirements register + developer handoff |
| Other skills needed | CSV/CSA Expert (validation strategy / claim wording); GxP Validation Test Architect (IQ/OQ/PQ protocols for SV-REQ-003/004); Data Integrity / Part 11 Expert (ALCOA+ adequacy SV-REQ-004/013); AI Validation & Governance Expert (Intended Use, Annex 22 / EU AI Act, SV-REQ-006/019); Head of QA (final risk acceptance + release) |
| Out-of-scope items avoided | Validation strategy → CSV/CSA; detailed protocols → Test Architect; Part 11/Annex 11 adequacy → Data Integrity; AI governance adequacy → AI Validation & Governance; final QA approval/claim sign-off → Head of QA |
| Final status | `Draft within skill boundary` — **`Draft — not validation-ready`**; Head of QA decision required before any external claim |

*Status: `Draft — not validation-ready`. New module documenting an existing partially-built capability and its target state. Read-only analysis; no Verixa repo files modified by this URS.*


---

# Hardened Harness Addendum — v1.2-harness-grade

| Field | Value |
|---|---|
| Addendum ID | URS-40-HARDENING-001 |
| Addendum version | v1.2-harness-grade — DRAFT for QA/Validation review |
| Source baseline | URS-40 v1.0 Draft + Engineering Build Specification v0.1 |
| Purpose | Bring URS-40 requirements to the same harness-engineering rigor as the Claude Verixa GxP Validation Harness Release v1.0.1-GO |
| Status | DRAFT — blockers open — not executed — not approved — not validation-ready |
| Rule | This addendum adds requirements only. It does not remove or weaken SV-REQ-001…034, SV-COR-001…029, or ADD-VER-01…03. |

## H0. Harness-grade operating doctrine

The self-validation engine shall be built as a **regulated validation harness**, not as a workflow feature. The engine shall have four separated layers:

1. **Specification layer** — URS, FS, DS, risk assessment, protocol library, predicate-rule map, AI intended-use records.
2. **Execution layer** — deterministic runners, Playwright/API/DB execution adapters, audit/e-signature/record-layer assertions, AI advisory review through URS-32 only.
3. **Evidence layer** — immutable artifacts, evidence index with SHA-256, traceability, environment lock, tool-run log, source-document hash register, package manifest.
4. **Control layer** — run-readiness gate, transition guards, RBAC/SoD, compliance-claim guard, external signature verification, independent qualification gate, human QA disposition.

The engine shall never validate itself using only its own output. Initial qualification, major-change requalification, protocol-library qualification, and harness qualification require independent evidence defined by the CSV/CSA Validation Strategy annex.

## H1. Additional harness-grade requirements — SV-COR-030…037

### SV-COR-030 — Run-readiness gate
- **Problem:** The current URS requires environment baselines and OQ, but does not define a single deterministic pre-run gate.
- **Evidence:** Existing documents contain open blockers for environment baseline, independence, predicate-rule map, BCDR, release-gate interface, and approval scope.
- **Corrective requirement:** Before any run, the engine shall execute a run-readiness gate that verifies: `run_intent`, environment lock, source-document hashes, synthetic-data policy, jurisdiction scope, connected-service scope, approval matrix, external-signing status, tool-qualification status, protocol-library version, migration status, feature-flag baseline, AI model/prompt baseline, and independent-qualification status.
- **Acceptance:** A run with any missing readiness input is blocked with `BLOCKED — evidence required`. No execution adapter starts until run-readiness passes.
- **Evidence required:** Readiness report, input file hashes, failed/passed gate details, QA/Validation disposition.

### SV-COR-031 — Compliance-claim guard
- **Problem:** URS wording is disciplined, but no machine-enforced claim control is specified.
- **Corrective requirement:** The engine shall scan all generated packages, reports, dashboards, exports, and API responses for prohibited claims. Prohibited terms include: `validated`, `compliant`, `approved`, `released`, `inspection-ready`, `audit-ready`, `secure`, `Part 11 compliant`, `Annex 11 compliant`, `GAMP 5 validated`, `Schedule M compliant`, `DPDP compliant`, unless a linked executed evidence package and human approval record explicitly authorize the claim.
- **Allowed pre-approval wording:** `DRAFT`, `BLOCKED — evidence required`, `READY FOR HUMAN QA REVIEW`, `internal validation-engineering framework`, `evidence scaffold`.
- **Acceptance:** Attempting to emit a final compliance claim without approval fails the package generation gate.
- **Evidence required:** Compliance-claim register, claim scan report, human approval record where any claim is allowed.

### SV-COR-032 — External release signing and verification
- **Problem:** Internal hashes alone are self-attesting.
- **Corrective requirement:** Every controlled validation harness release and every approved validation package shall support external signature verification using an out-of-band public key or equivalent trusted release-signing mechanism. Internal hashes remain evidence, not the trust anchor.
- **Acceptance:** A package cannot move beyond `READY FOR HUMAN QA REVIEW` until signature status is recorded as `verified` or a QA-approved waiver is attached.
- **Evidence required:** Signature file, public-key location, signature verification record, signer identity, release approval.

### SV-COR-033 — Tool-run logging for the validation engine itself
- **Problem:** The engine uses software tools and advisory AI to produce GxP-supporting evidence.
- **Corrective requirement:** Each generated artifact shall record tool and agent metadata: engine version, validation pack version, Claude/GPT model version, URS-32 gateway version, prompt/template hash, run ID, agent/service name, skill/protocol invoked, input hashes, output hashes, executor, reviewer, timestamp.
- **Acceptance:** Missing tool-run metadata blocks package readiness.
- **Evidence required:** Tool-run log, model/prompt version register, input/output hash register.

### SV-COR-034 — Source-library and regulatory citation currency gate
- **Problem:** Regulatory applicability cannot depend on stale or missing source texts.
- **Corrective requirement:** Regulatory mappings shall cite controlled source documents with document title, version/date, source path, checksum, applicability status, and jurisdiction. Where the source is missing, the row remains `BLOCKED — source evidence required`.
- **Acceptance:** No regulatory matrix row may be marked complete if the source file is missing or checksum is absent.
- **Evidence required:** Source-library filing register, source-document hash register, citation-currency report.

### SV-COR-035 — Connected-service privacy and supplier crosswalk
- **Problem:** Connected SaaS surfaces introduce per-connector DPDP/GDPR/privacy and supplier risk.
- **Corrective requirement:** For each connector or external service, the engine shall maintain connector-level mapping: connector ID, service class, data categories, personal-data flag, health-data flag, DPDP basis, GDPR basis if applicable, processor/subprocessor role, cross-border transfer, retention rule, breach notification owner, supplier qualification status, sandbox/production status, credential policy, tenant-isolation test status.
- **Acceptance:** A connector scenario cannot execute against any external service unless the connector crosswalk is complete or a signed scope-exclusion exists.
- **Evidence required:** Connector privacy crosswalk, supplier-control register, legal/privacy approval, sandbox evidence.

### SV-COR-036 — Validation package generator outputs
- **Problem:** Evidence-package generation must be standardized and complete.
- **Corrective requirement:** The engine shall generate controlled draft validation package artifacts: VMP/VP reference, IQ/OQ/PQ protocols, risk assessment, RTM, scenario execution matrix, Part 11 matrix, Annex 11 matrix, Schedule M/India matrix, AI governance matrix, connected-SaaS matrix, audit/e-signature/record-layer registers, deviations, CAPA/remediation, evidence index, validation summary, approval matrix, and release-signing record.
- **Acceptance:** A validation package missing any required artifact remains `BLOCKED — evidence required`.
- **Evidence required:** Package readiness check, package manifest, artifact hashes, workbook/document export.

### SV-COR-037 — Deterministic enforcement layer
- **Problem:** Requirements alone do not enforce behavior.
- **Corrective requirement:** The build shall include deterministic guard scripts or equivalent backend gates for run-readiness, evidence completeness, compliance claims, AI advisory boundary, e-signature validity, audit atomicity, RBAC/SoD, tenant isolation, package hashing, source-library currency, connector privacy crosswalk, and external signature status.
- **Acceptance:** Each gate has a negative test proving that the prohibited condition is blocked.
- **Evidence required:** Gate source, gate execution logs, negative-test evidence, CI/controlled-run output.

## H2. Additional AI governance and validation requirements — SV-COR-038…051

### SV-COR-038 — AI feature inventory register
- **Requirement:** Every AI use in Module 40 shall have an inventory row covering feature ID, intended use, model/provider, prompt/template, input data, output use, GxP impact, system-of-record status, human oversight, and current validation status.
- **Acceptance:** No AI call executes unless its feature ID is registered and approved or explicitly BLOCKED.

### SV-COR-039 — AI intended-use register
- **Requirement:** Each AI feature shall have a signed intended-use statement defining allowed inputs, allowed outputs, prohibited uses, decision boundary, human reviewer, evidence requirements, and model-change triggers.
- **Acceptance:** Missing intended-use record blocks AI review.

### SV-COR-040 — AI risk classification register
- **Requirement:** Each AI feature shall be risk-classified under internal AI governance, EU AI Act applicability assessment, Annex 22 draft applicability, GMLP relevance, and GxP criticality. Generative LLMs used in Module 40 shall remain advisory-only and shall be prohibited from final critical GMP decisions.
- **Acceptance:** Any AI feature with `system_of_record_status != advisory-only` is blocked until QA/AI Governance/Legal approval.

### SV-COR-041 — Model / provider / prompt / dataset version register
- **Requirement:** Each AI review shall record provider, model name, model version, endpoint/gateway version, prompt ID, prompt version, prompt hash, input hash, output hash, test dataset hash where used, and change-control reference.
- **Acceptance:** Missing model/prompt metadata blocks AI review completion.

### SV-COR-042 — AI advisory-output audit register
- **Requirement:** Each AI finding shall be traceable to the input section, provider, model version, confidence, cited evidence, reviewer disposition, and final human resolution. Unsupported findings are flagged, not silently accepted.
- **Acceptance:** AI findings without evidence remain advisory and cannot be used to change a result or disposition.

### SV-COR-043 — AI adversarial validation test set
- **Requirement:** The OQ suite shall include AI adversarial tests: hallucinated citation, missing citation, prompt injection, wrong-tenant retrieval, low-confidence response, provider unavailability, conflicting provider outputs, PHI/PII/secret input, and unsupported compliance claim.
- **Acceptance:** Each adversarial case produces the expected blocked/hold/redaction behavior.

### SV-COR-044 — Prompt-injection and retrieval-isolation validation
- **Requirement:** The AI gateway and retrieval layer shall reject or neutralize prompt-injection content and shall deny cross-tenant evidence retrieval.
- **Acceptance:** A prompt-injection payload cannot cause tool execution, data exfiltration, cross-tenant retrieval, result mutation, or approval mutation.

### SV-COR-045 — Hallucination / unsupported-citation detection
- **Requirement:** The system shall require AI findings to cite available evidence. Fabricated clauses, invented file paths, and unsupported statements shall be flagged as unsupported.
- **Acceptance:** A seeded hallucinated citation is detected and does not enter final evidence without human rejection/annotation.

### SV-COR-046 — Low-confidence / unavailable-provider handling
- **Requirement:** Low confidence, provider timeout, or provider unavailability creates `ai_review_status = ai_hold` or `ai_incomplete`; it never changes run result or disposition.
- **Acceptance:** Provider-unavailable tests produce a hold/incomplete status and preserve deterministic result unchanged.

### SV-COR-047 — AI monitoring and drift evidence
- **Requirement:** The system shall monitor AI divergence rate, human override rate, unsupported-finding rate, provider unavailability, prompt/model changes, and adversarial-test failures. Thresholds require QA/AI Governance approval.
- **Acceptance:** Monitoring thresholds exist or remain `BLOCKED — evidence required`; threshold breach creates a review hold/deviation.

### SV-COR-048 — AI supplier qualification evidence
- **Requirement:** AI provider qualification shall be linked to supplier assessment, security/privacy assessment, data-use/retention terms, region routing, subprocessor status, and model-change notification process.
- **Acceptance:** AI provider use remains blocked if supplier qualification evidence is missing or expired.

### SV-COR-049 — AI allowed/prohibited-use matrix
- **Requirement:** The system shall maintain an allowed/prohibited-use matrix. Allowed: advisory review, completeness check, inconsistency detection, drafting of reviewer notes. Prohibited: pass/fail, disposition, approval, release readiness, e-signature, audit-record mutation, record-layer evidence generation, regulatory compliance conclusion.
- **Acceptance:** Any attempted prohibited use is blocked and audited.

### SV-COR-050 — Human re-derivation and QA disposition
- **Requirement:** For GxP-impacting AI findings, the human reviewer shall independently verify or re-derive the finding from source evidence before accepting it. Approval must identify reviewer, role, basis, and disposition.
- **Acceptance:** An AI finding cannot be marked accepted without a human disposition and evidence basis.

### SV-COR-051 — AI compliance-claim guard
- **Requirement:** The engine shall block AI-generated claims of compliance, validation, approval, audit-readiness, or legal/regulatory conclusion unless authorized by executed evidence and human approval.
- **Acceptance:** AI-generated overclaim text is detected and package generation fails or marks the item `BLOCKED — evidence required`.

## H3. Harness-grade OQ acceptance matrix

At minimum, OQ shall include negative and positive cases for:

| Gate / control | Minimum OQ case |
|---|---|
| Run-readiness | Missing run intent blocks execution |
| Environment lock | Commit SHA or migration version mismatch blocks execution |
| Evidence completeness | Missing screenshot/trace/API/DB/audit evidence blocks package readiness |
| Evidence hash | File hash mismatch blocks readiness |
| AI advisory boundary | AI cannot write `validation_result`, `run.status`, `disposition`, or `release_readiness` |
| AI divergence | Claude/GPT material disagreement creates hold, deterministic result unchanged |
| Provider unavailable | AI review incomplete/hold, deterministic result unchanged |
| Prompt injection | No tool execution, no cross-tenant retrieval, no status mutation |
| E-signature | Missing/reused/wrong-user/post-mutation signature blocked |
| RBAC/SoD | Author cannot approve; execute role cannot approve; viewer cannot mutate |
| Tenant isolation | Tenant A cannot read or mutate Tenant B records |
| Audit atomicity | Failed audit write rolls back business mutation |
| Record immutability | Approved package/evidence cannot be updated/deleted except supersede workflow |
| Package hash | Any included evidence change changes package hash |
| Compliance claim | Prohibited claim blocked without human approval |
| External signature | Missing signature keeps package below approved state |

## H4. Updated freeze decision

The URS-40 target state plus this addendum is **strong enough for engineering build planning**, but not for URS freeze or QA approval until the existing dependencies D-1…D-8 and the new harness addendum acceptance gates are dispositioned by the named owners. The addendum shall be treated as part of the engineering source of truth for Module 40.



---

# v1.2 QA Corrective Expansion — Freeze-Candidate Addendum

## H5. v1.2 QA corrective integration — CG-1 through CG-8

### H5.1 CG-1 — India regulatory scope resolution
India is **conditionally in scope** for URS-40 where Verixa is operated by an India-domiciled entity, used by Indian pharma/biotech customers, processes Indian personal data, supports Indian GMP records, or is presented to Indian customers as part of validation evidence. The engine shall therefore include a jurisdiction-gated India regulatory mapping for Schedule M, Drugs Rules 1945, DPDP Act 2023, IT Act / e-record and e-signature validity, and related CDSCO/GCP/GDP areas where applicable.

**Do not claim India compliance.** If jurisdiction applicability or source text is missing, the India row remains `BLOCKED — jurisdiction/source evidence required`. Security/Privacy/Legal own the DPDP/GDPR legal basis determination; the engine consumes and records their approved basis through the connector privacy crosswalk.

### H5.2 CG-4 — ARCH-AI-001 controlled reference handling
ARCH-AI-001 is now supplied and pinned as a controlled-reference candidate: **ARCH-AI-001 "AI Optionality and Manual Continuity" v1.0** with target QMS location `docs/architecture/ARCH-AI-001_AI-Optionality-and-Manual-Continuity.md`. URS-40 binds specifically to **AC-5 / AC-6 / AC-7**. This closes the prior `Unknown — controlled-document reference required` defect at the document-reference level only. It does **not** close approval: ARCH-AI-001 remains `DRAFT — not approved`, so URS-40 freeze remains blocked until the architecture record is approved and filed under controlled change.


### H5.3 CG-5 — Privacy / supplier ownership boundary
The engine shall **not** determine DPDP/GDPR lawful basis, cross-border transfer adequacy, supplier qualification status, or DPA/SCC adequacy. It shall consume approved values supplied by Security/Privacy, Legal, Supplier Quality, or System Owner and shall block execution where those approved values are missing.

### H5.4 CG-6 — D-9 external-signing key management dependency
Add dependency D-9: external signing key lifecycle and ownership. Owner role: Security / Platform Release Owner. Required evidence: key owner, public-key location, signing tool, signing procedure, signature verification record, key rotation / revocation procedure, and release-approval record. Until complete, release-signing status remains `BLOCKED — evidence required`.

### H5.5 CG-8 — Context-aware compliance-claim guard
The compliance-claim guard shall scan narrative status and evidence reports for prohibited claims, but shall allow legitimate controlled-field values where context proves they are not assertions, including enum names, code identifiers, regulatory clause titles, negative-test payloads, and quoted prohibited-word examples. Every allowlist entry shall carry reason, owner, expiry/review date, and evidence path. The guard shall never allow final claims such as `validated`, `compliant`, `audit-ready`, or `inspection-ready` without executed evidence and human approval.


## H7. v1.2 SV-REQ / RTM integration for SV-COR-030…051

| Req ID | Type | Requirement (`shall`) | Risk | Acceptance | Trace | Status |
|---|---|---|---|---|---|---|
| SV-REQ-035 | Harness / AI governance | The engine shall implement Run-readiness gate as a deterministic, evidence-producing harness control with fail-closed gates and human approval boundaries. | High | OQ-HARNESS-030 executes positive and negative cases; missing evidence remains BLOCKED. | SV-COR-030; RTM-HARNESS-030 | DRAFT — evidence required |
| SV-REQ-036 | Harness / AI governance | The engine shall implement Compliance-claim guard as a deterministic, evidence-producing harness control with fail-closed gates and human approval boundaries. | High | OQ-HARNESS-031 executes positive and negative cases; missing evidence remains BLOCKED. | SV-COR-031; RTM-HARNESS-031 | DRAFT — evidence required |
| SV-REQ-037 | Harness / AI governance | The engine shall implement External release signing and verification as a deterministic, evidence-producing harness control with fail-closed gates and human approval boundaries. | High | OQ-HARNESS-032 executes positive and negative cases; missing evidence remains BLOCKED. | SV-COR-032; RTM-HARNESS-032 | DRAFT — evidence required |
| SV-REQ-038 | Harness / AI governance | The engine shall implement Tool-run logging for the validation engine itself as a deterministic, evidence-producing harness control with fail-closed gates and human approval boundaries. | High | OQ-HARNESS-033 executes positive and negative cases; missing evidence remains BLOCKED. | SV-COR-033; RTM-HARNESS-033 | DRAFT — evidence required |
| SV-REQ-039 | Harness / AI governance | The engine shall implement Source-library and regulatory citation currency gate as a deterministic, evidence-producing harness control with fail-closed gates and human approval boundaries. | High | OQ-HARNESS-034 executes positive and negative cases; missing evidence remains BLOCKED. | SV-COR-034; RTM-HARNESS-034 | DRAFT — evidence required |
| SV-REQ-040 | Harness / AI governance | The engine shall implement Connected-service privacy and supplier crosswalk as a deterministic, evidence-producing harness control with fail-closed gates and human approval boundaries. | High | OQ-HARNESS-035 executes positive and negative cases; missing evidence remains BLOCKED. | SV-COR-035; RTM-HARNESS-035 | DRAFT — evidence required |
| SV-REQ-041 | Harness / AI governance | The engine shall implement Validation package generator outputs as a deterministic, evidence-producing harness control with fail-closed gates and human approval boundaries. | High | OQ-HARNESS-036 executes positive and negative cases; missing evidence remains BLOCKED. | SV-COR-036; RTM-HARNESS-036 | DRAFT — evidence required |
| SV-REQ-042 | Harness / AI governance | The engine shall implement Deterministic enforcement layer as a deterministic, evidence-producing harness control with fail-closed gates and human approval boundaries. | High | OQ-HARNESS-037 executes positive and negative cases; missing evidence remains BLOCKED. | SV-COR-037; RTM-HARNESS-037 | DRAFT — evidence required |
| SV-REQ-043 | Harness / AI governance | The engine shall implement AI feature inventory register as a deterministic, evidence-producing harness control with fail-closed gates and human approval boundaries. | High | OQ-HARNESS-038 executes positive and negative cases; missing evidence remains BLOCKED. | SV-COR-038; RTM-HARNESS-038 | DRAFT — evidence required |
| SV-REQ-044 | Harness / AI governance | The engine shall implement AI intended-use register as a deterministic, evidence-producing harness control with fail-closed gates and human approval boundaries. | High | OQ-HARNESS-039 executes positive and negative cases; missing evidence remains BLOCKED. | SV-COR-039; RTM-HARNESS-039 | DRAFT — evidence required |
| SV-REQ-045 | Harness / AI governance | The engine shall implement AI risk classification register as a deterministic, evidence-producing harness control with fail-closed gates and human approval boundaries. | High | OQ-HARNESS-040 executes positive and negative cases; missing evidence remains BLOCKED. | SV-COR-040; RTM-HARNESS-040 | DRAFT — evidence required |
| SV-REQ-046 | Harness / AI governance | The engine shall implement Model / provider / prompt / dataset version register as a deterministic, evidence-producing harness control with fail-closed gates and human approval boundaries. | High | OQ-HARNESS-041 executes positive and negative cases; missing evidence remains BLOCKED. | SV-COR-041; RTM-HARNESS-041 | DRAFT — evidence required |
| SV-REQ-047 | Harness / AI governance | The engine shall implement AI advisory-output audit register as a deterministic, evidence-producing harness control with fail-closed gates and human approval boundaries. | High | OQ-HARNESS-042 executes positive and negative cases; missing evidence remains BLOCKED. | SV-COR-042; RTM-HARNESS-042 | DRAFT — evidence required |
| SV-REQ-048 | Harness / AI governance | The engine shall implement AI adversarial validation test set as a deterministic, evidence-producing harness control with fail-closed gates and human approval boundaries. | High | OQ-HARNESS-043 executes positive and negative cases; missing evidence remains BLOCKED. | SV-COR-043; RTM-HARNESS-043 | DRAFT — evidence required |
| SV-REQ-049 | Harness / AI governance | The engine shall implement Prompt-injection and retrieval-isolation validation as a deterministic, evidence-producing harness control with fail-closed gates and human approval boundaries. | High | OQ-HARNESS-044 executes positive and negative cases; missing evidence remains BLOCKED. | SV-COR-044; RTM-HARNESS-044 | DRAFT — evidence required |
| SV-REQ-050 | Harness / AI governance | The engine shall implement Hallucination / unsupported-citation detection validation as a deterministic, evidence-producing harness control with fail-closed gates and human approval boundaries. | High | OQ-HARNESS-045 executes positive and negative cases; missing evidence remains BLOCKED. | SV-COR-045; RTM-HARNESS-045 | DRAFT — evidence required |
| SV-REQ-051 | Harness / AI governance | The engine shall implement Low-confidence / unavailable-provider handling validation as a deterministic, evidence-producing harness control with fail-closed gates and human approval boundaries. | High | OQ-HARNESS-046 executes positive and negative cases; missing evidence remains BLOCKED. | SV-COR-046; RTM-HARNESS-046 | DRAFT — evidence required |
| SV-REQ-052 | Harness / AI governance | The engine shall implement AI monitoring and drift evidence as a deterministic, evidence-producing harness control with fail-closed gates and human approval boundaries. | High | OQ-HARNESS-047 executes positive and negative cases; missing evidence remains BLOCKED. | SV-COR-047; RTM-HARNESS-047 | DRAFT — evidence required |
| SV-REQ-053 | Harness / AI governance | The engine shall implement AI supplier qualification evidence as a deterministic, evidence-producing harness control with fail-closed gates and human approval boundaries. | High | OQ-HARNESS-048 executes positive and negative cases; missing evidence remains BLOCKED. | SV-COR-048; RTM-HARNESS-048 | DRAFT — evidence required |
| SV-REQ-054 | Harness / AI governance | The engine shall implement AI allowed/prohibited-use matrix as a deterministic, evidence-producing harness control with fail-closed gates and human approval boundaries. | High | OQ-HARNESS-049 executes positive and negative cases; missing evidence remains BLOCKED. | SV-COR-049; RTM-HARNESS-049 | DRAFT — evidence required |
| SV-REQ-055 | Harness / AI governance | The engine shall implement Human re-derivation and QA disposition requirement as a deterministic, evidence-producing harness control with fail-closed gates and human approval boundaries. | High | OQ-HARNESS-050 executes positive and negative cases; missing evidence remains BLOCKED. | SV-COR-050; RTM-HARNESS-050 | DRAFT — evidence required |
| SV-REQ-056 | Harness / AI governance | The engine shall implement AI compliance-claim guard as a deterministic, evidence-producing harness control with fail-closed gates and human approval boundaries. | High | OQ-HARNESS-051 executes positive and negative cases; missing evidence remains BLOCKED. | SV-COR-051; RTM-HARNESS-051 | DRAFT — evidence required |


## H8. v1.2 implementation-grade PECRA expansion — SV-COR-030…051

The following section closes CG-2 by expanding the v1.1 summary-grade harness requirements into implementation-grade PECRA. These requirements are still **not executed** and **not approved**. They are freeze candidates only after RTM linkage, DDL ratification, and OQ execution.

### SV-COR-030 — Run-readiness gate [v1.2 PECRA expansion]
- **Risk rating:** High. Critical where the control can affect validation-result integrity, compliance-claim wording, AI decision boundary, or evidence admissibility.
- **Current state / verified evidence:** Harness-Hardened v1.1 added this requirement as summary-grade. The v1.1 QA review found SV-COR-030…051 were not yet implementation-grade, not in the SV-REQ register / RTM, and not re-verified against the pinned code baseline. No runtime implementation is claimed.
- **Problem:** A summary-grade harness requirement cannot be used as a freeze-ready engineering requirement because it lacks implementation-level acceptance, traceability, and OQ closure criteria.
- **Corrective requirement:** The system **shall** implement `Run-readiness gate` as a deterministic, evidence-producing harness control. The control shall be tenant-scoped where it stores records, attributed with `created_by`/`updated_by`, included in the validation package evidence manifest, and blocked from claiming completion until executed evidence exists.
- **Acceptance:** OQ shall prove: (1) required input rows exist; (2) missing/Unknown inputs block execution or mark BLOCKED; (3) generated evidence has file path + SHA-256 where file-based; (4) human approval fields remain `Unknown — evidence required` until signed; (5) no prohibited compliance claim is emitted; and (6) the control is represented in the RTM and validation package readiness check.
- **Negative acceptance:** A deliberately missing required field, stale source, unapproved AI output, or fabricated evidence path shall fail the relevant deterministic gate and shall not produce READY or VALIDATED language.
- **Reg/QS basis:** GAMP 5 CSA; Annex 11 §4; ALCOA+ Complete/Available.
- **Trace:** SV-REQ-035 ↔ SV-COR-030 ↔ OQ-HARNESS-030 ↔ RTM-HARNESS-030.
- **Status:** DRAFT — not executed — not approved — not validation-ready.


### SV-COR-031 — Compliance-claim guard [v1.2 PECRA expansion]
- **Risk rating:** High. Critical where the control can affect validation-result integrity, compliance-claim wording, AI decision boundary, or evidence admissibility.
- **Current state / verified evidence:** Harness-Hardened v1.1 added this requirement as summary-grade. The v1.1 QA review found SV-COR-030…051 were not yet implementation-grade, not in the SV-REQ register / RTM, and not re-verified against the pinned code baseline. No runtime implementation is claimed.
- **Problem:** A summary-grade harness requirement cannot be used as a freeze-ready engineering requirement because it lacks implementation-level acceptance, traceability, and OQ closure criteria.
- **Corrective requirement:** The system **shall** implement `Compliance-claim guard` as a deterministic, evidence-producing harness control. The control shall be tenant-scoped where it stores records, attributed with `created_by`/`updated_by`, included in the validation package evidence manifest, and blocked from claiming completion until executed evidence exists.
- **Acceptance:** OQ shall prove: (1) required input rows exist; (2) missing/Unknown inputs block execution or mark BLOCKED; (3) generated evidence has file path + SHA-256 where file-based; (4) human approval fields remain `Unknown — evidence required` until signed; (5) no prohibited compliance claim is emitted; and (6) the control is represented in the RTM and validation package readiness check.
- **Negative acceptance:** A deliberately missing required field, stale source, unapproved AI output, or fabricated evidence path shall fail the relevant deterministic gate and shall not produce READY or VALIDATED language.
- **Reg/QS basis:** GDocP; 21 CFR 11.10(a); QA language discipline.
- **Trace:** SV-REQ-036 ↔ SV-COR-031 ↔ OQ-HARNESS-031 ↔ RTM-HARNESS-031.
- **Status:** DRAFT — not executed — not approved — not validation-ready.


### SV-COR-032 — External release signing and verification [v1.2 PECRA expansion]
- **Risk rating:** High. Critical where the control can affect validation-result integrity, compliance-claim wording, AI decision boundary, or evidence admissibility.
- **Current state / verified evidence:** Harness-Hardened v1.1 added this requirement as summary-grade. The v1.1 QA review found SV-COR-030…051 were not yet implementation-grade, not in the SV-REQ register / RTM, and not re-verified against the pinned code baseline. No runtime implementation is claimed.
- **Problem:** A summary-grade harness requirement cannot be used as a freeze-ready engineering requirement because it lacks implementation-level acceptance, traceability, and OQ closure criteria.
- **Corrective requirement:** The system **shall** implement `External release signing and verification` as a deterministic, evidence-producing harness control. The control shall be tenant-scoped where it stores records, attributed with `created_by`/`updated_by`, included in the validation package evidence manifest, and blocked from claiming completion until executed evidence exists.
- **Acceptance:** OQ shall prove: (1) required input rows exist; (2) missing/Unknown inputs block execution or mark BLOCKED; (3) generated evidence has file path + SHA-256 where file-based; (4) human approval fields remain `Unknown — evidence required` until signed; (5) no prohibited compliance claim is emitted; and (6) the control is represented in the RTM and validation package readiness check.
- **Negative acceptance:** A deliberately missing required field, stale source, unapproved AI output, or fabricated evidence path shall fail the relevant deterministic gate and shall not produce READY or VALIDATED language.
- **Reg/QS basis:** Annex 11 §4.5; GAMP 5 tool qualification; ALCOA+ Original.
- **Trace:** SV-REQ-037 ↔ SV-COR-032 ↔ OQ-HARNESS-032 ↔ RTM-HARNESS-032.
- **Status:** DRAFT — not executed — not approved — not validation-ready.


### SV-COR-033 — Tool-run logging for the validation engine itself [v1.2 PECRA expansion]
- **Risk rating:** High. Critical where the control can affect validation-result integrity, compliance-claim wording, AI decision boundary, or evidence admissibility.
- **Current state / verified evidence:** Harness-Hardened v1.1 added this requirement as summary-grade. The v1.1 QA review found SV-COR-030…051 were not yet implementation-grade, not in the SV-REQ register / RTM, and not re-verified against the pinned code baseline. No runtime implementation is claimed.
- **Problem:** A summary-grade harness requirement cannot be used as a freeze-ready engineering requirement because it lacks implementation-level acceptance, traceability, and OQ closure criteria.
- **Corrective requirement:** The system **shall** implement `Tool-run logging for the validation engine itself` as a deterministic, evidence-producing harness control. The control shall be tenant-scoped where it stores records, attributed with `created_by`/`updated_by`, included in the validation package evidence manifest, and blocked from claiming completion until executed evidence exists.
- **Acceptance:** OQ shall prove: (1) required input rows exist; (2) missing/Unknown inputs block execution or mark BLOCKED; (3) generated evidence has file path + SHA-256 where file-based; (4) human approval fields remain `Unknown — evidence required` until signed; (5) no prohibited compliance claim is emitted; and (6) the control is represented in the RTM and validation package readiness check.
- **Negative acceptance:** A deliberately missing required field, stale source, unapproved AI output, or fabricated evidence path shall fail the relevant deterministic gate and shall not produce READY or VALIDATED language.
- **Reg/QS basis:** Annex 11 §4.5; GAMP 5 tool qualification; ALCOA+ Attributable.
- **Trace:** SV-REQ-038 ↔ SV-COR-033 ↔ OQ-HARNESS-033 ↔ RTM-HARNESS-033.
- **Status:** DRAFT — not executed — not approved — not validation-ready.


### SV-COR-034 — Source-library and regulatory citation currency gate [v1.2 PECRA expansion]
- **Risk rating:** High. Critical where the control can affect validation-result integrity, compliance-claim wording, AI decision boundary, or evidence admissibility.
- **Current state / verified evidence:** Harness-Hardened v1.1 added this requirement as summary-grade. The v1.1 QA review found SV-COR-030…051 were not yet implementation-grade, not in the SV-REQ register / RTM, and not re-verified against the pinned code baseline. No runtime implementation is claimed.
- **Problem:** A summary-grade harness requirement cannot be used as a freeze-ready engineering requirement because it lacks implementation-level acceptance, traceability, and OQ closure criteria.
- **Corrective requirement:** The system **shall** implement `Source-library and regulatory citation currency gate` as a deterministic, evidence-producing harness control. The control shall be tenant-scoped where it stores records, attributed with `created_by`/`updated_by`, included in the validation package evidence manifest, and blocked from claiming completion until executed evidence exists.
- **Acceptance:** OQ shall prove: (1) required input rows exist; (2) missing/Unknown inputs block execution or mark BLOCKED; (3) generated evidence has file path + SHA-256 where file-based; (4) human approval fields remain `Unknown — evidence required` until signed; (5) no prohibited compliance claim is emitted; and (6) the control is represented in the RTM and validation package readiness check.
- **Negative acceptance:** A deliberately missing required field, stale source, unapproved AI output, or fabricated evidence path shall fail the relevant deterministic gate and shall not produce READY or VALIDATED language.
- **Reg/QS basis:** GDocP; regulatory citation control; EU Annex 11 §4.8.
- **Trace:** SV-REQ-039 ↔ SV-COR-034 ↔ OQ-HARNESS-034 ↔ RTM-HARNESS-034.
- **Status:** DRAFT — not executed — not approved — not validation-ready.


### SV-COR-035 — Connected-service privacy and supplier crosswalk [v1.2 PECRA expansion]
- **Risk rating:** High. Critical where the control can affect validation-result integrity, compliance-claim wording, AI decision boundary, or evidence admissibility.
- **Current state / verified evidence:** Harness-Hardened v1.1 added this requirement as summary-grade. The v1.1 QA review found SV-COR-030…051 were not yet implementation-grade, not in the SV-REQ register / RTM, and not re-verified against the pinned code baseline. No runtime implementation is claimed.
- **Problem:** A summary-grade harness requirement cannot be used as a freeze-ready engineering requirement because it lacks implementation-level acceptance, traceability, and OQ closure criteria.
- **Corrective requirement:** The system **shall** implement `Connected-service privacy and supplier crosswalk` as a deterministic, evidence-producing harness control. The control shall be tenant-scoped where it stores records, attributed with `created_by`/`updated_by`, included in the validation package evidence manifest, and blocked from claiming completion until executed evidence exists.
- **Acceptance:** OQ shall prove: (1) required input rows exist; (2) missing/Unknown inputs block execution or mark BLOCKED; (3) generated evidence has file path + SHA-256 where file-based; (4) human approval fields remain `Unknown — evidence required` until signed; (5) no prohibited compliance claim is emitted; and (6) the control is represented in the RTM and validation package readiness check.
- **Negative acceptance:** A deliberately missing required field, stale source, unapproved AI output, or fabricated evidence path shall fail the relevant deterministic gate and shall not produce READY or VALIDATED language.
- **Reg/QS basis:** DPDP/GDPR privacy governance; Annex 11 §7; supplier control.
- **Trace:** SV-REQ-040 ↔ SV-COR-035 ↔ OQ-HARNESS-035 ↔ RTM-HARNESS-035.
- **Status:** DRAFT — not executed — not approved — not validation-ready.


### SV-COR-036 — Validation package generator outputs [v1.2 PECRA expansion]
- **Risk rating:** High. Critical where the control can affect validation-result integrity, compliance-claim wording, AI decision boundary, or evidence admissibility.
- **Current state / verified evidence:** Harness-Hardened v1.1 added this requirement as summary-grade. The v1.1 QA review found SV-COR-030…051 were not yet implementation-grade, not in the SV-REQ register / RTM, and not re-verified against the pinned code baseline. No runtime implementation is claimed.
- **Problem:** A summary-grade harness requirement cannot be used as a freeze-ready engineering requirement because it lacks implementation-level acceptance, traceability, and OQ closure criteria.
- **Corrective requirement:** The system **shall** implement `Validation package generator outputs` as a deterministic, evidence-producing harness control. The control shall be tenant-scoped where it stores records, attributed with `created_by`/`updated_by`, included in the validation package evidence manifest, and blocked from claiming completion until executed evidence exists.
- **Acceptance:** OQ shall prove: (1) required input rows exist; (2) missing/Unknown inputs block execution or mark BLOCKED; (3) generated evidence has file path + SHA-256 where file-based; (4) human approval fields remain `Unknown — evidence required` until signed; (5) no prohibited compliance claim is emitted; and (6) the control is represented in the RTM and validation package readiness check.
- **Negative acceptance:** A deliberately missing required field, stale source, unapproved AI output, or fabricated evidence path shall fail the relevant deterministic gate and shall not produce READY or VALIDATED language.
- **Reg/QS basis:** 21 CFR 11.10(b); Annex 11 §8; GAMP 5 validation reporting.
- **Trace:** SV-REQ-041 ↔ SV-COR-036 ↔ OQ-HARNESS-036 ↔ RTM-HARNESS-036.
- **Status:** DRAFT — not executed — not approved — not validation-ready.


### SV-COR-037 — Deterministic enforcement layer [v1.2 PECRA expansion]
- **Risk rating:** High. Critical where the control can affect validation-result integrity, compliance-claim wording, AI decision boundary, or evidence admissibility.
- **Current state / verified evidence:** Harness-Hardened v1.1 added this requirement as summary-grade. The v1.1 QA review found SV-COR-030…051 were not yet implementation-grade, not in the SV-REQ register / RTM, and not re-verified against the pinned code baseline. No runtime implementation is claimed.
- **Problem:** A summary-grade harness requirement cannot be used as a freeze-ready engineering requirement because it lacks implementation-level acceptance, traceability, and OQ closure criteria.
- **Corrective requirement:** The system **shall** implement `Deterministic enforcement layer` as a deterministic, evidence-producing harness control. The control shall be tenant-scoped where it stores records, attributed with `created_by`/`updated_by`, included in the validation package evidence manifest, and blocked from claiming completion until executed evidence exists.
- **Acceptance:** OQ shall prove: (1) required input rows exist; (2) missing/Unknown inputs block execution or mark BLOCKED; (3) generated evidence has file path + SHA-256 where file-based; (4) human approval fields remain `Unknown — evidence required` until signed; (5) no prohibited compliance claim is emitted; and (6) the control is represented in the RTM and validation package readiness check.
- **Negative acceptance:** A deliberately missing required field, stale source, unapproved AI output, or fabricated evidence path shall fail the relevant deterministic gate and shall not produce READY or VALIDATED language.
- **Reg/QS basis:** GAMP 5 tool controls; Annex 11 §4.5; CSA risk-based verification.
- **Trace:** SV-REQ-042 ↔ SV-COR-037 ↔ OQ-HARNESS-037 ↔ RTM-HARNESS-037.
- **Status:** DRAFT — not executed — not approved — not validation-ready.


### SV-COR-038 — AI feature inventory register [v1.2 PECRA expansion]
- **Risk rating:** High. Critical where the control can affect validation-result integrity, compliance-claim wording, AI decision boundary, or evidence admissibility.
- **Current state / verified evidence:** Harness-Hardened v1.1 added this requirement as summary-grade. The v1.1 QA review found SV-COR-030…051 were not yet implementation-grade, not in the SV-REQ register / RTM, and not re-verified against the pinned code baseline. No runtime implementation is claimed.
- **Problem:** A summary-grade harness requirement cannot be used as a freeze-ready engineering requirement because it lacks implementation-level acceptance, traceability, and OQ closure criteria.
- **Corrective requirement:** The system **shall** implement `AI feature inventory register` as a deterministic, evidence-producing harness control. The control shall be tenant-scoped where it stores records, attributed with `created_by`/`updated_by`, included in the validation package evidence manifest, and blocked from claiming completion until executed evidence exists.
- **Acceptance:** OQ shall prove: (1) required input rows exist; (2) missing/Unknown inputs block execution or mark BLOCKED; (3) generated evidence has file path + SHA-256 where file-based; (4) human approval fields remain `Unknown — evidence required` until signed; (5) no prohibited compliance claim is emitted; and (6) the control is represented in the RTM and validation package readiness check.
- **Negative acceptance:** A deliberately missing required field, stale source, unapproved AI output, or fabricated evidence path shall fail the relevant deterministic gate and shall not produce READY or VALIDATED language.
- **Reg/QS basis:** EU AI Act risk management; GMLP; Annex 22 draft — internal anticipatory.
- **Trace:** SV-REQ-043 ↔ SV-COR-038 ↔ OQ-HARNESS-038 ↔ RTM-HARNESS-038.
- **Status:** DRAFT — not executed — not approved — not validation-ready.


### SV-COR-039 — AI intended-use register [v1.2 PECRA expansion]
- **Risk rating:** High. Critical where the control can affect validation-result integrity, compliance-claim wording, AI decision boundary, or evidence admissibility.
- **Current state / verified evidence:** Harness-Hardened v1.1 added this requirement as summary-grade. The v1.1 QA review found SV-COR-030…051 were not yet implementation-grade, not in the SV-REQ register / RTM, and not re-verified against the pinned code baseline. No runtime implementation is claimed.
- **Problem:** A summary-grade harness requirement cannot be used as a freeze-ready engineering requirement because it lacks implementation-level acceptance, traceability, and OQ closure criteria.
- **Corrective requirement:** The system **shall** implement `AI intended-use register` as a deterministic, evidence-producing harness control. The control shall be tenant-scoped where it stores records, attributed with `created_by`/`updated_by`, included in the validation package evidence manifest, and blocked from claiming completion until executed evidence exists.
- **Acceptance:** OQ shall prove: (1) required input rows exist; (2) missing/Unknown inputs block execution or mark BLOCKED; (3) generated evidence has file path + SHA-256 where file-based; (4) human approval fields remain `Unknown — evidence required` until signed; (5) no prohibited compliance claim is emitted; and (6) the control is represented in the RTM and validation package readiness check.
- **Negative acceptance:** A deliberately missing required field, stale source, unapproved AI output, or fabricated evidence path shall fail the relevant deterministic gate and shall not produce READY or VALIDATED language.
- **Reg/QS basis:** GMLP intended use; EU AI Act transparency/human oversight; Annex 22 draft.
- **Trace:** SV-REQ-044 ↔ SV-COR-039 ↔ OQ-HARNESS-039 ↔ RTM-HARNESS-039.
- **Status:** DRAFT — not executed — not approved — not validation-ready.


### SV-COR-040 — AI risk classification register [v1.2 PECRA expansion]
- **Risk rating:** High. Critical where the control can affect validation-result integrity, compliance-claim wording, AI decision boundary, or evidence admissibility.
- **Current state / verified evidence:** Harness-Hardened v1.1 added this requirement as summary-grade. The v1.1 QA review found SV-COR-030…051 were not yet implementation-grade, not in the SV-REQ register / RTM, and not re-verified against the pinned code baseline. No runtime implementation is claimed.
- **Problem:** A summary-grade harness requirement cannot be used as a freeze-ready engineering requirement because it lacks implementation-level acceptance, traceability, and OQ closure criteria.
- **Corrective requirement:** The system **shall** implement `AI risk classification register` as a deterministic, evidence-producing harness control. The control shall be tenant-scoped where it stores records, attributed with `created_by`/`updated_by`, included in the validation package evidence manifest, and blocked from claiming completion until executed evidence exists.
- **Acceptance:** OQ shall prove: (1) required input rows exist; (2) missing/Unknown inputs block execution or mark BLOCKED; (3) generated evidence has file path + SHA-256 where file-based; (4) human approval fields remain `Unknown — evidence required` until signed; (5) no prohibited compliance claim is emitted; and (6) the control is represented in the RTM and validation package readiness check.
- **Negative acceptance:** A deliberately missing required field, stale source, unapproved AI output, or fabricated evidence path shall fail the relevant deterministic gate and shall not produce READY or VALIDATED language.
- **Reg/QS basis:** EU AI Act risk classification; GMLP risk management.
- **Trace:** SV-REQ-045 ↔ SV-COR-040 ↔ OQ-HARNESS-040 ↔ RTM-HARNESS-040.
- **Status:** DRAFT — not executed — not approved — not validation-ready.


### SV-COR-041 — Model / provider / prompt / dataset version register [v1.2 PECRA expansion]
- **Risk rating:** High. Critical where the control can affect validation-result integrity, compliance-claim wording, AI decision boundary, or evidence admissibility.
- **Current state / verified evidence:** Harness-Hardened v1.1 added this requirement as summary-grade. The v1.1 QA review found SV-COR-030…051 were not yet implementation-grade, not in the SV-REQ register / RTM, and not re-verified against the pinned code baseline. No runtime implementation is claimed.
- **Problem:** A summary-grade harness requirement cannot be used as a freeze-ready engineering requirement because it lacks implementation-level acceptance, traceability, and OQ closure criteria.
- **Corrective requirement:** The system **shall** implement `Model / provider / prompt / dataset version register` as a deterministic, evidence-producing harness control. The control shall be tenant-scoped where it stores records, attributed with `created_by`/`updated_by`, included in the validation package evidence manifest, and blocked from claiming completion until executed evidence exists.
- **Acceptance:** OQ shall prove: (1) required input rows exist; (2) missing/Unknown inputs block execution or mark BLOCKED; (3) generated evidence has file path + SHA-256 where file-based; (4) human approval fields remain `Unknown — evidence required` until signed; (5) no prohibited compliance claim is emitted; and (6) the control is represented in the RTM and validation package readiness check.
- **Negative acceptance:** A deliberately missing required field, stale source, unapproved AI output, or fabricated evidence path shall fail the relevant deterministic gate and shall not produce READY or VALIDATED language.
- **Reg/QS basis:** GMLP lifecycle control; URS-13 change control; prompt/model versioning.
- **Trace:** SV-REQ-046 ↔ SV-COR-041 ↔ OQ-HARNESS-041 ↔ RTM-HARNESS-041.
- **Status:** DRAFT — not executed — not approved — not validation-ready.


### SV-COR-042 — AI advisory-output audit register [v1.2 PECRA expansion]
- **Risk rating:** High. Critical where the control can affect validation-result integrity, compliance-claim wording, AI decision boundary, or evidence admissibility.
- **Current state / verified evidence:** Harness-Hardened v1.1 added this requirement as summary-grade. The v1.1 QA review found SV-COR-030…051 were not yet implementation-grade, not in the SV-REQ register / RTM, and not re-verified against the pinned code baseline. No runtime implementation is claimed.
- **Problem:** A summary-grade harness requirement cannot be used as a freeze-ready engineering requirement because it lacks implementation-level acceptance, traceability, and OQ closure criteria.
- **Corrective requirement:** The system **shall** implement `AI advisory-output audit register` as a deterministic, evidence-producing harness control. The control shall be tenant-scoped where it stores records, attributed with `created_by`/`updated_by`, included in the validation package evidence manifest, and blocked from claiming completion until executed evidence exists.
- **Acceptance:** OQ shall prove: (1) required input rows exist; (2) missing/Unknown inputs block execution or mark BLOCKED; (3) generated evidence has file path + SHA-256 where file-based; (4) human approval fields remain `Unknown — evidence required` until signed; (5) no prohibited compliance claim is emitted; and (6) the control is represented in the RTM and validation package readiness check.
- **Negative acceptance:** A deliberately missing required field, stale source, unapproved AI output, or fabricated evidence path shall fail the relevant deterministic gate and shall not produce READY or VALIDATED language.
- **Reg/QS basis:** 21 CFR 11.10(e); GMLP traceability; AI auditability.
- **Trace:** SV-REQ-047 ↔ SV-COR-042 ↔ OQ-HARNESS-042 ↔ RTM-HARNESS-042.
- **Status:** DRAFT — not executed — not approved — not validation-ready.


### SV-COR-043 — AI adversarial validation test set [v1.2 PECRA expansion]
- **Risk rating:** High. Critical where the control can affect validation-result integrity, compliance-claim wording, AI decision boundary, or evidence admissibility.
- **Current state / verified evidence:** Harness-Hardened v1.1 added this requirement as summary-grade. The v1.1 QA review found SV-COR-030…051 were not yet implementation-grade, not in the SV-REQ register / RTM, and not re-verified against the pinned code baseline. No runtime implementation is claimed.
- **Problem:** A summary-grade harness requirement cannot be used as a freeze-ready engineering requirement because it lacks implementation-level acceptance, traceability, and OQ closure criteria.
- **Corrective requirement:** The system **shall** implement `AI adversarial validation test set` as a deterministic, evidence-producing harness control. The control shall be tenant-scoped where it stores records, attributed with `created_by`/`updated_by`, included in the validation package evidence manifest, and blocked from claiming completion until executed evidence exists.
- **Acceptance:** OQ shall prove: (1) required input rows exist; (2) missing/Unknown inputs block execution or mark BLOCKED; (3) generated evidence has file path + SHA-256 where file-based; (4) human approval fields remain `Unknown — evidence required` until signed; (5) no prohibited compliance claim is emitted; and (6) the control is represented in the RTM and validation package readiness check.
- **Negative acceptance:** A deliberately missing required field, stale source, unapproved AI output, or fabricated evidence path shall fail the relevant deterministic gate and shall not produce READY or VALIDATED language.
- **Reg/QS basis:** GMLP test coverage; prompt-injection / hallucination risk control.
- **Trace:** SV-REQ-048 ↔ SV-COR-043 ↔ OQ-HARNESS-043 ↔ RTM-HARNESS-043.
- **Status:** DRAFT — not executed — not approved — not validation-ready.


### SV-COR-044 — Prompt-injection and retrieval-isolation validation [v1.2 PECRA expansion]
- **Risk rating:** High. Critical where the control can affect validation-result integrity, compliance-claim wording, AI decision boundary, or evidence admissibility.
- **Current state / verified evidence:** Harness-Hardened v1.1 added this requirement as summary-grade. The v1.1 QA review found SV-COR-030…051 were not yet implementation-grade, not in the SV-REQ register / RTM, and not re-verified against the pinned code baseline. No runtime implementation is claimed.
- **Problem:** A summary-grade harness requirement cannot be used as a freeze-ready engineering requirement because it lacks implementation-level acceptance, traceability, and OQ closure criteria.
- **Corrective requirement:** The system **shall** implement `Prompt-injection and retrieval-isolation validation` as a deterministic, evidence-producing harness control. The control shall be tenant-scoped where it stores records, attributed with `created_by`/`updated_by`, included in the validation package evidence manifest, and blocked from claiming completion until executed evidence exists.
- **Acceptance:** OQ shall prove: (1) required input rows exist; (2) missing/Unknown inputs block execution or mark BLOCKED; (3) generated evidence has file path + SHA-256 where file-based; (4) human approval fields remain `Unknown — evidence required` until signed; (5) no prohibited compliance claim is emitted; and (6) the control is represented in the RTM and validation package readiness check.
- **Negative acceptance:** A deliberately missing required field, stale source, unapproved AI output, or fabricated evidence path shall fail the relevant deterministic gate and shall not produce READY or VALIDATED language.
- **Reg/QS basis:** Security/Privacy + AI governance; tenant isolation; prompt injection controls.
- **Trace:** SV-REQ-049 ↔ SV-COR-044 ↔ OQ-HARNESS-044 ↔ RTM-HARNESS-044.
- **Status:** DRAFT — not executed — not approved — not validation-ready.


### SV-COR-045 — Hallucination / unsupported-citation detection validation [v1.2 PECRA expansion]
- **Risk rating:** High. Critical where the control can affect validation-result integrity, compliance-claim wording, AI decision boundary, or evidence admissibility.
- **Current state / verified evidence:** Harness-Hardened v1.1 added this requirement as summary-grade. The v1.1 QA review found SV-COR-030…051 were not yet implementation-grade, not in the SV-REQ register / RTM, and not re-verified against the pinned code baseline. No runtime implementation is claimed.
- **Problem:** A summary-grade harness requirement cannot be used as a freeze-ready engineering requirement because it lacks implementation-level acceptance, traceability, and OQ closure criteria.
- **Corrective requirement:** The system **shall** implement `Hallucination / unsupported-citation detection validation` as a deterministic, evidence-producing harness control. The control shall be tenant-scoped where it stores records, attributed with `created_by`/`updated_by`, included in the validation package evidence manifest, and blocked from claiming completion until executed evidence exists.
- **Acceptance:** OQ shall prove: (1) required input rows exist; (2) missing/Unknown inputs block execution or mark BLOCKED; (3) generated evidence has file path + SHA-256 where file-based; (4) human approval fields remain `Unknown — evidence required` until signed; (5) no prohibited compliance claim is emitted; and (6) the control is represented in the RTM and validation package readiness check.
- **Negative acceptance:** A deliberately missing required field, stale source, unapproved AI output, or fabricated evidence path shall fail the relevant deterministic gate and shall not produce READY or VALIDATED language.
- **Reg/QS basis:** GMLP evidence quality; hallucination / unsupported-citation controls.
- **Trace:** SV-REQ-050 ↔ SV-COR-045 ↔ OQ-HARNESS-045 ↔ RTM-HARNESS-045.
- **Status:** DRAFT — not executed — not approved — not validation-ready.


### SV-COR-046 — Low-confidence / unavailable-provider handling validation [v1.2 PECRA expansion]
- **Risk rating:** High. Critical where the control can affect validation-result integrity, compliance-claim wording, AI decision boundary, or evidence admissibility.
- **Current state / verified evidence:** Harness-Hardened v1.1 added this requirement as summary-grade. The v1.1 QA review found SV-COR-030…051 were not yet implementation-grade, not in the SV-REQ register / RTM, and not re-verified against the pinned code baseline. No runtime implementation is claimed.
- **Problem:** A summary-grade harness requirement cannot be used as a freeze-ready engineering requirement because it lacks implementation-level acceptance, traceability, and OQ closure criteria.
- **Corrective requirement:** The system **shall** implement `Low-confidence / unavailable-provider handling validation` as a deterministic, evidence-producing harness control. The control shall be tenant-scoped where it stores records, attributed with `created_by`/`updated_by`, included in the validation package evidence manifest, and blocked from claiming completion until executed evidence exists.
- **Acceptance:** OQ shall prove: (1) required input rows exist; (2) missing/Unknown inputs block execution or mark BLOCKED; (3) generated evidence has file path + SHA-256 where file-based; (4) human approval fields remain `Unknown — evidence required` until signed; (5) no prohibited compliance claim is emitted; and (6) the control is represented in the RTM and validation package readiness check.
- **Negative acceptance:** A deliberately missing required field, stale source, unapproved AI output, or fabricated evidence path shall fail the relevant deterministic gate and shall not produce READY or VALIDATED language.
- **Reg/QS basis:** GMLP fail-safe controls; AI unavailability handling.
- **Trace:** SV-REQ-051 ↔ SV-COR-046 ↔ OQ-HARNESS-046 ↔ RTM-HARNESS-046.
- **Status:** DRAFT — not executed — not approved — not validation-ready.


### SV-COR-047 — AI monitoring and drift evidence [v1.2 PECRA expansion]
- **Risk rating:** High. Critical where the control can affect validation-result integrity, compliance-claim wording, AI decision boundary, or evidence admissibility.
- **Current state / verified evidence:** Harness-Hardened v1.1 added this requirement as summary-grade. The v1.1 QA review found SV-COR-030…051 were not yet implementation-grade, not in the SV-REQ register / RTM, and not re-verified against the pinned code baseline. No runtime implementation is claimed.
- **Problem:** A summary-grade harness requirement cannot be used as a freeze-ready engineering requirement because it lacks implementation-level acceptance, traceability, and OQ closure criteria.
- **Corrective requirement:** The system **shall** implement `AI monitoring and drift evidence` as a deterministic, evidence-producing harness control. The control shall be tenant-scoped where it stores records, attributed with `created_by`/`updated_by`, included in the validation package evidence manifest, and blocked from claiming completion until executed evidence exists.
- **Acceptance:** OQ shall prove: (1) required input rows exist; (2) missing/Unknown inputs block execution or mark BLOCKED; (3) generated evidence has file path + SHA-256 where file-based; (4) human approval fields remain `Unknown — evidence required` until signed; (5) no prohibited compliance claim is emitted; and (6) the control is represented in the RTM and validation package readiness check.
- **Negative acceptance:** A deliberately missing required field, stale source, unapproved AI output, or fabricated evidence path shall fail the relevant deterministic gate and shall not produce READY or VALIDATED language.
- **Reg/QS basis:** GMLP monitoring; model drift / performance monitoring.
- **Trace:** SV-REQ-052 ↔ SV-COR-047 ↔ OQ-HARNESS-047 ↔ RTM-HARNESS-047.
- **Status:** DRAFT — not executed — not approved — not validation-ready.


### SV-COR-048 — AI supplier qualification evidence [v1.2 PECRA expansion]
- **Risk rating:** High. Critical where the control can affect validation-result integrity, compliance-claim wording, AI decision boundary, or evidence admissibility.
- **Current state / verified evidence:** Harness-Hardened v1.1 added this requirement as summary-grade. The v1.1 QA review found SV-COR-030…051 were not yet implementation-grade, not in the SV-REQ register / RTM, and not re-verified against the pinned code baseline. No runtime implementation is claimed.
- **Problem:** A summary-grade harness requirement cannot be used as a freeze-ready engineering requirement because it lacks implementation-level acceptance, traceability, and OQ closure criteria.
- **Corrective requirement:** The system **shall** implement `AI supplier qualification evidence` as a deterministic, evidence-producing harness control. The control shall be tenant-scoped where it stores records, attributed with `created_by`/`updated_by`, included in the validation package evidence manifest, and blocked from claiming completion until executed evidence exists.
- **Acceptance:** OQ shall prove: (1) required input rows exist; (2) missing/Unknown inputs block execution or mark BLOCKED; (3) generated evidence has file path + SHA-256 where file-based; (4) human approval fields remain `Unknown — evidence required` until signed; (5) no prohibited compliance claim is emitted; and (6) the control is represented in the RTM and validation package readiness check.
- **Negative acceptance:** A deliberately missing required field, stale source, unapproved AI output, or fabricated evidence path shall fail the relevant deterministic gate and shall not produce READY or VALIDATED language.
- **Reg/QS basis:** Supplier quality; Annex 11 §4.3/4.5; GAMP 5 supplier assessment.
- **Trace:** SV-REQ-053 ↔ SV-COR-048 ↔ OQ-HARNESS-048 ↔ RTM-HARNESS-048.
- **Status:** DRAFT — not executed — not approved — not validation-ready.


### SV-COR-049 — AI allowed/prohibited-use matrix [v1.2 PECRA expansion]
- **Risk rating:** High. Critical where the control can affect validation-result integrity, compliance-claim wording, AI decision boundary, or evidence admissibility.
- **Current state / verified evidence:** Harness-Hardened v1.1 added this requirement as summary-grade. The v1.1 QA review found SV-COR-030…051 were not yet implementation-grade, not in the SV-REQ register / RTM, and not re-verified against the pinned code baseline. No runtime implementation is claimed.
- **Problem:** A summary-grade harness requirement cannot be used as a freeze-ready engineering requirement because it lacks implementation-level acceptance, traceability, and OQ closure criteria.
- **Corrective requirement:** The system **shall** implement `AI allowed/prohibited-use matrix` as a deterministic, evidence-producing harness control. The control shall be tenant-scoped where it stores records, attributed with `created_by`/`updated_by`, included in the validation package evidence manifest, and blocked from claiming completion until executed evidence exists.
- **Acceptance:** OQ shall prove: (1) required input rows exist; (2) missing/Unknown inputs block execution or mark BLOCKED; (3) generated evidence has file path + SHA-256 where file-based; (4) human approval fields remain `Unknown — evidence required` until signed; (5) no prohibited compliance claim is emitted; and (6) the control is represented in the RTM and validation package readiness check.
- **Negative acceptance:** A deliberately missing required field, stale source, unapproved AI output, or fabricated evidence path shall fail the relevant deterministic gate and shall not produce READY or VALIDATED language.
- **Reg/QS basis:** EU AI Act human oversight; Annex 22 draft; internal prohibited-use governance.
- **Trace:** SV-REQ-054 ↔ SV-COR-049 ↔ OQ-HARNESS-049 ↔ RTM-HARNESS-049.
- **Status:** DRAFT — not executed — not approved — not validation-ready.


### SV-COR-050 — Human re-derivation and QA disposition requirement [v1.2 PECRA expansion]
- **Risk rating:** High. Critical where the control can affect validation-result integrity, compliance-claim wording, AI decision boundary, or evidence admissibility.
- **Current state / verified evidence:** Harness-Hardened v1.1 added this requirement as summary-grade. The v1.1 QA review found SV-COR-030…051 were not yet implementation-grade, not in the SV-REQ register / RTM, and not re-verified against the pinned code baseline. No runtime implementation is claimed.
- **Problem:** A summary-grade harness requirement cannot be used as a freeze-ready engineering requirement because it lacks implementation-level acceptance, traceability, and OQ closure criteria.
- **Corrective requirement:** The system **shall** implement `Human re-derivation and QA disposition requirement` as a deterministic, evidence-producing harness control. The control shall be tenant-scoped where it stores records, attributed with `created_by`/`updated_by`, included in the validation package evidence manifest, and blocked from claiming completion until executed evidence exists.
- **Acceptance:** OQ shall prove: (1) required input rows exist; (2) missing/Unknown inputs block execution or mark BLOCKED; (3) generated evidence has file path + SHA-256 where file-based; (4) human approval fields remain `Unknown — evidence required` until signed; (5) no prohibited compliance claim is emitted; and (6) the control is represented in the RTM and validation package readiness check.
- **Negative acceptance:** A deliberately missing required field, stale source, unapproved AI output, or fabricated evidence path shall fail the relevant deterministic gate and shall not produce READY or VALIDATED language.
- **Reg/QS basis:** CSV/CSA independence; QA human decision of record; GDocP.
- **Trace:** SV-REQ-055 ↔ SV-COR-050 ↔ OQ-HARNESS-050 ↔ RTM-HARNESS-050.
- **Status:** DRAFT — not executed — not approved — not validation-ready.


### SV-COR-051 — AI compliance-claim guard [v1.2 PECRA expansion]
- **Risk rating:** High. Critical where the control can affect validation-result integrity, compliance-claim wording, AI decision boundary, or evidence admissibility.
- **Current state / verified evidence:** Harness-Hardened v1.1 added this requirement as summary-grade. The v1.1 QA review found SV-COR-030…051 were not yet implementation-grade, not in the SV-REQ register / RTM, and not re-verified against the pinned code baseline. No runtime implementation is claimed.
- **Problem:** A summary-grade harness requirement cannot be used as a freeze-ready engineering requirement because it lacks implementation-level acceptance, traceability, and OQ closure criteria.
- **Corrective requirement:** The system **shall** implement `AI compliance-claim guard` as a deterministic, evidence-producing harness control. The control shall be tenant-scoped where it stores records, attributed with `created_by`/`updated_by`, included in the validation package evidence manifest, and blocked from claiming completion until executed evidence exists.
- **Acceptance:** OQ shall prove: (1) required input rows exist; (2) missing/Unknown inputs block execution or mark BLOCKED; (3) generated evidence has file path + SHA-256 where file-based; (4) human approval fields remain `Unknown — evidence required` until signed; (5) no prohibited compliance claim is emitted; and (6) the control is represented in the RTM and validation package readiness check.
- **Negative acceptance:** A deliberately missing required field, stale source, unapproved AI output, or fabricated evidence path shall fail the relevant deterministic gate and shall not produce READY or VALIDATED language.
- **Reg/QS basis:** GDocP; QA claim governance; AI-specific claim control.
- **Trace:** SV-REQ-056 ↔ SV-COR-051 ↔ OQ-HARNESS-051 ↔ RTM-HARNESS-051.
- **Status:** DRAFT — not executed — not approved — not validation-ready.


## H6. v1.2 ratifiable DDL for harness registers

**Purpose:** closes CG-3. These are design-level tables for the harness-grade controls introduced in SV-COR-030…051. Exact migration number is assigned by Engineering. This DDL is a draft design specification requiring Product/Engineering Architect + Data Integrity ratification before build.

**Common rules:** every table is tenant-scoped, RLS-enabled, attributable, rollback-commented, and append-only unless a controlled correction workflow is explicitly defined. Do not remove RLS. Do not store secrets or production PHI/PII in these registers.

```sql
-- ROLLBACK: drop the tables, policies, and indexes created in this migration.


CREATE TABLE IF NOT EXISTS validation_run_readiness (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  tenant_id UUID NOT NULL REFERENCES tenants(id) ON DELETE RESTRICT,
  run_id UUID, readiness_status VARCHAR(32), blocked_reason TEXT, run_intent_hash VARCHAR(64), jurisdiction_scope_hash VARCHAR(64), synthetic_data_policy_hash VARCHAR(64), approval_matrix_hash VARCHAR(64), tool_qualification_status VARCHAR(64), external_signing_status VARCHAR(64),
  created_by UUID NOT NULL,
  updated_by UUID,
  created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
  updated_at TIMESTAMPTZ
);
ALTER TABLE validation_run_readiness ENABLE ROW LEVEL SECURITY;
DROP POLICY IF EXISTS tenant_isolation ON validation_run_readiness;
CREATE POLICY tenant_isolation ON validation_run_readiness
  USING (tenant_id = current_setting('app.current_tenant_id')::uuid);


CREATE TABLE IF NOT EXISTS validation_environment_lock (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  tenant_id UUID NOT NULL REFERENCES tenants(id) ON DELETE RESTRICT,
  run_id UUID, node_version TEXT, npm_version TEXT, postgres_version TEXT, browser_version TEXT, playwright_version TEXT, os_version TEXT, commit_sha VARCHAR(64), docker_image_digest TEXT, migration_version TEXT, seed_dataset_hash VARCHAR(64), validation_pack_version TEXT,
  created_by UUID NOT NULL,
  updated_by UUID,
  created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
  updated_at TIMESTAMPTZ
);
ALTER TABLE validation_environment_lock ENABLE ROW LEVEL SECURITY;
DROP POLICY IF EXISTS tenant_isolation ON validation_environment_lock;
CREATE POLICY tenant_isolation ON validation_environment_lock
  USING (tenant_id = current_setting('app.current_tenant_id')::uuid);


CREATE TABLE IF NOT EXISTS validation_evidence_manifest (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  tenant_id UUID NOT NULL REFERENCES tenants(id) ON DELETE RESTRICT,
  run_id UUID, artifact_type TEXT, artifact_path TEXT, sha256 VARCHAR(64), generated_by UUID, generated_at TIMESTAMPTZ,
  created_by UUID NOT NULL,
  updated_by UUID,
  created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
  updated_at TIMESTAMPTZ
);
ALTER TABLE validation_evidence_manifest ENABLE ROW LEVEL SECURITY;
DROP POLICY IF EXISTS tenant_isolation ON validation_evidence_manifest;
CREATE POLICY tenant_isolation ON validation_evidence_manifest
  USING (tenant_id = current_setting('app.current_tenant_id')::uuid);


CREATE TABLE IF NOT EXISTS validation_compliance_claim_register (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  tenant_id UUID NOT NULL REFERENCES tenants(id) ON DELETE RESTRICT,
  run_id UUID, artifact_path TEXT, claim_text TEXT, claim_class TEXT, allowed_status VARCHAR(64), approval_required BOOLEAN,
  created_by UUID NOT NULL,
  updated_by UUID,
  created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
  updated_at TIMESTAMPTZ
);
ALTER TABLE validation_compliance_claim_register ENABLE ROW LEVEL SECURITY;
DROP POLICY IF EXISTS tenant_isolation ON validation_compliance_claim_register;
CREATE POLICY tenant_isolation ON validation_compliance_claim_register
  USING (tenant_id = current_setting('app.current_tenant_id')::uuid);


CREATE TABLE IF NOT EXISTS validation_external_signature_record (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  tenant_id UUID NOT NULL REFERENCES tenants(id) ON DELETE RESTRICT,
  release_id UUID, signature_file_path TEXT, public_key_location TEXT, signature_algorithm TEXT, verification_status VARCHAR(64), verified_by UUID, verified_at TIMESTAMPTZ,
  created_by UUID NOT NULL,
  updated_by UUID,
  created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
  updated_at TIMESTAMPTZ
);
ALTER TABLE validation_external_signature_record ENABLE ROW LEVEL SECURITY;
DROP POLICY IF EXISTS tenant_isolation ON validation_external_signature_record;
CREATE POLICY tenant_isolation ON validation_external_signature_record
  USING (tenant_id = current_setting('app.current_tenant_id')::uuid);


CREATE TABLE IF NOT EXISTS validation_tool_run_log (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  tenant_id UUID NOT NULL REFERENCES tenants(id) ON DELETE RESTRICT,
  run_id UUID, tool_name TEXT, tool_version TEXT, model_name TEXT, model_version TEXT, prompt_hash VARCHAR(64), input_hash VARCHAR(64), output_hash VARCHAR(64), human_reviewer UUID,
  created_by UUID NOT NULL,
  updated_by UUID,
  created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
  updated_at TIMESTAMPTZ
);
ALTER TABLE validation_tool_run_log ENABLE ROW LEVEL SECURITY;
DROP POLICY IF EXISTS tenant_isolation ON validation_tool_run_log;
CREATE POLICY tenant_isolation ON validation_tool_run_log
  USING (tenant_id = current_setting('app.current_tenant_id')::uuid);


CREATE TABLE IF NOT EXISTS validation_source_library_register (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  tenant_id UUID NOT NULL REFERENCES tenants(id) ON DELETE RESTRICT,
  source_id TEXT, jurisdiction TEXT, source_title TEXT, source_version TEXT, source_path TEXT, source_sha256 VARCHAR(64), filing_status VARCHAR(64), owner_role TEXT,
  created_by UUID NOT NULL,
  updated_by UUID,
  created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
  updated_at TIMESTAMPTZ
);
ALTER TABLE validation_source_library_register ENABLE ROW LEVEL SECURITY;
DROP POLICY IF EXISTS tenant_isolation ON validation_source_library_register;
CREATE POLICY tenant_isolation ON validation_source_library_register
  USING (tenant_id = current_setting('app.current_tenant_id')::uuid);


CREATE TABLE IF NOT EXISTS validation_connector_privacy_crosswalk (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  tenant_id UUID NOT NULL REFERENCES tenants(id) ON DELETE RESTRICT,
  connector_id TEXT, connector_class TEXT, data_categories TEXT, personal_data BOOLEAN, health_data BOOLEAN, dpdp_basis TEXT, gdpr_basis TEXT, processor_subprocessor TEXT, cross_border_transfer TEXT, retention_rule TEXT, breach_notification_owner TEXT, basis_owner_role TEXT,
  created_by UUID NOT NULL,
  updated_by UUID,
  created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
  updated_at TIMESTAMPTZ
);
ALTER TABLE validation_connector_privacy_crosswalk ENABLE ROW LEVEL SECURITY;
DROP POLICY IF EXISTS tenant_isolation ON validation_connector_privacy_crosswalk;
CREATE POLICY tenant_isolation ON validation_connector_privacy_crosswalk
  USING (tenant_id = current_setting('app.current_tenant_id')::uuid);


CREATE TABLE IF NOT EXISTS validation_package_document_register (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  tenant_id UUID NOT NULL REFERENCES tenants(id) ON DELETE RESTRICT,
  package_id UUID, document_type TEXT, document_path TEXT, document_sha256 VARCHAR(64), status VARCHAR(64), reviewer UUID,
  created_by UUID NOT NULL,
  updated_by UUID,
  created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
  updated_at TIMESTAMPTZ
);
ALTER TABLE validation_package_document_register ENABLE ROW LEVEL SECURITY;
DROP POLICY IF EXISTS tenant_isolation ON validation_package_document_register;
CREATE POLICY tenant_isolation ON validation_package_document_register
  USING (tenant_id = current_setting('app.current_tenant_id')::uuid);


CREATE TABLE IF NOT EXISTS validation_gate_result_register (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  tenant_id UUID NOT NULL REFERENCES tenants(id) ON DELETE RESTRICT,
  run_id UUID, gate_name TEXT, gate_version TEXT, gate_status VARCHAR(64), finding_count INTEGER, evidence_path TEXT, executed_at TIMESTAMPTZ,
  created_by UUID NOT NULL,
  updated_by UUID,
  created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
  updated_at TIMESTAMPTZ
);
ALTER TABLE validation_gate_result_register ENABLE ROW LEVEL SECURITY;
DROP POLICY IF EXISTS tenant_isolation ON validation_gate_result_register;
CREATE POLICY tenant_isolation ON validation_gate_result_register
  USING (tenant_id = current_setting('app.current_tenant_id')::uuid);


CREATE TABLE IF NOT EXISTS validation_ai_feature_inventory (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  tenant_id UUID NOT NULL REFERENCES tenants(id) ON DELETE RESTRICT,
  feature_id TEXT, feature_name TEXT, intended_use_id TEXT, model_type TEXT, system_of_record_status TEXT, hitl_required BOOLEAN, prohibited_use_basis TEXT,
  created_by UUID NOT NULL,
  updated_by UUID,
  created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
  updated_at TIMESTAMPTZ
);
ALTER TABLE validation_ai_feature_inventory ENABLE ROW LEVEL SECURITY;
DROP POLICY IF EXISTS tenant_isolation ON validation_ai_feature_inventory;
CREATE POLICY tenant_isolation ON validation_ai_feature_inventory
  USING (tenant_id = current_setting('app.current_tenant_id')::uuid);


CREATE TABLE IF NOT EXISTS validation_ai_intended_use_register (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  tenant_id UUID NOT NULL REFERENCES tenants(id) ON DELETE RESTRICT,
  intended_use_id TEXT, feature_id TEXT, allowed_inputs TEXT, allowed_outputs TEXT, prohibited_uses TEXT, reviewer UUID, approval_status VARCHAR(64),
  created_by UUID NOT NULL,
  updated_by UUID,
  created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
  updated_at TIMESTAMPTZ
);
ALTER TABLE validation_ai_intended_use_register ENABLE ROW LEVEL SECURITY;
DROP POLICY IF EXISTS tenant_isolation ON validation_ai_intended_use_register;
CREATE POLICY tenant_isolation ON validation_ai_intended_use_register
  USING (tenant_id = current_setting('app.current_tenant_id')::uuid);


CREATE TABLE IF NOT EXISTS validation_ai_risk_classification_register (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  tenant_id UUID NOT NULL REFERENCES tenants(id) ON DELETE RESTRICT,
  feature_id TEXT, risk_class TEXT, eu_ai_act_status TEXT, annex22_status TEXT, gxp_impact TEXT, classification_owner TEXT,
  created_by UUID NOT NULL,
  updated_by UUID,
  created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
  updated_at TIMESTAMPTZ
);
ALTER TABLE validation_ai_risk_classification_register ENABLE ROW LEVEL SECURITY;
DROP POLICY IF EXISTS tenant_isolation ON validation_ai_risk_classification_register;
CREATE POLICY tenant_isolation ON validation_ai_risk_classification_register
  USING (tenant_id = current_setting('app.current_tenant_id')::uuid);


CREATE TABLE IF NOT EXISTS validation_ai_model_version_register (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  tenant_id UUID NOT NULL REFERENCES tenants(id) ON DELETE RESTRICT,
  feature_id TEXT, provider TEXT, model_name TEXT, model_version TEXT, prompt_doc_id TEXT, prompt_version TEXT, dataset_hash VARCHAR(64), change_control_id TEXT,
  created_by UUID NOT NULL,
  updated_by UUID,
  created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
  updated_at TIMESTAMPTZ
);
ALTER TABLE validation_ai_model_version_register ENABLE ROW LEVEL SECURITY;
DROP POLICY IF EXISTS tenant_isolation ON validation_ai_model_version_register;
CREATE POLICY tenant_isolation ON validation_ai_model_version_register
  USING (tenant_id = current_setting('app.current_tenant_id')::uuid);


CREATE TABLE IF NOT EXISTS validation_ai_advisory_output_register (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  tenant_id UUID NOT NULL REFERENCES tenants(id) ON DELETE RESTRICT,
  run_id UUID, feature_id TEXT, provider TEXT, model_version TEXT, input_hash VARCHAR(64), output_hash VARCHAR(64), findings_path TEXT, advisory_status VARCHAR(64),
  created_by UUID NOT NULL,
  updated_by UUID,
  created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
  updated_at TIMESTAMPTZ
);
ALTER TABLE validation_ai_advisory_output_register ENABLE ROW LEVEL SECURITY;
DROP POLICY IF EXISTS tenant_isolation ON validation_ai_advisory_output_register;
CREATE POLICY tenant_isolation ON validation_ai_advisory_output_register
  USING (tenant_id = current_setting('app.current_tenant_id')::uuid);


CREATE TABLE IF NOT EXISTS validation_ai_adversarial_test_register (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  tenant_id UUID NOT NULL REFERENCES tenants(id) ON DELETE RESTRICT,
  test_case_id TEXT, feature_id TEXT, adversarial_class TEXT, synthetic_payload_id TEXT, expected_result TEXT, actual_result TEXT, status VARCHAR(64),
  created_by UUID NOT NULL,
  updated_by UUID,
  created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
  updated_at TIMESTAMPTZ
);
ALTER TABLE validation_ai_adversarial_test_register ENABLE ROW LEVEL SECURITY;
DROP POLICY IF EXISTS tenant_isolation ON validation_ai_adversarial_test_register;
CREATE POLICY tenant_isolation ON validation_ai_adversarial_test_register
  USING (tenant_id = current_setting('app.current_tenant_id')::uuid);


CREATE TABLE IF NOT EXISTS validation_ai_monitoring_register (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  tenant_id UUID NOT NULL REFERENCES tenants(id) ON DELETE RESTRICT,
  feature_id TEXT, metric_name TEXT, threshold_value TEXT, observed_value TEXT, monitoring_period TEXT, disposition TEXT, reviewer UUID,
  created_by UUID NOT NULL,
  updated_by UUID,
  created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
  updated_at TIMESTAMPTZ
);
ALTER TABLE validation_ai_monitoring_register ENABLE ROW LEVEL SECURITY;
DROP POLICY IF EXISTS tenant_isolation ON validation_ai_monitoring_register;
CREATE POLICY tenant_isolation ON validation_ai_monitoring_register
  USING (tenant_id = current_setting('app.current_tenant_id')::uuid);

```


## H9. v1.2 QA defect closure register

| QA defect | v1.2 disposition | Residual status |
|---|---|---|
| CG-1 India scope conflict | India made conditionally in scope with jurisdiction/source gating; no India compliance claim permitted. | Closed structurally; source/legal confirmation pending. |
| CG-2 SV-COR-030…051 summary-grade | Expanded to PECRA and added to SV-REQ/RTM mapping. | Requires OQ execution. |
| CG-3 New registers below design grade | Added ratifiable DDL with RLS, attribution, rollback. | Requires Architect + DI ratification. |
| CG-4 ARCH-AI-001 unpinned | Reference supplied and pinned to ARCH-AI-001 v1.0 DRAFT. | Freeze remains blocked until ARCH-AI-001 is approved and filed in the QMS location. |
| CG-5 Privacy/supplier ownership conflict | Engine consumes crosswalk; Legal/Security/Supplier Quality own determinations. | Closed structurally. |
| CG-6 External signing owner missing | Added D-9 owner role and key lifecycle evidence. | Execution pending. |
| CG-7 Version reference inconsistency | Corrected in v1.2/v0.3 release documents. | Closed. |
| CG-8 Claim scanner false-positive risk | Added context-aware allowlist rules with owner/review evidence. | Closed structurally; verify in OQ. |