Skip to content

Engineering Drawing Error Detection — Models and Architecture

Source: Architechture & Research/RapidDraft/Technical Architecture/Error Detection Models for Drawings.docx (2026 research session) Status: Reference — architecture and model selection guide for drawing check module Audience: Technical team, engineers building the drawing check pipeline

Executive Summary

True end-to-end engineering drawing error detection ("this GD&T callout is misapplied / noncompliant") is not available as an off-the-shelf open-weights model in 2026. Public research repeatedly relies on in-house annotated datasets (not released) and reports performance that does not translate directly to nuanced drafting mistakes across varied corporate standards.

What does exist (downloadable / locally runnable) is a practical set of building blocks: - Document/drawing type classification as open-weight image classifiers - Engineering drawing layout detection (title block / BOM / notes) in open weights - P&ID symbol detection in open codebases with CC-BY datasets

The RapidDraft path: A composable pipeline that combines these building blocks with a standards + rules engine.

Core Insight

Treat AI as evidence extraction. Treat checking as a rules + heuristics problem.

  • "AI" extracts structured evidence (what is present, where, and in what format)
  • "Checking" is a rules + policy + tolerance problem, with ML only supporting extraction and triage
  • This aligns with industrial products that emphasise deterministic, auditable outputs with evidence coordinates

The reason you cannot simply download a drawing error detection model and ship it:

Structural challenge Explanation
Ground truth scarcity Even adjacent tasks cite difficulty obtaining large datasets due to sensitive information and data protection in manufacturing
Visual density Drawings contain many symbols, numeric values, and terms that are hard to integrate into a single recognition system
Extraction ≠ compliance Research pipelines extract GD&T fields — that is a precursor to checking, not checking itself
Private datasets Multiple papers describe "in-house annotated" training data — a strong signal that open weights do not generalise across styles and companies
Normative context required Many "errors" are only errors relative to a design intent, a manufacturing process, an internal company standard, or a customer contract

Available Building Blocks

Open-Weight Models

Model What it does Licence / Notes
ssheroz/industrial-document-classifier-clip-lora (HuggingFace) Classifies industrial document categories including "engineering drawings" Open — fine-tune for specific buckets
hsarfraz/eng-drawing-title-block-bill-of-material-extractor (HuggingFace) Detects title block / BOM / notes regions; YOLO + ONNX artifacts Open — ready for layout detection stage
DocLayout-YOLO (opendatalab) General document layout detection AGPL — caution if distributing
P&ID symbol detection (mgupta70/PID_Symbol_Detection) Symbol detection + tag OCR for P&ID drawings CC-BY — usable with attribution

What's missing in open weights: A robust downloadable model that directly detects mechanical drafting / GD&T mistakes end-to-end (e.g., "positional tolerance missing datum reference"). The closest public artefacts are papers describing such systems, but they rely on private datasets and do not ship production-ready open weights.

Commercial Tools (Reference / Competitive Baseline)

Tool What it does Relevance
Werk24 Title block extraction, dimension/tolerance extraction, GD&T, structured JSON + evidence coordinates Best public example of structured extraction pipeline; evidence-grounded
HighQA 2D/3D automatic ballooning, GD&T extraction Inspection ballooning focus
NX Checker CAD-native standards and company rule checking Deterministic, NX-integrated — incumbent
SolidWorks Design Checker CAD-native drawing standards checking CAD-integrated, company rules
ColabSoftware AI drawing check tools for manufacturing (2026) Emerging market signal

Commercial tools focus on extraction/digitisation and inspection ballooning rather than standards-grade "error detection" in the drafting-review sense. RapidDraft's differentiation: stronger standards-aware error taxonomy, evidence-grounded review UX, and better deployment/privacy posture.

April 2026 Update: Werk24 Positioning Signal

The refreshed Werk24 source material emphasizes not only extraction quality, but downstream business workflows: price and costing automation, feasibility analysis, supplier comparison, and ERP data entry acceleration. This reinforces a product requirement for RapidDraft: extraction output should be designed as reusable structured data for manufacturing and procurement workflows, not only as viewer overlays.

