# Drawings vs Form 2 Brief Description of the Drawings — Multi-Document Consistency Audit (Rule 13(6))

**Date:** 2026-06-06
**Skill:** verixa-patent:patent-style-editor (Mode 4 Deep Multi-Document Consistency Audit)
**Tier:** T2 (pre-filing high-risk audit)
**Auditor:** Claude (read-only — no SVG or specification edits performed)
**Scope:** 18 figures across 3 provisional applications (P01: 8, P02: 5, P02b: 5)
**Jurisdiction:** India — Patents Act 1970 / Patents Rules 2003, Rule 13(6): "the drawings shall accord with the description."
**Filing stage:** Provisional, pre-filing.
**Outputs:** Flagged report only. No edits applied.

> **Numbering note.** P01 §5 and P02b §5 are the "Brief Description of the Drawings" sections. P02 places the same content at **§6** because §5 is reserved for "Technical Effects of the Invention." This is a structural choice and not a Rule 13(6) defect, but counsel should ensure the section reference inside any future Form 1 cross-references is correct for each application.

---

## Executive Verdict

| Patent | Total figs | ACCURATE | PARTIAL | DRIFT / HALLUCINATION / TRUNCATION / MISSING | Notes |
|---|---|---|---|---|---|
| P01 | 8 | 4 | 4 | 0 (no hard drift) | Several reference numerals appear in the SVGs that are not introduced in §5 verbatim but are introduced in Detailed Description and locked in `Reference_Numerals.md`. This is acceptable per Indian practice but should be acknowledged. Fig 5 contains element 545 (provider abstraction) only listed in §6.6.2 and Reference_Numerals.md — not in §5 text. Fig 6 contains element 650 (segregation-of-duties check) only in §6.7 and Reference_Numerals.md — not in §5 text. Fig 7 contains 770 (deliberation evidence) only in §6.8.7 and Reference_Numerals.md — not in §5 text. Fig 8 shows steps 801–809 + 810–816 — §5 mentions "audit-trail entries generated at each stage and the contents of the resulting exportable signature evidence packet" but does not enumerate steps. No drift; only depth-mismatch between §5 and SVG. |
| P02 | 5 | 5 | 0 | 0 | Tightly anchored: every reference numeral in every figure is introduced in §6 BDD and re-stated in §7 Detailed Description. Best-anchored set of the three. |
| P02b | 5 | 2 | 3 | 0 | P02b SVGs use mnemonic codes (E2-A, E2-B, E2-C, E2-D, E2-E, STEP 1–9, MIRA DISCLAIMER quoted text) that do not appear in §5 BDD. §5 describes the *substance* of each figure accurately, so this is a PARTIAL classification (visualisation labels exceed the §5 narrative), not DRIFT. The substantive elements (table names, FORBIDDEN_TERMS pattern set, columns named, services named) all reconcile against §6. |

**Headline finding.** No hard-drift, no hallucination, no truncation, no missing required element across all 18 figures. 9 figures classify as PARTIAL because of a recurring asymmetry: the §5 (or §6) BDD entries describe figures at a slightly higher level of abstraction than the SVGs depict. The SVGs introduce additional reference numerals or labels (legitimately supported by Detailed Description sections and, for P01, the `Reference_Numerals.md` crosswalk) that are not enumerated in the BDD entry. Under Rule 13(6), drawings must "accord with" the description — they do. However, best filing practice is for every reference numeral on a drawing to be introduced at first mention either in §5 BDD or in §6/§7 Detailed Description prose. The P01 set introduces several numerals only in the crosswalk file (not yet integrated into the filed Form 2 §6 Detailed Description prose). See §4 cross-cutting issues and §5 recommendations.

---

## §1 P01 — Patent 01 Platform Validated Model Lockstep

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

**A. Form 2 §5 entry (verbatim, line 120):**
> "Overall architecture of the multi-tenant control fabric showing the ordered request-processing pipeline, tenant data abstraction layer, route registry, hash-chained audit log, workflow graph template store, artificial-intelligence gateway, human-in-the-loop decision subsystem, and agentic-panel subsystem as cooperating components of a single computer system."

**B. Detailed Description references:** §6.1 (pipeline 110, stages 111–117), §6.2 (TDAL 120), §6.3 (route registry 130), §6.4 (audit log 140), §6.5 (workflow store 150), §6.6 (AI gateway 160), §6.7 (HITL 170), §6.8 (agentic panel 180). Elements 190 (regulatory-intelligence) and 195 (precedent-linked outcome memory) are extended embodiments (§6.9, §6.10). Element 199 (persistent storage) is described in §6.2 and §6.4.

**C. SVG content summary:**
- Title at top: "Fig. 1 — Overall Architecture of the Multi-Tenant Control Fabric"
- Reference numerals depicted: 100 (fabric), 105 (Client), 110 (pipeline), 111–117 (stages), 120 (TDAL), 130 (Route Registry), 140 (Audit Log), 150 (Workflow Template Store), 160 (AI Gateway), 170 (HITL), 180 (Agentic Panel), 190 (Regulatory-Intel, marked "extended"), 195 (Precedent-Linked Outcome Memory, marked "extended"), 199 (Persistent Storage).
- Solid/dashed line legend; mandatory flow vs optional embodiments distinguished.

**D. Verdict:** PARTIAL (information-rich; §5 does not enumerate 190, 195, 199 explicitly).

**E. Specific findings:**
- §5 names only the eight core subsystems; SVG additionally depicts 190 (regulatory-intel), 195 (precedent memory), and 199 (persistent storage). These are explicitly marked "extended embodiment" or are foundational storage. All three are anchored in §6.9, §6.10, §6.2/§6.4 respectively. No drift; visualisation depth exceeds §5 narrative depth.
- Reference numerals 105 (Client) and 117 (Action Dispatch) appear in SVG but are not separately introduced in §5; they are introduced in §6.1. Acceptable.

---

### Fig 2 — Pipeline Sequence

**A. Form 2 §5 entry (verbatim, line 121):**
> "Sequence diagram of an application programming interface request traversing the ordered request-processing pipeline, showing the order in which the correlation, authentication, tenant-scope, context-scope, permission-check, and audit-logging stages are performed and the audit-trail entries generated."

**B. Detailed Description references:** §6.1.1 (correlation), §6.1.2 (authentication), §6.1.3 (tenant-scope), §6.1.4 (context-scope), §6.1.5 (permission-check), §6.1.6 (audit-logging), §6.1.7 (failure semantics), §6.4 (audit-trail entry composition).

