Skip to content
ELEMENT 31

Site task

A site task is a unit of work for robots on a facility floor, authored in Agency Studio, versioned, bounded by zones, speeds, distances, and stops, and approved by named roles.

· 2 min read

IN SHORT

A site task is a unit of work for robots on a facility floor, authored in Agency Studio, given a version, bounded by zones, speeds, distances, and stops, and approved by named roles before it can run. It gives a floor of machines from different vendors one form for describing their work, with the bounds and approvals attached to the task itself.

A site task is a unit of work for robots on a facility floor, authored in Agency Studio, given a version, bounded by zones, speeds, distances, and stops, and approved by named roles before it can run.

Why it matters

Robots on a floor act on instructions, and on most sites those instructions are spread across vendor consoles, integrator scripts, and operating procedures that live on paper. When something happens, it is hard to say what the robot was told and who agreed to it.

A site task makes the instruction a single, versioned object. The bounds travel with it. The approvals are attached to it. When a mobile robot, a pick arm, and a humanoid from different vendors share a floor, the site can describe their work in one form rather than three.

How it works at Element 31

Site tasks are authored in Agency Studio, the task layer on a Czar Grid. Each task carries its bounds as part of its definition: the zones a robot may enter, the speeds it may travel, the distances it may reach, and the stops it must honor.

Every change produces a new version. A task does not run until the roles the site named, such as the automation lead or the safety officer, have approved that version. An approved version stays approved; a changed one needs sign-off again.

When a task runs, the robot asks the pool for perception and decisions inside the task's bounds, and Substrate answers within the robot's latency budget. The robot's own stops, speed limits, and motion limits remain on the machine, beneath the task. A task can ask for less than the robot allows; it cannot ask for more.

Every run is recorded and can be replayed. The run record ties the execution to the task version, its approvals, and the decisions served. All of it stays on the operator's hardware, on air-gapped and connected sites alike, and whether the Grid came through Facility Direct or as Czar Chassis. The Technology page shows where the task layer sits.

Questions this raises

What is the difference between a site task and a robot vendor's own task?
A vendor's task lives in that vendor's console and describes one fleet. A site task lives on the Grid and describes work on the floor in one form across vendors, with the site's bounds and the site's approvals attached.
Can a site task override the robot's safety limits?
No. Stops, speed limits, reflexes, and motion limits stay on the robot as the vendor shipped them. A site task bounds what is asked of the robot and can only narrow it.
What happens when a task is edited?
The edit produces a new version. That version does not run until the named roles have approved it again. The previous version and its runs remain in the record.

KEEP READING

Related.