Practical implication for roadmap sequencing:

  1. Keep evidence-grounded extraction first.
  2. Add normalized field contracts for downstream integrations (costing, sourcing, ERP handoff).
  3. Preserve rule-checking as a separate deterministic stage so extraction and compliance logic stay auditable.

Stage 1 — Drawing Type Classification

Route downstream models and rule packs. Start with coarse buckets: - Mechanical part vs assembly vs P&ID vs electrical schematic vs datasheet

Practical MVP: use the industrial document classifier, then build your own fine-grained classifier quickly for company-specific drawing families.

Stage 2 — Layout Detection

Detect regions that anchor downstream parsing. Minimum set: - Title block - BOM / parts list - Notes / general tolerances block - Revision table (if present) - Main view region(s) / detail views (optional in MVP)

Recent title-block research reports poor performance of general table models on title blocks due to irregular structures, motivating a specialised pipeline.

Use: hsarfraz/eng-drawing-title-block-bill-of-material-extractor as the starting point. Avoid AGPL layout models unless you intentionally accept that licensing surface.

Stage 3 — OCR and Domain Parsing

Apply OCR in each detected region with region-specific parsing. Output: structured fields + bounding box evidence snapshots.

MVP parsing rules: - Units (mm / inch / dual-dimensioning) - Projection type (ISO first-angle vs ANSI third-angle) - Scale - Material string (parseable vs nonstandard) - Surface finish - General tolerances - Revision identifiers - BOM row parsing (item number, part number, description, quantity)

Stage 4 — Symbol and Callout Detection (Optional in MVP)

  • P&ID: symbol detection + tag OCR + connectivity
  • Mechanical: in MVP, focus on presence/consistency checks on reliably extracted content — do not attempt GD&T correctness checking until extraction reliability is high

Stage 5 — Rule Engine (Standards + Company Policy Packs)

This is where "error detection" actually happens. Structure: - Standards policy layer (ISO GPS / ASME Y14.5 concepts) - Company policy layer (customer-specific, supplier-specific overlays)

Each finding emits: 

{
  "finding_type": "missing_material",
  "severity": "blocker",
  "rule_id": "meta.title_block.material_required",
  "message": "Material field is empty or unparseable",
  "evidence": [
    { "bbox": [x1, y1, x2, y2], "extracted_text": "" }
  ],
  "suggested_fix": "Add material designation per ISO 10579 or company standard M-001"
}

Stage 6 — Suspicious Patterns Pass (LLM/VLM)

Only after evidence extraction. Constrain the model to: - Reference only text already extracted - Point to specific bounding boxes (never free-form)

This prevents hallucinations and mirrors commercial tools' emphasis on deterministic, auditable outputs.

Error Taxonomy for MVP

Start with presence/consistency errors — manufacturing engineers catch these routinely, and they are definable without 3D semantics.

Foundational Sheet Metadata

  • Missing/ambiguous units
  • Scale missing or inconsistent across sheets
  • Projection symbol missing or inconsistent
  • Drawing number missing or revision missing
  • Revision history inconsistent (table vs title block vs filename)

Title Block and Notes

  • Material missing or nonstandard (unparseable string)
  • Heat treat / coating missing when required by company policy
  • General tolerance missing
  • Surface finish policy missing
  • Unsupported or conflicting standard references in notes

BOM and Assembly

  • BOM present but balloons missing (or vice versa)
  • Quantity mismatch between BOM and callouts
  • Duplicate item numbers
  • Missing part number / description fields per policy

Dimensioning and Tolerance Sanity

  • Dimensions without tolerances where policy requires
  • Conflicting tolerances for the same feature callout
  • Thread callout incomplete (missing pitch/class/length where applicable)
  • Duplicate dimensions (same feature dimensioned twice with different values)

Cross-Field Consistency

  • Material in title block conflicts with material in notes
  • Units in title block conflict with dual-dimensioning style
  • Revision conflicts across title block / revision table / filename

Data Strategy

The Dataset Problem

For a commercial RapidDraft, assume you will need a clean-room dataset built from (1) customer-consented drawings or (2) synthetic drawings you generate. Most "good" public datasets are either non-commercial or provenance-uncertain.

