THEPROTOCOL

ALEMBIC

#22 of 27Frontier · a future case9/9 primitives live in production
Self-Driving Labs and Wet-Lab Automation

Self-driving labs that book another lab’s robots, order reagents inside a named scientist’s mandate, and pay per run on the instrument’s own signature.

Open the live chamber in the app
The animated flow, the attack replays and the deep architecture run there; this page is the reference text.

Who this serves

The problem

Autonomous experimentation has outgrown its paperwork. A planning model proposes a hundred experiments overnight, but booking another lab’s robots, ordering reagents and paying per run still wait for a person with a purchase card, and when a result is questioned nobody can show which instrument ran it, from which reagent lot, under whose authority.

The system

ALEMBIC is a self-driving laboratory network for battery materials: a campaign planner in Singapore, a robotic liquid-handling lab in Leuven and a cell-cycling lab in Basel, each on its own frame. At 02:10 on a Tuesday, campaign 17 closes its eleventh round. The planner reads the capacity fade of the last 24 cells, proposes the next 24 electrolyte formulations and books four hours of the Leuven handler at 60 units a run. Each run is escrowed at booking and released on one thing only: the handler’s own signed attestation of what it mixed, from which reagent lot, under which protocol version.

Dr Amara Okafor, the principal investigator, never touches a purchase card. She funds campaign 17’s purse with 12,000 units and underwrites it with one mandate for ninety days, confirmed on her phone. The planner is the campaign’s own sub-agent: it holds no wallet, spends the campaign’s purse, and every run it books is checked against her mandate as it stands at that moment. The procurement desk orders on a capability token cut from the campaign’s authority, naming three approved suppliers, and a token can only narrow what its issuer holds. When the planner, working from a mislabelled paper, has the desk reach for a precursor from a supplier outside the list, the order is refused before a unit moves, and the refusal is recorded for her to read in the morning.

The results land where they cannot be edited. A negative round is as durable as a positive one, every data point traces back to an instrument identity and a paid run, and a reviewer can replay the campaign from its references. A result that no instrument signed never reaches the ledger, and a run that never happened cannot be paid.

The cast and their ceilings

AgentRoleCeiling
campaign-plannerProposes each round, books the runsThe campaign’s sub-agent, with no wallet of its own. Every booking is checked against Dr Okafor’s mandate as it stands, so revoking it stops the next one.
procurement-deskOrders reagentsA token cut from the campaign’s authority: three suppliers, a budget, ninety days. Cannot widen any of them.
handler-LEU-3Runs the formulations, signs each runAttests its own runs. Holds no budget and releases nothing.
cycler-BAS-7Cycles the cells, signs the resultsAttests results for runs it received. Cannot book, order or pay.

The flow, step by step

  1. Dr Okafor underwrites campaign 17 once: a budget, three suppliers, two instruments, ninety days.
  2. The planner reads the last round and proposes the next 24 formulations.
  3. Inside the mandate, robot time in Leuven is booked and escrowed run by run.
  4. Reagents go only to the suppliers on the list. Their own screening still applies.
  5. The handler signs each run: what it mixed, from which lot, under which protocol version.
  6. Each signed run releases its payment exactly once and lands on the ledger with its provenance.
  7. In Basel the cycler signs the cells’ results. A result no instrument signed never reaches the ledger.

Each need, mapped to a live primitive

The needThe protocol primitiveStatus
A named scientist behind every spendCockpit Card mandate, scope-clamped, re-derived per requestLIVE (gated)
Budgets, suppliers and instruments as boundsIRONKEY L4 capability caveats: counterparty allowlist, atomic budget debitLIVE
Robot time booked and paid per runContract spine: escrow at booking, released per attested runLIVE
Each instrument its own identitySPIFFE identity per instrument agent, short-lived certificatesLIVE
Runs that sign themselvesSigned attestations from identified parties, append-onlyLIVE
Paid exactly once, whatever retriesIdempotency keys, two-layer dedup (cache + ledger unique)LIVE
Labs in different currenciesCross-registry transfer and FX pools across sovereign framesLIVE
A campaign anyone can replayImmutable event ledger; a run is replayable evidenceLIVE
A failed run, contestedFour-phase dispute; the ruling drives the escrow splitLIVE

The attack this chamber refuses: The mislabelled precursor

The attack. Working from a mislabelled paper, the planner has the procurement desk order a precursor from a supplier that is not on the campaign’s list.

