← All Articles Blog & News

Elector: An End-to-End System for Engineering Drawing Understanding

Feb 2026 · 19 min read

Elector beats Claude 4.8 on OCR tasks for engineering drawings - read the details.

Iheb Brini, Calibras

---

Engineering drawings contain critical manufacturing information, including dimensions, tolerances, geometric requirements. Automatically transforming this information into structured, machine-readable records could reduce the manual effort and transcription errors associated with downstream manufacturing and quality workflows. This paper compares two approaches to structured entity extraction from mechanical engineering drawings: Elector, Calibras’s end-to-end extraction pipeline for mechanical engineering drawings, and Claude Opus 4.8 — referred to as Claude throughout the remainder of this paper — a general-purpose multimodal LLM used in a zero-shot setting. Both systems are evaluated on the same dataset of engineering drawings containing 486 annotated entities across three classes: dimensions, geometric dimensioning and tolerancing annotations (GD&T), and information-block fields. Evaluation separates detection and classification from text recognition so that localization errors and transcription errors are assessed independently. Elector achieves higher detection F1 scores across all three entity classes and substantially more precise localization. For dimension entities, its mean Intersection over Union (IoU) reaches 0.60, compared with 0.23 for Claude. On text recognition evaluated over matched entities, the systems are more competitive for dimension values, with exact-match accuracies of 0.57 for Elector and 0.51 for Claude. The largest difference occurs for information-block text, where Claude frequently merges multiple fields or generates content beyond the expected annotation, resulting in a Character Error Rate of 1.48 compared with 0.45 for Elector. The results show that the specialized pipeline of Elector remains significantly more reliable for end-to-end engineering-drawing extraction, particularly for entity localization and schema-aligned title-block processing.

1 Introduction

Manufacturing and quality workflows depend on the information contained in engineering drawings (EDs), including nominal dimensions, tolerances, surface and form requirements, and title-block metadata. Although engineering drawings are often created digitally, the information they contain is usually not available in a structured form that downstream software can process directly. Engineers and quality specialists must therefore manually re-enter dimensions, tolerances, and title-block information into Enterprise Resource Planning (ERP), Computer-Aided Quality (CAQ), and inspection-planning systems. This manual transfer is time-consuming, prone to transcription errors, and difficult to maintain when drawings are revised.

The goal of automated ED extraction is to eliminate this manual step by identifying the relevant information in a drawing—whether provided as a scanned image, an exported PDF, or a rasterized page—and converting it into structured, machine-readable fields that can be validated, searched, and imported into downstream systems.

Concretely, given the rendered image of a drawing page, a system must produce, for each entity of interest: (i) a bounding box locating it on the page, (ii) a class label describing what kind of entity it is, and (iii) the text content it carries (e.g. the value 35.00). This white paper benchmarks two systems on that task and quantifies how far a general-purpose large language model (LLM) is from a specialized extraction pipeline.

We compare Elector , Calibras’s purpose-built ED extraction pipeline, against Claude [5], a general-purpose multimodal LLM used entirely zero-shot. Both are evaluated on a common set of 11 drawings containing 486 annotated entities. Crucially, we score extraction as two separate problems— detection & classification , which concerns locating and categorizing entity boxes, and recognition , which concerns reading the text inside matched entities—so that geometric and textual performance are never conflated.

The contributions of this white paper are:

• a benchmark of specialized versus general-purpose ED extraction, using a common schema and evaluation metrics that keep detection and recognition separate;
• a per-class quantitative comparison across the three entity types represented in the evaluation set; and
• an analysis of where a zero-shot multimodal LLM is already competitive, where it remains limited, and which technical directions may help close the performance gap.

Section 2 introduces engineering drawings and the entity classes considered in this study. Section 3 describes the two systems. Section 4 reports the results, which are interpreted in Section 5, before Section 6 concludes the paper.

2 Background and Core Concepts

2.1 Engineering drawings

