The OOS that lands the day before release
Finished-product assay for batch FP-2847, Thursday afternoon. Spec 95.0–105.0%. Result: 93.8%. The analyst re-injects once. Carryover, maybe. Same number. LIMS goes red. Release freezes. Somebody says the quiet part out loud: pull another sample and "confirm."
That sentence is where OOS investigations usually break.
93.8% is not a draft waiting for a better run. It's a GMP result. Under 21 CFR §211.192 it has to be investigated, and under the Barr rule you don't get to make it disappear by hunting for a pass. Investigators care less about the eventual passing number than about whether you investigated the failing one first, with a record they can walk.
That's the gap this post is about: what still fails OOS files in 2026, after FDA's Level 2 revision, and what a linked file looks like when someone asks "show me how you knew this batch was safe to release." For the procedure definition itself, start with our OOS glossary term.
What changed in 2022 (and what did not)
There is no 2026 OOS rewrite. The document investigators still work from is Investigating Out-of-Specification (OOS) Test Results for Pharmaceutical Production, first issued October 2006, Level 2 revised May 16, 2022 (Revision 1).
What stayed:
- Phase I laboratory investigation before you expand the problem to manufacturing
- Phase II full-scale investigation when Phase I finds no assignable lab cause
- Retesting only after a scientifically justified path, not as a way to overwrite the first result
- Batch disposition from the investigation, not from the result you prefer
What Rev. 1 actually touched:
- Terminology: quality control unit → quality unit
- Clearer caution on averaging and outlier handling during OOS evaluation
- Same Barr spine underneath: treat the OOS as real until the investigation says otherwise
| Element | What the file has to show |
|---|---|
| Original result | Still there, not overwritten in LIMS |
| Phase I | Analyst + supervisor work, done promptly, documented |
| Phase II | Opened when lab cause isn't assignable; manufacturing/materials in scope |
| Retesting | Pre-approved protocol tied to a written hypothesis |
| Disposition | Release / reject / rework / reprocess, each with rationale |
| Systemic cause | CAPA (or a written reason it isn't needed) |
If your SOP binder still cites only "FDA 2006" and never mentions Revision 1, update the citation even when the two-phase map didn't change. Inspectors notice stale guidance references.
Where Phase I actually fails
Phase I is the laboratory investigation that starts the moment the OOS is confirmed, before anyone drafts a manufacturing root-cause story. The glossary procedure tab walks the checklist. Here's what fails when the release clock is loud:
- Phase I gets a signature but no real work: blank fields, "N/A" where chromatograms should be
- The analyst retests during Phase I "just to see," without a protocol, then the passing inject becomes the unofficial story
- QA hears about the OOS at close-out, not at confirmation
- The batch stays in a soft hold that production can talk past
Assignable lab errors (wrong standard, prep error, equipment fault on that run) do show up in Phase I when the checklist is honest. Skipping to "must be the batch" without that work is how a single assay becomes a data-integrity observation.
Many labs put a 24–48 hour box on Phase I. The exact clock is yours; the expectation is prompt, documented inquiry, not a Phase I that opens after the retest already "fixed" things.
When Phase II opens
Phase II starts when Phase I doesn't give you an assignable laboratory error. Scope leaves the bench: batch records, equipment logs, environmental monitoring, raw-material COAs, historical data for product / method / analyst / instrument train, parallel lots.
A sterility OOS pulls EM. A content-uniformity OOS pulls blend and compression. Name an owner, write the scope, and keep interim notes if the file stays open across review cycles. Root cause analysis tools belong here with attachments, not a paragraph that says "operator error" and stops.
Also scope other batches. §211.192 isn't satisfied by a tidy story about FP-2847 alone if the same standard, method, or process step could have hit the next lot.
Retesting without a hypothesis still fails fastest
Additional testing is allowed after a written hypothesis explains why the original result might not reflect true batch quality, and why the proposed design can test that idea. Barr and the guidance both reject:
- OOS confirmed
- Repeat until one pass appears
- Report the pass and release
The pattern that survives:
- OOS confirmed and locked
- Phase I (and Phase II if needed) finished
- Hypothesis approved by the quality unit
- Pre-approved retest protocol run
- Original, repeats, and retests evaluated together for disposition
Hypotheses that sometimes hold:
- Sample prep error → reserved sample, independent prep
- Equipment fault on the original run → demonstrate the fix, then retest retained sample under the validated method
- Suspected heterogeneity → additional sampling per a validated plan
Hypotheses that usually don't:
- "We need a pass to ship on Friday"
- "Junior analyst: rerun with a senior until it passes"
- "Average the OOS with the repeats; the mean is in spec" (when the method never allowed that)
OOS, OOT, and the trend inspectors connect
OOS is outside spec or method acceptance criteria. OOT is inside spec but moving the wrong way. Both need investigation; OOS usually freezes release.
Inspectors connect isolated closes. Three assay OOS events on the same HPLC method in six months, each closed as "lab error" with no CAPA, reads as a system that can't see itself, even when each file looks neat alone.
| Signal | How it usually reads |
|---|---|
| Single OOS, strong Phase I lab cause | Acceptable |
| Repeat OOS, same method or product | Trend: expect method review or CAPA |
| OOS closed by retest only | Data-integrity problem |
| OOT ignored until it becomes OOS | Monitoring gap |
Records investigators pull first
When they pick one OOS for depth, the ask is boring and predictable:
- Original chromatograms / raw files with integration parameters
- Sample login, custody, storage
- Method version, system suitability, calibration for that run
- Analyst training / competency for the method
- Phase I with supervisor review
- Phase II with cross-functional inputs (if opened)
- Retest protocol approval + all retest raw data
- Disposition memo tying results to the release call
- CAPA if the cause was systemic
If any of that lives in email, a personal spreadsheet, or a LIMS comment with no history, you spend the inspection explaining gaps instead of chemistry.
CAPA and disposition: keep the chain
Disposition follows the investigation. Acceptable: original OOS stands, batch rejected or held, CAPA on a manufacturing root cause. Unacceptable: original OOS hidden, passing retest reported as "the result."
Systemic causes (recurring glassware issues, weak method robustness, training gaps across shifts) should link forward to a CAPA with effectiveness checks planned. True one-off lab error with no product impact: document why CAPA isn't warranted and how you'll watch recurrence through quality-event trending, not a reassurance paragraph.
Same rule when the OOS ties to a manufacturing deviation or a supplier lot. Inspectors cross records. Your system should already have those links.
How Complere supports OOS investigations
The failing value stays on the record with its metadata from the moment it's entered. Nobody rebuilds "what the bench actually got" from memory three weeks later.
Phase templates push the lab checklist before the cross-functional expansion, so Phase II isn't used as a shortcut around Phase I. Retests don't move until approval sits on the same chain as the original OOS. While the investigation is open, linked lots show hold status instead of relying on whoever remembered to check a dashboard.
When Phase II points past a one-off lab mistake, the quality event links forward to CAPA with effectiveness checks planned, not a closed lab note that never surfaces again.
Nothing changes without leaving a mark. Immutable audit trail — database-enforced. Audit records cannot be modified or deleted, enforced by database-level constraints, scoped to the audit trail investigators use when they ask who changed a result, approved a retest, or signed release.
Your team still owns the science: the hypothesis, the root-cause call, the release decision. Complere keeps that judgement in a connected record so the inspection question gets an evidence trail, not a scavenger hunt.
