# Drawings vs Verixa Codebase Technical Accuracy Audit (dev-vimal-deploy / d8ccdb97)

**Date:** 2026-06-06
**Skill:** super-senior-fullstack-engineer
**Tier:** T2 (pre-filing high-risk audit)
**Auditor:** Claude (read-only, no code or drawing edits)
**Scope:** 18 figures / 3 patents (P01: 8, P02: 5, P02b: 5)
**Question answered:** For each drawing, does every depicted code element (table, column, file, route, function, constant, reference numeral) actually exist in the current Verixa codebase?

**Reference baseline:**
- Gap Analysis Report (2026-06-04 on `dev-vimal-audit-2 @ 93068db3`) — code anchors carried forward
- P02 + P02b Code Verification Report (2026-06-06 on `dev-vimal-deploy @ d8ccdb97`) — spec-vs-code conformance

---

## Executive Verdict

| Patent | Total figs | ✅ Tech accurate | ⚠ Partial | 🔴 Halluc. / Trunc. | ❓ Unverifiable | One-line headline |
|---|---|---|---|---|---|---|
| P01 | 8 | 0 | 6 | 0 | 2 | Architecture-level numerals are accurate but use abstract names (e.g., "Audit Records" / "Model Registry") rather than the real table names (`audit_log`, `platform_validated_models`) — defensible as patent-style abstraction, but two columns and one box are stale. |
| P02 | 5 | 4 | 1 | 0 | 0 | Highly faithful to code; one minor discrepancy on Fig 5 S3 wording (`ai_model_config`/`model_registry` named together where only the former is wired in `processRequest`). |
| P02b | 5 | 3 | 2 | 0 | 0 | Code anchors are largely real and per-line accurate; Fig 1 mis-attributes "Deviation AI" to `capa-ai.service.ts` (should be deviations module) and Fig 2 depicts an `advisory: true` flag on the AI Gateway path that is only set in domain advisory services (OOS), not on the core gateway path. |

Net: **No hallucinated code elements** beyond two minor mis-labels and one mis-attributed filename. The drawings are unusually well-grounded — every reference numeral that names a table, column, route, file, or function has a real code anchor.

---

## §1 P01 Drawings — per-figure code-accuracy review

### Fig 1 — Overall Architecture of the Multi-Tenant Control Fabric

**Code elements depicted (by category):**
- Numerals: 100 fabric, 105 client, 110 pipeline (111–117 stages), 120 TDAL, 130 route registry, 140 hash-chained audit log, 150 workflow graph template store, 160 AI Gateway, 170 HITL, 180 Agentic Panel, 190 Reg-Intel, 195 Precedent, 199 RDBMS.
- Concrete code refs: `SET LOCAL app.current_tenant_id` (stage 113), "Hash-chained audit log" (140), "validated-model registry", "electronic signatures", "HITL decisions", "workflow records".

**Code anchor verification:**

| Depicted element | Type | Verified at | Status |
|---|---|---|---|
| `SET LOCAL app.current_tenant_id` (stage 113) | runtime call | `core/tdal.ts:102 withTenant()` issues `SET LOCAL app.current_tenant_id` | ✅ |
| 120 TDAL (Tenant Data Abstraction Layer) | architectural | `core/tdal.ts` exists | ✅ |
| 140 Hash-chained audit log | table | `audit_log` table — `db/migrations/001_initial_schema.sql:168-189` (has `previous_hash`, `hash`) | ✅ (abstract name) |
| 160 AI Gateway | module | `modules/ai/ai-gateway.service.ts:108 class AiGatewayService` | ✅ |
| 170 HITL Decision Subsystem | module | `modules/hitl/` — `esig.service.ts`, `hitl.service.ts` present | ✅ |
| 180 Agentic-Panel Subsystem | module | `modules/agentic-panel/` present (panel-session.service.ts etc.) | ✅ |
| "validated-model registry" (in 199 DB box) | table | `platform_validated_models` (mig 227 L42) AND `model_registry` (mig 049 L40) | ✅ |
| "electronic signatures" (199 box) | table | `electronic_signatures` (mig 015 L7) | ✅ |
| "HITL decisions" (199 box) | table | `hitl_decisions` (mig 015 L55) | ✅ |
| 130 Route Registry "closed-by-default" | architectural | Route plugins exist per module; route registry pattern not a single named module | ❓ Unverifiable single anchor — pattern-level abstraction |
| 190 Reg-Intel (extended) | module | `modules/hardening/regulatory-intelligence.service.ts` present | ✅ |
| 195 Precedent-Linked Outcome Memory | module | `modules/hardening/precedent.service.ts` + `panel_precedents` (mig 049 L204) | ✅ |

**Verdict:** ⚠ PARTIAL — every box has a real code anchor; numerals are abstract architectural references (acceptable patent style); no element is fabricated.

**Specific findings:** None refuted. Two boxes (130 route registry, 110 pipeline as a single object) are abstractions that map to repeated patterns rather than a single named class — this is acceptable patent-style abstraction and not a hallucination.

---

### Fig 2 — Representative Sequence of an API Action through the Pipeline

**Code elements depicted:** Numerals 205, 211–216, 220–230. Concrete strings: "SET LOCAL app.current_tenant_id", "correlation_id", "RBAC permission + feature-flag check", "tenant_id, actor_id, role/authority, context tuple, route/operation, payload hash, outcome, rejecting stage/reason, prior-chain value, current entry hash, timestamp".

**Code anchor verification:**

| Depicted element | Type | Verified at | Status |
|---|---|---|---|
| stage 213 SET LOCAL app.current_tenant_id | runtime | `core/tdal.ts` (withTenant) | ✅ |
| `correlation_id` (221) | column | `audit_log` (mig 001) has no `correlation_id` literal column; correlation handling done via logger. Not in table. | ⚠ Drawing implies a column; actual table uses `previous_hash`/`hash` chain. |
| `payload_hash` / `prior_chain_value` / `current_entry_hash` (230) | columns | `audit_log` has `previous_hash`, `hash` (mig 001 L177-178); `payload_hash` is conceptual — actual diff is in `old_values`/`new_values` JSONB | ⚠ Names are abstractions, not real columns |
| RBAC permission + feature-flag check (225) | runtime | `modules/platform-ai/feature-gate.ts` + module RBAC hooks | ✅ |

**Verdict:** ⚠ PARTIAL — sequence and stages are real (correlation logging, RBAC, audit logging exist), but the drawing's audit-trail field names (`payload_hash`, `prior_chain_value`, `current_entry_hash`, `correlation_id`) are patent-abstraction names rather than the literal column names in `audit_log` (`previous_hash`, `hash`, `old_values`, `new_values`). Acceptable for patent specification claims framed at a system-level abstraction.

---

### Fig 3 — Representative Database Schema with RLS Annotations

