# Drawing Quality Critical Audit — 18 Patent SVG Files

**Date:** 2026-06-06
**Auditor seat:** Aeonn Founder Doctrine (Vimal)
**Discipline phrase (binding):** *"no drift. no hallucination. no truncation. no assumption. no model degradation. surgical precise and accurate fixes only should be inspection grade output"*
**Scope:** All 18 SVG drawings across P01 (8 figs), P02 (5 figs), P02b (5 figs)
**Method:** Programmatic audit (Python + real Liberation Sans font metrics via PIL) + line-by-line manual verification of every flagged finding and every overlap/orphan candidate.
**Audit script:** `/sessions/keen-magical-mccarthy/mnt/outputs/drawing_quality_audit_v2.py`
**Raw script output:** `/sessions/keen-magical-mccarthy/mnt/outputs/drawing_quality_audit_raw.txt`

---

## 0. Algorithm Summary

Each SVG is parsed with full inheritance through `<g>` ancestors (text-anchor, font-size, font-weight). For each figure five checks run:

1. **CHECK 1 — Orphan arrows/lines.** Every `<line>`, `<path>`, `<polyline>` with a `marker-end` or `marker-start` is examined: both endpoints are tested against (a) the boundary of any non-viewport `<rect>`/`<circle>`/`<ellipse>`/`<polygon>` (allowed tolerance 8 px), (b) the endpoints/segments of any other line element (allowed tolerance 2 px endpoint match, 2 px on-segment match — covers multi-segment L-shaped routing wires and lifelines), and (c) text labels that lie AHEAD of the arrow tip in the arrow's direction of travel (allowed tolerance 12 px close, 30 px acceptable). Any endpoint that fails all three checks is flagged orphan.
2. **CHECK 2 — Text-inside-its-own-box.** For every `<text>`, the smallest enclosing non-viewport rect is found; the text bbox (computed with **real Liberation Sans glyph widths** via PIL, not 0.55× heuristic) is compared. Overflow >1.5 px on any side is flagged.
3. **CHECK 3 — Text-text overlap.** All pairwise text bboxes are compared with real font metrics.
4. **CHECK 4 — Reference numerals legend completeness.** Numerals used in body `(NNN)` are compared against the legend block.
5. **CHECK 5 — Manual visual review.** Every figure was read line-by-line in the source SVG to catch semantics-level issues the geometric scan cannot detect (FK arrow target mismatch, label-vs-target mismatch, dangling references).

False positives encountered and resolved during iteration:
- Width-by-0.55-of-font-size heuristic overstated text width by 20-30 %. Replaced with PIL `getlength()` on Liberation Sans (a metrics-compatible Arial substitute).
- A4 viewport background `<rect>` made every endpoint appear "inside a shape". Background rect now excluded.
- L-shaped routing wires (two `<line>` segments sharing an endpoint, only the second carries `marker-end`) were flagged as orphans on the markerless first segment's endpoint. The check now treats any segment whose endpoint touches another segment as joined.
- Lifelines in sequence diagrams (long dashed verticals) and chain-link "..." continuations were flagged as orphan tips because nothing follows them. The check now also treats arrow tips landing within 12 px of a text label that lies ahead of the tip as connected.

---

## 1. Final Severity Summary

| File | BLOCKING | NEEDS-FIX | NOTE | Verdict |
|---|---|---|---|---|
| P01_Fig1_Overall_Architecture.svg | 0 | 0 | 0 | **FILE-READY** |
| P01_Fig2_Pipeline_Sequence.svg | 0 | 0 | 0 | **FILE-READY** |
| P01_Fig3_Database_Schema.svg | 0 | 1 (manual) | 0 | **FIX BEFORE FILING** |
| P01_Fig4_HashChain_Audit_Log.svg | 0 | 0 | 2 | **FILE-READY (cosmetic notes only)** |
| P01_Fig5_AI_Gateway.svg | 0 | 0 | 0 | **FILE-READY** |
| P01_Fig6_HITL_Esignature_Ceremony.svg | 0 | 0 | 0 | **FILE-READY** |
| P01_Fig7_Agentic_Panel.svg | 0 | 0 | 0 | **FILE-READY** |
| P01_Fig8_Worked_Example.svg | 0 | 0 | 0 | **FILE-READY** |
| P02_Fig1_System_Architecture_Overview.svg | 0 | 0 | 0 | **FILE-READY** |
| P02_Fig2_Per_Inference_LLM_Audit_Chain.svg | 0 | 0 | 2 | **FIX BEFORE FILING (legend hygiene)** |
| P02_Fig3_Model_Version_Governance.svg | 0 | 0 | 0 | **FILE-READY** |
| **P02_Fig4_Agent_Qualification_Protocol.svg** | 0 | **1 (user-flagged)** | 0 | **FIX BEFORE FILING — orphan "updates" arrow** |
| P02_Fig5_Integrated_AI_Gateway_Pipeline.svg | 0 | 0 | 0 | **FILE-READY** |
| VeriXA_P02b_Fig1_System_Architecture.svg | 0 | 0 | 0 | **FILE-READY** |
| VeriXA_P02b_Fig2_PerInference_Classification_Flow.svg | 0 | 0 | 0 | **FILE-READY** |
| VeriXA_P02b_Fig3_Prohibited_Field_Write_Prevention.svg | 0 | 0 | 0 | **FILE-READY** |
| VeriXA_P02b_Fig4_Proposal_Staging_Human_Decision.svg | 0 | 0 | 0 | **FILE-READY** |
| VeriXA_P02b_Fig5_Evidence_Pack_Generation.svg | 0 | 0 | 0 | **FILE-READY** |
| **TOTALS** | **0** | **2** | **4** | **2 figs need surgical fixes; 16 file-ready** |

