A goal has necessary stages.
How BPOS plans one.

A program, in BPOS, is the ordered set of stages one goal has to pass through: each stage its own blueprint, each with the stages it must wait for. A necessity is a fact about the world that the work depends on, whatever route it takes.

This is the first article of What BPOS runs, one mechanism at a time.

The idea

In September 2026, Hao Shi and Xi Li published Topological Necessities, a paper about robots carrying out long tasks. Their point is simple to state. In a long task, some stages are crossed by every successful attempt, whatever the robot and whatever its method: a door every route has to go through. Those stages belong to the task, not to any one executor, and they can be recovered by looking at many successful runs.

Every kind of work has the same doors. A store has to exist before an engine can read from it. A repository has to be cloned into a workspace before anything can be built in it. A plan that ignores one of them fails, however well each of its jobs is written.

What a program is

When BPOS plans a goal, the planner writes a program: the stages, what each one must wait for, which can run side by side, and a check that says when a stage has landed. Each stage is a blueprint of its own, with its sprints and jobs. When a stage's sprint completes, the program can start every stage whose dependencies have now landed, without a person in between.

How BPOS Lite was built

BPOS Lite, our memory system, was built through a program on 27 and 28 September 2026. Six stages, 19 sprints, 29 jobs, all 29 done, in 52 agent runs on Gemini 3.5 Flash-Lite and Gemini 3.8 Flash.

The order was the point. The engine waited for the store. The connector, which lets a company's own AI talk to Lite, waited for the engine. The server waited for both the connector and the web layer, which had run alongside the rest from the start.

The program did not make the hard stage easy. The store took 15 runs averaging 0.13, and a person approved every job in all four of its sprints. The engine averaged 0.56. The last two stages passed at 1.00 and committed on their own. A program decides what comes first; it does not do the work.

What "landed" meant was shallow. Each stage's check was mechanical: the store landed when its files declared a table and a store type. That proves the stage exists, not that the product works. The second Lite program, nine stages and under way, covers what the first did not: governance, database migrations, a test suite, the web app, intake, serving and extraction.

Necessities

A program says what comes first. A necessity says why: the fact about the world that makes a stage unavoidable. Planners rarely rediscover these facts on their own. On one goal, setting up developers' workspaces, the planner was given the fact "a repository exists in a workspace only after provisioning has cloned it" in some runs and not in others. With it, 3 of 5 plans put the work after the clone. Without it, none of 2 did.

So BPOS does not leave these facts to luck. A necessity is written down once, from what the runs showed, as a claim with a probe: a small check that re-runs every night and says whether the fact still holds as the code moves. Its weight starts low, at 0.2, and moves only with what the record shows. The program hands every necessity to every step of every round, the way it hands over the goal itself.

Two necessities exist today, both on that workspace goal: repositories exist only after cloning, and a change to the workspace image reaches only workspaces created after the image is rebuilt. The Lite program carried none.

Where we are behind the paper

• Our stages are written, not recovered. Shi and Li read the unavoidable stages from many successful runs. Our planner writes the program when it plans the goal. Every one of our runs is recorded, so the material for reading stages from the record exists; the reading does not yet.
• Two necessities, on one goal. The mechanism is built and delivers them to every step. It is barely populated.
• The landing checks are shallow. A stage that lands has the right files, not proven behaviour.

The paper is about robots. The match with BPOS is in the object, not the domain: the same idea of a stage every successful route must cross, applied in production.

Not only software

BPOS Lite is a software build, but a program is not a coding device. BPOS is a constraint engine: a goal, the stages it has to cross, and the constraints each stage has to meet, whatever the medium. A stage runs on the model its skillset declares, so a stage can render an image, a video clip, or run a decision model as easily as it writes code.

That makes a program a natural storyboard. A video has necessary stages too: the script before the shot list, the shot list before the frames, the frames before the cut. Our video work already writes its storyboard as a blueprint, with its stages running on image and video models such as Gemini 3.1 Flash Image and Veo 3.1 Fast.

How a stage takes on a different model, and how the steps inside it talk to each other, is the subject of a later article in this series: the mesh, and the neuron analogy it is built on.

Common questions

Sources

• Hao Shi, Xi Li, Topological Necessities: Mechanism-Invariant Strategic Subgoals for Cross-Embodiment Goal-Conditioned Control, arXiv:2609.11014, 10 September 2026.
• Our own records, as of 9 October 2026: the BPOS Lite program's stages, sprints, jobs, runs, scores and person gates; the two necessities and their goal; the planning runs on the workspace goal, September 2026.