Skip to content
Developers

Robotics

How a written procedure could drive robot work

Section titled “How a written procedure could drive robot work”

Tallyfy runs the steps people follow. Write a procedure once as a template, and each launch becomes a process with tasks, owners, deadlines and an activity log of who did what.

Some robot makers let outside software read a robot’s status or send it work. Where they do, a small program your developer writes could join the two, so a robot fault launches the right Tallyfy process. Boston Dynamics describes the same idea for Spot: an application that creates a work order whenever the robot finds an anomaly ↗[1]. Tallyfy doesn’t build or ship that program.

Your developer would need three things. The robot maker has to publish an interface, a documented way for a program to read the robot’s status or send it work. Tallyfy’s side exists today: another system can launch a process through the API or complete a task, and Tallyfy sends a webhook (a message to another system) when a task is completed or a process launches.

The program has to reach both sides, so plan where it runs with your IT team. NIST’s guide to operational technology security ↗[2] recommends keeping the networks that run physical equipment apart from the corporate network, with a buffer zone called a DMZ between them.

Before you buy, ask the robot maker in writing what your software may connect to. Some interfaces need an extra controller option, as FANUC’s driver does ↗[3].

As of October 2026, these seven have a page of their own:

As of October 2026, these four make humanoid robots but publish no developer interface we could find, so we found nothing documented for outside software to call.

As of October 2026, the standards bodies list these editions of the industrial robot safety standards:

(Skip this unless you’re setting up the technical side.)

Three shared ways to move robot data, as of October 2026: