Electrical Schematic Context Language

Why schematics need a new format

Every industrial machine ships with electrical schematics. These documents contain critical information: which relay controls which motor, what happens when an emergency stop is pressed, where each wire terminates. Engineers spend hours studying them during commissioning, maintenance, and troubleshooting.

The problem is that this knowledge is locked inside PDFs. EPLAN, AutoCAD Electrical, and similar CAD tools export beautiful drawings that humans can read—but machines cannot. When a circuit breaker trips at 2 AM, you're flipping through a 200-page PDF trying to trace which components are affected. When planning a modification, you're manually cross-referencing contacts across dozens of sheets.

ESCL changes this by representing schematics as structured text. Components, connections, potentials, and cross-references become data that an AI can query, trace, and reason about. The same troubleshooting that takes an experienced engineer 30 minutes now takes seconds.

What ESCL captures

ESCL is designed around how electrical engineers actually think about circuits. Rather than describing geometry (where lines are drawn), it describes topology (what connects to what) and semantics (what things mean).

Potentials are named power rails that span the entire schematic. L502 might be "24VDC after emergency stop"—a potential that originates at a safety contactor and feeds dozens of consumers across multiple pages. In ESCL, this relationship is explicit and queryable.

@potential L502 {
  description: "24VDC after E-Stop"
  type: DC
  voltage: 24V
  origin: -K2M =8/1.4
  consumers: [-U1, -A1, -K5, -B1, -B2]
}

Components carry their electrical identity: what they are, how they're configured, and what they connect to. A VFD isn't just a rectangle on a drawing—it has power inputs, motor outputs, digital I/O, fieldbus communication, and safety integration. ESCL captures all of this.

vfd -U1 "SEW Movidrive" {
  model: "MDX61B0110-5A3-4-00"
  power: 11kW
  input {
    L1, L2, L3: <- -Q8 =11/4.1
  }
  output {
    U, V, W: -> -M7 =11/4.8
  }
  digital_in {
    X13/1: "Controller lock" <- =11/5.3
    X13/2: "Forward" <- =68-K1 =68/1.1
  }
  safety {
    STO: <- [=20-K7 =20/5.5, =20-K8 =20/5.6]
  }
}

Cross-references use the standard EPLAN location format: =section/page.column. When a contactor coil is on page 7 and its contacts are scattered across pages 10, 15, and 20, ESCL preserves these relationships exactly as they appear in the original documentation.

contactor -K1M "Drives Enable Ch1" {
  coil: AC230V
  coil_at: =7/1.4
  aux_contacts {
    13-14.NO: -> /7.6
    21-22.NC: -> =20/15.4
    53-54.NO: -> /4.6
  }
  enables: L502
}

Two skills that work together

Converting a schematic to ESCL and then querying it are different tasks that require different approaches. ESCL provides two Claude skills optimized for each phase.

The Generator skill handles PDF-to-ESCL conversion. It extracts each page as an image, analyzes the drawing to identify components and connections, and produces structured ESCL output. Because large schematics can have hundreds of pages, the skill maintains a state file that tracks progress—you can pause and resume conversion across multiple sessions.

The Query skill answers questions about completed ESCL files. It understands electrical concepts like power distribution, signal flow, and safety circuits. You can ask natural language questions, send photos of components for identification, or request troubleshooting workflows.

The conversion workflow looks like this:

# Extract PDF pages as images
$ node extract-pdf.js schematic.pdf project/images/ --dpi 150

# Ask Claude to convert (Generator skill)
You: Convert this schematic to ESCL format.
# Agent processes each page, tracks progress in state.json
# Output: project/master.escl

# Query the result (Query skill)
You: What feeds motor -M7?
You: If -Q5 trips, what stops working?
You: Create a troubleshooting checklist for the conveyor.

What you can do with queryable schematics

Once your schematic is in ESCL format, the AI can answer questions that would otherwise require significant manual effort. Here are concrete examples from real troubleshooting sessions.

Diagnose a tripped breaker. When circuit breaker -Q7 trips, you need to know what's downstream. The agent traces the power chain and suggests probable causes based on the connected loads.

You: Why might circuit breaker -Q7 have tripped?

-Q7 protects the following circuit:
  → Line reactor -L1
  → VFD -U1 (SEW Movidrive MDX61B, 11kW)
  → Motor -M7 "Conveyor belt" (7.5kW)

Probable causes:
  1. Motor overload — check thermistor contacts T1-T2
  2. VFD fault — check fault relay X10/1, read display
  3. Short circuit in cable -W7 (4x2.5mm², 21m to field)
  4. Mechanical jam — motor drawing excess current

