A bracket cracks in the field for the third time this year. A technician traces the fault, logs the repair, and sends the truck back out. Three buildings away, a design engineer is asked to spec a similar bracket for the next model. She has no way of knowing that this same shape, under this same load, has already failed three times. She draws it the way the brief describes it, because that is all she has to go on. It clears review. Eighteen months later, in a customer's yard, it cracks the same way.
Why we build it this way
The instinct, once a plant starts buying AI tools for the shopfloor, is to buy the best diagnosis tool, the best documentation tool and the best design tool, each from whoever is best at that one thing. Each one, bought alone, is a real improvement. Put together, they reproduce the exact problem they were meant to fix: knowledge that lives with one person, or inside one system, and goes nowhere else.
The weld that failed belongs to the same machine the design engineer is redrawing. The step a service engineer corrects on the shopfloor belongs to the same model a technician is diagnosing two towns away. None of that is a coincidence of department. It is the same plant, the same products, looked at from three different jobs. A tool built to serve only the job in front of it throws that connection away by design, however well it does its own job.
So we do not sell three point tools that happen to share a logo. VEDA, Nirdesh and VCAD run on one on-premise core, and every verdict a person confirms in any of them — a diagnosis a technician accepted, a correction a service engineer spoke out loud, a design an engineer signed off — goes into one record the plant keeps for itself. Buying the best of each looks like rigour. It just builds three separate memories instead of one, and a plant that remembers in three disconnected places is not far ahead of a plant that does not remember at all.
Three well-built tools that do not share a memory are three more places the same knowledge can get lost.
How it works, roughly
Each module writes to the record only when a person confirms something, never on a guess it made on its own. What goes in:
- A diagnosis a technician accepted or rejected, and why
- A step in the manual a service engineer corrected, tied to the exact machine and procedure
- A design an engineer approved, with what it was meant to carry
What a module reads back is whatever the other two have already confirmed about the same machine or the same part. A bracket going through VCAD can be checked against a shape that has already cracked somewhere in the fleet. A technician diagnosing a new fault can see that this exact model's manual was corrected on this exact step last quarter. Neither module hands over the decision because of what it reads. It proposes, and the person standing at the machine, the manual or the drawing still decides — the one habit that stays the same across all three, and the single orange element in the structure below.
A year in, the plant is not running three systems that happen to be getting smarter on their own. It is building one record of what it actually knows — where a part has failed, what a step really takes, what a design was approved to carry — and the next person who needs that answer, in any of the three jobs, finds it already there. The record stays inside your own building, not spread across three vendors who have never spoken to each other.
See how the three fit together →