Twelve rules, written as refusals

Motion control, interlocks, emergency stops, protective stops and safety-rated monitoring belong to validated control systems. The software never commands them and has no interface that could. A stop is a fact it observes and plans around, never a state it can clear.

There is no code path from this software to a motion command or a safety function.

Legosphere does not build robots, controllers or meters. Every piece of equipment is reached through its vendor’s own interface, and an adapter declares exactly what that interface allows — report status, accept tasks, report energy. A robot whose interface only reports is never offered work.

A task for a report-only robot is refused at planning, naming the robot and its adapter.

Production plans and fleet-wide task plans are proposed by software and released by a named person. The release is a field on the record carrying who and when, and it records the simulation it was approved against.

An unreleased plan cannot dispatch a single task.

A task goes to the controller or fleet manager that owns the robot, which executes it under its own logic. When it refuses, the refusal is recorded with the reason it gave and the work goes back to the planner.

A refused task is replanned, never retried until it is accepted.

Allocation and scheduling are deterministic computations over recorded state. A model may suggest a schedule to compare or explain a bottleneck, but its output cannot become a dispatched task — and the allocation layer cannot import the model client, which the build enforces.

A suggestion with nothing computed behind it cannot reach a robot.

Given the same recorded state and the same released plan, allocation produces the same assignments, and every assignment records the reason it was made. That is what lets a bad shift be replayed and a planning problem be told apart from an equipment problem.

Every assignment carries its reason, and a shift can be replayed from its record.

Lifts, doors, aisles, chargers and stations are resources with calendars, reserved explicitly by the task that needs them — including resources shared between vendors’ fleets, which no single vendor can see.

Two tasks holding the same resource over the same interval are refused at planning.

Status, faults, machine signals and meter readings are stored with when they happened and when they arrived, and every plan, alert and forecast uses the first. A source that has gone quiet is shown as stale rather than as its last good state.

A robot whose last report is older than its heartbeat is not offered work.

A schedule that needs material not on hand, a cell booked for maintenance, or a robot that has reported an uncleared fault is not published with a warning. It is refused, naming what it depended on, while there is still time to change it.

The plan is refused naming the material, cell or robot it needed.

A changed allocation rule, zone, charging policy or fleet size runs against the site’s own layout and recorded demand before it can be released, and the release records which simulation it was approved against.

A coordination change with no simulation on its own layout cannot be released.

Energy and throughput savings are computed against a recorded, normalised baseline at the tariff in force, and the baseline is shown beside the figure. A period with no comparable baseline shows no saving rather than an estimate.

No baseline, no saving — the figure is not shown.

Scoping is applied where the query is built rather than at each endpoint, so it has one place it can be forgotten rather than one per route. A read, list, search or download across organisations answers as though the record does not exist — because a refusal would confirm it does, and a plant’s layout and equipment list are facts about somebody else’s business.

A cross-organisation read answers 404, not 403.