All posts
Engineering6 min readJuly 11, 2026

Generating PLC Documentation with AI, Graded by Controls Engineers

DM

Dylan McCarthy

Founder & Engineer

July 11, 2026-Engineering
nodeblue
04

Machine-written PLC documentation is only useful if every statement traces to the rung that makes it true. How we generate program docs, and how 137 of them survived grading by three independent Controls Engineers.

Nobody documents PLC programs, and everybody pays for it. The program grows for fifteen years under a dozen hands, the comments describe the machine as it was two rebuilds ago, and the real documentation is whatever the most senior Controls Engineer remembers. Then that person leaves, and the plant discovers the price of the gap all at once.

Writing documentation by hand never survives contact with production priorities, which makes it a natural thing to want a machine to do. It is also a place where AI-generated text can do real damage, because wrong documentation is worse than none. Someone troubleshooting at 2 a.m. will trust the document, and a document that misstates an interlock sends them down the wrong path with a line stopped. So the interesting question is not whether AI can write PLC documentation. It obviously can produce something shaped like it. The question is whether the result is accurate at the level where accuracy matters, which is the rung.

Why Program Docs Rot

The reasons are structural, not cultural. Documentation lives outside the program, so nothing forces it to change when the logic changes. The person making an emergency change at the panel is the least likely person to update a Word file afterward. And the knowledge that matters most, why the logic is shaped the way it is, is precisely the part that never gets written down anywhere.

Any fix that depends on people developing better documentation habits has been tried for forty years. The fix that can actually hold is generating the documentation from the program itself, so the source of truth is the logic and the document is a view of it.

What "Accurate" Has to Mean

A summary that says "this routine controls the infeed conveyor" is not documentation, it is a caption. Useful program documentation states what conditions start and stop the motion, what interlocks gate it, what faults latch and how they clear, and where each of those lives in the program. Every one of those statements is checkable against a specific rung, which means every one of them can be wrong in a specific, findable way.

That is the standard we hold the output to: rung-accurate. Each claim in the document traces to the rung that makes it true. Not approximately right, not right in spirit. Right in a way a Controls Engineer can verify by opening the routine at the cited location.

Wrong documentation is a trap with your company's logo on it. If a machine writes the document, the machine has to be held to the standard of the person who would have signed it.

How the Generation Works

The architecture matters more than the model. Nexus parses the project file deterministically first: every rung, tag, instruction, UDT, and cross-reference, exact and complete. We validated that layer on 509 real PLC project files from operating plants with zero parser errors. The language model then writes the documentation over that parsed representation, and it is constrained to it. It is not recalling what ladder logic usually looks like. It is describing this program, with citations back into it.

The result reads like documentation written by someone with unlimited patience: routine by routine, with the start and stop conditions, the interlock chains, the fault handling, and the rung references for each. Because it is generated from the program, regenerating it after a change is trivial, which is the property hand-written docs never had.

The Grading

Claims like this deserve hostile review, so we arranged some. We had the generated program documents graded by three independent Controls Engineers, people whose job is exactly the knowledge being tested, with no stake in the answer coming out well. The grading standard was the one above: rung accuracy, checked against the actual program.

The result was 137 of 137 documents graded rung-accurate. We publish that number because it is the only kind of evidence this category should accept. A demo on a synthetic project proves the demo works. Production programs, written by many hands over many years, full of the workarounds and oddities real machines accumulate, are the test that counts.

Where This Leaves the Engineer

Generated documentation does not capture intent on its own. The rung says what the logic does; the reason the timer is set to 4.5 seconds might still live in someone's head. What generation does is take the ninety percent of documentation work that is mechanical transcription of the program and make it free, so the scarce human knowledge can go where only it can go. It also means the day the senior engineer retires, the program itself is no longer undocumented, and what walks out the door is judgment rather than the only existing map of the logic.

That is a narrower promise than "AI documents your plant." It is also one we can prove, rung by rung.

Keep reading the work.

This is one of a series of field notes and essays on building systems that understand and act in real operations. Nexus is where the ideas get tested.