Solutions
Six workflows we build end to end
Use case index
An experiment defined once runs, is analysed, informs a model, and produces the next experiment without manual data transfer.
ELNMiddlewareAutomationAnalyticsML optimizer
View use caseExperiment definitions become executable automation workflows, and results return to the originating ELN record.
ELN templateTranslation layerAutomation runELN record
View use caseBayesian optimization and DoE running as a service, proposing conditions that automation systems can execute directly.
Parameter spaceOptimizerProposalExecutionObservations
View use caseInstrument output collected, parsed, validated and stored with full context, then exposed to analytics and models.
InstrumentsIngestionTransformationStorageConsumers
View use caseRetrieval and agents grounded in your SOPs, databases and scientific systems, with approval gates on anything that changes state.
QuestionRetrievalAgentReviewAction
View use caseA vendor-independent integration layer so systems connect through one contract instead of point-to-point adapters.
Source systemsAdaptersCanonical modelConsumers
View use case
Use case
Closed-loop experimentation
- 01
ELN
Experiment defined
- 02
Middleware
Compiled to a run
- 03
Automation
Executed on the deck
- 04
Analytics
Results captured
- 05
ML optimizer
Next conditions proposed
The loop closes. Each result feeds the next proposal, and the next proposal becomes the next experiment — without manual data transfer between systems.
The situation
The individual pieces already work. Experiments are defined in an ELN, an automation platform can execute them, instruments produce analytical data, and a model can propose better conditions. What is missing is the connective tissue: today a scientist exports results, reformats them, runs the model, reads the proposal, and re-enters it as a new experiment. That gap sets the iteration rate.
Outcome
Cycles run end to end without manual transfer. Every proposal is traceable to the data behind it, and the campaign can be paused, inspected or overridden at any point.
Systems involved
- ELN
- Scheduler
- Liquid handlers
- LC / GC / MS
- Optimizer service
- Data warehouse
What we build
- A canonical experiment definition that both the ELN and the automation platform can be driven from
- A compiler from that definition to device-level instructions and worklists
- Automated ingestion of analytical results, linked back to the run and conditions that produced them
- An optimizer service that consumes results and emits the next set of conditions as executable definitions
- Campaign-level controls: stopping criteria, budgets, constraints and scientist approval gates
Use case
ELN ↔ automation integration
- 01
ELN template
Structured definition
- 02
Translation layer
Validated and mapped
- 03
Automation run
Executed
- 04
ELN record
Results written back
The situation
Scientists design experiments in the ELN because that is where the record belongs. The automation platform needs plate maps, volumes, device programs and sequences. Somebody translates between the two by hand, and the translation is where transcription errors and lost context enter.
Outcome
One definition drives both systems. The ELN stays the record of intent and outcome, and the automation platform receives a validated, executable description of the work.
Systems involved
- ELN APIs
- Scheduler / workcell manager
- Liquid handlers
- Inventory
- Object storage
What we build
- A mapping between ELN experiment templates and automation run definitions
- Generation of plate maps, worklists and device programs from structured experiment data
- Validation before submission: reagent availability, volume limits, deck layout and hardware constraints
- Run status written back to the ELN record as execution progresses
- Results, files and run metadata attached to the originating experiment on completion
Use case
ML optimization platform
- 01
Parameter space
Constraints defined
- 02
Optimizer
Bayesian / DoE
- 03
Proposal
Executable conditions
- 04
Execution
Run in the lab
- 05
Observations
Fed back to the model
The loop closes. Each result feeds the next proposal, and the next proposal becomes the next experiment — without manual data transfer between systems.
The situation
Optimization logic exists in notebooks owned by individual data scientists. It is not reproducible across campaigns, not accessible to the lab, and not connected to execution. Each new project rebuilds the same machinery.
Outcome
Optimization becomes shared infrastructure. Campaigns are reproducible, proposals are auditable, and the lab can act on them without a data scientist in the loop for every cycle.
Systems involved
- BoTorch / GPyTorch
- scikit-learn
- Internal APIs
- Automation platforms
- Experiment tracking
What we build
- An optimization service exposing campaigns, observations and proposals over a versioned API
- Multi-objective Bayesian optimization, DoE generation and surrogate models with constraint handling
- Parameter-space definitions that encode real hardware, reagent and safety limits
- Proposals emitted as executable experiment definitions rather than tables
- A campaign interface showing progress, model state and the evidence behind each proposal
Use case
Scientific data pipeline
- 01
Instruments
Raw output
- 02
Ingestion
Collected and parsed
- 03
Transformation
Validated and normalised
- 04
Storage
Canonical schema
- 05
Consumers
Analytics and ML
The situation
Results sit on instrument workstations in vendor formats and folder conventions. Cross-campaign analysis means locating files, remembering which method produced them, and reconstructing the link to samples and conditions by hand.
Outcome
One queryable dataset instead of scattered files. Analysis and model training start from data that is already linked to its experimental context.
Systems involved
- Chromatography data systems
- PostgreSQL
- Object storage
- Airflow / Prefect
- Notebooks and BI
What we build
- Automated collection from instrument data systems, shared drives and APIs
- Parsers for vendor formats, with validation and unit normalisation at ingestion
- A canonical schema linking sample, conditions, run, method and measurement
- Provenance and audit metadata carried through every transformation
- Query, notebook and BI access layers, plus feature extraction for model training
Use case
AI laboratory assistant
- 01
Question
Asked by a scientist
- 02
Retrieval
SOPs, records, data
- 03
Agent
Tool calls against APIs
- 04
Review
Human approval gate
- 05
Action
Executed and logged
The situation
The knowledge needed to run an experiment correctly is spread across SOPs, protocol documents, past reports and the memory of experienced staff. New team members ask colleagues; experienced staff re-derive answers that already exist somewhere in the archive.
Outcome
Answers come with their sources attached, and the assistant operates inside defined boundaries rather than as an opaque layer over your records.
Systems involved
- Document stores
- Vector databases
- ELN / LIMS APIs
- LLM providers
- Audit logging
What we build
- Retrieval over internal documentation, protocols and historical experimental records, with citations to source
- Natural-language querying of experimental and analytical databases, returning data rather than prose
- Agents with an explicit tool surface: read ELN records, query databases, call internal APIs, draft definitions
- Human approval required for any action that writes to a scientific system
- Full logging of prompts, tool calls, sources and outputs for review
Use case
Custom laboratory middleware
- 01
Source systems
ELN, LIMS, instruments
- 02
Adapters
Vendor translation
- 03
Canonical model
One shared contract
- 04
Consumers
Automation, ML, reporting
The situation
Every new system connects to every other system directly. Six systems become fifteen possible integrations, each with its own auth, format and failure mode. Replacing one vendor means rewriting everything attached to it.
Outcome
Each system integrates once, against a contract you own. Swapping a vendor becomes one adapter rewrite instead of a cascade.
Systems involved
- REST APIs
- Message queues
- PostgreSQL
- Kubernetes / on-premise
What we build
- A canonical internal data model for samples, experiments, runs and results
- Per-system adapters that translate between vendor schemas and that model
- Reliable transport: queueing, retries, idempotency and dead-letter handling for long-running operations
- Observability: transfer logs, health checks and alerting on failed or stalled exchanges
- Versioned internal APIs so systems can be added or replaced without downstream rewrites
Which of these describes your situation?
If one of these workflows matches what you are trying to build — or if yours is a variation none of them cover — describe the systems involved and we will tell you how we would approach it.