From single-line diagram to validated network model

Every interconnection study, protection review, and planning model starts the same way: a junior engineer opens a stack of PDFs and types. Single-line diagrams, equipment schedules, spec sheets, prior studies: hours of transcription that has to be re-done every time a drawing revises. This post walks the pipeline we built to end that, stage by stage, in enough detail to argue with.

Stage 1: Parse

Vector PDFs first, always. A vector single-line diagram carries its geometry as drawing primitives, which means symbols, text, and line work are separable, and extraction becomes a structured reading problem instead of a vision guess. Raster scans are the fallback, where OCR and a vision model recover what the scan preserved. The parse stage records provenance from the first moment: every element knows its source file, page, and revision before anything else happens to it.

Stage 2: Extract

Extraction turns drawing elements into electrical objects: transformers with ratings and vector groups, breakers with interrupting ratings, buses, conductors with impedances, loads and generation with operating points. The equipment schedules and spec sheets contribute the nameplate authority: the values that win conflicts, because a drawing label is a convenience and a schedule row is a record.

Stage 3: Reconcile

This is the stage that decides whether the model is trustworthy. The same physical asset appears in multiple sources under different names: T-4 on the diagram, Transformer 4 on the schedule, the vendor designation on the spec sheet, and a bus number in the prior study. Entity resolution merges those into one canonical asset with one provenance chain, and flags every source conflict it cannot resolve on authority rules. Unresolved conflicts do not get silently averaged. They land in the discrepancy report.

Entity resolution across drawing, schedule, and study is where document AI projects in this industry live or die. Extraction is the easy 80 percent.

Stage 4: Validate

A reconciled graph that fails physics is a well-organized mistake. Validation runs two families of checks. Engineering rules: voltage compatibility across windings, rating consistency between series equipment, missing parameters that any study would need. And power-flow sanity: solving the network under light and peak assumptions with an open-source solver to confirm the model actually converges and behaves. The output of validation is a signed checklist attached to the graph, not a vibe.

Stage 5: Deliver

The deliverable set is deliberately boring: a canonical network graph in CIM-lite JSON, the discrepancy report with every value hyperlinked to its source sheet and revision, and export adapters for the environments downstream, PSS/E and friends. Boring is the point. The output has to drop into a consultant's existing stack without a migration project.

What this buys, concretely

• Transcription hours drop by 60 to 80 percent on a typical package, because the engine types and the engineer reviews.
• Revision cycles stop being re-types: re-run the pipeline on the new drawing set and diff the graphs.
• Every value in the model has a citation trail, which is exactly what an auditor, or a client's auditor, asks for.
• Discrepancies surface as findings with locations, not as study failures months later.

Where humans stay in the loop

The engine never signs anything. A professional engineer reviews the discrepancy report and the validated graph, resolves the flagged conflicts that require judgment, and approves the package. We consider that division non-negotiable, both for liability and because the review is where the paired data comes from: every engineer correction makes the next package in that fleet measurably better.