# AGRO-P-003 — Drawings Package v1

> **Matter**: AGRO-P-003 · Edge-Computing Veterinary Diagnostic System with Hybrid-Inference Method
> **Document control**: v1.0 · 2026-05-09 · Strictly Private and Confidential
> **Purpose**: UKIPO priority filing drawings (six figures) per Patent Council §5.2 checklist
> **Compliance regime**: UKIPO Patents Form & Rules Manual (Manual of Patent Practice §14) — black-line, white-background, reference-numerals only, no colour, no shading
> **Distribution**: Inventorship-disclosure document — DO NOT share externally until UKIPO priority filing is lodged

---

## §0 · Drawing Convention

### §0.1 Reference-numeral families

Reference numerals are allocated by tier so that any numeral immediately discloses which architectural tier the component belongs to. Once allocated, a numeral is **fixed across all six figures** — claim 1's four core elements (wearable biosensor `100`, edge gateway `200`, cloud-tier aggregation system `300`, chain-of-custody verification rail `400`) appear with the same numeral every time they are drawn.

| Family | Range | Tier / domain |
|---|---|---|
| 1xx | 100–199 | Sensor tier — wearable biosensor and its sub-components |
| 2xx | 200–299 | Edge tier — on-farm gateway and its sub-components |
| 3xx | 300–399 | Cloud tier — aggregation system and its sub-components |
| 4xx | 400–499 | Cryptographic chain-of-custody rail |
| 5xx | 500–599 | Federated cross-farm intelligence network |

### §0.2 UKIPO compliance notes

- Black ink on white background only. No grayscale, no colour, no photo-shading.
- All elements labelled with reference numerals (no descriptive text inside the drawing except short flow labels: "yes" / "no" on state-machine arrows, threshold values on band boundaries, "k≥5" suppression label on Fig 6).
- Resolution sufficient for 300+ dpi reproduction at A4.
- Margins: top 2.5 cm, sides/bottom 1 cm.
- One figure per sheet. Sheets numbered "FIG. 1" through "FIG. 6" centred at top of each sheet.
- Connecting lines: solid for data flow, dashed for cryptographic anchoring / audit-rail flow, double-line arrow for cloud-bound escalation.
- Mermaid blocks below are an **engineering wireframe only**. Final patent-line-art rendering is the illustrator's task (see §8).

---

## §1 · FIG. 1 — Closed-Loop Platform Architecture (4 modules)

### §1.1 Wireframe (Artefact A)

**Purpose**: The system-level overview claim 1 reads on. Discloses the four claim-1 elements as a closed loop with bidirectional flow.

**Layout**: Four modules arranged in a rectangular closed loop. Top-left `100` (wearable biosensor). Top-right `200` (edge gateway). Bottom-right `300` (cloud-tier aggregation system). Bottom-left and central spine `400` (chain-of-custody verification rail) drawn as a vertical bar connecting all three other modules with dashed lines. A solid arrow runs `100`→`200` (BLE/LoRa biomarker stream); `200`→`300` (anonymised pathway statistics, no raw biomarkers); `300`→`200` (cohort feedback / cloud-tier verdict); `200`→`100` (cadence + OTA control). Each of `100`, `200`, `300` has a dashed line into `400`.

**Components used**: `100`, `200`, `300`, `400` (see master list §7).

**Connecting arrows / labels**:
- `100`→`200` solid arrow, label "biomarker stream"
- `200`→`300` solid arrow, label "anonymised statistics"
- `300`→`200` solid arrow, label "cohort feedback"
- `200`→`100` solid arrow, label "control"
- `100`⇢`400`, `200`⇢`400`, `300`⇢`400` dashed arrows (audit anchoring)

**UKIPO note**: Closed-loop topology must read clearly at A4 — components drawn as labelled rectangles; no internal sub-component detail at this figure level (sub-components disclosed in Figs 2–6).

### §1.2 Mermaid (Artefact B)

```mermaid
flowchart LR
    subgraph LOOP[" "]
        direction LR
        A["100<br/>wearable biosensor"]
        B["200<br/>on-farm edge gateway"]
        C["300<br/>cloud-tier aggregation system"]
    end
    D["400<br/>chain-of-custody verification rail"]
    A -->|"biomarker stream"| B
    B -->|"anonymised statistics"| C
    C -->|"cohort feedback"| B
    B -->|"control"| A
    A -.->|"anchor"| D
    B -.->|"anchor"| D
    C -.->|"anchor"| D
```

---