An engineering drawing is a standardized two-dimensional technical document that communicates the information required to manufacture and inspect a part. It describes the part geometry through orthographic views, sections, and detail views; specifies its size through dimensions; defines acceptable variation through dimensional and geometric tolerances; and provides administrative metadata in a title block, including the part name, drawing number, material, scale, and revision. Engineering drawings follow established ISO and ASME drafting conventions [1–4], allowing the same document to be interpreted consistently across engineering teams, suppliers, and manufacturing environments.

Despite this standardization, engineering drawings remain challenging for automated information extraction. Their content is distributed across a dense and heterogeneous layout in which geometry lines, extension lines, leader lines, symbols, and text frequently intersect or appear close together. They also contain domain-specific notation, including diameter (∅), degree (^◦ ), plus/minus (±), datum identifiers, and GD&T feature-control frames^∗ . These elements cannot always be interpreted as ordinary text because their meaning depends on their symbols, spatial arrangement, and relationship to the part geometry.

The drawing border and zone grid introduce an additional spatial reference frame that an extraction system must identify before entity coordinates can be compared consistently. Drawings may also differ in page size, resolution, scale, orientation, and source format, ranging from scanned paper documents to digitally exported PDF files. An effective extraction system must therefore handle both the visual complexity of the page and the semantic conventions of the engineering domain.

∗See https://www.gdandtbasics.com/gdt-symbols/ for a reference guide to GD&T symbols and feature-control frames.

2.2 Entity representation and classes

In this benchmark, the information extracted from a drawing is represented as a collection of structured entities. Each entity contains three principal elements: a bounding box describing its location on the page, a class label identifying its semantic category, and a properties record containing its recognized value and associated attributes.

Class	Description	GT count
dimensions	Linear and angular dimensions and tolerances	171
gdt	GD&T feature-control frames	23
infoblocks	Title-block cells and note fields	292
Total		486

Table 1. Entity classes and ground-truth counts in the evaluation set.

Each bounding box is represented as [x, y, w, h], where x and y identify the upper-left position and w and h represent its width and height. The main textual field in the properties record is nominal, which contains the recognized value or text. Depending on the entity class, additional fields may describe its type, tolerance, limits, or condition.

The evaluation considers three mutually exclusive entity classes:

• dimensions, covering linear and angular dimensions together with their associated tolerances;
• gdt, covering GD&T annotations represented through feature-control frames; and
• infoblocks, covering title-block cells, drawing metadata, and note fields.

Table 1 summarizes the distribution of these classes in the evaluation set, which contains 11 engineering drawings and 486 annotated entities.

The dataset is strongly imbalanced: information-block entities account for the largest share of the annotations, while GD&T entities are comparatively rare. This imbalance is important when interpreting the per-class results, especially for GD&T, where conclusions are based on a limited number of examples. Because nominal is the most consistently populated textual field across the ground truth, it serves as the primary target for recognition evaluation.

2.3 Approaches to engineering-drawing extraction

Existing approaches to document and engineering-drawing extraction can be organized into two broad families: specialized pipelines and general-purpose multimodal models.

Specialized extraction pipelines. Purpose-built systems combine domain-specific rules with dedicated detection, classification, and recognition components. In engineering drawings, these systems can exploit standardized drafting conventions to identify the drawing frame, detect entity regions, classify their contents, and interpret technical notation. Their modular structure generally makes their behavior easier to inspect because errors can be attributed to a particular stage of the pipeline. Specialized systems can achieve strong performance within the drawing styles and layouts for which they were designed, but adapting them to new templates, standards, or document variations may require additional rules, training data, and engineering effort. Elector, the baseline evaluated in this white paper, belongs to this family.

General-purpose multimodal models. Large multimodal models provide a different approach. Rather than relying on a sequence of domain-specific components, they process the drawing image and can produce structured output directly from a natural-language instruction. Models such as Claude [5] can be applied in a zero-shot setting, without task-specific training or fine-tuning, which makes them easier to deploy across new document types. However, their end-to-end behavior is less transparent, and errors in localization, classification, recognition, or output formatting can be difficult to isolate. They may also identify the correct content while representing it at a different spatial or semantic granularity from the required output schema.

The comparison between Elector and Claude therefore examines two contrasting strategies: a specialized and modular pipeline designed for engineering drawings, and a general-purpose multimodal model applied without domain-specific training.

2.4 Evaluation concepts

A structured extraction system must perform both geometric and textual tasks. These capabilities are evaluated separately in this benchmark to prevent an accurate transcription from compensating for an incorrectly localized entity, or a well-localized box from masking an incorrect recognized value.

Detection and classification measure whether a system identifies the relevant entities, assigns them to the correct class, and places their bounding boxes in the appropriate regions of the drawing. Predicted and ground-truth boxes are compared using Intersection over Union (IoU), following established object detection methodology [7]. Precision, recall, and F1 measure the balance between detected, missed, and incorrectly predicted entities, while mean IoU measures the spatial accuracy of the matched boxes.

Recognition measures how accurately the system reads the textual content of an entity after its predicted box has been matched to a ground-truth box. It is assessed using exact-match accuracy and Character Error Rate (CER). Exact match requires the normalized prediction and reference to be identical, whereas CER uses the Levenshtein edit distance [8] to quantify character insertions, deletions, and substitutions. CER can exceed 1.0 when a prediction contains substantially more text than the corresponding ground-truth field.

3 Systems and Evaluation

This section presents the two systems included in the benchmark and the protocol used to compare their outputs. To ensure a consistent evaluation, both systems are required to represent their predictions using the same structured JSON schema. The schema follows the hierarchy document_entities → entities → {dimensions, gdt, infoblocks}. Each predicted entity contains a box, a flag, and a properties record. Using a common representation allows the outputs of the specialized pipeline and the general-purpose multimodal model to be evaluated with the same matching rules and metrics.

3.1 Systems under comparison

3.1.1 Elector. Elector is a purpose-built engineering-drawing extraction pipeline and serves as the specialized baseline in this study. For each input drawing, it identifies the drawing frame, localizes entities, assigns them to one of the three target classes, recognizes their textual content, and exports the result in the shared structured format.

Elector also returns a canonical drawing frame , defined as the resolved sheet border in image-pixel coordinates. This frame is used as the common coordinate system for the benchmark, allowing Elector predictions, Claude predictions, and ground-truth annotations to be compared in the same spatial reference. Elector is evaluated as a black-box system representing a pipeline specialized for engineering-drawing extraction [6].

Figure 1 shows a representative output produced by Elector. The colored overlays indicate the engineering-drawing entities localized and recognized by the pipeline, including dimensions, GD&T annotations, and information-block content.

3.1.2 Claude. The candidate system is Claude Opus 4.8 [5], a general-purpose multimodal large language model. It is evaluated in a zero-shot setting using the Anthropic API^† with high reasoning

†Anthropic Claude platform: https://platform.claude.com/.

Fig. 1. Representative Elector output on an engineering drawing. Colored overlays indicate the entities detected, classified, and recognized by the pipeline.

effort , without task-specific training or fine-tuning. For each drawing, Claude receives the rendered drawing image together with an instruction to return the extracted entities using the same schema as Elector.

Because the output of a large language model can vary between runs, each drawing is processed three times. Quantitative results are reported as the mean of the three attempts. For qualitative visualizations, the attempt with the highest F1 score for the corresponding drawing is selected. Claude produces bounding boxes in its own working coordinate frame; these coordinates are therefore transformed into Elector’s canonical drawing frame before evaluation.

3.2 Evaluation protocol

The benchmark evaluates two complementary capabilities separately: detection and classification , which measure whether entities are found, correctly categorized, and spatially localized; and recognition , which measures whether the textual content of successfully matched entities is read correctly. Keeping these tasks separate prevents localization errors and text recognition errors from being combined into a single score.

