Engineering across the scientific software stack

Problem

Scientific stacks grow one system at a time. An ELN is chosen by chemistry, a LIMS by analytics, a scheduler by the automation group, and instrument software arrives with the hardware. Each system has its own data model and its own idea of what an experiment is. The result is manual re-entry, exported spreadsheets moved by hand, and results that are hard to trace back to the conditions that produced them.

Solution

We build the middleware between those systems: typed data contracts, translation between each vendor's schema and a canonical internal model, queueing and retries for long-running operations, and audit trails for every transfer. The integration layer runs in your infrastructure and stays independent of any single vendor, so replacing one system does not require rewriting the others.

Example use cases

• Push an experiment defined in an ELN into a scheduler as an executable run, then write results back to the originating record
• Synchronise sample and batch identity across LIMS, inventory and automation systems
• Normalise instrument output into one schema so downstream analysis does not branch per vendor
• Replace file-drop and email handoffs between groups with monitored, idempotent API transfers

Typical integrations

• REST APIs
• Webhooks & event queues
• SQL / object storage
• CSV, XML and vendor file formats

Problem

Automation hardware is usually capable of more than the software around it allows. Protocols are authored by hand in vendor tools, run parameters are copied between screens, and error handling depends on whoever is watching the deck. Scaling from a demonstration run to routine throughput exposes every manual step in the chain.

Solution

We write the orchestration layer above the hardware: experiment definitions compiled into device-level instructions, run scheduling and resource allocation, state tracking through execution, structured error and exception handling, and result capture with full run context. Your existing vendor software keeps doing what it does well; we build what sits above and around it.

Example use cases

• Generate plate maps, worklists and device programs from a structured experiment definition
• Coordinate multi-device sequences with dependency and resource constraints
• Track run state and surface exceptions to operators with enough context to intervene
• Attach every measurement to the conditions, sample and run that produced it

Typical integrations

• Liquid handlers and robotic platforms
• Schedulers and workcell managers
• Analytical instruments (LC, GC, MS, NMR, plate readers)
• Device drivers and instrument control APIs
• Barcode and sample tracking systems

Problem

Off-the-shelf ELNs cover general documentation well and specialised workflows poorly. Teams end up maintaining parallel spreadsheets for the parts the product does not model — reaction arrays, screening campaigns, formulation matrices, device-specific run metadata — and the record of what happened splits across tools.

Solution

We build or extend applications that model your domain directly: structured experiment templates, campaign and array management, review and approval flows, and dashboards over live experimental data. These applications integrate with the systems you already run rather than replacing them, and they use your authentication, permissions and storage.

Example use cases

• Extend an existing ELN with domain-specific modules and API-driven automation
• Build a screening or campaign manager that models arrays of conditions as first-class objects
• Give scientists dashboards over live run and result data instead of exported reports
• Model review, sign-off and versioning for regulated or audited workflows

Typical integrations

• Commercial and open-source ELNs
• LIMS and inventory systems
• SSO (SAML / OIDC) and existing permission models
• Internal data warehouses
• Chemical structure and registration systems

Problem

Optimization work often stops at the notebook. A data scientist builds a model that suggests good conditions, but proposals reach the lab as a message or a spreadsheet, results come back days later in another format, and the loop runs at the speed of manual transfer. The modelling is sound; the plumbing is what limits the iteration rate.

Solution

We build optimization services that run as part of the workflow: multi-objective Bayesian optimization, DoE generation, surrogate and predictive models, and constraint handling that reflects real reagent, hardware and safety limits. Proposals are emitted as executable experiment definitions and results are ingested automatically, so each cycle closes without human data transfer.

Example use cases

• Multi-objective optimization of reaction conditions against yield, purity, cost and throughput
• DoE generation and analysis integrated with automated execution
• Predictive models for process parameters, stability or analytical outcomes
• Active learning campaigns that select the next batch of experiments from current results

Typical integrations

• Python ML stack (scikit-learn, PyTorch, GPyTorch, BoTorch)
• Optimization services exposed over internal APIs
• Experiment tracking and model registries
• Automation platforms and schedulers
• Analytical data pipelines

Problem

General-purpose assistants do not know your protocols, your instruments or your data model, and an assistant that cannot be audited has no place near experimental records. The useful version is narrow, grounded in internal sources, and explicit about what it did.

Solution

We build retrieval systems over internal documentation and structured scientific data, and agents with a defined tool surface — querying databases, reading ELN records, drafting experiment definitions, calling internal APIs. Actions that change state are gated behind human approval, and every step is logged with its inputs, its sources and its result.

Example use cases

• Retrieval over SOPs, protocols, internal reports and past experimental records with citations
• Natural-language querying of experimental and analytical databases
• Drafting experiment definitions from a described objective, submitted for scientist review
• Assisted triage of failed runs by correlating logs, instrument output and run metadata

Typical integrations

• Internal document stores and wikis
• Vector and relational databases
• ELN, LIMS and automation APIs
• LLM providers, self-hosted or via API
• Approval and audit-logging systems

Problem

Analytical data tends to live where it was generated: on instrument workstations, in per-vendor formats, in folders named by whoever ran the sample. Answering a question across six months of experiments becomes a manual archaeology exercise, and models are trained on whatever subset was easy to extract.

Solution

We build ingestion and transformation pipelines for scientific data: parsers for vendor formats, validation and unit handling, canonical schemas that keep the link between sample, conditions, run and result, and storage designed for query rather than archival. The output is a dataset your analysts and models can use without preprocessing it again each time.

Example use cases

• Automated ingestion and parsing of chromatography, spectroscopy and plate-reader output
• Canonical schemas linking samples, conditions, runs and measurements
• Validation, unit normalisation and provenance tracking at ingestion time
• Query and analysis layers over historical experimental data

Typical integrations

• Instrument data systems (CDS and equivalents)
• PostgreSQL, time-series and object storage
• Workflow orchestration (Airflow, Prefect, Dagster)
• Cloud and on-premise infrastructure
• BI, notebook and ML consumers