---

## 2. SPOTLIGHT — P02 Fig 4 "updates" Orphan Arrow (USER-FLAGGED)

**File:** `Patent 02 - Cryptographic Per-Inference Audit Model Version Governance and Agent Qualification/Filing/Drawings/Fig4_Agent_Qualification_Protocol.svg`

**Severity:** NEEDS-FIX (BLOCKING for inspection grade)

**Defect.** Source lines **42-43**:

```svg
<!-- Arrow from run down to status -->
<line x1="565" y1="265" x2="565" y2="318" stroke="black" stroke-width="1.5" marker-end="url(#arrow4)"/>
<text x="575" y="298" font-size="9">updates</text>
```

- Source point (565, 265) is on the BOTTOM edge of the **Qualification Run (420)** rect (`<rect x="415" y="80" width="300" height="185">` ⇒ spans (415-715, 80-265)). OK.
- Tip (565, 318) is intended to land on the **Qualification Status (430)** rect (`<rect x="247" y="320" width="300" height="140">` ⇒ spans (247-547, 320-460)).
- BUT the tip's x = **565** lies **18 px to the RIGHT** of the (430) rect's right edge at x=547. The arrow points into the EMPTY GUTTER between (430) and the right margin. The "updates" label hangs in the same gutter.

Measured by script: tip is **18.1 px** from nearest non-viewport shape; nearest text label in the tip's direction is **102.7 px** away (i.e., no nearby target text either).

**Surgical fix (single-line edit, preserves all other geometry).** Re-target the arrow so its tip lands on the top edge of the (430) box and keep the label adjacent:

| File line | Old | New |
|---|---|---|
| L42 | `<line x1="565" y1="265" x2="565" y2="318" stroke="black" stroke-width="1.5" marker-end="url(#arrow4)"/>` | `<line x1="565" y1="265" x2="520" y2="320" stroke="black" stroke-width="1.5" marker-end="url(#arrow4)"/>` |
| L43 | `<text x="575" y="298" font-size="9">updates</text>` | `<text x="555" y="295" font-size="9">updates</text>` |

Result: arrow now slants from (565, 265) at the (420) bottom to (520, 320) which is **exactly on the top edge of (430)** (520 ∈ [247, 547]; y=320 is the rect top). The `arrow4` marker has `refX="6"` so the visible arrowhead point lands one stroke-width inside the rect. The "updates" label sits above the arrow midpoint at (555, 295).