Why it fails. The procurement desk acts on a capability token cut from the campaign’s authority, and its caveats name the three suppliers. The payment is checked against those caveats and against the issuer’s authority as it stands now, before any escrow is touched. A token can narrow what its issuer holds; it cannot add a counterparty.

Rail S03 · Capability attenuation. A capability token conveys its caveats intersected with the issuer’s current authority, nothing more.

What actually happens. No order, no escrow movement, nothing to unwind. The refusal is recorded, waiting for the PI.

The attack this chamber refuses: The run paid twice

The attack. A faulty driver on the handler retries its attestation after a crash, and a second copy of the same run arrives asking to be paid.

Why it fails. Each run is its own milestone on the booking, and a milestone releases once: the first signed report claims it, and its payout carries a key made from the booking and the milestone. The copy of the same run finds nothing left to release, and a retried release replays under the same key and moves nothing.

Rail S15 · Exactly-once money. Money moves once across retries, crashes and duplicate submits.

What actually happens. The lab is paid once for one run. The duplicate is visible, not profitable.

Deep architecture

ALEMBIC deployed: the campaign’s frame holds the PI’s mandate, the run escrow and the result ledger; the labs sell robot time from their own frames; the instruments, the reagents and the LIMS stay where they are, signed at the edges. The trace replays one round of campaign 17, from the mandate to the preserved result.

The deployment, traced

  1. Dr Okafor funds campaign 17’s purse and underwrites it once, with her device key, for ninety days.
  2. The planner reads the last round and proposes the next 24 formulations.
  3. The planner, the campaign’s sub-agent, books four hours of the Leuven handler, run by run, each booking checked against her mandate.
  4. Each run is escrowed at booking, on the campaign’s frame.
  5. The procurement desk orders reagents from the three listed suppliers only. Their own screening still applies.
  6. The handler signs each run with its own identity: what it mixed, from which lot, under which protocol version.
  7. In Basel the cycler signs the cells’ results.
  8. The signed runs cross the fabric; the relaying peer is a courier, never the principal.
  9. Each signed run releases its payment exactly once.
  10. The lab is paid on its own frame, in its own currency.
  11. The ledger keeps every run, positive or negative, with its provenance. A result no instrument signed never arrives.

Adoption, phase by phase

Discover: One past campaign, re-read as bookings.

Pilot: One lab, one instrument, pilot budgets.

Production: The campaign’s own frame.

Federation: Labs bring their own frames.

Sizing

LevelWhatContainers
L1Scientists join with accounts and agents only0 of theirs
L2A lab runs its instrument agents against a hosted seatagents only
L3The campaign’s own frame, and each lab’s, federateda full frame each

One run, booking to preserved result

sequenceDiagram
  participant PI as Dr Okafor (device key)
  participant Pl as campaign-planner
  participant Man as campaign mandate
  participant TEG as run escrow
  participant Lab as handler-LEU-3 (lab frame)
  participant ES as result ledger
  PI->>Man: mandate for campaign 17, ninety days
  Pl->>Man: book the next 24 runs
  Man->>TEG: escrow per run, inside the mandate
  Lab->>TEG: run 42 signed: mix, lot, protocol version
  TEG-->>Lab: release, exactly once
  TEG-->>ES: run and payment, append-only
  Note over Man: an off-list supplier is refused before any escrow
  Note over ES: a negative round is as durable as a positive one

Topology, as declared

flowchart LR
  PI(["Dr Okafor<br/>mandate"]) -->|"scope"| G{"campaign gate<br/>budget, suppliers,<br/>instruments"}
  P["campaign-planner"] -->|"next 24"| G
  G -->|"robot time, escrowed"| E["run escrow"]
  G -->|"reagents, allowlisted"| S["approved suppliers"]
  H["handler-LEU-3"] -->|"run, signed"| E
  E --> L[("result ledger<br/>provenance")]
  C["cycler-BAS-7"] -->|"results, signed"| L

Standing it up

Runs beside what you already have

A full sovereign frame is nine containers and boots in about two minutes, on anything from a Raspberry Pi to a rack. That is cheap enough to run the whole system in parallel with the legacy stack: the old system keeps running, real work mirrors onto the rails, and you compare ledgers until the evidence settles the argument. Nothing is ripped out.

Planned: a public proxy library. Free, ready-made connectors for the systems above and whatever else a merge needs, so the bridge is an import, not an integration project.

What this does not claim