**C. SVG content summary:**
- Title: "Fig. 2 — Representative Sequence of an API Action through the Ordered Pipeline"
- Reference numerals: 205 (Client), 211–216 (stage lifelines), 220 (HTTP request), 221–225 (per-stage actions), 226 (PASS path — record pre-action outcome), 227 (dispatch handler), 228 (REJECT path — record rejection), 230 (audit-trail field composition box).
- Two outcomes shown: [PASS] and [REJECT at 212/213/215].

**D. Verdict:** ACCURATE.

**E. Specific findings:**
- All six stages enumerated in §5 (correlation, authentication, tenant-scope, context-scope, permission-check, audit-logging) appear in correct order.
- PASS/REJECT bifurcation is anchored by §6.1.7 and is consistent with §5 phrase "audit-trail entries generated."
- No missing or extra mechanism.

---

### Fig 3 — Database Schema

**A. Form 2 §5 entry (verbatim, line 122):**
> "Database schema diagram showing representative tenant-user or membership records, audit log records, validated-model registry records, artificial-intelligence inference records, electronic-signature records, human-in-the-loop decision records, workflow-template records, workflow-instance records, and transition records, together with row-level-security policy notations associated with such records."

**B. Detailed Description references:** §6.2 (TDAL + RLS), §6.4 (audit), §6.5 (workflow templates/instances/transitions), §6.6 (AI inference + model registry), §6.7 (signatures + HITL decisions).

**C. SVG content summary:**
- Title: "Fig. 3 — Representative Database Schema with Row-Level-Security Annotations"
- Tables depicted: 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, 395 RLS policy box.
- Notation legend: PK / FK / RLS / * (NOT NULL) / TENANT-SCOPED.

**D. Verdict:** ACCURATE.

**E. Specific findings:**
- All nine record types enumerated in §5 are depicted. RLS notation present. Match is one-to-one with §5.
- Element 395 (RLS policy box) is depicted but not separately introduced in §5; §5 says "together with row-level-security policy notations associated with such records" — the policy notation block (395) directly realises this. Acceptable.

---

### Fig 4 — Hash-Chain Data Structure

**A. Form 2 §5 entry (verbatim, line 123):**
> "Hash-chain data structure of representative audit records, showing per-tenant chains, prior-chain values, current entry-hash fields, and an algorithm by which a verification operation identifies a detected break in the chain."

**B. Detailed Description references:** §6.4 (entry composition, chain construction, advisory locking, verify_chain pseudocode).

**C. SVG content summary:**
- Title: "Fig. 4 — Hash-Chain Data Structure of Representative Audit Records (320)"
- Reference numerals: 410 (Tenant-A chain) with three entries (A-E1, A-E2, A-E3 rejected); 411 (Tenant-B chain) with two entries (B-E1, B-E2); 420 (entry-hash payload composition); 430 (chain-verification algorithm) with sub-steps 431–436 including TAMPER DETECTED / CHAIN VALID outcome.
- "(rejected)" annotation on A-E3 with `stage = 215 permission`.

**D. Verdict:** ACCURATE.

**E. Specific findings:**
- All four elements in §5 (per-tenant chains, prior-chain values, current entry-hash fields, verification algorithm with break detection) are depicted with sub-step granularity (431–436).
- Inclusion of a "rejected" audit row with `stage = 215 permission` is anchored in §6.4 ("persists entries for successful actions and for rejected actions under an identical row schema and identical hash chain").
- No drift.

---

### Fig 5 — AI Gateway Pipeline

**A. Form 2 §5 entry (verbatim, line 124):**
> "Pipeline diagram of the artificial-intelligence gateway, showing the feature-flag check, rate-limit check, eligible validated-model record lookup including active-status, validity-period, and expiration-condition checks, inference dispatch, confidence-band classification, and inference-record persistence stages."

**B. Detailed Description references:** §6.6 (AI gateway pipeline), §6.6.2 (provider abstraction), §6.7 (HITL routing connection).

**C. SVG content summary:**
- Title: "Fig. 5 — Artificial-Intelligence Gateway Pipeline (160)"
- Reference numerals: 505 (Caller), 510 (Feature-Flag Check), 520 (Rate-Limit/Budget Check), 530 (Validated-Model Row Lookup), 540 (Inference Dispatch), 545 (Provider abstraction), 550 (Confidence-Band Classification), 551/552/553 (HIGH/MEDIUM/LOW bands with routing notes including reviewer roles), 560 (Inference-Record Persistence into 340), 570 (Append to 140 audit log), 580 (Output-Class Indicator: advisory vs deterministic).

**D. Verdict:** PARTIAL.

**E. Specific findings:**
- All six stages enumerated in §5 are present (feature-flag, rate-limit, validated-model lookup, inference dispatch, confidence-band, persistence).
- SVG depicts additional elements not enumerated in §5: 545 (provider abstraction), 551/552/553 (HIGH/MEDIUM/LOW confidence bands with reviewer-role routing), 570 (audit-log append), 580 (output-class indicator). These are anchored in §6.6 and §6.6.2 of the Detailed Description and in `Reference_Numerals.md`. No drift; depth-mismatch only.
- Element 580 ("Output-Class Indicator: advisory vs deterministic") asserts that "Generative AI output is advisory." This is consistent with §6.6 / P02b §6.2 ethos but the text on the SVG ("Direct writes to critical fields require configured workflow, permission, audit, and HITL/e-sign controls") goes slightly beyond what §6 of P01 narrates. Counsel should consider whether this constitutes an extra disclosure not yet locked into Form 2 prose.

---

### Fig 6 — HITL Decision Subsystem and Electronic-Signature Ceremony

**A. Form 2 §5 entry (verbatim, line 125):**
> "Flow of the human-in-the-loop decision subsystem including reviewer assignment by confidence band, electronic-signature ceremony comprising primary-credential re-authentication, meaning-vocabulary selection, meaning-statement confirmation, and persistence of the signature record with its cryptographic binding fields."

**B. Detailed Description references:** §6.7 (HITL + e-signature ceremony), §6.4 (linkage to audit chain).

**C. SVG content summary:**
- Title: "Fig. 6 — HITL Decision Subsystem and Electronic-Signature Ceremony (170)"
- Reference numerals: 605 (Trigger), 610 (Reviewer Assignment) with 611 (medium → reviewer) and 612 (low → senior reviewer), 620 (decision UI), 630 (accept/override/escalate), 631 (escalate), 640 (E-signature ceremony container) with sub-steps 641 (re-auth), 642 (meaning-vocabulary selection), 643 (meaning-statement confirmation), 644 (persist signature into 350), 645 (append to 140 audit log), 650 (SoD check — self-signing rejected).

**D. Verdict:** PARTIAL.