## §2 · FIG. 2 — Three-Layer Sensor → Edge → Cloud Topology

### §2.1 Wireframe (Artefact A)

**Purpose**: Discloses the multi-instance topology. Multiple sensors per gateway; multiple gateways per cloud-tier; the cloud tier serves a federated network. This is the figure claim 1(a)–(c) reads on, and it grounds the dependent claims for plurality (claim 5 federated network, claim 6 LoRa fallback).

**Layout**: Three horizontal bands stacked vertically. Top band — Sensor Layer. Middle band — Edge Layer. Bottom band — Cloud Layer.

- **Top band (Sensor Layer)**: three instances of `100` shown side-by-side (`100a`, `100b`, `100c` for clarity, but treated as the same component `100` per §7). One additional instance shown displaced horizontally with a longer-range link to indicate pasture deployment.
- **Middle band (Edge Layer)**: two instances of `200` shown side-by-side (`200a`, `200b`) representing two distinct on-farm gateways at two distinct farms. A LoRa concentrator `218` drawn between them collecting from the pasture sensor.
- **Bottom band (Cloud Layer)**: a single block `300` containing internal sub-block `310` (federated aggregation engine) and sub-block `320` (cohort-statistics datastore).

**Connecting arrows / labels**:
- BLE coded-PHY links: `100a`→`200a` solid arrow labelled "BLE 5.x"; `100b`→`200a` solid arrow "BLE 5.x"; `100c`→`200b` solid arrow "BLE 5.x"
- LoRa fallback link: pasture-displaced `100`→`218` solid arrow labelled "LoRa SX1262"; `218`→`200b` solid arrow "backhaul"
- Edge → Cloud: `200a`→`300` and `200b`→`300` solid arrows labelled "anonymised statistics (no raw)"
- Cloud → Edge feedback: `300`→`200a` and `300`→`200b` solid arrows labelled "cohort feedback"
- Audit rail: dashed lines from each tier into vertical bar `400` running down the right margin

**UKIPO note**: Layer-band labels ("Sensor Layer", "Edge Layer", "Cloud Layer") may appear as marginal text outside the drawing border per UKIPO §14.4 (descriptive layer titles permitted as legends).

### §2.2 Mermaid (Artefact B)

```mermaid
flowchart TB
    subgraph SENSOR["Sensor Layer"]
        S1["100a"]
        S2["100b"]
        S3["100c"]
        S4["100d (pasture)"]
    end
    subgraph EDGE["Edge Layer"]
        G1["200a"]
        G2["200b"]
        L1["218<br/>LoRa concentrator"]
    end
    subgraph CLOUD["Cloud Layer"]
        C1["300<br/>(310 fed-agg / 320 cohort-store)"]
    end
    R["400<br/>audit rail"]
    S1 -->|"BLE 5.x"| G1
    S2 -->|"BLE 5.x"| G1
    S3 -->|"BLE 5.x"| G2
    S4 -->|"LoRa"| L1
    L1 -->|"backhaul"| G2
    G1 -->|"anonymised stats"| C1
    G2 -->|"anonymised stats"| C1
    C1 -->|"cohort feedback"| G1
    C1 -->|"cohort feedback"| G2
    S1 -.-> R
    G1 -.-> R
    C1 -.-> R
```

---

## §3 · FIG. 3 — Wearable Biosensor Schematic

### §3.1 Wireframe (Artefact A)

**Purpose**: Discloses internal sub-components of `100`. This is the figure claim 1(a) and dependent claims 6 (BLE+LoRa transceiver), 11 (power budget), 12 (microneedle geometry) read on.

**Layout**: Outer rectangle `100` (the wearable Pod housing). Inside, divided into four quadrants:

- **Upper-left quadrant**: `104` Nordic nRF5340 SoC, with adjacent `105` secure enclave / hardware root-of-trust drawn as a smaller rectangle inside `104`.
- **Upper-right quadrant**: RF block. `106` BLE 5.x coded-PHY transceiver. `108` Semtech SX1262 LoRa modem. `110` antenna (single element shared between `106` and `108` shown as a labelled stub line exiting the housing).
- **Lower-left quadrant**: `102` quad-needle hydrogel-microneedle array drawn as a 2×2 cluster of triangular needle profiles below the housing baseline. Cluster footprint annotation "1.5–2.0 mm" with pitch annotation "0.5–0.8 mm" between adjacent needles. Needle-length annotation "0.7–1.3 mm" along the side of one needle. `103` per-needle EIS continuity-check trace lines drawn from each needle base back into `104`.
- **Lower-right quadrant**: `112` CR2477H battery (1,000 mAh @ 3.0V), `114` 32 MB SPI-NOR ring buffer (≥30-day primary / ≥7-day fallback retention), `116` quad-array cluster_health state machine block (green/yellow/red, ≥3-of-4 quorum).