3.2.1 Coordinate normalization and box matching. Before matching, all ground-truth and predicted bounding boxes are expressed in Elector’s canonical drawing frame. This normalization ensures that differences between the coordinate systems used by the two systems do not directly affect the comparison.

Predicted boxes are matched to ground-truth boxes within the same entity class. For each class, candidate pairs are ordered by decreasing IoU, and matching is performed greedily so that each

prediction and each ground-truth entity can belong to at most one pair. A pair is retained only when its IoU satisfies

The relatively permissive threshold is intended to credit predictions that identify the approximate entity region, while the mean IoU of the retained pairs is reported separately to measure localization precision. A matched pair is counted as a true positive (TP). An unmatched prediction is counted as a false positive (FP), and an unmatched ground-truth entity is counted as a false negative (FN).

Because matching is performed independently within each class, a prediction contributes to a class only when its predicted label agrees with the corresponding ground-truth class. A box assigned to the wrong class therefore remains unmatched in the intended class and is reflected in the resulting false-positive and false-negative counts.

3.2.2 Detection and classification metrics. Detection and classification performance is summarized using precision, recall, F1 score, and mean IoU. Precision measures the proportion of predicted entities that are successfully matched:

Recall measures the proportion of ground-truth entities recovered by the system:

The F1 score is the harmonic mean of precision and recall:

All three scores lie between 0 and 1, with higher values indicating better performance. Precision penalizes unsupported or hallucinated entity boxes, whereas recall penalizes missed entities. F1 is used as the principal summary measure because it balances both effects. Mean IoU is calculated over matched pairs and indicates how closely the predicted boxes align with their corresponding ground-truth regions. This evaluation follows established object detection practice based on the PASCAL VOC methodology [7].

3.2.3 Recognition metrics. Recognition is evaluated only on the entity pairs established by the box-matching procedure. Consequently, the recognition results measure how accurately a system reads an entity once it has been localized sufficiently well to obtain a match; they do not represent end-to-end accuracy over all ground-truth entities.

The principal textual field, nominal, is evaluated using exact-match accuracy and Character Error Rate (CER). Exact-match accuracy assigns a score of one when the normalized prediction is identical to the normalized ground-truth value, and zero otherwise. CER is based on the Levenshtein edit distance and measures the number of character substitutions, insertions, and deletions relative to the length of the reference text [8].

Lower CER values indicate better recognition. Unlike accuracy, CER is not bounded above by 1.0: it may exceed 1.0 when a prediction contains substantially more text than the corresponding groundtruth field. This behavior is particularly relevant when a system merges several information-block fields into a single output.

Class	Metric Claude 4.8 (high effort)	Elector
dimensions	Precision 0.235	0.382
	Recall 0.245	0.662
	F1 0.237	0.476
	Mean IoU 0.230	0.596
gdt†	Precision 0.208	0.400
	Recall 0.222	0.438
	F1 0.214	0.417
	Mean IoU 0.100	0.253
infoblocks	Precision 0.373	0.776
	Recall 0.399	0.536
	F1 0.381	0.583
	Mean IoU 0.268	0.535

Table 2. Detection & classification, macro mean over the drawings containing each class; higher is better. The stronger system per row is in bold .^† gdt is averaged over the 8 drawings that contain GD&T frames; dimensions and infoblocks over all 11.

3.2.4 Aggregation and reporting. Metrics are first computed for each entity class and each drawing. The reported class-level results are then aggregated across drawings using a macro average, so that each drawing contributes equally regardless of how many entities it contains. Mean values and standard deviations are reported to show both overall performance and variation across drawings.

