Factories and buildings are full of controllers nobody has documentation for. The integrator left, the vendor is gone. Nobody dares to retune or migrate the loop, because nobody knows what it does. The usual way to find out is a bump test: step the process and watch. That costs production time. Käyrä does it from data the site already logs. I work as director of IT security and architecture in factories with a lot of legacy OT, so this is a problem I see at work. The proof of concept is my own district heating substation: two heating loops, one commercial controller, Home Assistant room sensors, FMI outdoor temperature. The controller's outputs are not logged, so Käyrä identifies it through the building. Sources, signals and groups are configuration, so the same engine runs on any process. Each hypothesis about the controller is a short program in a small language: weather curve, curve with summer stop, PI control, thermostat, night setback. The language has no numbers. The model writes the shape and the fitter finds every value, thousands of parameter sets at a time as tensors in PyTorch. So no number in the output comes from the language model. The language model runs on the AMD token factory. I benchmarked every chat model on it with Käyrä's own tasks, graded by code: valid hypothesis programs, an operator note turned into a program, and number-grounded prose. DeepSeek-V4.1-Flash and MiMo-V2.6-Flash scored best (0.96); every model could write grounded prose, few could write valid programs. DeepSeek-V4.1-Flash runs the loop. It reads what the best program fails to explain and proposes new mechanisms. Every proposal, score and verdict goes into a lab notebook. Operator beliefs are tested the same way. The first entry was mine, "L2 is L1 minus a few degrees", and the panel's own readings refute it.
Category tags: