Aquifer is the public survey inside Oolitic, DArnTech's on-prem domain-intelligence program. It reads the open world around PyLabRobot and labautomation.io — the code and its docs, the community's shared protocols, and the forum threads where its users talk — and organizes all of it into one structured map of how that world fits together.
It is a map of their public surface, not a product demo. Everything here is sourced from public material, credited to its authors, and links back to them. Read the four promises below before the map.
Every item is the work of the open community. We credit labautomation.io / PyLabRobot and link back — never presenting their work as ours.
This is an independent survey. DArnTech / Oolitic is not affiliated with, sponsored by, or endorsed by PyLabRobot or labautomation.io.
We map and redistribute only what each item's license allows — structure and citations with attribution; forum posts paraphrased and credited, never republished wholesale.
This page surveys the community's public surface. It renders no Oolitic engine output and makes no built-product claim — it is a map.
The open world sorts into a handful of facets. Each one states what the public surface actually provides, how rich or thin that coverage honestly is, and — as a concept, not a running feature — the shape it would map onto in an operating layer.
PyLabRobot's most mature surface. It splits cleanly into a Resource Management System (the
model of physical reality) and a Machine Control System. The resource side gives every piece
of labware a typed, spatially-aware definition — geometry, coordinates, volume — nested into a tree rooted at
the deck. All of it lives in the pylabrobot.resources package.
Deck — the root container / coordinate origin.Carrier / PlateCarrier / TipCarrier / ResourceHolder — positioning and holding intermediaries.Plate → Wells · TipRack → TipSpots · Container / Trough reservoir types.A typed, nested, geometry-bearing resource tree is structurally a node set for an operation graph: each labware item is a typed node with attributes and parent/child edges. The point of the map is that the open ontology already supplies a clean node vocabulary to align to — you map onto theirs, you do not invent labware types.
License posture: PyLabRobot is MIT. The class taxonomy and docs are freely citable and mappable with attribution and link-back — no restriction here.
The operator always talks to one stable interface layer (LiquidHandler,
PlateReader, …). Each interface holds a backend that translates universal commands
into hardware-specific instructions. The whole liquid-handling surface reduces to four universal atomic
commands — pick_up_tips, drop_tips, aspirate,
dispense.
Two roles. The backend roster is the operation-graph instrument layer — the set of executable targets a method can bind to. And the open Python API is the natural emit target: an operating layer generates to this open interface, never to a proprietary vendor GUI. Emitting to an open API is what keeps the whole approach clean-room.
License posture: MIT. The backend roster and the atomic-command contract are public API surface — freely mappable with attribution.
The facet that matters most for "shared protocols" is, honestly, the thinnest in delivered form. What actually exists in public today:
Where public protocols exist they map directly to operation sequences — ordered atomic-command chains over the Facet 1 nodes, bound to Facet 2 instruments. The turbidostat is the one concrete, fully-described public sequence; the named families are labels without canonical public implementations.
This facet is rich in demand and thin in delivered protocols. There is no large public corpus of canonical protocols — there is genuine demand and a nascent, open Cookbook the community is building itself. We map what exists and say plainly where it is sparse. Anyone claiming "a protocol corpus" here today would be inflating it.
License posture: Cookbook recipes ship under PyLabRobot's MIT license (verified per-file before any redistribution). Forum-posted protocols are user posts — summarized, attributed by username, and linked back; never republished wholesale.
Two community surfaces carry the demand and pain signals: the broad labautomation.io Lab Automation Forums, and discuss.pylabrobot.org where the deep development threads live. The clearest single artifact is the wishlist thread — "What do you wish PLR did that it cannot currently do?" — every distinct request below, credited to the person who asked.
| Asked by | Want | Category |
|---|---|---|
| cwehrhan | A repository of basic protocols people can riff off — "would really help my non-technical colleagues" (cherry-picking, normalization, serial dilution, plate stamper, visual transfer selector) | protocol-library gap |
| CamilloMoschner | Standardize STARBackend argument naming across methods | API design |
| CamilloMoschner | "Documentation, documentation, documentation" | docs |
| CamilloMoschner | Resource-model overhaul — ResourceHolder for trays, Rack subclasses, multi-child carriers, Tip/TipRack rework | resource model |
| CamilloMoschner | Versioning + simpler install for entry/mid-level scripters | deployment |
| CamilloMoschner | Error handling for tip_pickup / aspirate / dispense / drop_tip | error handling |
| CamilloMoschner | New machine integrations — "big one == arms" (robotic arms) | hardware |
| cwehrhan | Visualizer: green-circle transferred wells, red error wells, toggle name layers | visualizer |
| hazlamshamin | Visualizer time-travel playback — "click forward and backward through the states like a debugger" | visualizer |
| cwehrhan | Formulatrix FLO i8 support (cLLD, sensors, camera); Tecan Fluent noted unrealistic now (no firmware docs) | hardware |
Forum threads are the seed of a pattern library — what counts as "normal," where hand-offs happen, where things break. The pattern that jumps out is the absence of one: error handling and safety on the atomic commands is a top wish, not a delivered feature. That absence is the precise shape of the gap an operating layer would fill — reasoning that inserts the safety gate a hand-off requires — and the forum proves the demand for it in the community's own words.
This facet is rich in what people want and thin in documented safety/handoff patterns anyone could lift. There is no public corpus of "validated safety gates for protocol X." So this is demand-evidence today, not pattern-content — useful for showing the community asks for exactly this, not yet a mineable knowledge base. We will not overstate it.
License posture: all forum content is user-authored. Posture here is link + attribute by username + paraphrase the request — post bodies are never republished.
The serialization side is well-defined and public; the safety side is where the open surface stops — and that stopping point is itself the signal.
Resource serializes via .serialize() /
.save() to JSON — a full recursive dump of the resource tree (children, coordinates, wells);
Resource.load restores it.save_state_to_file / serialize_all_state() and their load counterparts.validation.json
convention (which records what was tested, not safety rules). Error handling is a wishlist item, not a
shipped subsystem.The JSON resource/state schema is the natural schema authority to align to — you validate a generated protocol against the format the open execution layer already accepts, so output is always well-formed. The safety-validation authority is the part the open surface leaves empty — which is exactly where a reasoning layer would sit. Mapping onto the public schema is clean-room and credible; the safety reasoning on top is the part nobody has built.
License posture: the schema is MIT API surface — freely mappable with attribution.
A community is its people. These are the public voices steering the open ecosystem — the maintainers, the most active contributors, the persona who named the gap, and the academic origin. Mapped from public posts and the published paper, credited to each, and read as an ally surveying the ecosystem — not a competitor scraping it.
| Person / org | Role in the ecosystem | What the signal means |
|---|---|---|
| rickwierenga | Core maintainer + primary decision-maker; lead author of the paper | Gatekeeper of what the project becomes; sets conventions and a "keep it simple" posture. |
| CamilloMoschner | Most active power-contributor; created the Cookbook; deep resource-model + deployment voice | The person actually building the open protocol-library / AI-training surface — closest to the commoditization edge; worth watching closely. |
| cwehrhan | Voiced the non-programmer protocol-library gap, plus visualizer and hardware wishes | The literal persona an operating layer would serve — "help my non-technical colleagues." |
| aidan-baydush | Proposed the Protocol Library; contributed a working turbidostat protocol | Demand for shared protocols, expressed directly in code. |
| hazlamshamin | Asked for visualizer time-travel / playback | Appetite for richer state and observability — adjacent to operation-graph value. |
| Paper authorsWierenga, Golas, Ho, Connor Coley, Kevin Esvelt · MIT Media Lab · Device (Cell Press) 2023 | The project's academic origin | Credibility anchor; Coley and Esvelt are recognizable names in the field. |
| Pioneer LabsDevon Stork | Published "We Replaced Our Automation Software Stack With Python" | The flagship "a real lab dropped its vendor stack" proof point, and a clear picture of the self-serve scientist persona. |
| Argonne RPL, Opentrons community | Institutional and adjacent users | Breadth of adoption across the field. |
The open lab-automation surface beyond PyLabRobot proper — the adjacent APIs, the standardization efforts that have not yet solved interoperability, and the reference material. Context for the "build on the open layer, don't compete with it" framing.
Each is single-vendor; the cross-vendor wedge is what sets PyLabRobot apart.
Named efforts exist, but none has solved interoperability at the execution layer:
The published paper notes interoperability "has yet to be adequately addressed by any existing interface" — the void the open execution layer fills, and that an intelligence layer would sit above.
10.1101/2023.07.10.547733 (bioRxiv); Cell S2666-9986(23)00170-9; PMC10369895Every source this map draws on, its public origin and license type, and exactly how Aquifer treats it. This ledger is the discipline behind the four promises — it is what makes the page defensible: we show only what each license permits, and we say where each thing came from.
| Source | License / type | How Aquifer treats it |
|---|---|---|
| PyLabRobot code + docs + Cookbook | MIT | Map the structure freely, with attribution + link-back; verify each file's license before lifting any code. |
| Device / Cell paper | Journal (Cell Press) | Cite by DOI; do not redistribute full text. |
| labautomation.io · discuss.pylabrobot.org posts | User-authored forum posts | Paraphrase + attribute by username + link; never republish post bodies. |
| Pioneer Labs substack | Authored blog | Cite + link; quote minimally with attribution. |
| Standardization projects (SiLA, LabOp, …) | Various | Reference by name + link only. |
| Lab Automation Wiki (labautowiki.org) | Community wiki | Reference by name + link only; never republish entries. |