How I make a factory observable first
Most industrial AI work starts with an assumption: the factory already has usable data.
That assumption is often false. Many real manufacturers still run on paper, memory, WhatsApp messages, spreadsheets, operator habits, and files moving between people. The problem is not that AI is missing. The problem is that the factory is not yet observable.
That changes the research question.
Instead of asking how to add AI to an existing digital production system, I am interested in how a low-digital-maturity factory can become observable, data-driven, and eventually adaptive.
The first research layer is observability
An AI-native factory does not begin with agents. It begins with traces.
The first layer should answer basic questions:
- What job is running?
- Which machine is involved?
- When did the work start and stop?
- Which operator checkpoint happened?
- Which material or file was used?
- What failed, paused, changed, or completed?
- Which parts of the trace are missing or uncertain?
This is minimum viable observability. It is the smallest useful combination of sensors, manual inputs, timestamps, identifiers, schemas, validation, and storage that can make one production workflow legible.
Why low digital maturity is not a disadvantage
At KIT, access to continuous real-time industrial data is limited. That can feel like a blocker if the goal is to validate methods on already instrumented production systems.
But a factory with almost no digital base creates a different and useful validation environment. It lets the research study the transformation itself: how manual production becomes observable enough for analytics, inference, and decision support.
That is more general than one factory digitization project. Many small and medium manufacturers are in exactly this state. They do not need a full AI platform first. They need a method for becoming observable without breaking how production already works.
The worked example: Skytex Georgia
Skytex Georgia is an embroidery manufacturing environment with limited digital infrastructure and mostly manual workflows. It is also a real factory, not a lab toy.
The current work started with owned digital infrastructure and product-facing software: AI-assisted product concepts, a wholesale brand platform, product data, customer intent, files, and the first operating layer the company controls.
The next research step is narrower and more important: choose one production workflow and make it observable.
For an embroidery line, that could mean defining jobs, machines, operators, materials, design files, checkpoints, delays, defects, and completion events. Some events may come from sensors. Some may come from manual inputs. Some will be missing. The method has to handle that honestly.
Where inference enters
Once a real workflow has reliable enough traces, the deeper research becomes possible:
- process reconstruction from incomplete observations
- monitoring and cycle-time analytics
- probabilistic state estimation
- belief propagation over uncertain production state
- adaptive inference under missing and noisy data
- decision support for operators and managers
- eventually, industrial agents that act on a maintained operating substrate
This is why I see software architecture and research as the same path. The architecture creates the data reality. The research reasons over it. The company pilot validates whether the whole thing survives practice.
The role I am moving toward
I am not only trying to build one application. I am moving toward becoming a system architect and maintainer for industrial AI systems: someone who can design the sensing layer, data layer, software layer, inference layer, and maintenance routines as one coherent system.
That is the work worth spending years on: making real factories observable enough that advanced AI has something true to stand on.