(Optional alternative — pure-vertical L-shaped wire that avoids any slant: replace L42 with a polyline `<polyline points="565,265 565,295 520,295 520,318" fill="none" stroke="black" stroke-width="1.5" marker-end="url(#arrow4)"/>` and keep the label at (530, 290). Same end state. Choose whichever style matches the rest of the figure's wire convention; the existing figure uses straight `<line>` elements, so the slant option above is the more consistent surgical change.)

**Note on user's "overlap issues" phrasing.** The audit did not find any geometric box-on-box overlap in P02 Fig 4. The user's visual perception of "overlap" is almost certainly caused by the orphan "updates" arrow hanging in the gutter alongside the **Regulated Decision (450)** box, which lives in that same right-hand column at (600-750, 510-570). Once the arrow is re-targeted as above, the gutter clears and the overlap-illusion resolves. If after the fix the user still reports overlap, the candidate next suspects are (a) the **Periodic Review** dashed rect (80-280, 510-600) touching the **Qualification Refused (441)** rect (280-514, 620-670) along the x=280 vertical seam — they touch but do not overlap; (b) the diamond polygon (304-490, 500-580) and the Periodic Review rect (80-280, 510-600) which share Y range but not X. Neither is a real overlap.

---

## 3. P01 Fig 3 — Database Schema (manual finding, script did not detect)

**File:** `Patent 01 - Platform Validated Model Lockstep/Filing/Drawings/Fig3_Database_Schema.svg`
**Severity:** NEEDS-FIX (semantic mismatch — would be visible to an inspector reading FK fields)

**Defect.** Source line **149**:

```svg
<line x1="260" y1="465" x2="534" y2="430" marker-end="url(#arrow)"/>
```

This is inside the `<g stroke-dasharray="3,3">` block of "Foreign key arrows" (lines 147-155). It originates at (260, 465) which is the right edge of `340 AI Request Records` (`<rect x="60" y="370" width="200" height="160"/>` ⇒ x range 60-260, y range 370-530). Y=465 falls in the FK row band (`FK* feature_key → 330`, `FK* model_row_id → 330`).

The arrow's tip lands at (534, 430). The `330 Model Registry` rect spans **(534-734, 115-275)**. **y=430 is 155 px BELOW the bottom of 330** (y=275). The tip actually lands on the LEFT edge of `360 HITL Decisions` (`<rect x="534" y="370" width="200" height="160"/>` ⇒ (534-734, 370-530)) — y=430 is inside 360.

But the **declared FK** in the 340 row at y=457 is `FK* feature_key → 330` and at y=441 is `FK* model_row_id → 330`. **The arrow that should point 340→330 actually points 340→360.** The 340→360 relationship is also not declared in the schema text (360 has `FK ai_request_id → 340`, which is the reverse direction).

This is a real semantic defect: the FK arrow renders pointing at the wrong table.

**Surgical fix.** Re-target the FK arrow tip onto the bottom edge of the 330 box (`y=275`) instead of into 360:

| File line | Old | New |
|---|---|---|
| L149 | `<line x1="260" y1="465" x2="534" y2="430" marker-end="url(#arrow)"/>` | `<line x1="260" y1="465" x2="534" y2="275" marker-end="url(#arrow)"/>` |

This points from 340's right edge UP-AND-RIGHT to the bottom-left corner of 330, matching the declared `FK* feature_key → 330` / `FK* model_row_id → 330` relationships.

**Additional cosmetic note.** L150 and L154 both arrow into 360's left edge from 350's right edge at very close Y values (460 and 490). They appear to represent the **same** `FK signature_id → 350` relationship twice. The 360 row at y=441 declares `FK ai_request_id → 340` and at y=457 declares `FK signature_id → 350`. So one of L150/L154 likely should be the 340→360 arrow that I have just re-purposed above (L149) — meaning after fixing L149, L154 becomes redundant and can be deleted, OR L154 can be retained as the explicit `ai_request_id` arrow if L149's destination is changed back. Recommendation: implement L149 fix as written, and then **delete L154** (`<line x1="497" y1="495" x2="534" y2="490" marker-end="url(#arrow)"/>`) since it duplicates L150. Net result: 6 FK arrows ↦ 6 distinct FK relationships, no duplicates, no semantic mismatches.

---

## 4. P02 Fig 2 — Legend Hygiene (NOTE)

**File:** `Patent 02 - Cryptographic Per-Inference Audit Model Version Governance and Agent Qualification/Filing/Drawings/Fig2_Per_Inference_LLM_Audit_Chain.svg`
**Severity:** NOTE (legend lists numerals not used in diagram body)

The REFERENCE NUMERALS block at lines 121-136 lists 15 numerals: 200, 201, 202, 203, 204, 210, 211, 212, 213, 220, 221, 222, 223, 230, 240. The diagram body uses only 13 of them as `(NNN)` tags. Two numerals are listed but never tagged in the body:

- **(222) Current Response Hash** — appears as `rawHash` inside the Chain-Link formula at line 63 (`combinedHash = SHA-256(prev || rawHash || ts)`) but is not tagged `(222)`.
- **(223) Timestamp (ISO 8601)** — appears as `ts` in the same formula, untagged.

**Surgical fix.** Add the numerals inline in the formula text. Lines 62-63 are currently:

```svg
<text x="570" y="420" font-size="9">combinedHash = SHA-256(</text>
<text x="570" y="434" font-size="9">  prev || rawHash || ts)</text>
```

Replace L63 only:

| File line | Old | New |
|---|---|---|
| L63 | `<text x="570" y="434" font-size="9">  prev (221) \|\| rawHash (222) \|\| ts (223))</text>` |

(Inspector now sees every legend numeral grounded in the body. The `(221)` is also added as it was already in the legend and was implicit via the `previousHash (221):` label on L59 — making it explicit in the formula closes the loop.)

If preferred to keep the formula tight, the alternative is to **delete the (222) and (223) lines from the legend** (lines 133 and 134) since they are minor named hash components rather than apparatus elements. Recommendation: add the inline tags as shown — this preserves the legend at full granularity and matches the documentation expectation for India provisional drawings.

---

## 5. P01 Fig 4 — Hash-Chain Continuation Arrows (NOTE)

**File:** `Patent 01 - Platform Validated Model Lockstep/Filing/Drawings/Fig4_HashChain_Audit_Log.svg`
**Severity:** NOTE (cosmetic — figure renders correctly; the "..." ellipsis is the recognised convention for "chain continues")

The arrows on lines **73** and **118** point at the visual "..." text that follows them on lines 76 and 119 (font-size 20 chars at x=680/475, y=178/394 respectively). The arrow tips at (660, 147) and (460, 363) are 24 / 20 px to the upper-left of the "..." text bounding box — they target the ellipsis as the conventional "chain continues" symbol.

**This is intentional patent-drawing convention.** A common alternative for higher inspection grade is to bring the arrow tip closer to the ellipsis (tip at e.g. (670, 165) and (470, 380)) and/or place the ellipsis on the same baseline as the arrow tip. **Not required for filing**; only mark as a polish item for the final Form-2 drawing pass.

---

## 6. P01 Figures 1, 2, 5, 6, 7, 8 — Confirmed Clean

All six figures pass every check after manual line-by-line review. Earlier audit-script versions reported text-overflow false positives on these figures; those were caused by a 0.55-of-font-size width heuristic that overstated Liberation Sans glyph widths by ~25 %. Re-measured with real PIL glyph widths, every text element in these figures fits inside its declared rect with at least 6 px of margin on every side. No real findings.

## 7. P02 Fig 1, 3, 5 and all P02b Figures — Confirmed Clean

Same conclusion as Section 6 — these figures had no findings in either the programmatic audit or the manual line-by-line review.

---

## 8. Verdict

- **Re-render required:** NONE.
- **Surgical edit required before filing:**
  - **P02 Fig 4** — 2-line edit (L42 + L43) per Section 2.
  - **P01 Fig 3** — 1-line edit (L149) plus optional delete of L154 per Section 3.
  - **P02 Fig 2** — 1-line edit (L63) per Section 4.
- **File-ready as-is (with optional polish):** all other 15 figures.

Total surgical edits across the entire 18-file portfolio: **4 line changes + 1 optional delete**. No figure requires a re-render or layout rework.

---

## 9. Source Ledger (V3 §11)

| Source type | Source name/path | Date/version | Claim supported | Limitations |
|---|---|---|---|---|
| Repo SVG file | `Patent 02 …/Fig4_Agent_Qualification_Protocol.svg` (lines 42-43, 46) | 2026-06-06 working copy | "updates" arrow tip (565, 318) lies 18 px outside the (430) Qualification Status rect (x≤547) | Snapshot may have been updated since audit; verify file head before applying edit. |
| Repo SVG file | `Patent 01 …/Fig3_Database_Schema.svg` (lines 44, 58, 89, 149-154) | 2026-06-06 working copy | FK arrow at L149 points (260, 465)→(534, 430); 330 rect ends at y=275; arrow lands inside 360 not 330 | Manual semantic finding; script identified geometry as "inside 360" which is technically inside a shape but semantically wrong. |
| Repo SVG file | `Patent 02 …/Fig2_Per_Inference_LLM_Audit_Chain.svg` (lines 56-75, 121-136) | 2026-06-06 working copy | Legend lists (222) and (223); body uses only `rawHash` and `ts` text without `(222)/(223)` tags | None. |
| Audit script | `/sessions/keen-magical-mccarthy/mnt/outputs/drawing_quality_audit_v2.py` | 2026-06-06 v2 (this audit) | All programmatic findings reproducible by running this script. | Text-overlap and text-in-box checks depend on Liberation Sans being a faithful proxy for Arial; minor pixel-level differences possible. |
| Raw audit output | `/sessions/keen-magical-mccarthy/mnt/outputs/drawing_quality_audit_raw.txt` | 2026-06-06 | Per-figure machine-verified finding list. | None. |
| Font binary | `/usr/share/fonts/truetype/liberation/LiberationSans-Regular.ttf` | Liberation 2 (Debian package fonts-liberation) | Per-glyph width metrics used for text-bbox computation. | Substitutes for Arial (metric-compatible by design; sub-pixel differences exist). |

No verified source supplied beyond the SVG files themselves and the audit script. All findings cite the SVG file path and exact source line numbers.