Project where an attribute lands before it gets there
An agent that reads every timepoint in the stability program, fits the trend per attribute per condition, and tells you which study is heading for a specification limit while there is still time to act.
You find the trend at the pull that confirms it.
The stability program is running properly. Protocols are approved, pulls happen on schedule, results go into the LIMS, and every individual result is within specification. Nothing is wrong, which is exactly the problem: a drift is only visible if somebody plots it, and plotting it means exporting timepoints for one study, one condition and one attribute at a time into Excel.
So it gets done quarterly, or when a report is due, or when someone has a bad feeling. And the aggregation trend that would have been obvious at nine months gets noticed at eighteen, when the protocol is locked, the claim is filed and the options have narrowed to the expensive ones.
Meanwhile the routine questions go unanswered because answering them is tedious rather than hard. Which studies have a timepoint outside its window. Which attribute has the least margin to spec at the end of the claimed shelf life. Which condition is actually driving the shelf-life limit.
Every study, every condition, every attribute, in one pass.
The agent reads the whole stability program out of the LIMS rather than one study at a time. For each attribute at each condition it fits the observed trend, projects forward to the end of the claimed shelf life, and returns the studies where the projection meets a specification limit first, ranked by how little margin is left.
The fitting is arithmetic. The judgment is not.
This workflow is deliberately conservative about what the model is allowed to do. Curve fitting and projection are deterministic calculations executed as tool calls, so the numbers are reproducible and testable. The language model organizes, explains and flags. It does not compute.
- LIMS for every stability result in the program, keyed by study, storage condition, timepoint, attribute and the method that produced it.
- Protocol context from the stability protocols themselves: the claimed shelf life, the pull schedule, the specification limits in force, and the acceptance criteria per attribute.
- Deterministic trending per attribute per condition, with the projection and its confidence interval calculated in code and returned to the model as a value. The model reports the number; it never generates one.
- Margin ranking across the whole program, so the answer to "what should worry me" is a sorted list rather than an impression.
- Data integrity checks in the same pass: timepoints pulled outside their window, missing conditions, results entered against the wrong study, and methods that changed mid-study.
Aggregation is not the same as significance. The agent surfaces where a trend is heading and shows the fit it used; a stability lead decides whether the trend is real, whether it warrants action, and what goes into a report. Nothing reaches a regulatory document without that judgment in between.
From quarterly and partial to continuous and complete.
- Per study, exporting timepoints and plotting them by hand in Excel
- Run quarterly at best, so a drift can sit unseen for two or three pulls
- Covers the studies someone thought to look at, not the whole program
- The projection lives in a workbook on one person's drive
- The entire program fitted and projected in one pass, not one study at a time
- Ranked by margin to specification, so the worst case surfaces without being looked for
- Out-of-window pulls and missing timepoints flagged in the same run
- A stability lead still judges whether a trend is real and what it means
These figures come from my demo environment running on synthetic CMC data. They are not client results. The "today" column is what I watched teams actually do across HGS, GSK and Novavax; the "with an agent" column is measured on the demo, against a data model built to be representative rather than against your systems.
Stability data is usually the cleanest data you have.
Which makes this one of the more achievable workflows to stand up. The gaps that do show up tend to be about context rather than results: specification limits held in a document rather than a queryable field, protocols whose shelf-life claim is not machine-readable, method changes mid-study that are recorded but not linked, and legacy studies migrated from a previous LIMS with the timepoint structure flattened.
The Data Diagnostic tells you which of those apply to your program, and whether this workflow is a short build or a longer one, before you commit to either.
The Data Diagnostic, including the price
Your IT and quality systems group will want the architecture, the read and write paths, the Part 11 position and the validation approach. That is all written down on the governance and validation page, in a form you can forward or print.
Send me a workflow.
Tell me the process that eats your team's week. I'll record an agent running it on your data model and send it back. No call required.
kyle@kylelangham.comNo form, no gate, no email capture.
Would rather talk it through? 30 minutes on your workflow, no pitch.