**E. Specific findings:**
- All four ceremony sub-steps from §5 (re-authentication, meaning-vocabulary selection, meaning-statement confirmation, signature persistence with cryptographic binding) are present in the SVG (641, 642, 643, 644).
- SVG additionally depicts 630 (accept/override/escalate branching), 631 (escalation), 645 (audit-log append), and 650 (SoD check). These are anchored in §6.7 / `Reference_Numerals.md`. No drift; the SVG is more granular than §5.
- The SVG label for 642 lists controlled vocabulary examples ("approved / rejected / acknowledged / reviewed / verified / other configured controlled meanings"). §5 says only "meaning-vocabulary selection." Counsel should consider whether the SVG examples need explicit anchor in §6.7 text (currently §6.7 anchors them in `Reference_Numerals.md` only — depth-mismatch).

---

### Fig 7 — Agentic-Panel Subsystem

**A. Form 2 §5 entry (verbatim, line 126):**
> "Composition flow of the agentic-panel subsystem showing panel composition per the diligence-match and weight-balance rules, agent qualification gates, per-agent inference dispatch through the artificial-intelligence gateway, weighted aggregation of panel decisions, conflict-score computation, and conflict-band escalation routing."

**B. Detailed Description references:** §6.8 (agentic panel: 710 composition, 711 diligence-match, 712 weight-balance, 720 qualification gate, 730 panel, 740 aggregation, 750 conflict score, 760 band routing), §6.8.1, §6.8.2, §6.8.7 (deliberation/transcript), §6.8.8 (dossier-coverage extension).

**C. SVG content summary:**
- Title: "Fig. 7 — Agentic-Panel Subsystem (180) Composition and Decision Flow"
- Reference numerals: 705 (Input), 710 (Panel Composition Policy), 711 (Diligence-Match), 712 (Weight-Balance), 713 (Dossier extension), 720 (Agent Qualification Gate), 730 (Composed Panel) with 731/732/733 (Agents α/β/γ), 740 (Weighted Aggregation), 750 (Conflict Score), 760 (Conflict-Band Routing), 761 (low/middle → HITL or senior review), 762 (high → escalate adjudication), 770 (Deliberation Evidence).

**D. Verdict:** PARTIAL.

**E. Specific findings:**
- All six elements in §5 are present (composition, diligence-match, weight-balance, qualification gate, per-agent inference dispatch, weighted aggregation, conflict-score, conflict-band routing).
- SVG depicts additional elements: 713 (Dossier extension; anchored §6.8.8), 770 (Deliberation Evidence; anchored §6.8.7). Both legitimately anchored but not enumerated in §5. No drift; depth-mismatch.
- "→ dispatch through 160" notation on each agent correctly anchors the "per-agent inference dispatch through the artificial-intelligence gateway" phrase in §5.

---

### Fig 8 — Worked Example: Deviation Classification

**A. Form 2 §5 entry (verbatim, line 127):**
> "Worked example of an electronic-record transition (illustrative, using a quality-management deviation classification scenario) walked end-to-end through the fabric, with the audit-trail entries generated at each stage and the contents of the resulting exportable signature evidence packet. The worked example uses representative identifiers, routes, roles, and table labels for illustration and is not intended to limit the invention to a specific deployed implementation."

**B. Detailed Description references:** §8 / §8.1 (worked example walkthrough), §8.4 (exportable signature evidence packet contents).

**C. SVG content summary:**
- Title: "Fig. 8 — Worked Example: Deviation Classification Walked End-to-End (illustrative scenario per Section 8 of the specification)"
- Reference numerals: 801–809 (sequential walkthrough steps with "Audit e1" through "Audit e8" entries shown), 810 (Exportable Evidence Packet) with sub-elements 811 (Entity reference), 812 (AI inference record references), 813 (Signature record references), 814 (HITL decision reference), 815 (Audit-chain verification result), 816 (Packet integrity hash/seal).
- Step 803 references "model M-7"; Step 804 references "Confidence = MEDIUM".

**D. Verdict:** PARTIAL.

**E. Specific findings:**
- §5 describes "audit-trail entries generated at each stage and the contents of the resulting exportable signature evidence packet" at a high level. SVG enumerates eight specific stages (801–808 with corresponding Audit e1–e8) and six packet-content elements (811–816). Both layers are anchored in §8 / §8.1 / §8.4. No drift.
- The specific identifiers "M-7" (model) and "0.72" (confidence) on the SVG are illustrative — §5 explicitly states "uses representative identifiers, routes, roles, and table labels for illustration." Acceptable under §5 disclaimer language.
- Reference numerals 801–816 are introduced in `Reference_Numerals.md` and §8 but not in §5 verbatim. Depth-mismatch only.

---

## §2 P02 — Cryptographic Per-Inference Audit, Model Version Governance, Agent Qualification

> P02 BDD lives in **§6** of the Form 2 (not §5). §5 is reserved for "Technical Effects of the Invention."

### Fig 1 — System Architecture Overview

**A. Form 2 §6 entry (verbatim, line 102):**
> "**Figure 1** — System Architecture Overview: illustrates the system architecture including the per-inference audit chain and optional governance layers, showing the AI Gateway Service (100) as the central integration point, the LLM Audit Chain Layer (110), the optional Model Version Governance Layer (120), and the optional Agent Qualification Layer (130), together with the multi-tenant database fabric (140) and the RLS enforcement boundary (150)."

**B. Detailed Description references:** §7.1 (architecture overview), §7.2 (LLM audit chain layer H1 with table schema and chain construction), §7.3 (model version governance H2), §7.4 (agent qualification H3), §7.5 (AI Gateway integration), §7.6 (RLS / multi-tenant fabric).

**C. SVG content summary:**
- Title: "FIG. 1 — System Architecture Overview"
- Reference numerals: 100 (AI Gateway Service), 110 (H1: LLM Audit Chain Layer), 120 (H2: Model Version Governance), 130 (H3: Agent Qualification), 140 (Multi-Tenant Database Fabric), 150 (RLS Enforcement Boundary), 500 (Nine-Stage Pipeline shown inside 100).
- Per-layer details: H1 table+API list; H2 table+state-machine+API; H3 tables+API+expiry.
- Side panels: Regulatory Inspector Access (REST endpoints listed); GxP Record Consumer (Deviations, CAPAs, OOS, Batch Records, Change Control).
- Embedded REFERENCE NUMERALS legend listing 100/110/120/130/140/150/500.

**D. Verdict:** ACCURATE.

