One loop, and a reason to stop.
Six steps. The interesting parts are the two that most generators skip: a static pass that catches problems before a container is worth starting, and a stop condition for when the loop isn't learning anything.
Illustrates the control flow. Not a recording of a run. The steps, the loop-back and the stop condition are how the engine is built; the failure shown is an example, not output.
Plan
Vesk reads your robot’s model manifest — derived from its URDF — links, joints, which joints are actually actuated, and the control interfaces declared on them — alongside the task you wrote. It produces a spec: the package to build, the node, the topics, and what an external observer would have to see for the task to count as done.
Those success criteria matter more than they look. They become the assertions in step three, so a vague plan produces a verification case that cannot fail.
Retrieve
The plan names the concepts it needs, and those queries search a version-pinned corpus of ROS 2 Jazzy documentation. Pinning is the point: a model trained across every ROS distribution will happily write ROS 1 idioms, or an API that was removed two releases ago, and both compile far enough to look fine.
If retrieval comes back with nothing above the relevance floor, the run is abandoned rather than generated blind.
Generate
Vesk writes the package — manifest, setup, the node module — and, in the same pass, a verification case that launches the node and asserts observable behaviour.
The case is written against the spec’s success criteria, not against the code, so it is not free to assert whatever the node happens to do.
Check
Static checks run first, because they are nearly free and a container run is not. They catch imports of packages that don’t exist, joint names that aren’t on your robot, and — the one that matters most — a verification case whose final assertion is unreachable.
A case that returns early reports nothing and passes. That is the most dangerous failure in the whole system, because it looks exactly like success.
Verify
The package is built and run inside a containerized ROS 2 Jazzy environment — isolated, resource-capped, and with no network. The case reports a structured result: how many expectations were checked, and which failed.
A case that exits cleanly having checked nothing is treated as a failure, not a pass. Separately, Vesk can score a task in physical simulation; those results are marked advisory and never gate anything.
Fix — and stop
The failure is classified and diagnosed into the specific slice that matters: the assertion that failed, the traceback, the build error. That diagnosis goes back with the previous code, so the next attempt is targeted rather than a fresh guess.
On a second failure, retrieval re-runs using the error text as the query — the one step that gives the model something it did not already have. And when two consecutive attempts fail in exactly the same way, the run stops. More attempts would not help; the model lacks the information, and nothing about attempt N+1 changes that.
What this does not do yet.
Vesk isn't open yet, and the parts that don't exist are worth naming.
Verification runs against ROS 2 Jazzy in a container, and physical scoring runs in MuJoCo. There is no Gazebo layer. The documentation corpus covers more than the verification harness does, and we would rather say that than let the two blur together.
There are no published benchmarks, success rates, or timings on this site because we have not run them. When there are numbers worth quoting, they will come with the method that produced them.
What we can point at is small and real: five runs have been verified end to end — generated, built, and run in a container against a case that asserted behaviour. Five is not a success rate and we are not going to present it as one. It is the evidence that exists.