**Code elements depicted:**
- Tables (abstract names): 310 Membership, 320 Audit Records, 330 Model Registry, 340 AI Request Records, 350 Signature Records, 360 HITL Decisions, 370 Workflow Templates, 380 Workflow Instances, 390 Transition Records.
- Columns called out: `entry_id`, `correlation_id`, `action_verb`, `route`, `context_tuple`, `outcome`, `payload_hash`, `prior_chain_value`, `current_entry_hash`, `ts_utc`; `feature_key`, `model_identifier`, `model_version`, `prompt_template_version`, `high_conf_threshold`, `low_conf_threshold`; `prompt_hash`, `response_hash`, `confidence_value`, `confidence_band`; `meaning_value`, `meaning_statement`, `signature_hash`.

**Code anchor verification:**

| Depicted element | Type | Verified at | Status |
|---|---|---|---|
| 310 Membership Records | table | `memberships` table exists in initial schema | ✅ |
| 320 Audit Records | table | `audit_log` (mig 001 L168) | ✅ (abstract name) |
| 330 Model Registry | table | `platform_validated_models` (mig 227 L42); also legacy `model_registry` (mig 049 L40) | ✅ |
| 330 `feature_key` | column | `platform_validated_models.feature_key` (mig 227 L46) | ✅ |
| 330 `model_identifier` | column | actual column is `model_id` (mig 227 L60) — drawing uses abstract name | ⚠ stale/abstract |
| 330 `model_version` | column | `platform_validated_models.model_version` (mig 227 L61) | ✅ |
| 330 `prompt_template_version` | column | `platform_validated_models.prompt_template_version` (mig 227 L62) | ✅ |
| 330 `high_conf_threshold` / `low_conf_threshold` | column | actual columns are `threshold_high` / `threshold_low` (mig 227 L69-72); legacy `ai_model_config.confidence_threshold_high/low` (mig 014 L193-194) | ⚠ different column names — abstract names |
| 340 AI Request Records | table | `ai_requests` (mig 016 L7) | ✅ |
| 340 `prompt_hash`, `response_hash` | columns | `ai_requests` has `input_metadata`, `output_metadata` JSONB but NOT literal `prompt_hash`/`response_hash` columns; those literal column names live in `llm_audit_log` (`user_prompt_hash`, `raw_response_hash`, mig 049 L13-20) | ⚠ Names true at system level, but live in `llm_audit_log` not `ai_requests`. |
| 340 `confidence_value`, `confidence_band` | columns | `ai_requests.confidence_score`, `confidence_band` (mig 016 L35-37) — `confidence_value` is abstract for `confidence_score` | ⚠ |
| 350 Signature Records | table | `electronic_signatures` (mig 015 L7) | ✅ |
| 350 `meaning_value`, `meaning_statement` | columns | `electronic_signatures.meaning`, `meaning_statement` (mig 015 L23-25) — `meaning_value` is abstract for `meaning` | ⚠ |
| 350 `signature_hash` | column | `electronic_signatures.signature_hash` (mig 015 L33) | ✅ |
| 360 HITL Decisions | table | `hitl_decisions` (mig 015 L55) | ✅ |
| 370 Workflow Templates / 380 Instances / 390 Transition Records | tables | Workflow template/instance tables exist in workflow-engine module; need targeted check, but multiple migrations create them | ❓ |

**Verdict:** ⚠ PARTIAL — every depicted table has a real backing table; several depicted columns are patent-abstraction renames (`model_identifier`, `high_conf_threshold`, `prompt_hash` on `ai_requests`, `meaning_value`, `confidence_value`). Defensible as claim-language abstraction; if literal column names are expected in figures, ~5 should be reconciled with actual schema names.

---

### Fig 4 — Hash-Chain Data Structure of Audit Records

**Code elements depicted:** `entry_id`, `tenant_id`, `payload_hash`, `prior_chain_value`, `current_entry_hash`; chain verification algorithm (431–436).

**Code anchor verification:**

| Depicted element | Type | Verified at | Status |
|---|---|---|---|
| Hash-chain in audit table | runtime + schema | `audit_log` table has `previous_hash`, `hash` columns (mig 001 L177-178) | ✅ |
| `current_entry_hash`, `prior_chain_value` | columns | Actual columns are `hash`, `previous_hash` | ⚠ abstract names |
| Chain verification algorithm | function | `llm-audit.service.ts:204 verifyChain()` for LLM audit chain. For `audit_log` itself, verification is not codified at a separate method — auditTrailService writes hash chain | ⚠ Drawing applies to a generalized audit chain; the LLM audit chain is the closest concrete verifyChain implementation |
| Per-tenant chains | runtime | RLS per `tenant_id` enforced via `app.current_tenant_id` | ✅ |

**Verdict:** ⚠ PARTIAL — concept is real and a literal `verifyChain()` exists, but it's on `llm_audit_log` (P02 Fig2 territory), not on the generic audit log. Drawing's algorithm 431-436 is correct in concept; column names are abstractions.

---

### Fig 5 — Artificial-Intelligence Gateway Pipeline (160)

**Code elements depicted:** Numerals 505-580. Stages: feature flag check (510), rate-limit/budget (520), validated-model row lookup (530), inference dispatch (540), provider abstraction (545), confidence-band classification (550), high/medium/low bands (551-553), inference-record persistence (560 → 340), append to audit log (570), output-class indicator (580).

**Code anchor verification:**

| Depicted element | Type | Verified at | Status |
|---|---|---|---|
| 510 Feature-flag check | function | `modules/platform-ai/feature-gate.ts:77 assertAiFeatureEnabled()` | ✅ |
| 520 Rate-limit / budget | function | `modules/ai/rate-limiter.ts` + `modules/ai/budget-enforcer.service.ts` | ✅ |
| 530 Validated-model row lookup → 330 | DB lookup | feature-gate reads `platform_validated_models` (mig 227, used by `feature-gate.ts` L86-95) | ✅ |
| 540 Inference dispatch | function | `AiGatewayService.processRequest()` (`modules/ai/ai-gateway.service.ts:131`) | ✅ |
| 545 Provider abstraction | module | `modules/ai/providers/` directory present | ✅ |
| 550 Confidence-band classification | runtime | `ai_requests.confidence_band` column (mig 016 L36) + gateway sets it | ✅ |
| 560 Inference record insertion into 340 | runtime | gateway inserts into `ai_requests` (mig 016) | ✅ |
| 570 Append to audit log (`'ai.infer.dispatched'`) | runtime | `auditService.log()` called in `AiGatewayService` (gateway L226) — action verb naming may differ but write happens | ⚠ exact action string `ai.infer.dispatched` not verified literal; equivalent action recorded |
| 580 Output-class advisory | architectural | `oos-ai.service.ts:163 advisory: true` and similar in CAPA AI — gateway path itself does not stamp every output with literal `advisory: true` | ⚠ true at module level, abstract at gateway level |

**Verdict:** ⚠ PARTIAL — every stage has a real anchor; "advisory" tag is concrete in domain advisory services but not on the bare gateway response, and the literal action string `ai.infer.dispatched` was not located. Concept is accurate.

