Robots, industrial cells and embedded systems make supervisory decisions constantly: is it OK to start this task, which robot takes this job, does this part pass. Helixor runs in-process on a GPU edge computer in the cell or at the line, with no network round trip, and records why each decision was made.
These are examples, not a complete list. A decision usually fits when it has written criteria, pulls from several systems, happens often, and someone may later ask why it went the way it did. Pick one to jump to it.
Before a robot starts a task, the cell controller confirms preconditions: the right tool is mounted and calibrated, the payload is within limits, fixtures are in place, the program version is approved, and the safety system reports the zone clear. These checks are scattered across PLC logic, the MES and operator habits.
Helixor gathers those preconditions as typed state and returns release, hold, or block, with the precondition that failed. It sits above your certified safety controllers and never replaces them. The safety PLC still owns the safety function; Helixor makes sure the procedural checks around it happen every time, and leaves a receipt for each release.
{
"cell": "WELD-07",
"task": "JOB-448-A",
"receipt": "hx_proof_b2e61f09c8a3d74e5f0a1c62",
"pack": "plant3.task_release v5",
"action": "hold",
"rules": ["REL-TOOL-CAL-DUE-48H"],
"input_sha256": "d91c...2e4a",
"remedy": ["recalibrate torch TCP before next shift"],
"logged_at": "2026-09-28T21:14:09Z"
}In a warehouse or plant with mobile robots, a fleet manager decides which robot takes each job based on battery, location, payload, zone restrictions and priority. The logic usually lives in vendor software you can't inspect, and nobody can say why a robot sat idle while jobs queued.
Battery, payload and zone rules go into a pack you own and can read. The solver assigns jobs across the fleet, including charging stops, and re-plans as new jobs arrive. Every assignment is checked by the decision core first, so no robot is sent where it isn't rated to go. The pack holds the hard rules and the goal. The solver searches for the best plan that satisfies every hard rule, working from the same typed state the decision core uses. If no plan can satisfy them all, it tells you so instead of quietly breaking one. The solvers are built for GPUs, and that's where large plans solve fastest. Solvers are in Preview today.
Vision systems and gauges measure each part. Someone, or some script, decides pass, rework, scrap or hold, based on tolerances, the customer's requirements and how the line has been running. The rules drift between shifts.
Tolerances and disposition rules become a pack per product. Each part comes back pass, rework, scrap or hold for engineering, with the measurement that decided it. Rework results and customer returns feed the next pack version.
| Decision | What Helixor decides |
|---|---|
| Predictive maintenance triggers | Turn sensor thresholds and run hours into a maintenance work order under written rules. |
| Device configuration checks | Confirm firmware and settings are approved before a device joins the fleet. |
| Workload | Pattern |
|---|---|
| In the cell or on the line | In-process on a GPU edge computer, no network needed |
| Site level, shared by many cells | Loopback sidecar or shared service on a GPU edge server |
| Isolated plants | Air-gapped |
Helixor makes supervisory decisions, not motion control, and it is not a safety-rated component. Keep your certified safety functions where they are. Helixor is optimized for GPUs, and that's where fleet allocation and high-volume quality checks run best. Simple task release checks also run on a CPU, just not as fast. Either way, measure on your target hardware before you rely on a timing budget.
Go deeper on helixor.dev: Deployment patterns ↗ • Core concepts ↗ • Receipts ↗
Bring a written policy and a handful of past cases. We'll turn it into a pack and run it next to your current process so you can compare.