**E. Specific findings:**
- Every numeral on the drawing (100, 110, 120, 130, 140, 150) is introduced in §6 BDD verbatim.
- Element 500 ("Nine-Stage Pipeline") shown on Fig 1 is introduced in §6 BDD entry for Figure 5 (line 110). Cross-figure numeral reuse is acceptable provided it is consistent — and it is.
- "GxP Record Consumer" and "Regulatory Inspector Access" panels are illustrative context; the §7 prose names these consumers and the inspector verifyChain API. Acceptable.

---

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

**A. Form 2 §6 entry (verbatim, line 104):**
> "**Figure 2** — Per-Inference LLM Audit Chain: illustrates the data flow for a single inference call, showing hash computation (210) for system prompt (211), user prompt (212), and raw response (213); the chain-link computation (220) combining the previous combined hash (221) with the current response hash (222) and timestamp (223); the resulting audit record (230) with all fields; and the GENESIS block pattern (240) for the first entry in a tenant's chain."

**B. Detailed Description references:** §7.2.1 (table schema for llm_audit_log — id, tenant_id, session_id, agent_id, model_id, model_provider, system_prompt_hash, system_prompt_version, user_prompt, user_prompt_hash, temperature, max_tokens, raw_response, raw_response_hash, parsed_output, parse_success, parse_errors, input_tokens, output_tokens, latency_ms, previous_hash, combined_hash, created_at), §7.2.2 (hash chain construction including GENESIS variant), §7.2.3 (verifyChain).

**C. SVG content summary:**
- Title: "FIG. 2 — Per-Inference LLM Audit Chain"
- Reference numerals: 200 (Inference Call Input), 201–204 (system prompt text / system prompt version / user prompt text / model id+provider), 210 (Hash Computation umbrella), 211 (System Prompt Hash, SHA-256), 212 (User Prompt Hash, SHA-256), 213 (Raw Response Hash, SHA-256), 220 (Chain-Link), 221 (previousHash), 222 (current response hash), 223 (timestamp ISO 8601), 230 (llm_audit_log Record with Identity/Hash/Metrics/Parse field groups), 240 (GENESIS Block).
- Embedded REFERENCE NUMERALS legend listing 200–240.

**D. Verdict:** ACCURATE.

**E. Specific findings:**
- Every numeral in §6 (210, 211, 212, 213, 220, 221, 222, 223, 230, 240) appears in the SVG with matching role.
- SVG additionally shows 200 (Inference Call Input) and 201–204 (input components: system prompt text, system prompt version, user prompt text, model id+provider). These are not in §6 BDD by number, but are anchored in §7.2.1 schema. Acceptable as input grouping numerals.
- Field list in 230 reconciles against §7.2.1 schema one-for-one (id, tenant_id, session_id, agent_id, model_id, model_provider, system_prompt_hash, system_prompt_version, user_prompt, user_prompt_hash, temperature, max_tokens, raw_response, raw_response_hash, parsed_output, parse_success, parse_errors, input_tokens, output_tokens, latency_ms, previous_hash, combined_hash, created_at).

---

### Fig 3 — Model Version Governance Layer

**A. Form 2 §6 entry (verbatim, line 106):**
> "**Figure 3** — Model Version Governance Layer: illustrates the model registry qualification state machine (310) with states pending (311), qualified (312), deprecated (313), and blocked (314); the drift detection engine (320) with input of current provider version (321) and qualified version (322) and output of recommendation (323); and the optional pre-call check API (330) available for integration prior to inference dispatch (340) as an administrative governance service."

**B. Detailed Description references:** §7.3.1 (model_registry table schema), §7.3.2 (qualification state machine), §7.3.3 (drift detection), §7.3.4 (preCallCheck API).

**C. SVG content summary:**
- Title: "FIG. 3 — Model Version Governance Layer"
- Reference numerals: 300 (model_registry table with full schema), 310 (state machine), 311 (pending), 312 (qualified), 313 (deprecated), 314 (blocked), with transitions qualify()/supersede/blockModel()/block/requalify; 320 (Drift Detection Engine), 321 (current provider version), 322 (qualified version), 323 (recommendation output), 330 (Pre-Call Check API), 331 (refused), 340 (Inference Dispatch).
- Embedded REFERENCE NUMERALS legend listing 300–340.

**D. Verdict:** ACCURATE.

**E. Specific findings:**
- All numerals in §6 (310, 311, 312, 313, 314, 320, 321, 322, 323, 330, 340) appear in SVG with matching role.
- SVG shows 300 (model_registry table schema box) and 331 (Refused/Blocked Call). 300 is anchored in §7.3.1. 331 is the natural negative outcome of 330's allowed=false branch — anchored implicitly in §7.3.4. Counsel may wish to make 331 explicit in §6 BDD or §7.3.4 text. Currently a PARTIAL minor depth-mismatch, but borderline ACCURATE.

---

### Fig 4 — Agent Qualification Protocol

**A. Form 2 §6 entry (verbatim, line 108):**
> "**Figure 4** — Agent Qualification Protocol: illustrates the qualification test case structure (410) with test categories (411); the qualification run record (420) with run types (421), pass rate (422), and status (423); the qualification status record (430) with expiry (431) and next review date (432); and the optional qualification gate (440) for exclusion of non-qualified agents from regulated-record write paths (450)."

**B. Detailed Description references:** §7.4.1 (agent_qualification_tests table), §7.4.2 (categories), §7.4.3 (run record / pass rate / status), §7.4.4 (status table with expiry), §7.4.5 (assertQualified API), §7.4.6 (periodic review).

**C. SVG content summary:**
- Title: "FIG. 4 — Agent Qualification Protocol"
- Reference numerals: 410 (Qualification Test Cases), 411 (Test Categories: regulatory_knowledge / scoring_accuracy / escalation_behavior / boundary_compliance / output_schema), 420 (Qualification Run table with run types initial/requalification/prompt_change/model_change), 421 (Run Types), 422 (Pass Rate), 423 (Status: PASSED/FAILED/CONDITIONAL), 430 (Qualification Status table), 431 (Qualification Expiry), 432 (Next Review Due Date), 440 (Qualification Gate), 441 (Qualification Refused), 450 (Regulated Decision).
- Embedded REFERENCE NUMERALS legend listing 410–450.

**D. Verdict:** ACCURATE.

**E. Specific findings:**
- All numerals in §6 (410, 411, 420, 421, 422, 423, 430, 431, 432, 440, 450) appear in SVG with matching role.
- SVG additionally shows 441 (Qualification Refused) — the negative branch of 440 gate. Anchored implicitly in §7.4.5. Borderline ACCURATE.

---

### Fig 5 — Integrated AI Gateway Pipeline