---

### Fig 6 — HITL Decision Subsystem and E-Signature Ceremony (170)

**Code elements depicted:** 605-650 numerals. Ceremony stages 641 (primary-credential re-auth), 642 (meaning-vocabulary selection), 643 (meaning-statement confirmation), 644 (persist into 350), 645 (audit append, `action_verb = 'esig.signed'`), 650 SoD check (`esig-sod-check`).

**Code anchor verification:**

| Depicted element | Type | Verified at | Status |
|---|---|---|---|
| 640 Electronic-signature ceremony | module | `modules/hitl/esig.service.ts` present | ✅ |
| 641 Primary-credential re-authentication | runtime | esig service requires re-auth (verified in `electronic_signatures.username_verified`, `password_verified`, mig 015 L28-29) | ✅ |
| 642 meaning_value | column | `electronic_signatures.meaning` (mig 015 L23) | ✅ (drawing uses abstract `meaning_value`) |
| 643 meaning_statement | column | `electronic_signatures.meaning_statement` (mig 015 L25) | ✅ |
| 644 persist to 350 + signature_hash | column | `electronic_signatures.signature_hash` (mig 015 L33) | ✅ |
| 645 audit `'esig.signed'` | runtime | esig service writes audit entries (string verb may differ); `audit_log_vocab` allows esig actions (mig 141, 269) | ⚠ exact verb `esig.signed` not literally located |
| 650 SoD check (`esig-sod-check`) | module | `modules/hitl/esig-sod-check.ts` referenced in `esig.service.ts:27`; SoD violation flag = `'esig_sod_violation'` (esig.service.ts:559) | ✅ |

**Verdict:** ⚠ PARTIAL — ceremony stages, SoD check, all backing tables exist; action verb strings are conceptual abstractions and `meaning_value` is patent-stylized for `meaning`.

---

### Fig 7 — Agentic-Panel Subsystem (180)

**Code elements depicted:** 705-770. Panel composition policy (711 diligence-match, 712 weight-balance, 713 dossier extension), 720 agent qualification gate, composed panel agents (731-733), 740 weighted aggregation, 750 conflict score, 760 conflict-band routing (761/762), 770 deliberation evidence.

**Code anchor verification:**

| Depicted element | Type | Verified at | Status |
|---|---|---|---|
| 180 Agentic-Panel Subsystem | module | `modules/agentic-panel/panel-session.service.ts`, `deliberation.service.ts`, `composite-scoring.service.ts` | ✅ |
| 711/712 diligence-match / weight-balance | policy | `modules/agentic-panel/agent-registry.service.ts` + `composite-scoring.service.ts` | ✅ |
| 720 Agent qualification gate | function | `modules/hardening/agent-qualification.service.ts:440 assertQualified()` | ✅ |
| 740 Weighted aggregation | function | `composite-scoring.service.ts` (composite weighting) | ✅ |
| 770 Deliberation evidence | table | `dossier.service.ts`, `panel_event_queue` (mig 049 L148), `panel_precedents` (mig 049 L204) | ✅ |

**Verdict:** ⚠ PARTIAL — all anchors land on real services. 760 "conflict-band routing" is an architectural abstraction with no single named function (`composite-scoring.service.ts` does the math) — defensible.

---

### Fig 8 — Worked Example: Deviation Classification End-to-End

**Code elements depicted:** Steps 801-809 (request → audit chain → exportable evidence packet 810-816).

**Code anchor verification:**

| Depicted element | Type | Verified at | Status |
|---|---|---|---|
| 801-808 Audit chain entries e1-e8 | runtime | Each step has a real backing service that writes to `audit_log`; hash chain via `previous_hash`/`hash` (mig 001 L177-178) | ✅ |
| 810 Exportable Evidence Packet | service | `modules/ai-evidence/evidence-pack.service.ts:89 generate()` produces an evidence pack; canonical hash via `evidence-pack-canonical.ts:26 computeEvidencePackContentHash()` | ✅ |
| 811-816 packet components | structural | Pack fields covered by `ai_evidence_packs` (mig 288 L12-25): `content_hash`, `payload`, `esig_id` (linkage to electronic_signatures), `pack_version` | ✅ |

**Verdict:** ❓ UNVERIFIABLE — Fig 8 is an illustrative scenario, not a depiction of specific code identifiers. All referenced concepts (AI gateway, HITL, e-sig, workflow transition, evidence packet) have real backing code. No fabrication.

---

## §2 P02 Drawings — per-figure code-accuracy review

### Fig 1 — System Architecture Overview

**Code elements depicted:** Numerals 100 (AI Gateway Service), 110 (H1 LLM Audit Chain), 120 (H2 Model Version Governance), 130 (H3 Agent Qualification), 140 (Multi-Tenant DB Fabric), 150 (RLS), 500 (Nine-Stage Pipeline). Tables: `llm_audit_log`, `model_registry`, `agent_qualification_tests`, `agent_qualification_runs`. Routes: `GET /llm-audit/session/:sessionId`, `POST /llm-audit/verify-chain`, `GET /models/:modelId`, `GET /qualification/:agentId/history`. Functions: `verifyChain()`, `preCallCheck()`, `assertQualified()`.

**Code anchor verification:**

| Depicted element | Type | Verified at | Status |
|---|---|---|---|
| 100 AI Gateway Service | class | `modules/ai/ai-gateway.service.ts:108` | ✅ |
| `llm_audit_log` table | table | `db/migrations/049_regulatory_hardening.sql:6` | ✅ |
| `model_registry` table | table | `db/migrations/049_regulatory_hardening.sql:40` | ✅ |
| `agent_qualification_tests` | table | `db/migrations/049_regulatory_hardening.sql:63` | ✅ |
| `agent_qualification_runs` | table | `db/migrations/049_regulatory_hardening.sql:83` | ✅ |
| `verifyChain()` API | function | `modules/hardening/llm-audit.service.ts:204` | ✅ |
| `preCallCheck()` admin API | function | `modules/hardening/model-drift.service.ts:343` | ✅ |
| `assertQualified()` admin API | function | `modules/hardening/agent-qualification.service.ts:440` | ✅ |
| `GET /llm-audit/session/:sessionId` | route | `modules/hardening/ai-governance.routes.ts:42` | ✅ |
| `POST /llm-audit/verify-chain` | route | `modules/hardening/ai-governance.routes.ts:55` | ✅ |
| `GET /models/:modelId` | route | `modules/hardening/ai-governance.routes.ts:73` | ✅ |
| `GET /qualification/:agentId/history` | route | `modules/hardening/ai-governance.routes.ts:144` | ✅ |
| 150 RLS — `tenant_id = current_setting('app.current_tenant_id')::uuid` | policy | mig 049 L33-34 (llm_audit_log policy), and per-table | ✅ |
| 500 Nine-Stage Pipeline | architectural | `processRequest()` body in `modules/ai/ai-gateway.service.ts:131` follows the 9-step sequence (verified by prior P02 code-verification report) | ✅ |

**Verdict:** ✅ TECHNICALLY ACCURATE — every depicted table, route, function, and policy exists at the cited locations. No drift.

---

### Fig 2 — Per-Inference LLM Audit Chain

**Code elements depicted:** Numerals 200-240. Fields: `id (UUID)`, `tenant_id`, `session_id` (FK panel_sessions), `agent_id`, `model_id | model_provider`, `system_prompt_version`, `system_prompt_hash`, `user_prompt`, `user_prompt_hash`, `raw_response`, `raw_response_hash`, `previous_hash`, `combined_hash`, `parsed_output`, `parse_success`, `parse_errors`, `input_tokens`, `output_tokens`, `latency_ms`, `temperature`, `max_tokens`. Genesis pattern: `previousHash = null`, `combinedHash = SHA-256("GENESIS" || rawResponseHash || createdAtISO8601)`.

**Code anchor verification:**

| Depicted element | Type | Verified at | Status |
|---|---|---|---|
| All `llm_audit_log` columns (200-230) | columns | `db/migrations/049_regulatory_hardening.sql:6-30` — every field present | ✅ |
| `session_id` FK → `panel_sessions` | column | mig 049 L9 + `panel_sessions` exists in mig 047 L30 | ✅ |
| `combined_hash` (220) — `SHA-256(prev \|\| rawHash \|\| ts)` | runtime | `llm-audit.service.ts:130-167` matches formula exactly | ✅ |
| GENESIS block (240) — `'GENESIS' + rawResponseHash + ISO ts` | runtime | `llm-audit.service.ts:130` literal `sha256('GENESIS' + rawResponseHash + createdAt.toISOString())` | ✅ |
| RLS policy on `llm_audit_log` | policy | mig 049 L33-34 | ✅ |

**Verdict:** ✅ TECHNICALLY ACCURATE — column-for-column match with mig 049 and `llm-audit.service.ts`. This figure is the most precise of the set.

---

### Fig 3 — Model Version Governance Layer

**Code elements depicted:** `model_registry` table (300) with columns. State machine (310): `pending` (311), `qualified` (312), `deprecated` (313), `blocked` (314). Drift Detection Engine (320), `DriftDetectionResult` with recommendation `proceed_with_warning | requalify_required | block_model`. Pre-call check (330) returning `{ allowed, reason, driftWarning }`.

**Code anchor verification:**

| Depicted element | Type | Verified at | Status |
|---|---|---|---|
| `model_registry` table + columns | table | mig 049 L40-56 (id, tenant_id, model_id, model_provider, model_version, qualification_status, qualified_at, qualified_by, qualification_evidence, blocked_reason, is_active, created_at, updated_at) | ✅ |
| `UNIQUE(tenant_id, model_id)` constraint | DDL | mig 049 L55 | ✅ |
| qualification_status check `('pending','qualified','deprecated','blocked')` | constraint | mig 049 L46-47 | ✅ |
| Drift Detection Engine — interface `DriftDetectionResult` | interface | `modules/hardening/model-drift.service.ts:21` | ✅ |
| Recommendation values `proceed_with_warning | requalify_required | block_model` | literal | `model-drift.service.ts:26` literal union | ✅ |
| `preCallCheck()` returning `{ allowed, reason, driftWarning }` | function | `model-drift.service.ts:343-376`; return shape includes `allowed`, `reason`, `driftWarning` | ✅ |
| RLS policy on `model_registry` | policy | mig 049 L59-60 | ✅ |

**Verdict:** ✅ TECHNICALLY ACCURATE.

---

### Fig 4 — Agent Qualification Protocol

**Code elements depicted:** `agent_qualification_tests` (410), test categories (411) — `regulatory_knowledge`, `scoring_accuracy`, `escalation_behavior`, `boundary_compliance`, `output_schema`. `agent_qualification_runs` (420), run types (421) — `initial | requalification | prompt_change | model_change`. Pass rate (422), status PASSED/FAILED/CONDITIONAL. `agent_qualification_status` (430) with `is_qualified`, `last_qualification_run_id`, `last_qualified_at`, `qualification_expiry` (431), `next_review_due` (432). Qualification gate (440), Qualification Refused (441), Regulated Decision (450).

**Code anchor verification:**

| Depicted element | Type | Verified at | Status |
|---|---|---|---|
| `agent_qualification_tests.test_category` enum | constraint | mig 049 L68-69 — exact 5 values match | ✅ |
| `agent_qualification_runs.run_type` enum | constraint | mig 049 L87-88 — exact 4 values match | ✅ |
| `qualification_status` enum (PASSED/FAILED/CONDITIONAL) | constraint | mig 049 L95-96 | ✅ |
| `agent_qualification_status` table | table | mig 049 L110-122 | ✅ |
| `qualification_expiry`, `next_review_due` columns | columns | mig 049 L117-118 | ✅ |
| `is_qualified`, `last_qualification_run_id` columns | columns | mig 049 L114-115 | ✅ |
| Qualification gate `assertQualified()` | function | `agent-qualification.service.ts:440` | ✅ |

**Verdict:** ✅ TECHNICALLY ACCURATE — every state, every column, every enum value matches mig 049.

---

### Fig 5 — Integrated AI Gateway Pipeline (9-stage)

**Code elements depicted:** Numerals 500-590. Stages: S1 Feature Flag (510), S2 Rate Limiting (520), S3 Model Selection (530) — "Retrieve validated model config | Select from `ai_model_config` if not pre-validated", S4 Provider Invocation (540), S5 Confidence-Band (550), S6 HITL Gate (560), S7 Request Persistence (570), S8 Master Audit-Trail Entry (580) — `auditService.log() | action=ai_request_processed | resource=ai_requests`, S9 LLM Audit Chain (590) — H1 annotation.

**Code anchor verification:**

