WireSchematic

Inspiration

Electrical documentation often exists as old drawings, scans, or photographs. These sources are easy for a person to look at, but difficult for software to edit, validate, compare, or keep up to date.

WireSchematic started from a simple question: can AI help turn an existing electrical schematic into a structured digital model without pretending that the AI is always correct?

That led to the core idea of the project: AI should accelerate the first reconstruction, while an electrician remains responsible for the final electrical meaning.

What it does

WireSchematic takes an image of an electrical schematic and converts it into a structured candidate containing devices, conductors, buses, junctions, and connections.

The AI result is not accepted automatically.

An electrician can review the extracted structure, confirm or correct elements, reject things that are not actually present, add missing information, and edit connections.

The same structured state can then be viewed as a graphical electrical schematic.

The visual schematic is not generated by the LLM. It is rendered deterministically from the structured graph.

The UI also communicates how much each part of the result can be trusted: what has been confirmed or corrected by a person, what was added manually, what is still only a model proposal, and what could not be determined.

How we built it

WireSchematic is a full-stack TypeScript application built with Next.js.

For extraction, the backend uses Gemini through Genkit. The source image is sent to an extraction flow, and Gemini returns structured data rather than a free-form text description.

That candidate is validated before it reaches the application state.

One of the main architectural rules is that the LLM never directly mutates the schematic state. AI produces a proposal, and the human review layer decides what should be accepted.

Rendering is kept separate from the AI layer. Once the structured graph exists, the schematic is laid out and drawn deterministically.

The application is deployed as a single service on Google Cloud Run, serving both the frontend and the production API routes.

Challenges we ran into

The hardest part was not recognizing labels such as QF1 or QA1. It was reconstructing electrical topology correctly.

A schematic can contain relationships that are visually obvious to an electrician but difficult to represent with a limited data model.

For example, neutral and protective-earth conductors may bypass a single-pole breaker and continue toward a load outside the visible drawing. If the current model has no explicit endpoint for that outgoing circuit, inventing a neutral-to-breaker connection would make the graph look more complete while making the electrical meaning wrong.

That taught us not to optimize extraction metrics blindly.

We also found a completely different class of problem in the renderer. One valid QF1 → QA1 connection existed in the structured graph, but its deterministic route passed almost on top of a neighboring PE connection and became visually unreadable.

The extraction was correct. The rendering was not.

We fixed the routing algorithm so that wires sharing the same physical gap are coordinated by a common lane allocator.

This distinction between extraction defects, representation defects, and rendering defects became an important part of the project.

Accomplishments that we're proud of

We built a complete end-to-end flow from an unstructured image to an editable structured schematic.

Gemini does not simply describe the image. It produces a graph that the application can validate, review, mutate, and render.

We also implemented a human-in-the-loop boundary where model output remains a proposal until it is reviewed.

Another accomplishment is keeping rendering deterministic and independent of the LLM. The model is responsible for proposing structure, not for drawing the final schematic.

We also built an evaluation workflow for extraction quality and used it to distinguish actual model errors from incorrect assumptions in reference data.

Finally, the complete application is deployed on Google Cloud Run and the production extraction flow uses Gemini through Genkit.

What we learned

The biggest lesson was that building AI for a technical domain is not mainly about writing a better prompt.

It is about defining what the model is allowed to know, what it is allowed to propose, and where human judgement must take over.

We also learned that an evaluation metric is only useful when the reference itself is correct. Improving a score against a wrong representation can make the product worse.

Another important lesson was that deterministic software is not automatically correct from a human perspective. A renderer can preserve every graph edge and still produce a diagram that is difficult to read.

For this kind of product, extraction quality, domain representation, human review, and visual readability all have to be evaluated separately.

What's next for WireSchematic

The current Phase 1 keeps the schematic only in the active session.

The next steps are persistent storage, revision history, comparison between schematic versions, export workflows, and a richer canonical model for terminals, outgoing circuits, and other electrical structures that are not yet represented explicitly.

We also want to test WireSchematic on a larger set of real field photographs and more complex electrical panels.

The longer-term goal is to turn existing electrical documentation into structured, editable data while keeping the electrician in control of every important electrical decision.