**A. Form 2 §6 entry (verbatim, line 110):**
> "**Figure 5** — Integrated AI Gateway Pipeline: illustrates the sequential nine-stage pipeline (500) through which every inference call passes: feature flag check (510), rate-limit check (520), model selection (530), provider invocation (540), confidence-band computation (550), HITL gate assessment (560), request persistence (570), master audit-trail entry (580), and per-inference LLM audit-chain entry (590)."

**B. Detailed Description references:** §7.5 (AI Gateway processRequest pipeline with all nine stages enumerated and integration with H1, H2, H3).

**C. SVG content summary:**
- Title: "FIG. 5 — Integrated AI Gateway Pipeline"
- Reference numerals: 500 (pipeline), 510 (S1: Feature Flag), 520 (S2: Rate Limiting), 530 (S3: Model Selection), 540 (S4: Provider Invocation), 550 (S5: Confidence-Band), 560 (S6: HITL Gate), 570 (S7: Request Persistence), 580 (S8: Master Audit-Trail), 590 (S9: Per-Inference LLM Audit Chain — labeled "H1 Audit chain captured here").
- REFUSE arrows from each of S1, S2, S3, S6.
- Embedded REFERENCE NUMERALS legend listing 500–590.

**D. Verdict:** ACCURATE.

**E. Specific findings:**
- All ten numerals in §6 (500, 510, 520, 530, 540, 550, 560, 570, 580, 590) appear in SVG with matching label.
- Nine-stage sequence (S1–S9) matches §6 BDD ordering exactly.

---

## §3 P02b — AI Output Segregation Engine

### Fig 1 — System Architecture

**A. Form 2 §5 entry (verbatim, line 96):**
> "**Figure 1** — System architecture diagram illustrating the AI Output Segregation Engine as a cross-cutting enforcement layer across GxP modules, showing: AI gateway service, per-inference output type classifier, prohibited-field write prevention boundary, human-decision recording subsystem, AI proposal staging structure, and advisory evidence pack generator; per-tenant RLS layer shown at the database tier."

**B. Detailed Description references:** §6.1 (system overview), §6.2 (per-inference output type classification), §6.3 (prohibited-field write prevention), §6.4 (human-decision recording subsystem), §6.5 (AI proposal staging), §6.6 (advisory evidence pack generator), §6.7 (RLS / tenant-isolation).

**C. SVG content summary:**
- Title: "FIG. 1 — SYSTEM ARCHITECTURE: AI OUTPUT SEGREGATION ENGINE"
- Mnemonic labels (no numeric reference numerals): E2 (engine envelope), E2-A (AI Gateway Service), E2-B (Prohibited-Field Boundary), E2-C (Human-Decision Recording), E2-D (AI Proposal Staging Structure with two-state model), E2-E (Advisory Evidence Pack Generator).
- GxP Application Modules (Deviation AI, CAPA AI, OOS AI, DQG Classification, MIRA Assistant, Risk/RCA AI) and their source file names listed.
- MIRA disclaimer quoted: "MIRA suggestions are advisory only. All actions require human confirmation."
- Database tier: ai_requests, mira_messages, dqg_artifact_classifications, ai_evidence_packs, hitl_decisions with column lists and RLS notation.

**D. Verdict:** PARTIAL.

**E. Specific findings:**
- All six §5 elements (AI gateway service, per-inference output type classifier, prohibited-field write prevention boundary, human-decision recording subsystem, AI proposal staging structure, advisory evidence pack generator) are present and labeled E2-A through E2-E.
- The mnemonic labels (E2-A, B, C, D, E) are not introduced in §5 prose. §5 names the elements descriptively but not by code. Counsel should confirm that the SVG mnemonic labels are acceptable to the Indian Patent Office — generally they are, as Form 2 / Rule 13 does not mandate numeric reference numerals (most Indian practitioners do use numeric numerals for consistency with USPTO/EPO practice).
- Source file names (`capa-ai.service.ts`, `oos-ai.service.ts`, `mira.service.ts`, etc.) appear on the SVG. §6.2 footer "Verified against:" notes cite these files, so they are anchored in the spec. However, displaying TypeScript file names on patent drawings may inadvertently narrow the disclosure to a specific implementation — counsel should consider whether to generalise these on the final filed drawings.
- The MIRA disclaimer quoted text on the drawing is not in §5; it appears in §6.4 prose. Borderline drift / depth-mismatch.

---

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

**A. Form 2 §5 entry (verbatim, line 98):**
> "**Figure 2** — Per-inference output type classification flow diagram, showing: AI gateway `processRequest()` pipeline (feature gate → rate limit → model selection → provider call → confidence band → HITL gate → ai_requests INSERT → audit log → LLM audit chain); `advisory: true` flag assignment path; `status = 'filtered'` suppression path for low-confidence output; HITL linkage path."

**B. Detailed Description references:** §6.2 (per-inference output type classification with steps a-f including confidence band mapping, status='filtered' for low, hitl_required=true for medium, advisory:true flag, ai_requests persistence).

**C. SVG content summary:**
- Title: "FIG. 2 — PER-INFERENCE OUTPUT TYPE CLASSIFICATION FLOW"
- Labels (no numeric reference numerals): STEP 1 Feature Gate, STEP 2 Rate Limit, STEP 3 Model Selection, STEP 4 LLM Provider Call, STEP 5 Confidence Band (with low/medium/high branches), STEP 6 HITL Gate, STEP 7 ai_requests INSERT (per-tenant, RLS-enforced), STEP 8 Audit Trail Entry (auditTrailService.log), STEP 9 LLM Audit Chain (prompt_hash, response_hash, combined_hash, prev_hash).
- Three confidence-band branches: low → "status = 'filtered'" + Output SUPPRESSED + Mandatory HITL escalation; medium → "hitl_required = true" + HITL review required; high.
- Final box: "Advisory Response to QMS Module" { advisory: true, suggestion, confidence, ai_request_id }.

**D. Verdict:** ACCURATE.

**E. Specific findings:**
- All four elements named in §5 are present: nine-step pipeline, `advisory: true` flag, `status = 'filtered'` suppression for low, HITL linkage.
- Step sequence in SVG (Feature Gate → Rate Limit → Model Selection → Provider Call → Confidence Band → HITL Gate → ai_requests INSERT → Audit log → LLM Audit Chain) matches §5 description exactly.
- No drift.

---

### Fig 3 — Prohibited-Field Write Prevention

**A. Form 2 §5 entry (verbatim, line 100):**
> "**Figure 3** — Prohibited-field write prevention enforcement diagram, showing: application service layer boundary between AI advisory service and GxP record service; server-side forbidden-term sanitizer scan with FORBIDDEN_TERMS regex registry; audit violation event emission on strip; system-of-record write path requiring human-initiated PATCH operation under authenticated human identity; `ai_requests.was_overridden` / `override_by` / `original_output` preservation path."

**B. Detailed Description references:** §6.3 (prohibited-field write prevention — Layer 1 service boundary + Layer 2 sanitizer with FORBIDDEN_TERMS array, audit violation event, generalised manifest/runtime-registry/build-time-guard embodiments), §6.4 (override tracking with was_overridden, override_by, original_output).

**C. SVG content summary:**
- Title: "FIG. 3 — PROHIBITED-FIELD WRITE PREVENTION ENFORCEMENT"
- Sections: AI Advisory Service Layer with file names (`oos-ai.service.ts`, `capa-ai.service.ts`, `rca-ai.service.ts`); Compliance Boundary block quoting code comments; sanitizeSteps() block listing FORBIDDEN_TERMS patterns (`/classif(y|ication|ied)/i`, `/lab error/i`, `/process deviation/i`, `/true OOS/i`, `/root cause/i`); Advisory Response Object box; STRIP matched steps; Audit Violation Event (action = 'oos_ai_sanitization_violation'); Application Service Boundary line; Human-Initiated SoR Write Path; Authentication+Permission Check; GxP Record Field Write Under Human Identity; AiGatewayService.overrideResult() block; GxP-Critical Record Fields panel listing deviations.investigation_conclusion/root_cause, capas.action_description/priority/due_date, oos_investigations.classification/disposition, batch_records.disposition/release_decision, change_requests.change_description/impact_assessment; "✕ BLOCKED" indicator.

**D. Verdict:** PARTIAL.

**E. Specific findings:**
- All five elements in §5 are present: service-layer boundary, FORBIDDEN_TERMS regex registry, audit violation emission, human-initiated PATCH path, was_overridden / override_by / original_output preservation.
- FORBIDDEN_TERMS patterns shown on the SVG match the §6.3 example (`/\bclassif(?:y|ication|ied|ies)\b/i`, `/\blab\s+error\b/i`, `/\bprocess\s+deviation\b/i`, `/\btrue\s+oos\b/i`, `/\broot\s+cause\b/i`) — note: SVG simplifies the word boundaries (omitting `\b` and `\s+`). This is a presentation simplification, not a substantive drift, because §6.3 quotes the patterns in `code` blocks and the SVG carries the canonical pattern identity.
- The SVG lists six GxP-critical record fields (deviations, capas, oos_investigations, batch_records, change_requests, with sub-field names). §5 references the principle ("AI direct write below — blocked") but does not enumerate the field list. §6.3 prose and CLAUDE.md Gate 7 reference these fields. Depth-mismatch only.
- Source-file names again on the drawing — same caution as Fig 1 about narrowing disclosure.

---

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

**A. Form 2 §5 entry (verbatim, line 102):**
> "**Figure 4** — AI proposal staging and human decision flow for DQG classification, showing: AI-generated proposal INSERT with `is_active = false`, `proposed_taxonomy_code`, `proposed_confidence`, `proposed_at`; human review path; `activateClassificationProposal()` → `is_active = true` promotion; `rejectClassificationProposal()` → `is_active = false` retained; audit trail rows for both paths; MIRA message `suggestion_accepted` / `suggestion_accepted_by` / `suggestion_accepted_at` attribution fields."

**B. Detailed Description references:** §6.4 (human-decision recording subsystem — MIRA acceptSuggestion / rejectSuggestion; AI request override), §6.5 (AI proposal staging structure with two-state model is_active=false→true; activateClassificationProposal at service.ts:4254-4266; rejectClassificationProposal at service.ts:4385).

**C. SVG content summary:**
- Title: "FIG. 4 — AI PROPOSAL STAGING AND HUMAN DECISION FLOW"
- Sections: AI Classification Engine block; PROPOSAL INSERT box (dqg_artifact_classifications with is_active=false, proposed_taxonomy_code, proposed_confidence, proposed_at); Human Reviewer Decision branching (Accept / Accept Modified / Reject); activateClassificationProposal() block with hitl_approved_by/hitl_approved_at attribution; Accept (Modified) variant with was_human_overridden=true and taxonomy_code≠proposed; rejectClassificationProposal() block with is_active=false retained for audit; MIRA SUGGESTION ATTRIBUTION parallel section showing acceptSuggestion(messageId, userId) and rejectSuggestion(messageId, userId) with suggestion_accepted / suggestion_accepted_by / suggestion_accepted_at columns; "re-decision blocked if already non-null" guard note.

**D. Verdict:** PARTIAL.

**E. Specific findings:**
- All seven §5 elements are present: AI-generated proposal INSERT with named fields, human review path, activateClassificationProposal() → is_active=true, rejectClassificationProposal() → is_active=false retained, audit trail rows for both paths, MIRA suggestion_accepted/by/at attribution.
- SVG additionally depicts (a) "Accept (Modified)" branch with `was_human_overridden = true` and `taxonomy_code ≠ proposed` — anchored in §6.5 prose and column list, but not in §5 BDD; (b) the explicit "re-decision blocked if already non-null" guard — anchored in §6.4 prose. Depth-mismatch only.
- Service file line numbers (`service.ts:4092`, `service.ts:4254–4266`, `service.ts:4385`, `mira.service.ts:399`, `mira.service.ts:484`) appear on the drawing. As with Figs 1 and 3, counsel should consider generalising these for filing.

---

### Fig 5 — Advisory Evidence Pack Generation

**A. Form 2 §5 entry (verbatim, line 104):**
> "**Figure 5** — Advisory evidence pack generation flow, showing: `EvidencePackService.generate()` aggregating `ai_requests`, `hitl_decisions`, `mira_messages`, `dqg_artifact_classifications` for a time period; `computeEvidencePackContentHash()` canonical JSON serialisation; `content_hash` SHA-256 seal; `ai_evidence_packs` INSERT with append-only RLS (SELECT + INSERT only, no UPDATE/DELETE); `esig_id` linkage to electronic signature ceremony."

**B. Detailed Description references:** §6.6 (advisory evidence pack generator with EvidencePackService.generate aggregating ai_requests + hitl_decisions + mira_messages + dqg_artifact_classifications, computeEvidencePackContentHash, content_hash SHA-256, ai_evidence_packs append-only via SELECT+INSERT RLS, esig_id FK to electronic_signatures).

