Skip to content

Schedule more than one plate, and price a plate-moving arm honestly - #3

Open
di-omics wants to merge 1 commit into
mainfrom
feat/workcell-scheduling
Open

Schedule more than one plate, and price a plate-moving arm honestly#3
di-omics wants to merge 1 commit into
mainfrom
feat/workcell-scheduling

Conversation

@di-omics

Copy link
Copy Markdown
Owner

autonomous_lab/orchestrate.py plus autonomous-lab schedule. Every existing layer costs a single run; this is the first that asks what happens when a second plate enters.

The design constraint: no durations

throughput already refuses a plates-per-day number because 18 of 18 steps are untimed, and adding plates makes that refusal stronger -- a pipelined estimate compounds every unmeasured duration in it. So this computes only what is structural:

  • Serialization point: the instrument owning the most steps (Namocell, 7 of 18). True at any speed, needs no stopwatch, and names which box to buy a second of.
  • Stalls, classified not collapsed: five constraints stop a run and each costs a different budget -- decode, handoff, gate, trust, attended.
  • Cycle time: explicitly refused, with the reason.

The result worth reading

arm_relief() prices the reflex answer to a stalling schedule. On the genomics protocol a plate-moving arm clears 5 of 22 stalls and none of the 8 undecoded commands. It carries plates and reports the move, which is the only thing that closes a custody gap, and it decodes nothing. Which purchase helps is computable before the order rather than after it.

trust is scoped to where it binds: a USB enumeration moves nothing, so no robot benchmark gates it. It fires only where the machine can act and has not earned the right, so proving run cards moves stalls from decode to trust rather than removing them.

Provenance

Every stall resolves from the layer that already computed it -- verdicts from the ledger, hops from handoffs(), readiness from qc, benchmarks from intelligence. A test pins the unattended-step count to the ledger's own headless_prefix(), because two answers to that question would eventually disagree with nothing to reveal which was wrong.

11 new tests. Recreated after the PR history was reset; the branch is unchanged.

Every layer here costs a single run. A workcell exists because one plate at a time wastes
the instruments, and the second plate introduces constraints a single-run report cannot
see. Nothing in this package computed them.

Computes them without durations, which is the constraint that shaped the design.
`throughput` refuses a plates-per-day number because 18 of 18 steps are untimed, and
adding plates makes that refusal stronger rather than weaker: a pipelined estimate
compounds every unmeasured duration in it. But the serialization point is the instrument
that owns the most steps, which is true at any speed and needs no stopwatch, and it names
which box to buy a second of.

Stalls are classified rather than collapsed. Five constraints stop a run and each is
cleared by a different budget -- decode is reverse-engineering, handoff is a plate mover
or a barcode, gate is an instrument that returns a usable number, trust is a calibration
experiment, and attended is the one no purchase fixes.

arm_relief() prices the reflex answer. On the genomics protocol a plate-moving arm clears
5 of 22 stalls and none of the 8 undecoded commands: it carries plates and reports the
move, which is the only thing that closes a custody gap, and it decodes nothing.

Scopes trust to where it binds. A USB enumeration moves nothing, so no robot benchmark
gates it; it fires only where the machine can act and has not earned the right, so proving
run cards moves stalls from decode to trust rather than removing them.

Every stall resolves from the layer that already computed it rather than being recomputed,
and a test pins the unattended-step count to the ledger's own headless prefix.

11 new tests, 156 total.
@di-omics
di-omics force-pushed the feat/workcell-scheduling branch from e445d07 to c604875 Compare July 29, 2026 17:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant