We do best on CAD-originated PDFs where we can use the underlying vector data, but we can run on scanned/hand-drawn sets too. In that case we rely more on image-based detection + OCR (no clean vector layer), so accuracy depends on scan quality, contrast, and how consistent the annotations are. We’ve had success on some older/detail-heavy scans, but it’s definitely a harder mode. If you have a representative “old-school” set, we’d love to run it and show you where it works well vs where it struggles.

Great point! Owner’s reps and commissioning teams are becoming one of the fastest-growing user groups for us. At SD/DD we can surface coordination risks early, highlight spec–drawing mismatches, and give owners a clearer picture of design completeness before things get locked in. If you’re open to it, we’d love to run a sample SD/DD set from your world and see what’s most useful.

Hallucinations still happen occasionally, but we bias heavily toward high-confidence findings so noise stays low. On typical projects we surface a few hundred coordination issues that are real, observable conflicts across sheets rather than speculative checks. We’re actively improving precision by learning from every false positive customers flag. We show you the drawings, specs, etc. so you can verify it yourself not just trust the AI.

Could you share a bit more about what didn’t work on your end?

Symbol variation is a huge challenge across firms.

Our approach mixes OCR, vector geometry, and learned embeddings so the model can recognize a symbol plus its surrounding annotations (e.g., “6-15R,” “DIM,” “GFCI”).

When symbols differ by drafter, the system leans heavily on the textual/graph context so it still resolves meaning accurately. We’re actively expanding our electrical symbol library and would love sample sets from your workflow.

We parse symbols using a mix of vector geometry, OCR, and learned detection for common architectural/MEP symbols. Cross-discipline checks are a big focus as we already flag mismatches between architectural, structural, and MEP sheets, and we’re expanding into deeper electrical/mechanical spec alignment next. Would love to hear which symbols matter most in your workflow so we can improve coverage.

I do electrical so parsing lighting is often a big issue. (Subcontractor)

One big issue Ive had is drafters use the same symbol for different things per person. One person's GFCi is another's switched receptacle. People use the specialty putlet symbol sometimes very precisely and others not. Often accompanied by an annotation (e.g. 6-15R).

Dimmers being ambiguous is huge; avoiding dimming type mismatches is basically 80% the lutron value add.

This is exactly the hard part symbols aren’t enough when each drafter overloads them, so we lean on the annotation + schedule context (fixture tags, notes like “DIM,” control zones, panel/ckt callouts, and control intents) to disambiguate.

We're in a similar space doing machine assisted lighting take offs for contractors in AU/NZ, with bespoke models trained for identifying & measuring luminaires on construction plans.

Compliance is a space we've branched into recently. Would be super interested in seeing how you guys are currently approaching symbol detection.

Happy to swap notes. If you send a representative lighting plan set, we can run it and share how the detector clusters, resolves, and cross-references symbols across sheets. Always excited to compare approaches with teams solving adjacent problems.

What do you mean when you say "vector geometry"? Are you using the geometry extracted from PDFs directly? I'm curious how that interacts with the OCR and detection model portion of what you're doing

Great question. By “vector geometry” we mean we’re using the underlying CAD-style vector data embedded in many PDFs (lines, arcs, polylines, hatches, etc.), not just raster images. We reconstruct objects and regions from that geometry, then fuse it with OCR (for annotations, tags, labels) and a detection model that operates on rendered tiles. The detector + OCR tells us what something is; the vector layer tells us exactly where and how it’s shaped so we can run dimension/clearance and cross-sheet checks reliably.

Woah! What determines if something is an object at that vector level? I've done some light PDF investigations before and the whole PDF spec is super intimidating. Seems insane that you can understand which things are objects in the actual drawing at the PDF vector level

Mamy of the drawings in pdf space have some layer data from CAD/revit attached to them that might make it easier to cluster objects

Yep, exactly, when layer data survives the PDF export, it’s a huge help. We use it as a weak signal for clustering and object grouping, but never rely on it fully since it’s often inconsistent or stripped. When it’s there, accuracy and speed both improve noticeably.

We see that a lot — specs that are clearly boilerplate or outdated relative to the drawings. Our goal isn’t to force a change, but to surface where the specs and drawings diverge so the designer can quickly decide what’s intentional vs what’s baggage. “Flag + context for fast human judgment” is the philosophy.

100% agree the hardest problems are workflow and incentives, not file formats.

Even with a perfect BIM model, late changes and discipline silos mean drawings still diverge and coordination issues sneak through.

We’re trying to be the “safety net” that catches what falls through when teams are moving fast and not perfectly in sync.

We price per-project based on size/complexity not % of construction cost, so there’s no conflict of interest around bigger budgets. Today our main users are architects/engineers and GC pre-con teams, but subs who catch coordination issues early also get a ton of value.

At what stage do you run this on plans? like DD, some % CD? What's the intended target timeframe?

I don't see how subs get much value unless they can use it on ~80% CD for bid phases

Most teams run us late DD through CD anywhere the set is stable enough that coordination issues matter. Subs especially like running it pre-bid at ~80–100% CDs so they don’t inherit coordination risk. Earlier checks also help designers tighten the set before hand-offs, so value shows up at multiple stages. Eventually the goal is to be continuous QA tool including during construction by pulling in field data too and comparing to drawings and specs. Like drawings showed X size and field photos show Y size.

Would love to run it and give feedback if it's cheap to do so; my company just finished a bunch of projects and would love to cross reference if it catches the issues that we found by hand (assuming it's inexpensive enough). I do high rise electrical work for a subcontractor.

We’d love that — perfect use case. Send a recent set and we’ll run a discounted comparison so you can see what we catch vs. what surfaced during construction. If helpful, we can hop on a quick call to walk through results and collect feedback. Email me aakash@inspectmind.ai

Great question. We currently focus primarily on coordination, dimension conflicts, missing details, and clear code-triggered checks that don’t require sealed structural judgment. For structural code references (e.g., ASCE-7), we infer applicable sections and surface potential issues for a licensed engineer to review. We don’t replace engineering judgment or sealed design accountability.