**Connecting arrows / labels**:
- `102`→`104` solid arrows (analogue biomarker signal path, four parallel lines, one per needle)
- `104`↔`105` short bidirectional arrow ("HW root-of-trust")
- `104`→`106` solid arrow ("BLE TX")
- `104`→`108` solid arrow ("LoRa TX, fallback")
- `106`→`110` and `108`→`110` solid arrows
- `112`→`104` solid arrow ("3.0V; <1 mA primary, <5 mA fallback")
- `104`↔`114` bidirectional arrow ("ring buffer")
- `116` connected to `103` array via solid line ("≥3-of-4 quorum")

**UKIPO note**: Microneedle cluster geometry annotations (1.5–2.0 mm / 0.5–0.8 mm / 0.7–1.3 mm) are explicit dimensional callouts per the corrected substrate (per Technical Substrate Validation §C-2). These dimensional labels are claim-supportive disclosure and are permitted under UKIPO §14.4 as essential dimensional information.

### §3.2 Mermaid (Artefact B)

```mermaid
flowchart TB
    subgraph POD["100 wearable biosensor (Pod housing)"]
        SOC["104 Nordic nRF5340 SoC"]
        SEC["105 secure enclave / HW root-of-trust"]
        BLE["106 BLE 5.x coded-PHY"]
        LORA["108 SX1262 LoRa"]
        ANT["110 antenna"]
        BAT["112 CR2477H 1000 mAh @ 3.0V"]
        BUF["114 32 MB SPI-NOR ring buffer (≥30 d)"]
        HSM["116 cluster_health (≥3-of-4 quorum)"]
    end
    NEEDLES["102 quad-needle microneedle array<br/>cluster 1.5-2.0 mm · pitch 0.5-0.8 mm · length 0.7-1.3 mm"]
    EIS["103 per-needle EIS continuity"]
    NEEDLES -->|"ISF analogue"| SOC
    EIS --> HSM
    SOC <--> SEC
    SOC -->|"BLE TX"| BLE
    SOC -->|"LoRa TX (fallback)"| LORA
    BLE --> ANT
    LORA --> ANT
    BAT -->|"<1 mA primary / <5 mA fallback"| SOC
    SOC <-->|"ring buffer"| BUF
    HSM --> SOC
```

---

## §4 · FIG. 4 — Hybrid-Inference State Machine (three confidence bands)

### §4.1 Wireframe (Artefact A)

**Purpose**: Discloses the keystone method claim 2 + dependent claim 3. This is the load-bearing figure for inventive concept.

**Layout**: Single-page state diagram. Top of page — entry node `220` "candidate hypothesis + confidence score `c`". Three branching arrows down to three state nodes arranged left-to-right:

- **Left branch — High-confidence band** (`c ≥ 0.85`): state `222` "Local-tier verdict returned (sub-100 ms)". Single outflow arrow down to terminal node `230` "User-facing output" and a dashed arrow to `400` "audit log write".
- **Centre branch — Medium-confidence band** (`0.60 ≤ c < 0.85`): state `224` "Local verdict returned + cloud augmentation queued in background". Two outflow arrows: one solid to `230` (immediate local verdict surfaced); one to sub-state `226` "Cloud verdict received within 30 s; surface to user if differs from local". `226`→`230` solid arrow labelled "differs? surface; same? silent". Dashed arrow from `224` and `226` to `400`.
- **Right branch — Low-confidence band** (`c < 0.60`): state `228` "Await cloud verdict; user-facing output deferred". Solid outflow to `230`. Dashed arrow to `400`.

A fallback state `229` "Cloud unreachable — graceful degradation: local verdict surfaced with degraded-confidence flag" sits below `224` and `228`, reachable from both via a labelled "timeout" arrow.

**Threshold annotations on the band boundaries**: "0.85" labelled on the boundary line between High and Medium bands; "0.60" on the boundary between Medium and Low bands.

**Connecting arrows / labels**:
- `220`→`222` labelled "c ≥ 0.85"
- `220`→`224` labelled "0.60 ≤ c < 0.85"
- `220`→`228` labelled "c < 0.60"
- `224`→`226` labelled "background"
- `224`→`229` and `228`→`229` labelled "cloud timeout"
- `222`, `226`, `228`, `229`→`230` (user-facing output)
- All four routing-decision states have dashed arrows to `400` (audit-log-write per claim 2(d))

