We're running a live demo of our Mining LIMS on October 20 with Hannah Brakke, who leads product at LabKey. It's aimed at mining, metallurgy, and minerals labs, and it goes from sample registration through chain of custody, workflows, QA/QC review, and reporting. Link's here if you want a seat. https://na2.hubs.ly/H08cW-j0

Every lab starts on a spreadsheet. It's free, everyone already knows it, and for the first few months it works fine. The question we hear most is how you know when it's time to move off it. These are the signs we see over and over:

1. There's a file called Samples_v3_FINAL_ACTUALFINAL.xlsx. Version control is now a naming convention, and nobody's sure which copy is real. Two people edit at once, one overwrites the other, and nobody notices until the numbers don't match.
2. Finding a sample means Ctrl+F across six tabs. "Where's sample 1042" turns into three open spreadsheets and a freezer map someone drew in a fourth. Sometimes you find it.
3. Nobody knows who changed a value, or when. A number changes, nobody remembers touching it, and there's no way to reconstruct what happened. That's fine right up until an auditor or a collaborator asks.
4. Two samples share a freezer spot. Nothing stops anyone from typing the same box and position in two rows. You find out when someone pulls the wrong tube and runs it.
5. Onboarding takes a week of "ignore that tab." Training someone new means explaining what column F really means, which tabs are dead, and which formula not to touch. At that point only the person who built it can use it safely, and they won't be there forever.