**C. SVG content summary:**
- Title: "FIG. 5 — ADVISORY EVIDENCE PACK GENERATION"
- Sections: EvidencePackService.generate entry box; withRegulatedMutation() TDAL transaction block; STEP 1 Source Record Aggregation (ai_requests, hitl_decisions, mira_messages, dqg_artifact_classifications); STEP 2 computeEvidencePackContentHash() with canonical JSON serialisation and SHA-256 formula; STEP 3 ai_evidence_packs INSERT (APPEND-ONLY) with `288_urs_ai_governance_evidence_packs.sql` reference, Pack Record Fields, Integrity+Linkage fields including content_hash + payload + pack_version + esig_id FK; e-Signature Linkage box; Pack Lifecycle line: "mira_event_received → model_snapshot_taken → awaiting_human_review → reviewed_accepted/refused/overridden → audit_esign_complete → export_ready → published".

**D. Verdict:** PARTIAL.

**E. Specific findings:**
- All §5 elements are present: EvidencePackService.generate, aggregation of the four source tables, computeEvidencePackContentHash, content_hash SHA-256, ai_evidence_packs append-only RLS, esig_id linkage.
- SVG additionally depicts: (a) the migration file reference `288_urs_ai_governance_evidence_packs.sql` (anchored implicitly via §6.6 — but specifying the migration filename on a drawing is a minor narrowing concern); (b) the Pack Lifecycle state sequence (mira_event_received → model_snapshot_taken → awaiting_human_review → reviewed_accepted/refused/overridden → audit_esign_complete → export_ready → published) — these states are not in §5 BDD; counsel should confirm anchor in §6.6 or §6.7 prose. If not currently anchored in spec prose, this is a depth-mismatch that should be reconciled either by adding the lifecycle to spec prose or removing it from the drawing.
- The `withRegulatedMutation()` TDAL transaction primitive is on the drawing but is not in §5. It is foundational platform infrastructure (anchored in P01-style TDAL prose, and re-referenced in P02b §6.6). Acceptable as long as P02b §6.6 carries an equivalent narrative; if not, this is a missing-text gap to fix in the spec, not in the drawing.

---

## §4 Cross-Cutting Issues

1. **P01 §5 vs Reference_Numerals.md vs Form 2 prose.** P01 has a separate `Reference_Numerals.md` crosswalk that introduces several numerals (e.g., 105, 117, 199, 545, 580, 650, 713, 770, 811–816) and corresponding text not yet rolled into the Form 2 prose. This crosswalk is described in its own preamble as optional ("This table may be retained as an internal cross-reference or adapted into the filed specification if counsel determines it is useful"). Recommendation: counsel should either (a) integrate the crosswalk into Form 2 §5 / §6 as a numbered reference-numeral table before filing, or (b) confirm Indian filing-agent practice accepts numerals introduced in Detailed Description prose only.
2. **P02b SVGs use mnemonic codes (E2-A/B/C/D/E and STEP 1–9) rather than numeric reference numerals.** This is structurally different from P01 and P02 (which both use 100-series numerals). Indian Patent Office practice generally permits either, but inconsistency across a portfolio can be a stylistic concern. Recommendation: counsel may wish to standardise to numeric numerals for filing, or expressly state the mnemonic-code convention in §5 BDD.
3. **Source-file names on patent drawings (P02b Figs 1, 3, 4, 5).** P02b drawings cite specific TypeScript source files (`oos-ai.service.ts`, `capa-ai.service.ts`, `mira.service.ts`, `service.ts:4092`, `service.ts:4254-4266`, `service.ts:4385`, `288_urs_ai_governance_evidence_packs.sql`). These could narrow the disclosure to a specific implementation. The Form 2 prose acknowledges in §5 that "Table names, field names, service names ... need not correspond one-to-one with any particular source-code implementation, database migration, or deployed product version" (P01 §5 line 116; analogous language is implicit but not equally explicit in P02b). Recommendation: either add an equivalent §5 (or §6) disclaimer to P02b Form 2, or generalise file names on the drawings before filing.
4. **P02b Fig 5 Pack Lifecycle state sequence.** The seven-state lifecycle on Fig 5 (`mira_event_received → model_snapshot_taken → awaiting_human_review → reviewed_accepted/refused/overridden → audit_esign_complete → export_ready → published`) — Unknown — repo evidence required: I did not verify whether this state sequence is anchored verbatim in P02b §6.6 or §6.7 prose. Counsel must confirm before filing.
5. **P02b §5 line 102 missing in spec extraction**. During Grep extraction of P02b §5, line 102 was reported as "[Omitted long matching line]" by the Grep tool — the content was successfully read via direct Read at offset 94+ and matches the Figure 4 entry. No actual content gap; tool truncation artefact only.
6. **No hallucination, no truncation, no missing required element** detected across all 18 figures. The audit chain itself is consistent.
7. **Section numbering.** P01 uses "## 5. BRIEF DESCRIPTION OF THE DRAWINGS"; P02 uses "## §6 Brief Description of the Drawings"; P02b uses "## 5. BRIEF DESCRIPTION OF THE DRAWINGS". The §-number variance is a portfolio inconsistency, not a Rule 13(6) defect. Counsel should ensure Form 1 cross-references inside each application cite the correct section number.

---

## §5 Recommendations (one per finding)