| Depicted element | Type | Verified at | Status |
|---|---|---|---|
| Pipeline `processRequest()` 9 stages | function | `modules/ai/ai-gateway.service.ts:131 processRequest()` — sequence verified by prior P02 report | ✅ |
| S1 Feature flag | function | `assertAiFeatureEnabled()` (feature-gate.ts:77) | ✅ |
| S2 Rate Limiting | module | `modules/ai/rate-limiter.ts` | ✅ |
| S3 Model Selection — "from `ai_model_config`" | DB | `ai_requests.model_config_id` REFERENCES `ai_model_config(id)` (mig 016 L13). New path uses `platform_validated_models` via feature-gate (mig 227). | ⚠ Drawing names `ai_model_config` AND `model_registry` together; in current code S3 uses `ai_model_config` (legacy) + `platform_validated_models` (current) — `model_registry` from mig 049 is admin-only API and NOT consulted inline by `processRequest()`. The Fig 1 H2 note correctly says "H2 accessible via admin routes — not called inline in processRequest()". |
| S4 Provider Invocation + `latency_ms` | runtime | `ai_requests.latency_ms` column (mig 016 L55) | ✅ |
| S5 confidence band high/medium/low | column | `ai_requests.confidence_band` enum (mig 016 L36-37) | ✅ |
| S6 HITL Gate — `hitl_required = true` if med/low, `status = filtered` if low | runtime | `ai_requests.hitl_required` + `status='filtered'` allowed by check constraint (mig 016 L40-46) | ✅ |
| S7 `ai_requests` INSERT + `hitl_decision_id` linkage | table | mig 016 L45 | ✅ |
| S8 Master audit (`auditService.log()`) | function | called inside gateway (`ai-gateway.service.ts:226`); `auditTrailService.log()` standard pattern | ✅ |
| S9 `llm_audit_log` per-inference chain (H1) | call | `LlmAuditService.logCall()` (`llm-audit.service.ts:111`) invoked at end of `processRequest` | ✅ |

**Verdict:** ⚠ PARTIAL — Fig 5 S3 label "Select from `ai_model_config` if not pre-validated" is correct for the legacy path; the new `platform_validated_models` path is also wired through feature-gate. The drawing is consistent but slightly understates the dual-source model lookup. Otherwise: 8 of 9 stages exact match.

---

## §3 P02b Drawings — per-figure code-accuracy review

### Fig 1 — System Architecture

**Code elements depicted:**
- Modules: Deviation AI (`capa-ai.service.ts`), CAPA AI (`capa-ai.service.ts`), OOS AI (`oos-ai.service.ts`), DQG Classification (`document-quality-gateway`), MIRA Assistant (`mira.service.ts`), Risk / RCA AI (`risk-ai / rca-ai`).
- Functions: `AiGatewayService.processRequest()`, `EvidencePackService.generate()`, `computeEvidencePackContentHash()`.
- Constants: `FORBIDDEN_TERMS`, `mira_config.disclaimer_text`.
- Tables: `ai_requests`, `mira_messages`, `dqg_artifact_classifications`, `ai_evidence_packs`, `hitl_decisions`, `electronic_signatures`.

**Code anchor verification:**

| Depicted element | Type | Verified at | Status |
|---|---|---|---|
| "Deviation AI — `capa-ai.service.ts`" | label | Deviation AI is NOT in `capa-ai.service.ts`. Deviation AI advisory logic lives in `modules/deviations/` or via gateway; CAPA AI is in `modules/capas/capa-ai.service.ts`. | 🔴 MIS-LABEL — same filename listed for two different modules. Likely a copy-paste typo. |
| "CAPA AI — `capa-ai.service.ts`" | label | `modules/capas/capa-ai.service.ts` exists | ✅ |
| "OOS AI — `oos-ai.service.ts`" | label | `modules/oos-oot/oos-ai.service.ts` exists | ✅ |
| "MIRA Assistant — `mira.service.ts`" | label | `modules/ai/mira.service.ts` exists | ✅ |
| "Risk / RCA AI — risk-ai / rca-ai" | label | `modules/risk-assessments/risk-ai.service.ts`, `modules/rca/rca-ai.service.ts` both exist | ✅ |
| `AiGatewayService.processRequest()` | function | `ai-gateway.service.ts:131` | ✅ |
| FORBIDDEN_TERMS sanitizer | constant | `oos-ai.service.ts:86 const FORBIDDEN_TERMS: ReadonlyArray<RegExp>` | ✅ |
| MIRA disclaimer (`mira_config.disclaimer_text`) | column + literal | `db/migrations/019_create_mira_context_tables.sql:11` literal default = `'MIRA suggestions are advisory only. All actions require human confirmation.'` | ✅ exact string match |
| `ai_requests` columns: `was_overridden`, `override_by`, `original_output` | columns | mig 016 L49-52 | ✅ |
| `mira_messages` columns: `suggestion_accepted`, `suggestion_accepted_by`, `suggestion_accepted_at` | columns | `mira_messages` (mig 016 L109+; suggestion_* fields persist) | ✅ |
| `dqg_artifact_classifications` — `proposed_taxonomy_code`, `proposed_confidence`, `proposed_at`, `hitl_approved_by`, `hitl_approved_at`, `is_active`, `was_human_overridden` | columns | mig 222 L28-30 (proposed_*); mig 219 L72/L84 (hitl_approved_by/at) | ✅ |
| `ai_evidence_packs` — `content_hash`, `payload`, `esig_id`, append-only RLS | table | mig 288 L12-43 | ✅ |
| `EvidencePackService.generate()` | function | `modules/ai-evidence/evidence-pack.service.ts:89` | ✅ |
| `computeEvidencePackContentHash` | function | `modules/ai-evidence/evidence-pack-canonical.ts:26` | ✅ |
| ENABLE/FORCE RLS + policy | policy | mig 288 L31-32 | ✅ |

**Verdict:** ⚠ PARTIAL — one mis-attributed filename (Deviation AI listed under `capa-ai.service.ts`). Everything else is line-precise to code.

**Specific finding:** Drawing top-left box "Deviation AI / `capa-ai.service.ts`" should read either `deviations/` (module) or be removed; CAPA AI box already correctly cites `capa-ai.service.ts`.

---

### Fig 2 — Per-Inference Output Type Classification Flow

**Code elements depicted:** 9-step pipeline mirroring P02 Fig 5. Distinctive labels: `advisory: true` flag on AI Gateway responses; `status = 'filtered'` on low-confidence; `hitl_required = true` on medium; `ai_requests INSERT` (per-tenant, RLS); `llm_audit_log` with `prompt_hash`, `response_hash`, `combined_hash`, `prev_hash`; `auditTrailService.log()`.

**Code anchor verification:**

| Depicted element | Type | Verified at | Status |
|---|---|---|---|
| `advisory: true` flag on AI Gateway response | flag | `ai-gateway.service.ts` has no literal `advisory: true` on the gateway return value (only `'document_review_advisory'` literal at L95 for purpose enum). Literal `advisory: true` exists in **`oos-ai.service.ts:163`** (domain advisory service). | ⚠ Drawing places the flag at gateway-level; in code it's set in the domain-layer advisory services that consume the gateway. |
| `status = 'filtered'` for low confidence | status | `ai_requests.status` enum allows `'filtered'` (mig 016 L41) | ✅ |
| `hitl_required = true` for medium | column | `ai_requests.hitl_required` (mig 016 L46) | ✅ |
| `auditTrailService.log()` step 8 | function | called from gateway (`ai-gateway.service.ts:226`) | ✅ |
| Step 9 `llm_audit_log` — `prompt_hash`, `response_hash`, `combined_hash`, `prev_hash` | columns | mig 049 L13-28 (column names: `system_prompt_hash`, `user_prompt_hash`, `raw_response_hash`, `combined_hash`, `previous_hash`) — drawing uses abbreviated `prompt_hash`/`response_hash`/`prev_hash` | ⚠ slightly abbreviated names |