**UKIPO note**: State-machine flow labels ("yes"/"no"/threshold values) are permitted as essential operational annotations.

### §4.2 Mermaid (Artefact B)

```mermaid
stateDiagram-v2
    [*] --> Entry
    Entry: 220 candidate hypothesis + confidence c
    Entry --> High: c >= 0.85
    Entry --> Medium: 0.60 <= c < 0.85
    Entry --> Low: c < 0.60
    High: 222 local verdict (<100 ms)
    Medium: 224 local verdict + cloud queued
    Low: 228 await cloud verdict
    Medium --> CloudCheck: background
    CloudCheck: 226 cloud verdict <=30 s; surface if differs
    Medium --> Degrade: cloud timeout
    Low --> Degrade: cloud timeout
    Degrade: 229 graceful degradation
    High --> Out
    CloudCheck --> Out
    Low --> Out
    Degrade --> Out
    Out: 230 user-facing output
    High --> Audit
    Medium --> Audit
    Low --> Audit
    Degrade --> Audit
    Audit: 400 audit log write
    Out --> [*]
```

---

## §5 · FIG. 5 — Chain-of-Custody Merkle-Tree Anchoring Sequence

### §5.1 Wireframe (Artefact A)

**Purpose**: Discloses the cryptographic rail `400` and dependent claim 7 (SHA-256 + Merkle bundling + multi-chain anchoring). Cross-references GB2514773.7.

**Layout**: Sequence-diagram form, four vertical lifelines left-to-right: `100`, `200`, `400`, `410` (public ledger). Time flows top-to-bottom.

**Components**: `100`, `200`, `400`, plus child elements:
- `402` per-measurement SHA-256 digest
- `404` Merkle-tree leaf node
- `406` Merkle-tree root (bundle hash)
- `408` ECDSA-P256 signature by gateway secure-element
- `410` public-ledger anchor (Markush: Solana / Hedera / IOTA / XDC)
- `412` HKDF-derived per-event identifier (per v4.1 §11.1(e))

**Sequence**:
1. `100` produces a biomarker reading; `100` computes `412` (HKDF identifier) and `402` (SHA-256 digest); transmits both to `200`.
2. `200` accumulates `402`s into a batch over interval T (≤96 anchors/day).
3. `200` constructs `404` leaf nodes for each `402`, builds Merkle tree, computes `406` root.
4. `200`'s secure element computes `408` signing `406`.
5. `200` transmits `406` + `408` to `410` public-ledger anchor.
6. `410` returns transaction receipt back to `200`.
7. `200` writes the (`406`, `408`, receipt) tuple back into `400` audit-log store.

**Connecting arrows / labels**: All solid arrows in the sequence diagram. Dashed lifelines per sequence-diagram convention.

**UKIPO note**: Sequence diagrams are explicitly accepted under UKIPO §14.4 for method-of-operation disclosures. The Markush list at `410` is annotated as marginal legend ("Solana / Hedera / IOTA / XDC") outside the drawing border.

### §5.2 Mermaid (Artefact B)

```mermaid
sequenceDiagram
    participant S as 100 sensor
    participant G as 200 gateway
    participant A as 400 audit-log
    participant L as 410 public-ledger
    S->>S: 412 HKDF id + 402 SHA-256 digest
    S->>G: reading + 412 + 402
    G->>G: accumulate 402 over interval T
    G->>G: 404 Merkle leaves -> 406 Merkle root
    G->>G: 408 ECDSA-P256 sign(406) via secure element
    G->>L: anchor(406, 408)
    L-->>G: tx receipt
    G->>A: write(406, 408, receipt)
```

---

## §6 · FIG. 6 — Federated Cross-Farm Aggregation Network (k-anonymous)

### §6.1 Wireframe (Artefact A)

**Purpose**: Discloses dependent claim 5 (federated network with k≥5 suppression, no raw-data egress).

**Layout**: Hub-and-spoke. Central node `300` (cloud-tier aggregation) with sub-blocks `310` (federated aggregation engine) and `320` (cohort-statistics datastore) drawn inside. Around `300`, eight peripheral nodes — instances of `200` representing eight on-farm gateways (`200a` through `200h`) at eight distinct farms. Each `200` instance shows below it a small icon `100` indicating the herd of biosensors feeding that gateway (one `100` icon per `200` is sufficient — the multiplicity is implied by the topology in Fig 2).

