Electrical Design Cross-Checker: What If Design Documents Could Check Each Other?

Electrical Design Cross-Checker: What If Design Documents Could Check Each Other?

Electrical design reviews rarely fail because one document is completely wrong.

More often, the problem is simpler.

The documents do not agree with each other.

A breaker may be shown as 400 A on the Single-Line Diagram but 600 A on the panel schedule.

A cable size may be updated in the cable schedule but remain unchanged on the drawing.

A CT ratio may be revised in the protection settings while the Single-Line Diagram still shows the previous value.

Individually, each document may look reasonable.

The inconsistency appears only when someone compares them side by side.

That made me think:

What if electrical design documents could cross-check each other automatically?


The Problem Is Not Always Calculation

Electrical design packages contain many interconnected documents:

  • Single-Line Diagrams
  • Load Lists
  • Cable Schedules
  • Panel Schedules
  • Protection Settings
  • Equipment Data Sheets
  • Specifications

Each document is usually reviewed individually.

But many design errors exist between documents, not inside a single document.

For example:

SLD: Feeder breaker = 400 A
Panel Schedule: Feeder breaker = 600 A

Which one is correct?

Someone has to notice the mismatch, trace the latest revision, and confirm the intended design.

The more documents and revisions a project has, the easier these inconsistencies are to miss.


The Concept: Electrical Design Cross-Checker

I started sketching a simple concept called:

Electrical Design Cross-Checker

The idea is not to replace an electrical engineer.

It is to automate the repetitive comparison work before the engineer starts the real review.

The system would read multiple design documents and build relationships around common equipment tags such as:

  • TR-01
  • SWGR-01
  • MCC-01
  • FDR-01
  • UPS-01
  • PDU-01

Once the same equipment is identified across different documents, the system could compare key design values.


What Could It Check?

A first version could focus on relatively simple consistency checks.

1. Breaker Rating Mismatch

Compare feeder breaker ratings between:

  • Single-Line Diagram
  • Panel Schedule
  • Equipment Schedule

Example:

SLD: 2,000 A
Panel Schedule: 2,500 A

Result:

Breaker Rating Mismatch


2. Cable Size Inconsistency

Compare conductor information between:

  • Single-Line Diagram
  • Cable Schedule
  • Electrical Load Schedule

Example:

SLD: 4C-240 mm²
Cable Schedule: 4C-300 mm²

Result:

Cable Size Inconsistency


3. CT Ratio Mismatch

Compare Current Transformer (CT) ratios between:

  • Single-Line Diagram
  • Protection Settings
  • Relay Configuration

Example:

SLD: 600/5
Protection Setting: 800/5

Result:

CT Ratio Mismatch


4. Load Discrepancy

Compare equipment load values between:

  • Load List
  • Single-Line Diagram
  • Panel Schedule

Example:

Load List: 2.8 MVA
SLD: 3.0 MVA

Result:

Load Discrepancy


5. Missing Protection Setting

A feeder exists on the drawing, but no corresponding protection setting can be found.

Result:

Protection Setting Missing

That does not automatically mean the design is wrong.

But it gives the engineer a clear item to investigate.


The Important Part: Traceability

Simply saying “Mismatch Found” is not enough.

The engineer needs to know:

  • Which equipment is affected?
  • Which documents disagree?
  • What values were found?
  • Where were those values found?
  • Which revision was reviewed?
  • What rule triggered the issue?

For example:

Equipment: FDR-03
SLD: 2,000 A
Panel Schedule: 2,500 A
Rule: Equipment Rating Consistency
Status: Review Required

This kind of traceability is what could make the tool useful in an actual engineering workflow.


The Engineer Still Makes the Decision

Automation can identify inconsistencies.

It cannot automatically understand every design decision.

Sometimes the drawing is wrong.

Sometimes the schedule is outdated.

Sometimes the difference is intentional.

Sometimes a temporary revision has not yet propagated through the entire document package.

The Cross-Checker should therefore act as a review assistant, not as a design authority.

Its job would be simple:

Find suspicious inconsistencies early and bring them to the engineer’s attention.

The engineer still decides what is correct.


Why I Think This Could Be Useful

Electrical engineers spend a surprising amount of time comparing documents manually.

The work is important, but much of it is repetitive.

And repetitive work is exactly where human attention becomes unreliable.

A system like this could potentially reduce:

  • missed design inconsistencies
  • repetitive manual checking
  • review time
  • late-stage design corrections
  • construction rework

More importantly, it could allow engineers to spend more time on questions that actually require engineering judgment.

Not:

“Does this number match that number?”

But:

“Is this design actually safe, coordinated, maintainable, and reliable?”


Field Note

This is still only a concept.

I have not built the full software.

But I think there is value in starting with the problem before starting with the code.

The real question is not:

“Can AI read electrical drawings?”

The better question may be:

“Which engineering decisions are repetitive enough to automate, but important enough that missing them creates real risk?”

That is where I think engineering automation becomes interesting.


Not a complete automatic design checker.

Just a system that helps engineers catch inconsistencies before they become expensive problems.