You cannot wire a PLC to every question worth asking. But you can point a camera at the aisle, the cell, or the dock and describe the answer you want in a sentence. Nurby watches, checks with a vision model, and writes the result into the WMS, the ERP, or a relay on the wall.
The expensive problems are the ones that fall between sensors. They are all clearly visible on footage nobody watches.
PLCs count what they were wired to count. The pallet in the wrong bay, the operator without a hard hat, the jam nobody logged: none of that has a sensor, and buying one for every case is not a plan.
Everybody on the floor has a theory about which station is slow. Nobody has stood there with a stopwatch for a week, so the theory that wins is the one held by the loudest person in the meeting.
A forklift and a person in the same lane is the incident that did not happen yet. It is on the recording, it is not in any report, and the first time it reaches management is after somebody is hurt.
Nurby runs on your own hardware, decides locally, and only reaches outside your network when a rule you wrote tells it to.
You do not need a trained model per fault. Describe what wrong looks like, and a vision model checks the frame when the trigger fires, with a second opinion before anything escalates.
Tripwires and zones give you counts, dwell, and time between two points. The bottleneck stops being an opinion and starts being a number with a clip behind it.
Actions can fire a relay on an ESP32 or a Raspberry Pi, so a hazard-zone breach can hit a beacon or a stack light in the same second it raises the alert.
Open any row for the action chain and the primitives behind it. These are built from triggers and actions in Nurby today.
Every rule above is built from triggers and actions that ship in Nurby today. Nothing here is a roadmap item.
The API Call action speaks authenticated HTTP with templated URLs, headers, and bodies, and chains with everything else in the rule. If your WMS, ERP, or CMMS has an endpoint, a Nurby rule can reach it.
Keyless entry, door controllers, and credential readers. Nurby posts the body count that the badge event alone cannot give you.
Every site is odd in its own way. The lighting, the angle, the one forklift that always parks in shot. A camera product that cannot absorb your corrections makes you tune it forever. Here is where Nurby is on closing that loop, honestly labelled.
A rule can run a vision model as a second opinion before it fires, so the borderline calls get looked at twice instead of paging the shift lead.
Every fired event carries a right/wrong control. Correcting one is the whole interaction. No labelling tool, no dataset, no ML team.
Nurby reads back your corrections and proposes the change: raise this rule's confidence to 0.86 and 28 of the 31 you dismissed would have stayed quiet. You approve it, it does not apply itself.
Your corrections become examples attached to that rule's prompt, so the model learns what a mis-slotted pallet looks like in your aisle, not in a benchmark.
Pick the station everyone disagrees about. Run one rule for a week and let the number settle the argument.
Any RTSP or ONVIF camera, mounted where the disagreement is. Detection runs on CPU; only the vision-model checks want a GPU, and those only fire when a trigger already matched.
Click the polygon on the live feed and describe the condition in plain language. Test it against recorded footage before you let it act on anything.
Post to the WMS, the ERP, the maintenance system, or a relay on the floor. Everything stays on your network unless you explicitly send it somewhere.
Open source, self-hosted, and provider agnostic. Run the vision model locally on your own GPU or hand it to a cloud provider. Either way the footage stays where you put it.