**Components used**: `200`, `300`, `310`, `320`, plus federated-network-specific:
- `502` federated-statistic submission packet (signed, anonymised)
- `504` k-anonymous suppression filter (k ≥ 5)
- `506` differential-privacy noise envelope (ε ≤ 4 per round, gradient clip C = 1.0)
- `508` regional cohort statistic (output)
- `510` regulator-facing aggregate evidence channel (anchored via `400`)

**Connecting arrows / labels**:
- Each `200a`–`200h`→`300` solid arrow labelled `502` ("anonymised statistics + DP-noise; no raw biomarker"). The label "k≥5" appears once on the bundle of arrows entering `300`.
- Inside `300`: `502` arrows feed `504` filter; `504` feeds `310` aggregation engine via `506` DP envelope; `310` writes to `320`; `320` produces `508`.
- `508`→`510`→`400` chain shown as a single labelled outflow arrow exiting `300` to a small `400` node at the right margin, signalling the regulator-facing evidence anchoring.
- A red-line annotation (rendered as a heavy solid bar with no fill, since UKIPO disallows colour) sits across the inbound arrows: "NO RAW BIOMARKER EGRESS" — this is the data-sovereignty discipline of claim 10.

**UKIPO note**: The "NO RAW BIOMARKER EGRESS" textual annotation is functionally a flow-prohibition label and is permitted as essential operational annotation. The k≥5 numeric label is essential disclosure for claim 5.

### §6.2 Mermaid (Artefact B)

```mermaid
flowchart TB
    subgraph FARMS["8 farms"]
        G1["200a"]
        G2["200b"]
        G3["200c"]
        G4["200d"]
        G5["200e"]
        G6["200f"]
        G7["200g"]
        G8["200h"]
    end
    subgraph CLOUD["300 cloud-tier aggregation"]
        K["504 k-anonymous filter (k>=5)"]
        DP["506 DP envelope (eps<=4)"]
        AGG["310 federated aggregation engine"]
        STORE["320 cohort-statistics datastore"]
        OUT["508 regional cohort statistic"]
    end
    REG["510 regulator-facing evidence"]
    AUD["400 audit rail"]
    G1 -->|"502 anonymised, NO RAW"| K
    G2 -->|"502"| K
    G3 -->|"502"| K
    G4 -->|"502"| K
    G5 -->|"502"| K
    G6 -->|"502"| K
    G7 -->|"502"| K
    G8 -->|"502"| K
    K --> DP
    DP --> AGG
    AGG --> STORE
    STORE --> OUT
    OUT --> REG
    REG -.-> AUD
```

---

## §7 · Reference Numeral Master List

| Numeral | Component | Tier | Appears in |
|---|---|---|---|
| **100** | wearable biosensor (whole) | sensor | 1, 2, 3, 5, 6 |
| 102 | quad-needle hydrogel microneedle array (cluster 1.5–2.0 mm; pitch 0.5–0.8 mm; length 0.7–1.3 mm) | sensor | 3 |
| 103 | per-needle EIS continuity-check trace | sensor | 3 |
| 104 | Nordic nRF5340 SoC (Cortex-M33 dual-core, 128 MHz) | sensor | 3 |
| 105 | secure enclave / hardware root-of-trust | sensor | 3 |
| 106 | BLE 5.x coded-PHY transceiver | sensor | 3 |
| 108 | Semtech SX1262 LoRa modem | sensor | 3 |
| 110 | antenna | sensor | 3 |
| 112 | CR2477H battery (1,000 mAh @ 3.0V; <1 mA primary, <5 mA fallback) | sensor | 3 |
| 114 | 32 MB SPI-NOR ring buffer (≥30-day primary / ≥7-day fallback) | sensor | 3 |
| 116 | quad-array cluster_health state machine (green/yellow/red, ≥3-of-4 quorum) | sensor | 3 |
| **200** | on-farm edge gateway (whole) | edge | 1, 2, 5, 6 |
| 218 | LoRa concentrator / pasture backhaul | edge | 2 |
| 220 | candidate-hypothesis + confidence score entry node | edge | 4 |
| 222 | high-confidence local-verdict state (c ≥ 0.85) | edge | 4 |
| 224 | medium-confidence dual-track state (0.60 ≤ c < 0.85) | edge | 4 |
| 226 | cloud-augmentation arbiter sub-state (≤30 s) | edge | 4 |
| 228 | low-confidence cloud-await state (c < 0.60) | edge | 4 |
| 229 | graceful-degradation state (cloud unreachable) | edge | 4 |
| 230 | user-facing output | edge | 4 |
| **300** | cloud-tier aggregation system (whole) | cloud | 1, 2, 6 |
| 310 | federated aggregation engine | cloud | 2, 6 |
| 320 | cohort-statistics datastore | cloud | 2, 6 |
| **400** | chain-of-custody verification rail (whole) | crypto | 1, 2, 4, 5, 6 |
| 402 | per-measurement SHA-256 digest | crypto | 5 |
| 404 | Merkle-tree leaf node | crypto | 5 |
| 406 | Merkle-tree root (bundle hash) | crypto | 5 |
| 408 | ECDSA-P256 signature by gateway secure element | crypto | 5 |
| 410 | public-ledger anchor (Markush: Solana / Hedera / IOTA / XDC) | crypto | 5 |
| 412 | HKDF-derived per-event identifier | crypto | 5 |
| 502 | federated-statistic submission packet | network | 6 |
| 504 | k-anonymous suppression filter (k ≥ 5) | network | 6 |
| 506 | differential-privacy noise envelope (ε ≤ 4; clip C = 1.0) | network | 6 |
| 508 | regional cohort statistic output | network | 6 |
| 510 | regulator-facing aggregate evidence channel | network | 6 |