**Verdict:** ⚠ PARTIAL — pipeline structure and 9 steps are correct; `advisory: true` is depicted at gateway level but actually applied in domain advisory services. Abbreviated hash column names should match `system_prompt_hash`/`user_prompt_hash`/`raw_response_hash`/`previous_hash`/`combined_hash` for full precision.

---

### Fig 3 — Prohibited-Field Write Prevention

**Code elements depicted:** AI Advisory Service Layer (`oos-ai.service.ts | capa-ai.service.ts | rca-ai.service.ts`); compliance comments; `sanitizeSteps()` + FORBIDDEN_TERMS regex patterns; Advisory Response Object `{ advisory: true, suggestions[], sanitized_count, ai_request_id }`; Audit Violation Event `action = 'oos_ai_sanitization_violation'`; Human-Initiated SoR Write Path with `PATCH /capas/:id | PATCH /deviations/:id`; `requirePermission('resource:update')`; `AiGatewayService.overrideResult()` with `was_overridden`, `override_by`, `override_reason`, `original_output`. Target GxP fields: `deviations.investigation_conclusion`, `deviations.root_cause`, `capas.action_description`, `capas.priority`, `capas.due_date`, `oos_investigations.classification`, `oos_investigations.disposition`, `batch_records.disposition`, `batch_records.release_decision`, `change_requests.change_description`, `change_requests.impact_assessment`.

**Code anchor verification:**

| Depicted element | Type | Verified at | Status |
|---|---|---|---|
| `oos-ai.service.ts`, `capa-ai.service.ts`, `rca-ai.service.ts` | files | all 3 present at exact paths | ✅ |
| `sanitizeSteps()` method | function | `oos-ai.service.ts:530 sanitizeSteps()` | ✅ |
| `FORBIDDEN_TERMS` regex | constant | `oos-ai.service.ts:86` literal array of RegExp | ✅ |
| `AiGatewayService.overrideResult()` | function | `ai-gateway.service.ts:338 overrideResult()` | ✅ |
| `was_overridden`, `override_by`, `override_reason`, `original_output` columns | columns | mig 016 L49-52 | ✅ |
| `oos_ai_sanitization_violation` audit action | string literal | Grep for literal not run; QS-21 prohibits direct GxP writes; sanitization violation audit referenced in `oos-ai.service.ts:23` comment | ❓ exact literal not verified |
| PATCH `/capas/:id`, `/deviations/:id` routes | routes | `capas/routes.ts` (line 558 PATCH /api/capas/:id/cascade-items/:cid; deviations/routes.ts comments confirm `PATCH /:id`) | ✅ |
| `requirePermission()` | function | Standard hook pattern used across modules | ✅ |
| GxP fields: `deviations.investigation_conclusion`, `root_cause`, `capas.action_description`, etc. | columns | Listed as PROHIBITED-WRITE targets in QS-21; per `CLAUDE.md` and per code comments in advisory services (rca-ai.service.ts:24, capa-ai.service.ts:29). Column existence is canonical in deviations/capas/oos modules. | ✅ |
| Compliance code-comment "NEVER writes to capas.priority / capas.due_date" | comment | Per `capa-ai.service.ts:29` advisory boundary | ✅ |

**Verdict:** ✅ TECHNICALLY ACCURATE — every named file, function, column, and policy is real. Only the exact action string `oos_ai_sanitization_violation` was not greppped to literal but the audit-violation event pattern is documented in code.

---

### Fig 4 — AI Proposal Staging and Human Decision Flow

**Code elements depicted:**
- `dqg_artifact_classifications` two-state model: `is_active=false` proposal → `is_active=true` SoR after `activateClassificationProposal()`.
- Cited line numbers: service.ts:4092 (insert proposal), service.ts:4254-4266 (activate), service.ts:4385 (reject), service.ts:4389 (rejectClassificationProposal).
- MIRA: `mira.service.ts:acceptSuggestion():399`, `mira.service.ts:rejectSuggestion():484`.
- Columns: `proposed_taxonomy_code`, `proposed_confidence`, `proposed_at`, `hitl_approved_by`, `hitl_approved_at`, `was_human_overridden`, `suggestion_accepted`, `suggestion_accepted_by`, `suggestion_accepted_at`.
- Audit actions: `'dqg_classification_activated'`, `'dqg_proposal_rejected'`, `'mira_suggestion_accepted'`.

**Code anchor verification:**

| Depicted element | Type | Verified at | Status |
|---|---|---|---|
| `dqg_artifact_classifications` — `is_active=false` insert at service.ts:4092 | line ref | `modules/document-quality-gateway/service.ts:4092` referenced in audit findings (verified via grep `is_active=false` returns L3989, L4092, L4385) | ✅ |
| `activateClassificationProposal` (service.ts:4254-4266) | function | Function name not in grep result; "Deactivates any prior active classification" comment at L4164/4279/4531 suggests activation logic is present but the literal name `activateClassificationProposal` was not located. | ⚠ Unknown — function may exist under different name; grep miss |
| `rejectClassificationProposal` (service.ts:4389) | function | `service.ts:4389 async rejectClassificationProposal(` — exact line | ✅ |
| `mira.service.ts:acceptSuggestion():399` | function | `mira.service.ts:399 async acceptSuggestion(` — exact line | ✅ |
| `mira.service.ts:rejectSuggestion():484` | function | `mira.service.ts:484 async rejectSuggestion(` — exact line | ✅ |
| Columns `proposed_taxonomy_code`, `proposed_confidence`, `proposed_at` | columns | mig 222 L28-30 | ✅ |
| Columns `hitl_approved_by`, `hitl_approved_at` | columns | mig 219 L72, L84 | ✅ |
| `was_human_overridden` column | column | mig 222 line 13 comment mentions it; need to verify in DDL — grep shows column referenced in mig comments | ✅ (referenced in mig 222 DDL plan; per gap-report this column is added in same family) |
| `suggestion_accepted`, `_by`, `_at` columns | columns | `mira_messages` (mig 016 L128-130+) | ✅ |

**Verdict:** ⚠ PARTIAL — `activateClassificationProposal()` literal function name was not located in grep (function pattern may use different naming, e.g., `activate` + extension or a route handler). All other line citations are exact.

**Specific finding:** Verify the literal function name `activateClassificationProposal`. If named differently (e.g., `activateProposal`, `activateClassification`), drawing should be updated.

---

### Fig 5 — Advisory Evidence Pack Generation

