Automation discussions default to OQ and PQ because there is a screen to click and a tool that clicks it. IQ gets left behind — still a person with a checklist, reading version strings off a terminal and pasting them into a Word table.
Which is odd, because IQ is the most automatable of the three. It is almost entirely a set of factual assertions about a machine.
What IQ actually asks
Strip away the formatting and installation qualification asks a short list of closed questions:
- Is the software present, at the version the specification names?
- Are the files the ones the vendor shipped — checksums matching, nothing added?
- Are the services running, and set to start on boot?
- Is the operating system, runtime and database at a supported version?
- Are directories, permissions and ownership as specified?
- Are the configured connections — database, storage, identity — pointing where they should?
- Is there enough of what the system needs: memory, disk, licences?
Every one of those has a definite answer that a machine can read, and no judgement in it. The reason it is still manual is not difficulty. It is that the tools were built to drive browsers.
Reaching the host without handing over a shell
The obvious way to check a file version is to run a command, and we have argued at length against giving a test engine that ability. The two are reconcilable: the engine needs named checks against a host, not arbitrary execution on it.
So the step types are specific rather than general:
- File check — exists, size, checksum, modified time, permissions, owner.
- Version check — read a version from a named source and compare against an expected value.
- Service check — named service, running state, startup mode.
- Resource check — free disk on a named mount, available memory, a named licence count.
- Connection check — a named endpoint is reachable and identifies itself as expected.
Each takes parameters and returns a fact. None of them can be asked to do anything else. The same vocabulary works whether the target is the local machine, a host over SSH, or a container — the connection method is configuration, not a new class of step.
The failure that proves it is working
The first time an automated IQ fails on a real environment is the moment it earns its place. When we ran the full chain end to end on our own test estate, the IQ failed — a genuine mismatch between the specified and installed state, found in seconds rather than by a person reading a version string at the end of a long day.
It raised a deviation, which is exactly what should have happened. A failing automated test is not an inconvenience; it is the system doing the one job you bought it for. A tool that has never failed on your estate has not been tested, it has been demonstrated.
Where a person is still better
Two parts of IQ resist automation, and it is worth conceding them rather than pretending otherwise.
- Physical verification. Cabling, labelling, rack location, environmental conditions. If it is a fact about the room rather than the machine, somebody has to look.
- Documentation review. Confirming the vendor supplied what the contract says, that the manuals are the right revision, that the supplier qualification is current. See supplier qualification.
A realistic split on a typical system is most of the machine-readable checks automated and a short manual annex for the rest. That is still a large reduction in the part of IQ that is pure transcription — and transcription is where the errors were.
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.