**Bold** numerals (`100`, `200`, `300`, `400`) are the four claim-1 elements and appear in every figure that shows the relevant tier.

---

## §8 · Production Notes

### §8.1 Mermaid → patent-line-art conversion path

The Mermaid blocks render to SVG via `mmdc -i fig.mmd -o fig.svg -t neutral -b white`. SVGs import cleanly into Inkscape for tracing to UKIPO-compliant line art. Three options for final production, in increasing order of cost / quality:

1. **Self-trace in Inkscape (≤1 day)**. Render Mermaid → SVG → open in Inkscape → set all strokes black 0.5 mm → set all fills none → flatten text labels to paths → export PDF. Adequate for priority filing; not optimal for examiner-facing aesthetics.
2. **Patent illustrator refinement (£600–1,200; 3–5 working days)**. Brief a CIPA-network patent illustrator (e.g., the illustrator pool used by Marks & Clerk, Mewburn Ellis, or Carpmaels) with this drawings package and the Mermaid SVGs. Output is formal patent-line-art compliant with UKIPO Manual of Patent Practice §14, EPO Rule 46, and 37 CFR §1.84 simultaneously — useful because PCT entry Q3 2027 will reuse the same drawings.
3. **Senior patent illustrator with cross-jurisdiction sign-off (£1,500–2,500; 5–7 working days)**. Same as (2) but with a partner-grade illustrator who delivers UKIPO + EPO + USPTO compliant variants in one engagement. **Recommended** given the £0.5–1.0M valuation uplift the Patent Council attributes to filing within the 7-day window — illustrator cost is <0.5% of that uplift and reduces examiner-facing rework risk to near-zero.

### §8.2 Recommended action

Engage option (3) on Day 2 of the 7-day execution timeline (per Council §5.3). The illustrator works from this drawings-package wireframe + the Mermaid SVGs in parallel with the specification polish. The illustrator returns final PDFs by Day 4, in time for the UKIPO online portal submission.

### §8.3 Alternative — defer formal art to PCT entry

UKIPO accepts informal drawings at priority filing with a request to file formal drawings within the 12-month priority window. This route uses option (1) for priority filing and option (3) at PCT entry. Saves £1,500–2,500 today at the cost of an examiner-facing drawing-substitution event in late 2026. **Not recommended** — the priority filing drawings are part of the disclosure that PCT entry inherits, and substituting drawings post-priority creates an added-matter risk under EPC Article 123(2) at EPO regional phase.

### §8.4 File-format deliverables for UKIPO portal

- One PDF per figure, A4 portrait, 300 dpi minimum, black-line-on-white.
- Sheet header centred top: "FIG. 1" through "FIG. 6".
- No applicant/inventor metadata in the figure files (kept on Form 1).
- Native-file backup (Inkscape `.svg` + `.mmd` source) retained in `04_Specification/_artefacts/` for future reuse.

---

## Document control

> **v1.0 · 2026-05-09** — Initial issue. Six-figure drawings package per Patent Council §5.2 checklist. Reference-numeral families (1xx sensor / 2xx edge / 3xx cloud / 4xx crypto / 5xx network) established and audited consistent across all six figures. Ready for illustrator engagement Day 2 of 7-day execution timeline.