How do you extract, classify, and structure tag data from engineering drawings fast enough to matter?
A large oil and gas engineering operator needed tag data extracted and classified from engineering drawings, categorized for AVEVA Engineering tables, and equipment connections identified from wiring diagrams, fast enough to replace a multi-engineer manual process. Azati built the full pipeline in three months, processing up to 300 documents per hour.
engineering documents processed per hour by the extraction pipeline
months to deliver the full MLOps pipeline from data annotation to production
tag classification using visual context from drawings, not template matching
Every tag on an engineering drawing is a promise: find this equipment, trace this connection, confirm this attribute, in seconds, not hours. Reading that data by hand at any real volume eats engineering time no project budget survives, and the problem compounds because the same tag can mean one thing in a P&ID and something else entirely in a wiring diagram, correct classification is a judgment call, not a lookup. Wiring diagrams add a second layer: connections are drawn, never written down, so the equipment a wire connects to has to be traced through geometry, not text.
Azati built the answer as one pipeline: text extraction, symbol identification, multi-level tag classification through visual context, connection determination from wiring geometry, and AVEVA table generation, ready for an engineer to review and sign off. Delivered in three months. Running at 300 documents an hour.
A tag that marks one equipment category on a P&ID can indicate a completely different category on a wiring diagram for the same facility. Template-based extraction systems assume a fixed mapping between a tag and its meaning, an approach generic P&ID digitization tools still rely on, so they break silently here, producing confident, wrong answers rather than flagging the ambiguity. Correct classification meant treating every tag as a question to be answered by reading its surroundings, not a string to be looked up:
Wiring and electrical diagrams encode connectivity spatially: a line drawn from one symbol to another means those two pieces of equipment are wired together, and that fact exists nowhere as text. Determining which equipment a given wire connects to requires understanding the geometric layout of the drawing, tracing the physical path a line takes across the page, and interpreting spatial relationships between symbols, a fundamentally different task from anything a text extraction tool was built to do:
A pipeline that spans data annotation, model training, integration, and production delivery normally has room to let each phase breathe. This project didn't have that room. Every phase had to run efficiently and, wherever possible, in parallel with the others, with annotation and model development moving at the same time rather than one waiting on the other to finish:
The pipeline began with structured annotation of engineering drawing datasets in CVAT, with DVC managing data versions across every annotation iteration so nothing got lost or overwritten as the dataset grew. Critically, this phase ran in parallel with infrastructure setup rather than sequentially after it, which is the decision that made a three-month delivery timeline realistic rather than aspirational.
Models were trained using PyTorch Lightning, with Weights and Biases tracking every single experiment: hyperparameters, metrics, and artefacts, all logged automatically. That discipline turned model selection into a traceable, reproducible decision backed by data, not a judgment call based on whoever happened to run the last notebook before a deadline.
The classification and extraction logic was wrapped in a FastAPI service layer, containerised with Docker, and deployed on AWS with S3 handling document and artefact storage underneath. What came out the other end was a production pipeline processing up to 300 engineering documents per hour, with engineers reviewing structured output rather than performing the extraction themselves.
Tag category comes from reading the drawing itself, sequentially, the way an engineer would: what type of drawing is this, what surrounds the tag, what other symbols are present. That's why the same tag can be correctly classified two different ways in two different documents, and why new drawing formats need fine-tuning, not a rebuild.
Azati's engineering document AI has processed 120,000 P&ID documents in under 24 hours at 98.8% accuracy for one operator, and 50,000 documents across 200,000 SKUs for another running criticality analysis at scale no manual process could match. This pipeline sits in that same lineage of production-grade document AI, not a proof of concept dressed up for a case study.
CVAT annotation, PyTorch Lightning training, Weights and Biases tracking, DVC versioning, FastAPI serving, Docker and AWS underneath. Every piece of that stack was there from the first week, which is the only reason three months was enough.
300 documents an hour is what a team of engineers would need weeks to match. This isn't shaving time off a manual process, it's removing the manual process from the extraction and classification work entirely and leaving engineers to do what they're actually good at: judgment calls on the edge cases.
Tag classification, equipment connections, AVEVA table generation, Azati built the full pipeline in three months. Let's talk about yours.
Get my extraction pipeline builtFour stages, one pipeline: drawings go in, structured AVEVA tables come out, and engineers spend their time reviewing rather than extracting.
OCR and PDF processing pull every piece of text off the page. Computer vision models trained on engineering symbol libraries find every piece of equipment. Between the two, the pipeline knows what's on the drawing before it tries to make sense of it.
This is the stage that actually solves the hard problem. No lookup table. The system reads which drawing type it's on, what's around it, and cross-references other documents where needed, then classifies. It's the reason the same tag can end up correctly filed under two different categories depending on where it appears.
Wires don't announce what they connect to, they just get drawn there. This stage traces the geometry, symbol to symbol, to reconstruct the connections a text-only tool would never see.
Everything converges here: classified tags, resolved connections, full attribute sets, assembled into the AVEVA Engineering table format ready for upload. What an engineer receives is a finished draft, not a pile of raw extraction to sort through.
| Area | What was delivered |
|---|---|
| Text extraction | OCR and PDF-based text extraction across engineering document formats |
| Symbol identification | Computer vision models identifying equipment symbols on drawings |
| Tag classification | Multi-level visual context classification pipeline |
| Connection detection | Wire tracing and equipment connection identification from wiring diagrams |
| Report generation | AVEVA Engineering table generation from classified tag data |
| Data annotation | CVAT-based annotation of training data across document types |
| MLOps | Full pipeline with DVC, Weights and Biases, FastAPI, Docker, and AWS |
| Throughput | Up to 300 engineering documents processed per hour |
The pipeline runs on AWS infrastructure with S3 storage for document and model artefact management. All processing is containerised with Docker for consistent, reproducible deployments across environments.
A focused specialist team, not a large bench: ML engineering, data engineering, and backend development running in parallel from week one.
What used to need a team working for weeks now runs in a single working day. That's not marginal, it's a different cost structure for engineering data extraction altogether.
Reviewing structured output and spot-correcting edge cases is a fundamentally different job than manually reading drawings tag by tag. Same expertise, better use of it.
The classification logic gets the tricky cases right, the same tag meaning different things in different drawings, without a human resolving every instance by hand.
DVC, Weights and Biases, and CVAT didn't just ship this pipeline, they're now the default toolkit for whatever engineering document AI Azati builds next.
What this engagement demonstrates:
You can't determine a tag's category from the tag. You have to look at the drawing around it: the symbols, the layout, the document type. Text extraction gets this wrong at scale. Computer vision reasoning gets it right, which is the same lesson behind Azati's broader P&ID digitization work.
Annotation, training, versioning, integration, and deployment all fit inside one quarter because they ran in parallel from day one. Sequential phases would have blown the timeline before the second month started.
A pipeline that reads document content instead of matching a fixed template carries forward to new formats and new clients with fine-tuning, not a rebuild. That compounding is where the real return sits.
Multi-level tag classification, equipment connection detection, AVEVA table generation, the full pipeline, built and delivered in three months.
Stop extracting data by handExplore our successful projects and see how Azati delivers measurable results for our clients.
A US construction tech startup needed engineering capacity across the full stack of its SaaS + IoT digital twin platform: the browser-based 3D viewer, a cloud pipeline for large point cloud datasets, backend microservices, real-time collaboration, and AWS infrastructure, all working as one coherent product. Three different 3D rendering problems had to coexist in one interface, raw scan data had to be processed reliably at scale in the cloud, and infrastructure had to move from manually managed VMs to a reproducible, automated setup without disrupting active users.
Azati provided 24 months of full-cycle engineering, contributing to every layer of the product: a 3D viewer built with Autodesk APS Viewer SDK, Potree, and Three.js; an AWS Batch and SQS-based cloud processing pipeline; NestJS and Python microservices; custom AI models for face blurring and point cloud-to-blueprint conversion; WebSocket/SSE-based real-time collaboration; and a full migration to Terraform-managed AWS infrastructure. The result was a working scan-to-view workflow: scan a building, process the data in the cloud, view and collaborate on the digital twin in a browser.
A large Middle Eastern oil and gas operator held 35,000 Process Engineering Flow Scheme files across AutoCAD, PDF, TIFF, and JPEG formats, with no way to search them by equipment or process element. Every question about plant topology required manual review across the entire archive, and each format required a fundamentally different extraction approach, from vector parsing to computer vision-based symbol detection, while producing valid DEXPI output demanded precise process topology modeling rather than simple field mapping.
Azati built a multi-stage AI pipeline that ingests PEFS files in any format, detects and classifies equipment symbols, extracts and binds text to graphical elements, reconstructs process topology as a graph model, converts the result to the DEXPI industry standard via Proteus XML, validates it against the schema, and generates SVG visualizations for human review. The engagement started as a pilot and moved to full scale after the approach proved out, with models retrained iteratively as new drawing types surfaced.
A large Middle Eastern oil and gas operator was manually extracting data from technical documents and engineering drawings submitted by contractors, cross-checking it against internal systems, and compiling reports by hand. At scale, this process was slow, resource-intensive, and increasingly error-prone, with no systematic way to prioritize which discrepancies mattered most.
Azati built an AI-powered pipeline combining computer vision and OCR to extract and validate data from engineering documents and AutoCAD drawings, flagging discrepancies against internal system records and delivering verified results directly into the client's existing Knowledge Hub platform, extending it rather than replacing it.
Last updated
