Validation
Validation answers one question in a way an auditor can accept: on what basis was this output declared acceptable? The answer has to be a standard, a result and a person, not a feeling about the tone of the answer.
The work is the evidence that it held.
Testing asks whether something breaks. Validation asks whether it is the right thing. A generated report can pass every check in a test suite and still be invalid, because it answers a slightly different question than the one a contract asked for.
That distinction matters more with AI output than anywhere else, because the system is optimised to produce something that looks responsive. Fluency is not fitness.
We validate the output against the claims made about it, in four domains.
Validation ends in an artefact, not a conversation. The record holds the rule set version, the findings with severities, the score they produce and, where a human was involved, the reviewer's name and the changes they requested.
That record is what makes the process reusable a year later, when someone asks why a deliverable was signed off and nobody remembers the meeting.
Requirement drift
Output that is competent but answers a nearby question instead of the asked one.
Unverifiable statements
Claims a reader cannot check, presented with the same weight as the ones they can.
Scope gaps
Sections promised in the brief that quietly disappear from the deliverable.
Configuration assumptions
Hardcoded values that only hold on the machine the output was generated against.
Silent language
Confident phrasing where the underlying data supports only a hedge.
AI validation
The automated pass is free, needs no account and uploads nothing. Escalate to a named reviewer only where being wrong is expensive.