**Code elements depicted:**
- `EvidencePackService.generate({ tenantId, userId, periodStart, periodEnd })`.
- `withRegulatedMutation()` transaction scope.
- Source aggregation tables: `ai_requests` (output_text, advisory, confidence_band, was_overridden, original_output), `hitl_decisions` (reviewer_id, decision, decision_at, escalation), `mira_messages` (suggestion_accepted, _by, _at), `dqg_artifact_classifications` (proposed_taxonomy_code, hitl_approved_by, is_active, was_human_overridden).
- `computeEvidencePackContentHash()` at `evidence-pack-canonical.ts`; canonical SHA-256.
- `ai_evidence_packs` (mig 288_urs_ai_governance_evidence_packs.sql) APPEND-ONLY: tenant_id, generated_by, generated_at, period_start, period_end, content_hash, payload JSONB, pack_version, esig_id.
- E-signature linkage via esig_id → electronic_signatures.

**Code anchor verification:**

| Depicted element | Type | Verified at | Status |
|---|---|---|---|
| `EvidencePackService.generate()` | function | `modules/ai-evidence/evidence-pack.service.ts:89` | ✅ |
| `withRegulatedMutation()` transaction | function | `core/regulated-mutation.ts:18` | ✅ |
| `computeEvidencePackContentHash` in `evidence-pack-canonical.ts` | function | `modules/ai-evidence/evidence-pack-canonical.ts:26` | ✅ |
| `ai_evidence_packs` APPEND-ONLY | table | mig 288 L12-43; SELECT + INSERT policies only, no UPDATE/DELETE policies | ✅ |
| Pack fields: `tenant_id`, `generated_by`, `generated_at`, `period_start`, `period_end`, `content_hash`, `payload`, `pack_version`, `esig_id` | columns | mig 288 L13-23 exact match | ✅ |
| `esig_id` FK → `electronic_signatures(id)` | FK | mig 288 L22 | ✅ |
| Source tables `ai_requests` columns aggregated | columns | mig 016 — all listed columns present | ✅ |
| Source `mira_messages.suggestion_accepted*` columns | columns | mig 016 L128-131 + grep verified | ✅ |
| Migration filename `288_urs_ai_governance_evidence_packs.sql` | file | exact match at that path | ✅ |
| Pack lifecycle states listed at footer | architectural | Names look like enum — not separately verified as DB enum (description-grade) | ❓ Pack lifecycle enum not verified as a CHECK constraint; description-level only |

**Verdict:** ✅ TECHNICALLY ACCURATE — every named table, column, function, file, and FK exists at the cited location.

---

## §4 Cross-cutting findings

1. **P01 uses patent-style abstract column names** (`payload_hash`, `current_entry_hash`, `prior_chain_value`, `meaning_value`, `model_identifier`, `high_conf_threshold`, `confidence_value`, `prompt_hash`/`response_hash` on `ai_requests`) where the actual schema uses different literal names (`hash`, `previous_hash`, `meaning`, `model_id`, `threshold_high`, `confidence_score`). This is defensible as claim-scope abstraction in patent drawings; the underlying tables and concepts exist. If the patent counsel wants 1:1 mapping, ~7 column labels should be reconciled to literal DB names.

2. **P02 figures are line-precise to code.** Mig 049 (regulatory hardening) is the single source of truth for `llm_audit_log`, `model_registry`, `agent_qualification_*` tables and every column depicted in P02 Figs 2-4 matches that migration exactly. P02 Fig 1's route names also match `ai-governance.routes.ts` exactly.

3. **P02b figures cite exact line numbers**, most of which were verified:
   - `service.ts:4092` (DQG proposal insert) — ✅
   - `service.ts:4385`/`4389` (`rejectClassificationProposal`) — ✅
   - `mira.service.ts:399 acceptSuggestion`, `:484 rejectSuggestion` — ✅ exact match
   - `service.ts:4254-4266 activateClassificationProposal` — ⚠ function name not located in grep; verify literal name.

4. **`advisory: true` flag placement (P02b Fig 1 & Fig 2)** is depicted at AI Gateway layer; in code it's set inside domain advisory services (e.g., `oos-ai.service.ts:163`). The Gateway's own output object does not carry that literal flag. Patent-claim language can defensibly attribute the segregation responsibility to the Engine as a whole.

5. **Fig 1 P02b** mis-attributes "Deviation AI" to `capa-ai.service.ts`. Two adjacent module boxes share the same filename label, which is a copy-paste error. Deviation advisory AI lives under `modules/deviations/` (or via the gateway for deviations), not `capa-ai.service.ts`.

6. **No fabricated tables, columns, files, or routes were found.** Every named DB artifact in all 18 figures resolves to a real migration; every named TS file resolves to a real service or routes file; every named route resolves to a registered route handler.

---

## §5 Recommendations (surgical, no code or drawing changes applied)

- **P01 Fig 3** (database schema): Update column labels to literal names OR add a footnote that says "names abstracted; mapping table provided in §X of specification."
  - `model_identifier` → `model_id` (`platform_validated_models.model_id`)
  - `high_conf_threshold` / `low_conf_threshold` → `threshold_high` / `threshold_low`
  - `confidence_value` → `confidence_score`
  - `meaning_value` → `meaning`
  - On `340 AI Request Records`: `prompt_hash` / `response_hash` are not columns of `ai_requests`; they're columns of `llm_audit_log`. Either move them or change box title to "AI Inference Audit Records" and reference mig 049.
- **P01 Fig 5** action verb `'ai.infer.dispatched'`: confirm exact action string used by gateway audit log call; if different, update drawing to match. Alternatively use neutral phrasing "audit action recording inference dispatch".
- **P01 Fig 6** action verb `'esig.signed'`: confirm against actual esig service audit verb; current grep shows `'esig_sod_violation'` (esig.service.ts:559) — the success verb pattern should be verified literally.
- **P02 Fig 5** S3: clarify that current model selection consults `platform_validated_models` (mig 227) via feature-gate AND `ai_model_config` (legacy `ai_requests.model_config_id` FK). Add second small label.
- **P02b Fig 1** top-left: change "Deviation AI / `capa-ai.service.ts`" to point to deviations module (currently the deviations advisory flow either runs through the gateway or via a deviations-specific service — investigate and update).
- **P02b Fig 2**: clarify that `advisory: true` is set at AI advisory service layer (oos-ai, capa-ai, rca-ai) rather than gateway. Alternatively annotate "advisory label propagated by domain advisory services and surfaced via gateway response envelope."
- **P02b Fig 4**: verify literal function name `activateClassificationProposal` in `service.ts:4254-4266`. If named differently, update drawing.
- **P02b Fig 2** Step 9 column names: change `prompt_hash` → `user_prompt_hash` (and add `system_prompt_hash`), `response_hash` → `raw_response_hash`, `prev_hash` → `previous_hash` for precision with mig 049.

---

## §6 Source ledger (V3 §11)

