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 often clear early. The effort goes into the long, careful translation of that 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.
The Translation Is the Work
A controls engineer can usually describe what a machine should do in a few sentences. Turning those sentences into a tested, safe, maintainable implementation is where the weeks go. It is skilled work, but a large fraction of it is patterned: the same structures appear again and again, adapted to the specifics of this line, this process, this plant. Engineers spend a great deal of time rebuilding variations of things they have built before.
That pattern is exactly what makes it a research target. Where work is patterned and the intent is 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. The point is not to remove the engineer. It is to move them up the stack, from typing out the patterned implementation to reviewing and refining it.
A First Version You Can Trust Enough to Edit
The bar for this kind of system is specific and high. A first draft of control logic is only useful if it is trustworthy enough to read and edit, rather than something an engineer has to discard and redo. A draft that is subtly wrong in ways that are hard to spot is worse than no draft, because it hides its errors inside plausible structure.
The goal is not logic generated from a prompt. It is a trustworthy first version built with the engineer, transparent enough that they can see exactly what it did and why.
So the research is as much about legibility as generation. The engineer has to be able to see why each piece was built the way it was, trace it back to the intent it came from, and trust that the structure is sound before they refine the specifics. This connects directly to the rest of our work: the same insistence on a legible seam between system and person that shows up in our collaboration research shows up here, in how a generated draft presents itself for review.
Why It Belongs in a Research Lab
It would be possible to build a shallow version of this quickly, a template expander dressed up as intelligence. We are not interested in that, because it breaks exactly when the work stops being boilerplate, which is when help would matter most. The research question is harder: can a system understand engineering intent well enough to produce logic that is sound for the actual case, not just the common one, and present it honestly enough to be trusted.
Forge is in development, and we are deliberately not overselling it. Like everything we build, it exists to find out where the idea holds and where it breaks. What we can say is the premise: the bottleneck in building industrial systems is rarely knowing what to build. It is the cost of the translation into something that runs and can be trusted. If a system can carry the patterned part of that translation while keeping the engineer in full command of the judgment, that is a meaningful change in how these systems get built. Finding out whether it can is the work.