A LIMS where compliance is a property of the database

A sample record: storage and custody, aliquot and derivation lineage, a DataMatrix label, and versioned, four-eyes-verified results with a QC verdict.

Why lims-core

Compliance as schema, not as feature

The audit trail is hash-chained and written by database triggers, results are versioned rows that can never be overwritten, and signatures are bound by hash to the exact record version they approve. The app connects as a least-privilege role that cannot alter any of it.

Biobank and analytical on one core

Samples, tests, results, storage, and custody are modeled once. The biobank workflow came first; the analytical layer — specifications, worksheets, QC controls with Westgard rules, certificates of analysis — is built on the same core as modules, not a rewrite.

A modern, hireable stack

TypeScript, PostgreSQL, and React, not a legacy Java/Oracle platform. That is a far easier maintenance and hiring story, and it is why the compliance controls could be pushed down into the database in the first place.

Immutable by construction

Audit events, custody, results, and signatures reject UPDATE and DELETE by trigger. The runtime role cannot insert audit rows at all, so there is no path — not even a buggy one — to rewrite history.

Open source, no lock-in

AGPL-3.0 licensed: nobody can take this code and sell it back to you as a closed platform. Your specimen data and its full custody record live in a Postgres database you own and can query directly.

Honest about scope

This is a broad, working build on a production-shaped compliance core, not a validated production system and not a drop-in replacement for a large commercial LIMS. The roadmap is specific about where the line is.

Where to start

Getting started

Run the full stack locally in five commands, with a seeded demo study and accounts for every role.

User guide

The everyday lab tasks — accession, store, ship, aliquot, run assays and QC, sign, and review — screen by screen, with no code.

Compliance

Each guarantee, the database behavior that enforces it, and the automated test that proves it, with a traceable requirement ID.

Roadmap and status

What works today, what is designed, and what is not started — the honest, code-checked gap analysis.

Start here by seat

Lab and biobank teams

Accessioners, technicians, and lab managers: the receiving desk to a signed result, with the freezer map, shipments, aliquots, and holds.

Data managers and scientists

An open Postgres data model you can query directly, PHI-free by design, with EDC subject references rather than patient data.

Auditors and QA

The tamper-evident hash chain, one-click integrity verification, and a requirement-to-test traceability matrix for every control.

CRO and pharma leadership

The compliance posture, the open-source exit path, and an honest read on what a modern LIMS nucleus can and cannot claim today.

Status: a broad, working build, not yet validated. The biobank and analytical workflows both run front-to-back on a production-shaped compliance core, covered by tests that run against a real Postgres in CI. But lims-core is not yet a validated production system for running a regulated biobank, and not a drop-in replacement for a commercial LIMS. Read the completeness review before planning any deployment, and follow progress on GitHub.