The electronic lab notebook arrived in research settings as an improvement over paper notebooks in the way word processors were an improvement over typewriters: you could search, copy, and share more easily, but the underlying model — a scientist records observations in a document — remained the same. That model served the research needs of the time. It is less adequate for the research needs of now, and progressively less adequate for where experimental biology is going.
This is not a criticism of ELNs. For many research contexts, a well-implemented ELN combined with disciplined data management is a significant step forward from the paper-and-spreadsheet baseline. The question is what comes after: as experiments become more computational, as the boundary between wet-lab and data pipeline blurs, as research teams run more experiments in parallel with more complex dependencies — what does the software layer that supports that work actually need to be?
What an ELN Was Built to Do
The ELN model has a clear scope: it is a structured record of what a scientist did and observed. Entry fields, protocol steps, result images, comments. The value is in the record — searchable, shareable, and audit-trailable in ways a paper notebook is not. For regulatory purposes, for lab knowledge management, for onboarding, that value is real.
The limitations become visible when you look at what an ELN does not do. It does not execute a protocol — it records one. It does not connect instrument output to the entry that describes the experiment — it accepts a file attachment, which is categorically different. It does not know that the ELISA data in entry 47 is derived from the same cell stock as the RNA-seq data in entry 51. The ELN records artifacts; it does not model the relationships between them.
This is fine as long as the experiments generating those artifacts are relatively simple and the research team is small enough that the relationships can be held in people's heads. When experiments become complex — compound screening, iterative CRISPR optimization, multi-omic readouts across a cell line panel — the mental overhead of maintaining those relationships exceeds what any individual can sustain reliably. The ELN fills up with entries that are individually correct but collectively opaque.
The LIMS Layer and Its Own Limits
The LIMS (Laboratory Information Management System) was the enterprise answer to the ELN's scope limitations. Where an ELN tracks what you did, a LIMS tracks what you have: samples, reagents, instruments, storage locations, chain of custody. The two systems are complementary in theory — the LIMS knows which sample went into the experiment, the ELN records what happened to it. In practice, connecting them requires integration work that most labs do not fully complete, so the two records exist in partial synchronization, mediated by manual cross-referencing or the researcher's memory.
LIMS adoption in academic settings has historically been limited by implementation complexity. Enterprise LIMS platforms are built for regulated environments — pharmaceutical QC, clinical diagnostics — where workflow standardization and system validation are requirements, not obstacles. For a university research lab or an early-stage biotech, the implementation overhead is disproportionate to the workflow flexibility the system offers. The result is that many growing labs either use a lightweight LIMS with limited integration, use no LIMS and manage sample inventory in spreadsheets, or deploy an ELN with LIMS-like features that are insufficiently powerful for complex sample tracking needs.
What "Operating System" Actually Means Here
The operating system metaphor is overloaded in tech, but in this context it has a specific meaning worth making precise. A computer's OS does not tell applications what to compute; it provides the services — memory management, process scheduling, file system, device drivers — that applications run on top of. The value of the OS is not in any single service but in the fact that all applications share the same substrate, so resources and interfaces are interoperable by default.
The lab OS metaphor maps to this directly: not a single application that replaces the ELN and the LIMS and the analysis notebooks, but a substrate layer that provides the shared services those functions run on top of. Experiment identity — a persistent, queryable object that all other records reference. Instrument data ingest — a unified interface that normalizes heterogeneous instrument output into a common schema. Protocol execution — not just recording but running, with parameter capture and audit trail built into the execution model. Analysis provenance — code that ran, what it was given, what it returned, all attached to the experiment record rather than living in a personal folder.
When these services exist as shared substrate, the ELN becomes a view over the experiment object rather than an entry that stands alone. The LIMS becomes the sample dimension of that same object model rather than a separate system. The analysis notebook runs against the experiment's data layer rather than an exported file. The integration problem largely dissolves because the pieces are not separate systems being connected — they are views over a common model.
The Computational Biology Boundary Is Moving
Lab software architecture that made sense for predominantly wet-lab research is showing its age as the computational component of experimental biology grows. Structural biology workflows today generate petabytes of cryo-EM data that require distributed compute for processing. Single-cell sequencing experiments generate data that requires complex pipeline management and cloud storage. Multi-omic studies combine data from instruments that were never designed to interoperate. The boundary between "running an experiment" and "running a computation" is not where it was in 2005, or even 2015.
An ELN-plus-scripts model handles this poorly because it was not designed around data volume or compute orchestration. A typical single-cell RNA-seq run at a research institution in 2025 might generate tens of gigabytes of raw data that goes through alignment, quality control, normalization, and dimensionality reduction before a biologist can interpret the first figure. Each of those pipeline steps is a scientific step, not just a technical one — QC thresholds, normalization method, clustering resolution are all scientific choices that affect the conclusions. An ELN that can attach a pipeline output as a file does not capture those choices; an experiment OS that treats the pipeline as a traceable, versioned component of the experiment record does.
What the Transition Actually Looks Like
We are not suggesting the ELN disappears. For many labs, the right near-term move is an ELN that connects to better infrastructure: instrument connectors that automate data ingest rather than requiring manual file export, an experiment data model that makes cross-run queries possible, and analysis tooling that writes back to the same record rather than to a separate file. The full lab OS model is a longer transition, not a replacement decision a lab makes in a weekend.
The transition tends to happen most naturally at the edges where the ELN model visibly fails. A team running high-throughput screening, or a group doing iterative design-build-test-learn cycles in synthetic biology, or a computational biology group where the data pipeline is as complex as the experimental design — these are the labs where the limitations of the document-record model become operationally painful rather than just theoretically awkward. That is where the architecture pressure builds, and where investment in a more capable substrate makes an obvious return.
The Decade Ahead
The laboratory informatics market is at an inflection point that looks, from a product design perspective, like the transition from on-premise to cloud software in the early 2010s. The existing architecture — ELN for records, LIMS for samples, separate analysis tools, integration by hand — has delivered genuine value. It will continue to be used by labs that are not yet at the scale or computational intensity where its limitations dominate. But the category of lab where the limitations do dominate is growing, and the software architecture to serve those labs requires a different starting model.
The next decade of lab software is likely to be characterized by two parallel developments: existing ELN and LIMS platforms continuing to add integrations and API capabilities that pull them toward the connected model, and new platforms built from the substrate-up around experiment objects, unified data schemas, and agent-assisted analysis. The researchers best served by that transition are the ones whose work is most constrained by the current stack's gaps — and that population grows every time a new sequencing or imaging technology becomes accessible at the bench.
At Cypher AI, founded in 2025 in Cambridge, MA, we are building specifically for the substrate layer: not a better ELN, not a lighter LIMS, but the experiment data model and agent infrastructure that makes the integration problem structural rather than perennial. That is a longer horizon than shipping another notebook feature. We think it is the right horizon to aim at, and the early conversations we have had with research teams running into these limits confirm that the need is both real and underserved.