Lattice by BalanceByte · In development
One system of record for every experiment your lab runs.
Sample lineage, instrument exports, versioned methods and a hash-chained audit trail in one place. When a PI, a journal or a funder asks you to prove what happened, the answer should take thirty seconds, not three days.
10 founding slots open · The counter is real, not a growth tactic
Labs don’t have an assay problem. They have a data problem.
In our discovery interviews and survey with core facilities and PI labs, four pains surfaced independently. Only one of them is assay-specific, which is exactly why a single-assay tool cannot fix them.
Where is sample A7?
Specimen tracking lives in freezer sheets and spreadsheets. The person who knows the layout is the system of record.
Instrument data scatters
Every instrument exports somewhere different. Finding the raw file behind a figure means archaeology across shared drives.
Analysis happens in Excel
Thresholds, exclusions and formulas drift silently between workbooks, and nobody can say which version made the number.
You cannot reproduce it
When a PI, a reviewer or a funder asks what happened to a sample, reconstructing the answer takes days, if it is possible at all.
One provenance platform, whatever the experiment.
Almost everything a lab data system does is identical regardless of the experiment. Only the analysis step differs, so the common core is built once and analysis attaches to it.
That is why an all-in-one promise is honest here rather than aspirational: from your side, every experiment lives in one system, whether Lattice computed the result or recorded who did.
-
Identity & lineage
Samples, aliquots and derivations with full lineage, using one model regardless of which instrument the sample ends up in.
-
Ingestion adapters
One adapter interface, so each instrument gets a parser that normalises its export into a common envelope. Adding an instrument is a plugin, not a schema change.
-
Method & protocol versioning
Versioned methods, protocols, thresholds and parameters: the thing that drifts in every lab, in every assay.
-
Provenance & audit
A hash-chained event log covering registration, transformation, exclusion, analysis and reporting. Assay-independent, and the part that makes a record checkable.
-
Result envelope
Who, which sample, which method version, when, all wrapped around the result itself. The envelope is queryable across every experiment type.
-
Access, export & reporting
Search, permissions, tenancy and export. Your data leaves in open formats whenever you ask for it.
Your own numbers, reproduced to the decimal.
Our first analysis capability was built against a real laboratory’s real workbook and reproduced 100% of its results to the decimal, then added the QC flags and the audit trail a spreadsheet could never carry.
That is also the fastest way to judge us, and we would rather be judged that way than on a feature list. Send one raw instrument export and the workbook you process it with, and we will put your numbers next to ours, side by side. Fifteen minutes, and you keep the comparison either way, whether or not you ever become a customer.
- 1.00001.0000match
- 2.41312.4131match
- 0.88740.8874match
- 3.19023.1902match
- ……100% match
Illustrative of a validation run against a laboratory’s own workbook. Your numbers, your instrument, before you commit anything.
The cohort decides the order. Not a slide.
We architect for every experiment type from the start, because schema decisions are irreversible. We build a specific capability only when a specific laboratory has said it will use it.
So there is no roadmap slide here promising your assay by a quarter we invented. Tell us what your facility actually runs and where the data hurts, and we will tell you plainly whether it is built, in build, or a conversation for next year.
Built once, not per assay
Almost everything a laboratory data system does is identical whatever the experiment: identity, ingestion, versioned methods, provenance, export. Only the analysis step differs, so the common core is built once and analysis attaches to it.
Specifics under NDA
Which capabilities exist today, which are in build and which instrument exports we read are commercially sensitive, so we cover them on a call rather than publish them. A mutual NDA is available before any technical detail changes hands.
Nothing is claimed before it works
On the call you get a straight answer about what is validated and what is still in build, before you commit anything. A founding core that finds out later is a founding core we have lost.
Ten facilities build this in the open with us.
Lattice is being built with its first customers rather than sold to them afterwards. We are looking for ten core facilities and PI labs who will run real samples through it, tell us plainly what they need, and get the system they actually want instead of the one we guessed at.
What you get
- 50% off the first year, with founding pricing locked afterwards
- Your instrument formats supported first
- A direct line to the person building it, not a ticket queue
- Your own workbook reproduced and validated before you commit
- Full export of everything, in open formats, whenever you want it
What we ask
- Real samples and real exports, not a sandbox
- About an hour every two weeks for six months
- Candid feedback, including the unflattering kind
- Permission to say you are a founding core once you are happy with it
Institutional requirements vary, and we would rather work through yours directly than guess at them here. Bring your security review, data-protection agreements and any compliance obligations your institution requires to the first call, and we will tell you exactly how we meet them.
Apply · 10 slots open
Founding core application
Five fields. A real person reads every one and replies within two working days.
Do we have to change instruments or software?
No. Lattice reads the exports your instruments already produce. Where a mature analysis ecosystem already exists around an instrument, we do not try to replace it: we capture the inputs, the tool and its version, the parameters and the outputs, and bind them to the sample and the audit chain. You keep your tools, and we make the result reproducible and findable.
Does this compete with our LIMS or with iLab?
No. Scheduling, billing and recharge systems solve a different problem. Lattice sits where the data is: intake, instrument output, analysis and the record of what happened. Where a facility already runs a LIMS, we integrate around it rather than ask anyone to migrate.
What does this do for our NIH Data Management & Sharing plan?
A DMS plan makes commitments about retention, documentation and sharing that someone has to make true after the award. Lattice is where those commitments become checkable: versioned methods, a durable record of every transformation, and exports in open formats. We will not tell you it files your plan for you. It makes the plan defensible.
Where does our data live, and who can see it?
Your data is yours. It is stored in an isolated tenant, access is role-scoped, every read and write is written to the audit chain, and we do not use customer data to train models or sell anything derived from it. Full technical detail is available under NDA before you commit anything real.
What happens to our data if BalanceByte disappears?
You can export everything (samples, methods, results and the full audit chain) in open formats at any time, without asking us. That is a design requirement, not a courtesy: a provenance system you cannot get your records out of is not a provenance system.
What does it cost?
Lattice is priced against the whole lab’s data rather than one workflow, on an annual per-lab basis. Founding cores get 50% off the first year and locked pricing afterwards. We will quote you a real number on the first call rather than make you fill in a form to find out.
Something not answered here? Write to [email protected] and the people who build Lattice answer it.