A look at the research behind Forge, our effort to let teams describe what a system should do and get a trustworthy first version of the logic and configuration built with them, rather than from scratch.
Most engineering effort in an industrial system is not spent deciding what the system should do. That part is usually settled early. The effort goes into the long translation of intent into working logic and configuration: the routines, the interlocks, the mappings, the thousand small decisions that turn an idea into something that runs safely. Forge is our research into compressing that translation without giving up the trust it has to earn. It is in development, not shipping, and this post is about the premise rather than a product.
The translation is patterned, and the code says so
The claim that industrial logic is highly patterned is easy to assert and easy to check, because reading real controllers is what Nexus does all day.
In the decommissioned lane study, every unit on a sortation lane used the same standard conveyor instruction, and each unit's enable resolved to the same two-term expression: zone enable, and no latched drive fault. Not similar logic. The same shape repeated down the lane, which is why the entire lane collapsed to two bits once the pattern was identified.
The same thing holds a layer up. In the four-lane OEE study, every lane in the reporting routine is a self-contained block wrapped in a single enable gate, repeated per lane. In the cross-controller permit trace, each belt tells its upstream neighbor it can accept by passing a charge-enable bit into the same drive instruction, and that handshake repeats down the whole line.
Where the work is this patterned and the intent is this expressible, there is room for a system to do the first translation so the engineer starts from a credible draft instead of a blank page. That is the premise. The rest of this post is about why the draft is the easy half.
Hand-repeating a pattern is where defects live
The interesting part of that field work is not that the patterns exist. It is what happens at the places where a human copied one.
The OEE state machine decode went into a vendor instruction body to answer an unrelated question about how a conveyor reports its state, and surfaced three defects nobody had asked about. One branch of the state instruction skips a check that every other branch performs. A timer enable assignment is immediately overwritten and does nothing. And one routine block is missing an inversion on the downstream-disabled bit that all of its sibling blocks have, which means that block treats a blocked condition differently from the rest of the line.
That third one is the signature failure of patterned work done by hand. A row of near-identical blocks, one of them subtly not identical, silently behaving differently for years. Nobody was careless. That is just what happens when a person types the same structure out for the ninth time.
So the case for generating the patterned part is not only speed. It is consistency, which is the property hand repetition is worst at and the one a generator is naturally good at, provided the generated structure is legible enough to audit.
The hard cases are exactly where the pattern breaks
A template expander dressed up as intelligence would handle everything above and fail at the part that matters.
Look at the exception in the permit trace. Every belt on that line hands its neighbor a permit in software, except one, whose upstream neighbor lives on a different controller. For that belt the charge-enable leaves software and becomes a physical 24 V output to another controller. The pattern is the rule and the site is the exception. Any system that generates the regular cases confidently and the odd one confidently and wrongly has made things worse, because the wrong one is now hiding inside plausible structure.
That is the actual research question. Can a system carry engineering intent well enough to be right about the case in front of it rather than the common case, and be honest enough to say when it cannot tell the difference. It is the same honesty requirement that shows up everywhere in our field work: refusing rather than guessing when the evidence runs out.
A draft is worth having only if it arrives with its verification
The bar for a first version of control logic is not that it looks right. It is that an engineer can establish what it does faster than they could have written it.
Field work suggests two properties do most of that job.
The first is diffability against a source of record. In the merge slug-release investigation, the first question was whether the routine running in the controller matched the routine that had been reviewed. Extracting it and diffing it against the source of record cleared the entire category in minutes, with the only differences being export whitespace and a comment alignment. That is the least glamorous kind of finding and often the most valuable. Generated logic has to support the same test, which means it has to be structured, extractable, and stable enough that a diff is meaningful rather than noise.
The second is blast radius, established before anything is deployed. The four-lane OEE study turned on a complete cross-reference proving which bit governed exactly the requested lanes and which one reached across the whole merge zone. A draft that changes an existing system should arrive with that enumeration attached, in a form the engineer can re-run, rather than leaving them to work out what it touches.
The goal is not logic generated from a prompt. It is a trustworthy first version built with the engineer, legible enough that they can see exactly what it did and why, and verifiable before it ever runs.
Correct logic is not a finished change
There is a step past verification that generation-focused thinking tends to skip, and the ghost fault study is the reason we take it seriously.
Clearing one dead reference on one screen turned out to touch three separate configuration layers, and two of the three deploy as plant-wide reload events. Getting that wrong does not produce a wrong answer. It re-annunciates alarms across a running site, or strips the animation off a conveyor so it silently stops coloring on live faults while still looking correct. The correct handling was one change at a time, dated before-and-after copies of every file, and a low-throughput window with operators told in advance.
A system that turns intent into working systems has to carry that context, not just the logic. What the change touches, in what order it lands, what has to be backed up first, and what is safe to leave alone. Deliberately leaving harmless orphans in place beat reloading two engines on a running site out of tidiness.
Why it belongs in a research lab
It would be possible to ship a shallow version of this quickly. We are not interested in that, because it breaks precisely when the work stops being boilerplate, which is when help would matter most.
The honest position is that the bottleneck in building industrial systems is rarely knowing what to build. It is the cost of the translation into something that runs, plus the cost of proving it is safe to land. If a system can carry the patterned part of both while the engineer keeps every piece of the judgment, that is a real change in how these systems get built. It is also the same boundary problem as the gap between advising and acting, moved upstream to the moment a system is designed rather than the moment it runs. Names and shapes will change. The question will not.