Key concepts

A handful of terms appear everywhere in Zeon, in the Web IDE, the main app, the CLI, and these docs. Here's what each one means.

Project

The unit of versioning. A folder containing your skills, workflows, worlds, objects, and a project.json manifest.

Skill

A single robot action, written as a Python function. Lives at skills/<name>/.

Workflow

A visual graph that chains skills together. Stored as JSON at workflows/<name>.json.

World

A saved 3D scene: what objects are on the table and where they sit. Stored at worlds/<name>/.

Object

A physical thing the robot can pick up or interact with, such as a plate, a cold block, or a fixture. Pulled from the shared mesh database.

Canvas

An optional custom React UI that collects a workflow's inputs before it runs.

Sync

The cloud-canonical version control that backs every project. Like git, but built in.

Running on real hardware

Whether the workflow runs against a simulated scene or your physical robot.

How they fit together

A project is the top-level container. Inside it:

Skills are the building blocks, one Python function per skill.
Workflows wire skills together: grab this, move there, drop it.
Worlds describe the scene the workflow runs in, as in the table has these objects on it.
Objects are the things in the world. What does a "96-well plate" look like to the robot? They come from a shared mesh database, so a plate looks the same in everyone's project.
A canvas is an optional bit of custom UI for a single workflow. For example, "Which plate is the destination?" asked once before the run.

Sync is how all of the above gets versioned. Saving in the Web IDE or the main app writes a commit straight to the cloud, so anyone with the project can pull the latest state, see history, or roll back. From the CLI it's two steps (a local commit, then a push), or one, if you use zeon sync.

Sim vs real is decided per run. The same project, the same workflow, can run in a cloud simulator (no hardware) or on your local robot (real arms, real cameras).