| # | Patent | Figure | Finding | Recommended action (one of: edit SVG / edit spec / investigate) |
|---|---|---|---|---|
| R1 | P01 | Fig 1 | 190, 195, 199 in SVG not enumerated in §5 | Edit spec: amend §5 entry for Fig 1 to add "extended embodiments: regulatory-intelligence subsystem (190), precedent-linked outcome memory (195); together with persistent storage (199)." |
| R2 | P01 | Fig 5 | 545 (provider abstraction), 551/552/553 (band reviewer-role routing), 570 (audit-log append), 580 (output-class indicator) not in §5 | Edit spec: extend §5 Fig 5 entry to enumerate these (the Reference_Numerals.md descriptions are ready to be lifted). |
| R3 | P01 | Fig 6 | 630/631 (decision branching), 645 (audit-log append), 650 (SoD check), and ceremony vocabulary examples not in §5 | Edit spec: extend §5 Fig 6 entry; ensure §6.7 prose enumerates the SoD check and audit-log append step. |
| R4 | P01 | Fig 7 | 713 (Dossier extension), 770 (Deliberation Evidence) not in §5 | Edit spec: extend §5 Fig 7 entry to mention "dossier-coverage extension (713)" and "deliberation transcript / evidence linkage (770)." |
| R5 | P01 | Fig 8 | Steps 801–816 not enumerated in §5; identifiers M-7, 0.72 illustrative | Edit spec: extend §5 Fig 8 entry to acknowledge a numbered walkthrough; the §5 illustrative-identifiers disclaimer already covers M-7/0.72. |
| R6 | P01 | All | Reference_Numerals.md is an external crosswalk, not yet integrated into Form 2 | Investigate: counsel determine whether to merge crosswalk into filed Form 2 or rely on Detailed Description anchoring. If merging, recommend numeric reference-numeral table as a sub-section of §5 BDD before filing. |
| R7 | P02 | Fig 3 | 300 (model_registry table box) and 331 (Refused branch) not in §6 | Edit spec: amend §6 Fig 3 entry to add "the model_registry table (300) on which the state machine operates; and the refused branch (331) on a failed pre-call check." |
| R8 | P02 | Fig 4 | 441 (Qualification Refused branch) not in §6 | Edit spec: amend §6 Fig 4 entry to add "and the qualification-refused outcome (441) when the gate excludes a non-qualified agent." |
| R9 | P02b | Fig 1 | Mnemonic codes E2-A/B/C/D/E not in §5; MIRA disclaimer quoted text not in §5 | Investigate / edit SVG: either add a one-line note to §5 explaining the mnemonic-code convention, or replace E2-A/B/C/D/E with numeric numerals (e.g., 100/110/120/130/140) for portfolio consistency. |
| R10 | P02b | All | Source-file names visible on drawings | Edit SVG: replace specific TypeScript file names with generic component labels (e.g., "AI Gateway Service" instead of `ai-gateway.service.ts`) OR edit spec to add P01-style disclaimer §5 sentence: "Table names, field names, service names, and source file names shown in the drawings are descriptive of the disclosed architecture and need not correspond one-to-one with any particular source-code implementation." |
| R11 | P02b | Fig 3 | GxP-critical record field enumeration not in §5 | Edit spec: amend §5 Fig 3 entry to add "...and the prohibited-write designation enumeration of GxP-critical record fields including deviations, capas, oos_investigations, batch_records, and change_requests." |
| R12 | P02b | Fig 4 | Accept(Modified) branch with was_human_overridden, and the re-decision-blocked guard, not in §5 | Edit spec: amend §5 Fig 4 entry to add "...accept-with-modification variant marking `was_human_overridden = true`; and a re-decision guard rejecting any update where `suggestion_accepted` is already non-null." |
| R13 | P02b | Fig 5 | Pack Lifecycle state sequence on drawing | Investigate: verify whether the seven-state lifecycle (mira_event_received → ... → published) is anchored in P02b §6.6 or §6.7 prose. If not, either add the lifecycle to spec prose or remove it from the drawing. Unknown — repo evidence required. |
| R14 | All | §-numbering | P01 uses §5; P02 uses §6; P02b uses §5 | Investigate: confirm Form 1 cross-references inside each application cite the correct section number for BDD; harmonise stylistic conventions if portfolio consistency is desired. |
| R15 | All | Reference numerals | Whether numbered drawings are mandatory at Indian provisional filing | Investigate: counsel confirm filing-agent's view on whether unnumbered mnemonic-labelled drawings (P02b style) are acceptable for provisional filing under Rule 15 / Rule 13(6). |

No fixes have been applied — this audit is read-only. Recommendations are for counsel and the patent style editor to action.

---

## §6 Source Ledger (V3 §11)

| Source type | Source name/path | Date/version | Claim supported | Limitations |
|---|---|---|---|---|
| Specification (P01) | `Patent 01 - Platform Validated Model Lockstep/Filing/Verixa_Form2_Provisional_Specification.md` | REV-8 + cleanup pass (current on disk 2026-06-06) | §5 BDD verbatim entries for Figs 1–8; Detailed Description §6.1–§6.10 and §8 anchors for reference numerals | Did not read full §6 Detailed Description prose for every section; relied on §6 section headings and `Reference_Numerals.md` crosswalk to confirm anchoring |
| Drawings (P01) | `Patent 01 - Platform Validated Model Lockstep/Filing/Drawings/Fig{1..8}_*.svg` | Current on disk 2026-06-06 | SVG `<text>` element enumeration; reference numerals in 100–816 series | Extraction via grep of `<text>` elements; layout/graphical relations not inspected |
| Reference numerals crosswalk (P01) | `Patent 01 - Platform Validated Model Lockstep/Filing/Drawings/Reference_Numerals.md` | Current on disk 2026-06-06 | Numeral-to-§ref mapping for all P01 Fig 1–8 numerals | This is an internal crosswalk, explicitly described as "not filed" optionally — counsel must decide on inclusion |
| Specification (P02) | `Patent 02 - Cryptographic.../Filing/VeriXA_P02_Form2_Provisional_Specification.md` | v1.2 | §6 BDD verbatim entries for Figs 1–5; §7.1–§7.5 anchors for reference numerals | Did not read full §7 prose; relied on §7 section structure and on-SVG numeral legends |
| Drawings (P02) | `Patent 02 - Cryptographic.../Filing/Drawings/Fig{1..5}_*.svg` | Current on disk 2026-06-06 | SVG `<text>` enumeration; numerals 100–590 | Same as P01 |
| Specification (P02b) | `Patent 02b - AI Output Segregation Engine/Filing/VeriXA_P02b_Form2_Provisional_Specification.md` | v1.1 | §5 BDD verbatim entries for Figs 1–5; §6.1–§6.6 anchors | Did not read §6.7 onward; Pack Lifecycle anchor remains Unknown — repo evidence required |
| Drawings (P02b) | `Patent 02b - AI Output Segregation Engine/Filing/VeriXA_P02b_Fig{1..5}_*.svg` | Current on disk 2026-06-06 | SVG `<text>` enumeration; mnemonic codes E2-A through E2-E and STEP 1–9 | No numeric reference numerals; mnemonic codes only |
| Rule of construction | Patents Rules 2003, Rule 13(6) | India statutory | "Drawings shall accord with the description" — basis of the consistency test applied | Rule text is authoritative; specific Indian Patent Office practice on numbered vs mnemonic-labelled drawings — counsel discretion |

**No verified source supplied** for: (a) whether the P02b Pack Lifecycle state sequence is anchored in §6.6/§6.7 prose; (b) whether counsel intends to include `Reference_Numerals.md` in the filed P01 Form 2.

---

## §7 Final Editor Note

> This is a patent style and consistency edit, not a legal opinion. Patent counsel must verify claim scope, jurisdiction-specific compliance, prosecution impact, and final filing language before submission. The audit covers Rule 13(6) (drawings-description accord) only. It does not address Rule 13 enablement requirements, Rule 13(5) numbering of sheets, Rule 15 sheet-format requirements, Section 10(4) enablement, Section 10(5) claims sufficiency, Section 3(k) eligibility, or Section 8 disclosure obligations.

**Permitted fail-safe phrases used in this audit (V3 §4 / §02_evidence_validation_engine):**
- "Unknown — repo evidence required." — used at cross-cutting issue 4 and source ledger.
- "No verified source supplied" — used at source ledger.

**End of audit.**