Public Datasets Available

Dataset Content Licence
jcrzd/engineering-drawings-as1100 (HuggingFace) AS1100 standard drawings with systematic fault injection Usable for training / evaluation
WSKL/techmb (HuggingFace) Technical drawings Check before commercial use
Zenodo P&ID dataset (record 8028570) P&ID symbol detection CC-BY
Fusion360 Gallery Dataset CAD models (not drawings) Non-commercial

Synthetic "Bad Drawing" Generation

The fastest path to breadth is synthetic perturbation: - Delete a required field (material, units, surface finish) - Swap unit strings (mm ↔ inch) while leaving dimensions unchanged - Alter tolerance formats (± vs limits) to create inconsistencies - Remove datums in copied callouts

The AS1100 dataset explicitly uses systematic fault injection (single/double/triple faults), validating this as a workable construction pattern.

Anonymisation

Title blocks and notes are the highest-risk regions for sensitive identifiers. Minimum viable approach: 1. Detect title block regions 2. Redact: names, addresses, customer names, proprietary project identifiers 3. Optionally hash part numbers if you only need consistency checks

Local Deployment on AMD Hardware

Your constraints (large RAM, reserved GPU memory, preference for local/on-prem) are workable with careful runtime stack selection.

Option Details
Windows + DirectML ONNX Runtime with DirectML execution provider (DirectX 12 ML acceleration layer; works on any DX12-compatible GPU). Export all detectors/classifiers to ONNX early for vendor neutrality.
Linux + ROCm AMD ROCm stack; vLLM and TGI are explicitly supported for LLM serving. Use MIGraphX execution provider (ONNX Runtime's ROCm EP removed since v1.23).

Key constraint: Export to ONNX early. Avoid locking into a single execution provider.

Build Plan

Week 1–4 (MVP)

  • Implement PDF render + normalisation (target 300 DPI); store image pyramids
  • Integrate industrial document classifier — separate "engineering drawing vs not"; gather real label distribution
  • Integrate title block/BOM/notes detector; produce region crops
  • Implement JSON findings schema with evidence boxes
  • Ship 10 "presence/consistency" rules: units / material / revision / general tolerance / surface finish fields

Week 4–12 (Early Product)

  • Build labelled set of 1,000–3,000 drawings for layout + key fields
  • Train/fine-tune own layout detector (avoid AGPL dependencies)
  • Add BOM parsing + cross-field consistency checks
  • Create gold-set evaluation workflow with manufacturing engineers; measure class-wise precision/recall

Week 12+ (Specialisation Track)

Choose one: - Mechanical track: Expand callout parsing (threads/fits/roughness); begin GD&T primitive detection only after extraction reliability is established - P&ID/HVAC track: Integrate symbol detection pipeline + tag OCR; start topology checks (symbol–line connectivity), leveraging existing public datasets

Evaluation Plan

Activity Detail
Gold set 100–300 drawings per major drawing type; reviewed by ≥2 manufacturing engineers
Metrics Precision/recall per error class; false-positive cost (time wasted) vs false-negative cost (missed defect)
Confidence gating If evidence extraction confidence is low, downgrade to "needs review" instead of "error"
Active learning UI: accept / dismiss / mark as false positive → feed labelled data back into training

Integration Architecture

Implement as a local microservice:

POST /analyze
  Body: { image_bytes, metadata, policy_pack_id }

Response: {
  "findings": [
    {
      "finding_type": "...",
      "severity": "blocker|warning|info",
      "rule_id": "...",
      "message": "...",
      "evidence": [ { "bbox": [...], "extracted_text": "..." } ],
      "suggested_fix": "..."
    }
  ]
}

UI: highlight evidence boxes; provide accept / dismiss / false-positive feedback that feeds active learning.

Sources

  • Architechture & Research/RapidDraft/Technical Architecture/Error Detection Models for Drawings.docx
  • C:\Users\adeel\OneDrive\100_Knowledge\203_TextCAD\01_Product_Project_Management\TextCAD_Wiki\docs\01_RapidDraft\_sources\werk24_feature_extraction.mhtml