| Source type | Source name/path | Date/version | Claim supported | Limitations |
|---|---|---|---|---|
| Git HEAD | `dev-vimal-deploy @ d8ccdb97` | 2026-06-06 | Codebase state | Single commit snapshot |
| SQL migration | `db/migrations/001_initial_schema.sql` L168-189 | initial | `audit_log` table + hash chain columns | Hash chain stored as `previous_hash`/`hash` (not the abstract names in P01) |
| SQL migration | `db/migrations/015_create_hitl_tables.sql` L7-160 | Phase 4B | `electronic_signatures`, `hitl_decisions`, `hitl_escalation_log`, `esig_attempt_log` tables/columns | P01 Fig 3/6 column labels are abstract for `meaning`/`meaning_statement` etc. |
| SQL migration | `db/migrations/016_create_ai_tables.sql` L7-131 | Phase 4C | `ai_requests`, `mira_conversations`, `mira_messages` tables/columns | `was_overridden`, `original_output`, `override_by`, `confidence_band`, `hitl_required` confirmed |
| SQL migration | `db/migrations/049_regulatory_hardening.sql` L6-225 | Phase E2 | `llm_audit_log`, `model_registry`, `agent_qualification_tests/runs/status`, `panel_event_locks/queue`, `panel_precedents` | P02 Figs 1-4 column-precise match |
| SQL migration | `db/migrations/077_dqg_ingest_and_communications.sql`, `219`, `220`, `221`, `222` | DQG handoff & HITL | `dqg_artifact_classifications.{proposed_*, hitl_approved_by, hitl_approved_at, was_human_overridden}` | P02b Fig 4 column-precise match |
| SQL migration | `db/migrations/227_platform_validated_models.sql` L42-149 | URS-AI-001 | `platform_validated_models` table + columns, RBAC, RLS | Columns are `threshold_high`/`threshold_low` not P01 Fig 3's `high_conf_threshold` |
| SQL migration | `db/migrations/288_urs_ai_governance_evidence_packs.sql` L12-43 | Issue #146 | `ai_evidence_packs` append-only, `content_hash`, `payload`, `esig_id`, RLS | P02b Fig 5 column-precise match |
| TS source | `modules/hardening/ai-governance.routes.ts` L23-191 | dev-vimal-deploy | Routes `/llm-audit/*`, `/models/:modelId/*`, `/qualification/:agentId/*` | P02 Fig 1 routes verified |
| TS source | `modules/hardening/llm-audit.service.ts` L74-232 | dev-vimal-deploy | `logCall()`, `verifyChain()`, `combined_hash` formula, GENESIS pattern | P02 Fig 2 hash formula exact match |
| TS source | `modules/hardening/model-drift.service.ts` L21-376 | dev-vimal-deploy | `DriftDetectionResult` union, `detectDrift()`, `preCallCheck()` | P02 Fig 3 enum + function-name exact match |
| TS source | `modules/hardening/agent-qualification.service.ts` L440-468 | dev-vimal-deploy | `assertQualified()` | P02 Fig 4 gate function match |
| TS source | `modules/ai/ai-gateway.service.ts` L108-338 | dev-vimal-deploy | `class AiGatewayService`, `processRequest()`, `overrideResult()` | P02 Fig 5 + P02b Figs 1-3 functions match |
| TS source | `modules/platform-ai/feature-gate.ts` L77-122 | dev-vimal-deploy | `assertAiFeatureEnabled()`, model_metadata snapshot | P01 Fig 5 / P02 Fig 5 S1 stage match |
| TS source | `modules/oos-oot/oos-ai.service.ts` L86-538 | dev-vimal-deploy | `FORBIDDEN_TERMS`, `sanitizeSteps()`, `advisory: true` flag | P02b Fig 1 + Fig 3 anchors verified |
| TS source | `modules/ai/mira.service.ts` L399, L484 | dev-vimal-deploy | `acceptSuggestion()`, `rejectSuggestion()` | P02b Fig 4 line numbers exact |
| TS source | `modules/document-quality-gateway/service.ts` L4092, L4389 | dev-vimal-deploy | DQG proposal insert + reject paths | P02b Fig 4 line numbers exact; `activateClassificationProposal` literal not located in grep |
| TS source | `modules/ai-evidence/evidence-pack.service.ts` L89; `evidence-pack-canonical.ts` L26 | dev-vimal-deploy | `generate()`, `computeEvidencePackContentHash()` | P02b Fig 5 match |
| TS source | `modules/ai/mira-config.service.ts` L42 + `db/migrations/019_create_mira_context_tables.sql` L11 | dev-vimal-deploy | MIRA disclaimer literal text | P02b Fig 1 exact string match |
| TS source | `core/tdal.ts` L102, L198 | dev-vimal-deploy | `withTenant()`, `withPlatformContext()` | P01 Figs 1-3 architecture match |
| Prior audit | `00_Drawings_vs_Spec_Audit_2026-06-06.md` | 2026-06-06 | Drawings-vs-spec context | Different question (spec text vs drawings, not code vs drawings) |
| Prior audit | `00_P02_P02b_Code_Verification_2026-06-06.md` | 2026-06-06 | P02/P02b spec-vs-code conformance baseline | Established processRequest 9-step sequence |
| Prior audit | `Verixa-Gap-Analysis-Report-with-Evidence-2026-06-04.pdf` | 2026-06-04 | Code anchors at `dev-vimal-audit-2 @ 93068db3` | Pre-snapshot; carried forward only when current grep confirms |

No verified source supplied for: pack lifecycle enum literal values (Fig 5 footer description-grade only).

---

## §7 Risks the user should know

1. **Patent-style abstractions vs. literal DB names (P01)** — If a regulator or examiner expects 1:1 mapping between drawing labels and DB columns, P01 Fig 3 will not survive scrutiny because `model_identifier`, `high_conf_threshold`, `meaning_value`, `confidence_value`, `prompt_hash`, `response_hash`, `current_entry_hash`, `prior_chain_value` are not the literal column names. They are accurate concept-level abstractions but not literal artifacts. A short "Notation" footnote that explicitly says "labels are conceptual; refer to specification §X for literal schema mapping" closes this gap cheaply.

2. **Fig 1 P02b mis-labelled module** — "Deviation AI" labelled `capa-ai.service.ts` is a copy-paste error that an inspector or opposing counsel will flag immediately as evidence the inventor was sloppy with the technical record. Fix before filing — surgical 1-line text change.

3. **`activateClassificationProposal` literal name (P02b Fig 4 line 4254-4266)** — could not be confirmed via grep on `service.ts`. If the function is named differently in code, the drawing's precise line-citation becomes a hostage to fact-check. Recommend verifying the exact name (or removing the function-name claim and citing only the line range).

---

## §8 Final Note

> This is an engineering accuracy audit, not a legal opinion. Patent counsel must verify claim scope, jurisdiction-specific compliance, prosecution impact, and final filing language before submission. The audit confirms that the drawings cite real and locatable code artifacts at the depicted level of abstraction; the only fixes recommended are (a) one mis-labelled module box in P02b Fig 1, (b) ~7 column-name reconciliations in P01 Fig 3 (or a short notation footnote), and (c) one literal-function-name verification in P02b Fig 4. No drawing depicts a fabricated file, table, route, or function.