The drawings hold the answers. The system makes them readable.
Substation and network documentation turned into revision-aware, machine-readable records for a Nordic grid operator.
A documentation-engineering programme for a Nordic grid operator: primary, secondary and network drawing sets brought into one revision-aware structure that engineers can search, compare and trust.
Delivered engineering documentation work, presented with the client anonymised — a Nordic grid operator.
The problem
A grid operator's documentation is a record of every decision ever made about the network: what was built, what was changed, what was replaced, and why. It is also spread across decades of drawing sets, revisions and registers that were never designed to be read together.
The knowledge works because experienced engineers hold it. They know which drawing is current, which revision changed a circuit, and where the register and the drawing disagree. That knowledge walks out of the building at retirement, and every change makes the gap wider.
The environment
Single-line diagrams, protection and control schematics, layout drawings, cable and terminal documentation — issued in revisions, updated as markups, and corrected again as as-built after commissioning.
Alongside the drawings sits structured data: station and component registers, protection settings, maintenance records. The drawing and the register describe the same network, in different languages, at different ages.
Constraints
Nothing may be inferred into the record. If the system cannot point to the drawing and revision behind a statement, it does not make the statement.
Electrical documentation is dense with symbols, cross-references and conventions that vary by decade, discipline and author. The system has to read it as it was drawn, not as a clean modern format would like it to be.
Engineers stay the authority. The system prepares, links and checks; approval remains a human act with a name attached to it.
System
Ingestion takes whatever exists: vector PDF, native drawing files, and scans. Drawing understanding reads geometry, symbols and text together with the topology between them, so a component is recognised by where it sits and what it connects to, not only by its label.
A document model holds the result: a revision graph, cross-references between drawings, and links from drawings into the registers. Retrieval answers a question with the drawing, the revision and the context attached.
Architecture
Six layers: ingestion, drawing understanding, the document model, register alignment, retrieval, and the engineer-facing views.
The same model that answers an engineer's query also grounds a language model's answers, so a generated summary can be traced back to the same sources a person would check.
Workflow
From a set of drawings to a queryable documentation model: normalise the sources, understand each sheet, link the cross-references, align against the registers, validate the disagreements, then serve.
On change, the flow runs again: a new revision arrives, the system reports what changed, what it touches, and who needs to know — before someone discovers it during an outage or an audit.
Validation
Every extracted relationship carries its provenance. Where the drawing and the register disagree, both are shown and the disagreement is raised — never silently resolved.
Acceptance was run with the client's own engineers on their own documentation, not on a prepared sample.
What it changed
Before: establishing the current state of one circuit could mean reading three drawing sets across several revisions, and trusting memory for the rest. After: one query, every result naming its drawing and revision.
Documentation that used to be read becomes documentation that can be asked. New engineers get to the answer in minutes instead of an afternoon of searching.
What we learned
In infrastructure documentation the hard part is not extraction — it is revision identity and cross-references. Get those wrong and every answer is plausible and unreliable.
The architecture transfers: the same layers serve industrial technical documentation, building systems, and any domain where the record must agree with itself across decades.
The system, layer by layer.
Each layer does one job and hands a defensible result to the next. Nothing is inferred into the record, and the last layer is always a person.
Questions about this work.
What makes electrical documentation different from other document types?
Three things: revision identity, cross-references, and registers. A substation drawing is only meaningful at a named revision — the same sheet means different things at different times — and its statements depend on other drawings and on the asset register agreeing with it. The system is built around those three relationships rather than text extraction alone.
Is this a customer case study?
It is delivered engineering work, presented with the client anonymised — a Nordic grid operator. We publish what was built and how it is validated; the client's identity and their documentation stay theirs.
Which tools and formats does it work with?
Whatever the operator already uses: vector PDF and native drawing files in, with symbol, topology and text understanding, alignment to existing registers, and answers served through an API or an engineer-facing view. Nothing has to be re-drawn to get started.
See what we can engineer for your operation.
The same systems thinking applies to document flows, operations, sales and knowledge — not only technical design.