Skip to content
Samiel Remulla
← Selected work

PROJECT 06 · IN DEVELOPMENT

Proto-Lab

Protocol first. Automation attached.

A local-first development environment for scientific protocols and Opentrons automation.

Protocol first. Automation attached.

Scientific automation gets fragmented.

A single laboratory workflow can be spread across SOP documents, Python scripts, simulation tools, manual notes, revisions, and run history.

When those pieces live in different places, it is hard to see how the scientific procedure, the automation, and what actually ran belong together.

Make the protocol the workspace.

The scientific protocol becomes the primary object. Each protocol can hold scientific steps, manual actions, automated actions, Opentrons code, simulation output, revisions, run history, and notes or review.

Code is attached to the protocol. It is not the thing you organize everything else around.

Scientific steps and robot programs are not always one-to-one. One Opentrons program might perform an automated liquid-handling step, pause for a manual vortex or centrifuge, then resume. The interface should show that mixed workflow instead of assuming each scientific step maps to one file.

A mixed workflow

A protocol can move between human actions and robot execution without splitting the work across tools.

    Protocol timeline

  1. PROTOCOL

    Scientific Protocol

  2. 01 · MANUAL

    Preparation

  3. 02 · AUTOMATED

    Liquid handling

    Opentrons Python · Simulation

  4. 03 · MANUAL

    Vortex / centrifuge

  5. 04 · AUTOMATED

    Resume automation

    Opentrons Python

  6. HISTORY

    Run History

Proto-Lab protocol steps mixing manual lab work and Opentrons automation.
The protocol stays in view. Manual and Opentrons steps sit on the same list.
Proto-Lab editor with Opentrons Python attached to a scientific step.
Automation is attached to a step, not stored as a separate project.

Product principles

Protocol-first

The scientific procedure is the primary object.

Manual + automated

A workflow can move naturally between human actions and robot execution.

Local-first

Protocols and development artifacts should remain usable locally without depending on a cloud service.

Traceable

Code, simulation, revisions, and run history should stay connected to the protocol that produced them.

Direction

Proto-Lab is still being built. I am shaping it around a local protocol workspace, with structured steps and attached Python automation.

Opentrons simulation, revision history, execution history, and AI-assisted review are part of the product direction. They are not current capabilities.

Exploring now
Local protocol workspace, structured steps, attached Python
Still ahead
Opentrons simulation, revisions, run history, AI-assisted review
Status
In development

Protocol first. Automation attached.

The protocol stays at the center. Automation, simulation, revisions, and run history belong to that workflow instead of sitting in separate tools.