A drawing that contains no ground-truth entity of a given class cannot be scored for that class: recall has no denominator and F1 is undefined. Such a drawing is therefore excluded from that class’s average rather than being recorded as a score of zero, which would otherwise depress the mean and inflate the standard deviation. The number of contributing drawings consequently varies by class: dimensions and infoblocks appear in all 11 drawings, whereas gdt appears in only 8. The same convention already applies to the recognition metrics, which are undefined when a class yields no matched pairs.

Elector contributes one extraction result per drawing. Claude contributes three attempts per drawing, and its quantitative results are averaged across those attempts before comparison. Unless otherwise stated, all detection results use an IoU matching threshold of 0.1, and all recognition results are calculated only from the matched entity pairs.

4 Results

4.1 Detection & Classification

Table 2 reports the Group A metrics, averaged over the 11 drawings. Elector leads on every metric and every class: higher F1 throughout, and markedly tighter boxes (mean IoU up to 0.60 vs. 0.23 on dimensions). Figure 2 visualizes the comparison.

Figure 3 presents the same measurements grouped the other way round—one panel per entity class, with all four metrics side by side—so that the performance profile of a single class can be read without comparing across panels.

4.2 Recognition

Table 3 reports the Group B metrics on matched boxes. Here the picture is more nuanced: the two systems are competitive on dimension values (exact-match 0.51 vs. 0.57), but diverge sharply on info-block text, where Claude’s CER of 1.48 indicates it returns far more text than the GT field. Neither system reads GD&T (exact-match 0.00 for both). Figure 4 summarizes these results.

Fig. 2. Detection & classification metrics per class (Claude 4.8, high effort, averaged over three attempts per drawing, vs. Elector).

 

Class	Exact-match		CER	n(C/E)
dimensions	0.514 /0.569	0.418 /	0.309	11 / 11
gdt	0.000 / 0.000	1.279	/ 1.323	5 / 4
infoblocks	0.176 /0.444	1.479 /	0.449	11 / 11

Table 3. Recognition on matched boxes: exact-match (higher is better) and CER (lower is better), reported as Claude 4.8 (high effort) / Elector. The stronger value is in bold . n is the number of documents contributing.

4.3 Qualitative

Figure 5 shows a per-drawing three-panel overlay (ground truth, Elector, and Claude’s best attempt) for the Halter drawing. It makes the aggregate numbers concrete: Elector over-detects dimensions (36 boxes vs. 10 in GT) while Claude mislabels much of the title block, and both leave several GD&T frames unmatched.

Fig. 4. Recognition metrics per class (exact-match and CER) for Claude 4.8 (high effort, averaged over three attempts per drawing) and Elector.

5 Discussion

This section discusses the benchmark results and highlights the main findings and interpretations.

• Elector leads on every detection metric. Across all three classes Elector has higher F1 and, notably, much tighter boxes—mean IoU 0.60 vs. 0.23 on dimensions and 0.54 vs. 0.27 on info-blocks. Claude’s loose localization is partly structural: it reports coordinates in a coarse, down-scaled working frame, so even correctly-identified entities land approximately rather than exactly. The lenient IoU ≥ 0 . 1 threshold is what still credits many of these boxes; at a stricter threshold Claude’s F1 would fall further.
• GD&T is all-or-nothing, not uniformly mediocre. The wide error bars on gdt reflect a genuinely bimodal outcome rather than consistent mid-range performance. Across the 8 drawings that contain GD&T, Elector’s per-drawing F1 is either high (1.00, 1.00, 0.67, 0.67) or exactly zero (four drawings, three of which produced no GD&T prediction at all). The class mean of 0.42 therefore describes no drawing in the set: the pipeline either locks onto the

Fig. 5. Halter drawing: ground truth (left), Elector (centre), and Claude best attempt (right). Colours denote class: green = dimensions, orange = gdt, blue = infoblocks.

feature-control frames on a page or misses them entirely. With only 23 GD&T entities in total, this class remains the least reliable basis for conclusions in the benchmark.