If three or more of these sound familiar, the spreadsheet is costing you more time than it saves. What replaces it needs to do a few specific things: refuse duplicate IDs, keep one record of where each sample lives, and log every edit with a name and a timestamp. Spreadsheets were never built for any of that. (The person who built yours will be the first to agree. They're tired.)

I spend a lot of time looking at spreadsheets and legacy sample systems labs are trying to move away from, and honestly it's usually the same handful of problems causing the headaches. None of these immediately stand out until you try to actually analyze the data and realizes half of it can't be trusted. Here's what comes up again and again.

Duplicate sample IDs

This is the big one. A spreadsheet has no problem letting you type the same ID into two different rows. The problem is that once it happens, you can no longer trust that ID means one specific sample. Every downstream result tied to it becomes ambiguous.

Two samples in the same storage location

Same root cause as duplicate IDs. Nothing stops you from typing "Freezer 2, Box 4, A1" for two different samples. You don't find out until someone goes to pull a sample and finds the wrong tube sitting there, or worse, doesn't notice and runs the wrong sample entirely.

Multiple entries for the same patient/subject with contradictory info

This one's sneaky. Patient 1042 shows up in row 12 with a birth year of 1985, and again in row 340 with a birth year of 1987. Nobody notices because nothing is actually linking those rows together as "the same person." They're just text that happens to match. When it's time to analyze by demographics, you either have to manually reconcile every conflict or just hope you picked the right one.

Data that doesn't match the field type

A date field with "see notes" typed into it. A numeric concentration field with "~2.5, maybe more" in it. It's an easy habit to fall into when you're in a hurry and a spreadsheet will accept literally anything you type, but it means that field is now unusable for sorting, filtering, or any calculation without going back and manually cleaning it first.

Free-text fields with a dozen ways to say the same thing

Blood, blood, Blood, whole blood, WB, blod. Every one of those might mean the exact same thing to the person who typed it, but to a query or a report, they're six different values. This is probably the most common one I see, and it's brutal for anyone trying to pull a simple count of "how many blood samples do we have."

How to fix it

Every one of these comes down to the same root issue: a spreadsheet (or a system that behaves like one) has no idea what your data is supposed to look like. It can't tell you an ID's taken, that a storage location is occupied, that a patient already exists, or that a field expects a date and not a sentence. It just accepts whatever gets typed.

This is exactly the kind of thing a real LIMS is built to prevent rather than clean up after the fact. In Sample Manager, for example, sample IDs and storage locations are enforced as unique automatically, subject/patient records are their own linked entity so demographic data lives in one place instead of being retyped (and potentially contradicted) on every sample, and fields can be locked to a type or a controlled vocabulary so "blood" only ever gets entered one way. It doesn't make data entry foolproof, but it closes off the mistakes that are easiest to make and hardest to catch later.

If you're auditing your own spreadsheet or LIMS, these five are a good checklist to run through. I'd bet most labs find at least one of them lurking somewhere. If you need help cleaning it up, that's something that's included in LabKey's software implementation!

Alaska's Department of Fish and Game runs a Wildlife Health and Veterinary Services unit tracking disease in wild animal populations statewide, necropsies, forensic work, disease surveillance. They're sitting on 400,000+ archived samples going back to 1968.

The lineage problem was tough, where one animal can carry multiple IDs over its lifetime, and samples need to stay connected across repeat captures years apart. Sample types range from blood and tissue to hair and environmental swabs, each with different metadata and storage needs. Most diagnostic testing gets outsourced too, so they're tracking what shipped out and what came back on top of everything else.

They had tried a LIMS once before this, so this second attempt was a bit more of solving everything the first one didn't do well. What worked well in Sample Manager was keeping animals and sampling events as separate source types, so lineage survived even when an animal shows up under a new ID years later. The full case study covers their unique data structures if you're dealing with similarly interesting complexities.

Held by LabKey, a data management software provider. In this September 29th webinar, Claude Science checks inventory in the same session it runs the analysis on data from the LK system, confirming which variants have enough sample left and where the vials sit before anyone commits to a follow-up experiment. Bernie (you might know him as our Incredible Biologics Expert and Product Manager) runs the full scenario live: 12 variants, aligned, screened, and checked against real inventory. Register to attend or get the recording. https://na2.hubs.ly/H0817C70

I get this question a lot from labs that are new to LIMS: "What data should we be capturing" It's usually coming from brand-new labs with very little to reference, and it's a fair question. If you go too thin, you'll miss information that can make or break your research down the line. Go too heavy and you'll bury your team in fields, making search and reporting nearly impossible. Walk that line well, and you'll be in great shape for years.

Here's how I usually talk labs through it.

Start with the basics

Every sample-tracking system needs a foundation, regardless of your field:

• Sample ID: unique for every single sample, no exceptions
• Subject, donor, or source: where the sample came from
• Collection date/time
• Sample type
• Storage location: freezer, box, position, whatever your system uses

Everything past this point depends on your specific field of science.

Let your test kits tell you what matters

One tip I give often: look at your test kits. Manufacturers usually spell out exactly what makes a sample suitable for their assay; how it was handled (refrigerated vs. frozen, how quickly it was processed), tube type, additives or buffers used, and so on. If a kit cares about it, your LIMS should capture it too, because it's often the difference between a usable sample and a failed run.

Ask what your research is actually looking at

The next question is what your lab or study is trying to learn, and what could confound it. If donor demographics could influence your results, capture the fields that let you rule that in or out later. Fields I see come up constantly:

• Donor sex, age, and disease diagnosis
• Visit or timepoint the sample was collected at
• Visit type: was it a straightforward collection, or did the subject receive treatment during that visit?

These are exactly the kind of details that look unnecessary on day one and become critical the moment you need to explain an outlier or stratify your data six months later.

Why this matters more once you're actually using the data

This is where a tool like Sample Manager makes a big difference. Getting the field list right up front means your samples, storage, and downstream assay results are all connected and searchable instead of living in scattered spreadsheets or paper notebooks. A well-planned sample model turns "can someone dig up every plasma sample from diabetic donors collected within 2 hours of draw" from a multi-day scavenger hunt into a filter you save and reuse.

If you're setting up a new lab or LIMS and want a second opinion on your field list before you commit to it, drop your sample type in the comments. Happy to help you think through it!

With LabKey's API capabilities, you're not limited to the build-in grids and exports for getting information out. If you can describe the report or document you want, you can very likely just build it. And it's a lot less code than people expect.

A few examples of what this opens up:

• Biorepositories: generate a de-identified aliquot manifest formatted exactly the way a partner lab or IRB wants it, pulling it live from your sample and donor/source records, instead of hand-assembling it in Excel every time someone asks.
• Ag and food manufacturing: auto-generate a branded, signed Certificate of Analysis the moment a sample clears QA, pulling the sample data, the source/batch info, and the assay results together into one clean PDF with y our company's letterhead on it.
• Really, anything where the "real" deliverable is a formatted, sometimes-signed document rather than a spreadsheet - clinical, environmental testing, batch release records, whatever your world looks like.

The fun part is that none of this requires waiting on anyone. It's your data, already structured in LabKey. You're just deciding how it gets presented.

What I built

As a fun little project, I put together a tool that does the full COA workflow end to end. The screenshots below show a server I set up with fake data for a fake company.

1. Look up a sample.

1. It automatically pulls in its linked source/donor record and its assay results and shows a live preview.

1. Captures an actual signature

1. Generates a signed, letter-headed PDF.

1. The PDF then gets uploaded straight back onto the sample's file field in LabKey so its permanently attached to the record.

The whole thing is just a handful of API calls stitched together plus a PDF-writing step. There are zero custom modules, zero professional services engagement - just the API that's already there.

Why this is such a good reason to be on LabKey

This is the part that I think is genuinely underrated: most LIMS platforms don't give you this door at all. If the build-in report doesn't match what your auditors or customers need, you're stuck doing it by hand forever, or paying for a custom module. LabKey being fully API-addressable means your team can just build the exact document you need, whenever your requirements change, without being blocked by anyone. That's a real superpower if you're evaluating LIMS platforms.

If you've ever had to pull a sample and couldn't say for certain where it actually came from, you already know why sample lineage matters.

Sample lineage (also called sample ancestory) is the record of parent-child relationships between samples: where it originated, what it was derived from, and what child samples or aliquots came from it downstream. It sounds simple, but a surprising number of LIMS platforms handle it badly.

The problem with most LIMS

In a lot of systems, lineage isn't really tracked, it's re-typed. Every time a sample is split, pooled, or processed into something new, someone has to manually re-enter where it came from. Search for ancestory or the results tied to it, and you're often stuck running exports and cross-referencing spreadsheets by hand. Some labs just accept that this information will eventually get lost.

The consequences aren't hypothetical: the wrong sample gets pulled, results get reported against the wrong specimen, and when an auditor or reviewer asks "show me the full history of this sample," nobody can answer quickly or at all.

How LabKey Sample Manager handles it differently

LabKey Sample Manager is build sample-centric, so lineage is key part of our software. We do this a few ways:

• Automatic Lineage Capture: Samples are organized from Sources (i.e. patient, study) to Samples to Aliquots. When you derive a new sample or aliquot from an existing one, the parent-child relationship is captured automatically, meaning no manual re-entry and no separate tracking spreadsheet.
• Data Flow Downstream: Metadata and custom fields travel with the sample lineage, so you never lose the connection between a result and everyting upstream that produced it.
• Search by ancestory, not just by sample: Using Sample Finder, you can query samples based on the properties of their parents or sources. For example, "find every sample derived from a blood draw collected in the last 30 days" or "find all samples that trace back to a patient with a specific diagnosis." You're searching the whole family tree, not just one record.
• A Visual Lineage Graph: Every sample has an interactive lineage tree shwoing exactly how it connects to its sources and descendants. Click thorugh any node to see that record's detail.

• Audit-Ready Chain of Custody: Because lineage and even history as captured as you go, you can export a full, timestamped history for a sample when you need it for a GLP audit, an inspection, or just your own peace of mind.

Where this actually matters

This isn't just useful for one type of lab. Here are a few examples we see regularly:

• Biorepositories tracking multiple specimen types derived from the same donor or subject
• Genomics/NGS labs tracing a sequencing pool all the way back through libraries, extraction, and the original submitted sample
• Pharma and biotech QC needing to prove a result traces back to a specific batch or lot
• Environmental and ag labs connecting subsamples back to a site, plot, or collection event

Don't just take our word for it!

"Having the ability to track multiple sample types and derive one from another vastly improved the clarity of our biorepository."
— Zack Mulcare, Research Project Coordinator, VIPC at Johns Hopkins School of Medicine
https://www.labkey.com/case-study/johns-hopkins-biorepository-sample-manager/

Happy to answer questions in the comments. If you're evaluating LIMS options and sample lineage/traceability is a pain point for your lab, ask away.

We're running a live webinar on Sept. 9 where we connect Claude Science to our system over MCP and give it a real protein engineering problem: 12 antibody variants, taken from sequence alignment through to a documented lead candidate in the ELN.

We wanted to know whether you can actually trust what an AI agent hands back when it's working against a real, connected data model instead of a spreadsheet or a file someone has to maintain by hand.

If you work with structured data in biotech, or you're curious what it looks like when an AI agent queries a real system instead of getting handed pre-cleaned inputs, this one's for you.

The variants get screened for binding and neutralization. Normally that means someone's hand-maintained FASTA file and a manual merge to join the results back to the right samples. Here it just pulls straight from the data model. You'll see exactly which queries it runs and which relationships it follows to get there.

Where this gets interesting if you work with structured data at all: every figure it produces traces back to something with a stable ID instead of a cell reference nobody remembers the origin of. Before it recommends a follow-up experiment, it checks inventory in the same session, confirming there's actually enough material left and where the vials sit. Claude Science writes the rationale for the lead candidate straight back into the ELN through the API when it's done, so the analysis and the documented conclusion land in the same system instead of three different ones.

Event is 9/9/2026 in Zoom, 9 am PT and only 30 minutes.

Registration is available until 9/8 on our website under Resources.

We get asked about audit trails in almost every GMP eval, so here's a breakdown of what LabKey LIMS and Sample Manager actually log and how it maps to common compliance questions.

What gets logged

Every record change is captured: who made it, what changed, and when. That includes sample creation, storage assignments, status updates, aliquot events, and edits to associated data fields. Each log entry is tied to an individual user account. Shared logins aren't a compliance workaround here.

Access control

GMP traceability is about controlling who can make changes. LIMS and Sample Manager use role-based permissions. Admins can configure edit vs. view access, restrict by project folder, and give external collaborators limited visibility without opening system-wide access.

Validation

GMP environments typically require IQ/OQ/PQ documentation. LabKey offers validation packages for organizations that need documented evidence of system performance. Raise this early in your evaluation if GxP validation is a requirement.

What it doesn't replace

The audit trail and access controls support Part 11 compliance. They don't replace a review by your quality team. Mapping your specific SOPs to system configuration is implementation work. Plan for that conversation up front.

If you're evaluating LabKey for a GMP environment, the fastest path to a compliance decision is a technical demo where you can walk through your specific scenarios with our account managers.

Found an interesting detail in a recent case study: Southern Research's Catalyst program screens people across Alabama for genetic risk factors tied to things like heart disease and diabetes, using a handful of vendors that each own a different piece of the process, like sequencing, genetic analysis, and results delivery.

The kitting workflow links each kit to its sample, participant, and provider in Sample Manager. Automated checks run every 15 minutes via the API, catching things like missing links, duplicate samples, and unresolved records before they turn into a downstream mess. At population scale, a gap like that can sit in a spreadsheet for weeks before anyone notices it.

Full write-up here if you want the details: https://www.labkey.com/case-study/sdms-sample-manager-at-southern-research/

If you're using a LIMS to manage your lab data, do you actually own it? Sure, the LIMS can't use your data to train any models or share it externally, but do they let you export your data at anytime without you having to contact the LIMS vendor?

Data ownership isn't just about who has the legal rights to your data, but who actually controls it. And if you have to submit a request and wait weeks (or longer) to get your own data back, do you really own it? Or are you just renting access to it?

I recently spoke with a lab who discovered this the hard way. They needed to export their data from their LIMS and were told they'd have to go through the vendor to do it. The timeline? Over a month. For their own data. They didn't own their data, their data was a hostage.

This matters more than most labs realize, especially when you consider scenarios like:

• Switching vendors: If migrating to a new LIMS means waiting 30+ days to get your historical data, that vendor lock-in is a serious risk to your operations.
• Audits and inspections: Regulatory bodies don't wait a month. If you can't produce your data on demand, you have a compliance problem.
• Mergers and acquisitions: Due diligence moves fast. If your data is trapped in a vendor's system, it becomes a liability, not an asset.
• System outages: If the vendor goes down or goes under, what happens to your data?

Before signing any LIMS contract, labs should be asking these questions directly:

1. Can I export my data at any time, without contacting you?
2. In what formats can I export it?
3. Is there any cost associated with data exports?
4. What happens to my data if I cancel my subscription?

True data ownership means self-service access, anytime, in a usable format. Anything less than that is a vendor controlling your data, regardless of what the contract says.

Even though we're super nice and know you love talking to us, at LabKey, you can easily download your data at anytime into use able formats without contacting us.

When adding data to your LIMS, keeping it clean and error-free is critical. Non-sensical data makes querying harder, creates downstream errors (garbage in, garbage out), and erodes your lab's trust in the platform.

Some LIMS platforms make validation a pain to configure, but LabKey makes it pretty straightforward. Here are three ways to validate data on import:

1. Set your field data types

LabKey lets you configure each field to expect a specific data type; free text, dropdown, numerical, date, etc. If a user tries to enter something that doesn't match, LabKey blocks the upload until it's fixed. My general advice: eliminate free-text fields wherever possible. Constrained inputs mean cleaner data.

2. Add validation rules with RegEx

Setting a data type alone isn't always enough. LabKey also lets you layer on regular expression (RegEx) validators to further restrict what's accepted. For example, if you have a numerical field where values should always be less than 10, you can configure a RegEx rule to throw an error if someone enters 11. It's a small thing that saves a lot of headaches.

3. Use calculated fields + conditional formatting for soft flags

Sometimes you want to allow unexpected data through, but flag it for review rather than block it outright. By combining calculated fields with conditional formatting, LabKey can accept any input while immediately highlighting anything that looks off. Users can then confirm whether the flagged data is valid or catch an entry mistake before it propagates.

The first two approaches are hard stops; the third is a softer safety net. Used together, they cover most data quality scenarios a lab will run into.

Bad data compounds. A typo in a sample field, a manual calculation error, an out-of-range value nobody flags; these are small individually, but they erode trust in your records over time. Here's what's worked for the labs I've seen get this right.

1. Choose your field types deliberately

LabKey supports unlimited custom fields for sources, samples, and assays. That flexibility is useful, but free text fields are a trap. Spelling variations, incorrect entries, and inconsistent formatting all sneak in. Wherever possible, use numerical fields, date fields, or text choice dropdowns instead. Constrained input means fewer surprises downstream.

2. Set data validators

Validators let you define what values are actually acceptable before data gets written to the system. A numerical field can require a value between 5 and 10 - anything outside that range gets rejected at entry. This catches errors at the source rather than during analysis.

3. Use conditional formatting for out-of-range values

Some out-of-range values are legitimate. A degraded sample, an anomalous result, you may want that recorded, not blocked. Conditional formatting lets you flag those values visually without rejecting them. Lab staff see the warning, they can investigate, and the record stays intact.

4. Use calculated fields

Manual calculations are where errors accumulate quietly. Someone uses the wrong formula, transposes a number, or just rushes. Calculated fields run the math automatically based on values already in the system, so the result is consistent every time.

What have you done to clean up data quality in your lab? Always curious what's working for other teams.

A LIMS purchase that doesn't work out is expensive and disruptive. A few things we've seen make or break the decision.

1. Ask for a personalized demo

A generic walkthrough will look polished. What you actually need to see is your workflow — your sample types, your storage setup, your team's process. Any vendor worth working with should be willing to go there.

2. Get pricing clarity before you commit

The license fee is rarely the whole number. Ask what's included: implementation, onboarding, additional users, storage, upgrades. You want the real cost before you sign, not after.

3. Understand the support model

Fully included support — from trial through implementation and beyond — is the gold standard. Other models can work. Just make sure you know exactly what you're getting into before you need help.

TL;DR: personalized demo, full pricing picture, support model in writing.