BioTrack

The problem

A single bioburden deviation could take hours to assemble: pulling and reconciling process, environmental-monitoring and lab data by hand before any analysis could start — time that ate into the 30-day window reserved for physical inspection, CAPA design and QA review. The harder problem came second. An investigation aid that guesses is worse than no aid at all, because a plausible wrong cause is expensive to disprove and easy to believe.

Architecture

What it does

BioTrack is the investigation platform for bioburden quality events. It pulls process, environmental-monitoring, lab, ERP-maintenance and quality-system data into a single per-lot record, so an investigator starts from assembled evidence instead of a week of data plumbing — protecting the 30-day closure window for the work that actually needs human judgment.

It began as a fork of the retrieval architecture DevSight had reached at v2.5.0. v1.2.0 adds a third tab, Lot Context, alongside the analytics and assistant views.

Lot Context

The tab opens on a map of recent production lots carrying four encodings at once: colour is the result, size is the magnitude, a ring marks a lot with a linked quality record, and an arrow points to the next lot run on the same equipment. The point is to make sequence visible — most of what investigators ask is really a question about what ran before. Clicking a lot opens its full record:

• The result read against that lot's own limits, not a site-wide average
• The full equipment chain it passed through, with cycle times
• A process timeline pulled from the control system
• Maintenance history for the equipment involved
• Similar lots, linked investigations, and the leads those suggest

Nine rules, all arithmetic

The hypothesis engine is nine deterministic rules. Every one is arithmetic on data already on screen — a comparison, a count, a ratio — and every one reports in three states: it fired, it did not fire, or it could not run because the inputs weren't there. The third state matters as much as the first. 'No data' and 'no signal' are different answers and the panel never collapses them.

The LLM narrates and nothing else. It may restate a rule that already fired, in plain language. It may not add a hypothesis, rank hypotheses, re-weight them, infer a new one, or attach a probability to any of them. When zero rules fire, that is rendered as a result — nine rules ran, none fired — instead of an empty panel that leaves the investigator guessing whether the tool broke or the lot is clean.

• R computes the rates, cycle-time correlations, recovery frequencies and risk scores; the model only ever sees the output
• Six Plotly chart types generated per analysis — equipment heatmaps, scatter, trend lines, risk matrices
• Retrieval over the quality system cites only record identifiers present in the loaded data

Maintenance evidence from the ERP

Maintenance records come from JD Edwards, and v1.2.0 stopped treating them as one undifferentiated pile. Three claims are labelled separately because they are not equally strong. Routine scheduled work folds away by default, so what sits on top of the panel is the work that was unusual.

• Work performed on the equipment itself — the direct claim
• Work performed in the room the equipment sits in — proximity, not contact
• Work performed in the adjacent service space — weaker still, but not nothing

Four kinds of nothing

An empty maintenance panel used to mean four completely different things and the investigator had no way to tell which — so a blank panel could be read as reassurance when it was actually a failed lookup. v1.2.0 labels them apart:

• Checked, and found nothing — the only genuinely clean result
• Nothing recorded for this role — the record type exists but was never populated here
• Could not look it up — the query failed or the identifier didn't resolve
• Not checked — outside what this panel queries at all

The flag that got measured, then deleted

A 'recent maintenance' flag was proposed as a signal: highlight lots where work had happened on the equipment shortly beforehand. Before building it, we measured its base rate against the record set. Recent maintenance turned out to be present in a majority of records. The flag would have fired on most lots most of the time — useless as a discriminator, and worse than useless as a prompt, because it looks like evidence.

So it was deleted and rebuilt with a different job. Maintenance proximity is now corroboration: it can strengthen a conclusion a rule already reached, but it can never trigger one. The inverse is enforced too — absence of recent maintenance is never presented as reassuring, because a base rate that high makes absence almost as uninformative as presence.

Reporting a null as a finding

The equipment × failure-category view flags elevated rates. Run naively, that view makes a large number of comparisons at once and will hand back elevated cells purely by chance — the standard way a dashboard manufactures a lead that doesn't exist. Every flag now corrects for the number of comparisons being made, and rates on small denominators use a Wilson bound rather than a raw proportion, so a two-out-of-three doesn't outrank a much larger sample.

After correction, nothing is flagged. That result is shown to users in words — the units are running statistically indistinguishable profiles — rather than left as an empty table. A null users can see is a decision they can act on. A null they can't see just looks like the feature is broken.

Live quality-system integration

The assistant's quality context used to come from a hand-captured snapshot of under two dozen records — enough to demonstrate the idea, not enough to investigate with. v1.2.0 reads the quality system directly, so the context is whatever is true now instead of whatever was true the day the snapshot was taken.

Building it surfaced a record-matching defect in the old behaviour: some records had been matched to the wrong lot. That was fixed and disclosed in-app, with an explicit instruction to re-run any query that had relied on the old matching. Correcting it silently would have left investigators holding conclusions they had no reason to re-examine.

Where it stands

BioTrack shipped v1.2.0 in August 2026 and is now the site's only surviving quality GenAI platform. It grew from roughly 12,900 to roughly 20,800 lines of R across 16 modules over that cycle.

It also carries the part of DevSight worth keeping. The hybrid-RAG retrieval engine built for deviation search runs inside BioTrack and shares the same vector index. Retiring an application and retiring a capability are different decisions, and only the first one was made.