The most expensive decision in a validation project is usually made in its first week, by someone who is not certain, under no particular pressure, and without anybody reviewing it afterwards.
It is the software categorisation. Get it wrong upward and you spend months you did not need. Get it wrong downward and you produce a thin package that looks efficient until somebody reads it properly.
What the categories decide
GAMP 5 categorises software as 1 (infrastructure), 3 (non-configured products used as supplied), 4 (configured commercial products) or 5 (custom applications). Category 2 was retired and no longer exists, which still catches people working from old templates.
The category determines which deliverables apply. A Category 4 system needs a configuration specification and testing of the configuration you applied. A Category 5 system adds design specification and code review. The difference between them, across a full package, is months.
Why it goes wrong upward
Caution. Nobody is ever criticised for validating too much, and arguing for a lower category means writing a rationale you might have to defend. Writing "Category 5" requires no justification from anyone.
So a configured commercial product with a few integrations gets treated as custom development, and the project produces design specifications for software it did not design and code reviews for code it does not own. The documents are real. They demonstrate nothing, because they describe a build that never happened.
This is the single most common avoidable cost we see, and it is the cheapest to fix — it costs nothing but a defensible written rationale.
Why it goes wrong downward
Optimism, usually under schedule pressure. A heavily configured platform labelled Category 3 because "we are using it as supplied" — when fourteen workflows, a custom report set and three integrations say otherwise.
The package comes together quickly and looks efficient. Then an inspector asks why the configuration was never specified or tested, and there is no answer, because the category said it did not need to be.
This error is rarer and considerably worse. Over-categorisation wastes money; under-categorisation produces a validated state you do not actually have.
The third error: treating everything as software
An HPLC is not a GAMP category. A bioreactor is not a GAMP category. Pushing instruments and equipment through a software lifecycle produces documents that do not match what a qualification auditor expects to see.
Analytical instruments are classified by USP <1058> group and qualified accordingly. Equipment is assessed against EU GMP Annex 15 criticality, with factory and site acceptance and critical process parameters. Where an instrument has a software component — an HPLC with a chromatography data system — the software is categorised under GAMP 5 and the instrument is not.
Mixed assets are categorised by component, not forced under one label. That distinction is the one most likely to be missed by a team whose entire experience is application software.
How to decide it properly
Categorise from facts about the asset rather than from a feeling about it, write the rationale down at the time, and have someone who was not involved read it. Where a system is genuinely mixed, categorise its components separately rather than arguing about which single label is least wrong.
Then revisit it if the facts change. A categorisation that was right at intake and wrong by the time the configuration was finished is common, and the only thing worse than fixing it late is not fixing it at all.
Our GAMP 5 Second Edition consulting work frequently begins by rechecking this one decision, because it is the cheapest place to recover months. GxP Copilot computes the classification from confirmed facts and re-derives the document set when a fact is corrected, so the decision stays visible rather than being buried in the plan.
Where to go next
Explore GxP Copilot for AI-native validation, TraceDraft for source-traceable clinical documentation, or book a demo to see either on your own data.