• Claude both misses and hallucinates. On dimensions its recall (0.25) and precision (0.24) are both low: it finds only a quarter of the true callouts while a comparable share of what it draws is spurious. Elector’s dimension recall (0.66) shows the value of a detector tuned to the domain’s dense, repetitive callouts.
• Recognition is where Claude comes closest, yet still inferior. Given a correctly matched box, Claude reads dimension values almost as well as Elector, but does not overtake it on either metric (exact-match 0.51 vs. 0.57; CER 0.42 vs. 0.31). Reading a value such as 35.00 or 2×∅8.80 h8 is squarely an LLM strength, and the broad corpus behind a general-purpose model transfers well to it. The gap that remains is therefore narrow, but it is consistent: on this sub-task Claude approaches the specialized pipeline without matching it.
• Info-block text exposes a granularity mismatch. Claude’s info-block CER of 1.48 exceeding 1.0 indicates it frequently returns much more text than the GT field—merging several title-block cells into one string, or emitting whole notes where the GT expects a short label. Elector, aligned to the title-block grid, stays near CER 0.45. This is less a reading failure than a segmentation / schema-alignment failure: Claude does not chunk the title block into the same units as the ground truth.

6 Conclusion

On this benchmark, the specialized pipeline Elector, developed by Calibras, remains the stronger system for engineering-drawing extraction: it detects more entities, localizes them far more precisely, and reads title-block text with the correct granularity. The general-purpose model Claude Opus 4.8, used entirely zero-shot, is nonetheless competitive at the recognition sub-task for dimensional values—the part of the problem closest to natural-language reading—while lagging on localization and on structuring dense title blocks.

Two findings drive this result. First, the gap is largest where the task is geometric rather than textual: Elector more than doubles Claude’s mean IoU on dimensions (0.60 vs. 0.23) and on information blocks (0.54 vs. 0.27). Second, Claude’s information-block CER of 1.48 shows that its errors there are not misreadings but segmentation errors. Both are consequences of operating without a model of the drawing frame or of the title-block grid.

For production use on engineering drawings, Elector is the system to deploy today. It leads on every detection metric in every entity class, localizes entities more than twice as precisely, and reads title-block text at roughly a third of the error rate without a single task-specific training example. It is also deterministic and modular, so its output can be audited and fed directly into ERP, CAQ, and inspection-planning systems. A general-purpose model is the more flexible starting point for new document types, but on engineering drawings it would first need the spatial grounding that Elector excels in.

References

• [1] 2017. Geometrical Product Specifications (GPS) — Geometrical Tolerancing — Tolerances of Form, Orientation, Location and Run-out . Technical Report ISO 1101. International Organization for Standardization, Geneva, Switzerland.
• [2] 2018. Dimensioning and Tolerancing . Technical Report ASME Y14.5. American Society of Mechanical Engineers, New York, NY, USA.
• [3] 2018. Technical Drawings — Indication of Dimensions and Tolerances — Part 1: General Principles . Technical Report ISO 129-1. International Organization for Standardization, Geneva, Switzerland.
• [4] 2020. Technical Product Documentation (TPD) — General Principles of Representation . Technical Report ISO 128. International Organization for Standardization, Geneva, Switzerland.
• [5] Anthropic. 2026. Claude (Opus 4.8) Model Documentation. https://www.anthropic.com. Accessed 2026.
• [6] Elector Team. 2026. Elector: An Engineering-Drawing Extraction Pipeline. Internal technical documentation. Reference to be supplied.
• [7] Mark Everingham, Luc Van Gool, Christopher K. I. Williams, John Winn, and Andrew Zisserman. 2010. The PASCAL Visual Object Classes (VOC) Challenge. International Journal of Computer Vision 88, 2 (2010), 303–338.
• [8] Vladimir I. Levenshtein. 1966. Binary Codes Capable of Correcting Deletions, Insertions, and Reversals. Soviet Physics Doklady 10, 8 (1966), 707–710.