Identify a component from a photo. You're standing in front of a cabinet and see a tripped device. Send a photo and the agent matches it to the schematic, giving you the exact location and downstream effects.

You: [Photo of tripped motor protection switch]

This is -Q2 at location =12/4.1
  Model: Siemens 3RV2021-4DA10 (20-25A)
  Function: Motor protection for -M2 "Conveyor belt"

Trip indicator shows overload, not short circuit.
Auxiliary contact 13-14 signals to PLC at E32.0.

The motor -M2 is a 7.5kW drive for the conveyor belt.
Check for mechanical binding before reset.

Find where a sensor type is used. You have a spare proximity sensor and want to know where similar sensors exist in the machine. The agent searches the ESCL data and explains the function of each match.

You: [Photo of IFM proximity sensor]

This appears to be an IFM inductive sensor, M12 barrel.
Similar sensors in the schematic:

  -B1 at =45/3.2: "Forward limit"
  -B2 at =45/3.8: "Rear limit"
  -B5 at =45/5.1: "Reference" 

All three connect to AS-i slave @3 at =EXT/8.1,
which handles work table positioning.

Generate a troubleshooting checklist. Rather than generic advice, the agent creates a step-by-step workflow specific to your circuit, with exact locations for each checkpoint.

You: Motor -M2 won't start. Give me a troubleshooting checklist.

Troubleshooting checklist for -M2 "Conveyor belt" not starting:

□ Verify -Q8 breaker is ON (location =11/4.1)
□ Check for VFD fault on -U1 display
□ Verify L204 (230VAC drives circuit) at -K8M coil (=11/4.7)
□ Check "Drive block" signal at -U1 terminal X13/1
□ Verify safety relays -21-K7 and -21-K8 are energized (=21/5.5)
□ Check STO input status on VFD
□ Measure 24VDC control voltage at -U1 terminals

If all checks pass, the fault is likely in the PLC program
or fieldbus communication (PROFIBUS address 14).

The format at a glance

ESCL files are plain text, UTF-8 encoded, with a syntax optimized for both human readability and LLM parsing. The core elements are:

Component tags follow standard industrial conventions: -M7 for motors, -U1 for VFDs, -K1M for contactors, -Q5 for breakers. The full specification includes grammar rules, component type definitions, and example documents.

The bigger picture: an AI that knows your machine

Electrical schematics are just one piece of the puzzle. A typical industrial machine also has PLC programs, HMI configurations, mechanical drawings, spare parts lists, maintenance logs, and operational manuals. Today, this knowledge lives in disconnected silos—different file formats, different software tools, different departments.

The long-term vision for ESCL is to be the foundation for an AI agent that truly understands your entire machine. Imagine asking "why is station 3 producing rejected parts?" and getting an answer that correlates the PLC logic, the sensor wiring, the last maintenance intervention, and the mechanical tolerances. Or asking "what do I need to order if the hydraulic pump fails?" and receiving a complete parts list with lead times and compatible alternatives.

This requires structured representations of each knowledge domain—ESCL for electrical, similar formats for PLC code and mechanical assemblies—and an agent architecture that can reason across all of them. The troubleshooting checklist that ESCL generates today is a preview of what becomes possible when AI can access the full context of how a machine is built and operates.

We're starting with electrical schematics because they're the backbone of automation systems and because the problem is immediately painful. But every feature in ESCL—the cross-references, the component relationships, the queryable structure—is designed with this larger goal in mind: an AI copilot that knows your machine as well as your most experienced engineer.

Current status and roadmap

ESCL is functional today for schematic conversion and querying. The format specification is stable at v1.0, and both Claude skills are production-ready for typical industrial control panel documentation.

Getting started

To use ESCL, you need the skill files loaded into a Claude environment with file system access (Claude Code, computer use, or similar). The conversion process works with any schematic PDF, though results are best with clear, high-resolution exports from CAD systems.

Required files:

• escl-generator-skill.md — Conversion skill with phased workflow
• escl-query-skill.md — Query skill with analysis patterns
• ESCL_SPECIFICATION_v1.0.md — Complete language reference
• extract-pdf.js — Node.js tool for PDF page extraction

Typical workflow:

• Extract PDF pages: node extract-pdf.js schematic.pdf images/
• Ask Claude to convert using the Generator skill
• Review the generated ESCL file for accuracy
• Query with natural language using the Query skill

All files are available on GitHub, including example ESCL documents and sample queries.