Documentation-driven QA versus evidence-driven QA

Every service business has a version of the same QA process. Someone senior opens the closed tickets, reads the notes, checks that time was entered and the resolution makes sense, and signs off. It is thorough about one thing: whether the record of the work is tidy. It is silent about another: whether the work exists.

A ticket that says "SentinelOne deployed to all workstations" is a claim. The SentinelOne console listing 73 protected devices is a fact. Documentation-driven QA checks the claim. Evidence-driven QA checks the fact. When the two agree, nothing is lost. When they disagree, only one of them protects your client.

Why the claim drifts from the fact

Not because engineers lie. Because deployments fail silently on four machines that were powered off that afternoon, because a license assignment was queued and never applied, because the backup job that ran once has not run since. The engineer saw success at the moment of writing the note. The environment moved on.

What changes when you check the fact

The question flips from "was the process followed?" to "does the intended state exist?" Expected: 73 endpoints with active EDR. Observed: 69. Result: fail, with four hostnames. There is nothing to argue about and nothing to interpret. The engineer gets a list. The manager gets an answer. The client gets a project that was actually finished.

The record still matters, for billing and for history. But acceptance should rest on the environment, because that is what the client is paying for.