The Internal Build Checklist
Ten questions to ask about an AI system your own teams built — before it goes live, or now, if it already has.
No vendor wrote this system, so there is no contract to review and no signature that forces anyone to check it. These questions are the check.
Who hears the answer?
Who asked for this check — and who else will receive the findings?
The team that built a system can reasonably ask for it to be checked. It should not be the only party to hear the result. Name at least one other recipient outside that team's reporting line — usually the function whose work the system does, or the committee accountable for its outcomes — and agree before the work starts that they receive the same findings, at the same time, unedited.
Who championed it, who built it, who runs it, and who reports on whether it works?
Write down a name for each. If one team holds three or four of these, that is not a reason to stop. It is the most important thing to know before anything else is checked, because it tells you whose judgment every later answer depends on.
Was the problem written down before the build?
Is there a written specification, dated before building started?
It should say what the system is for, how success will be measured, what baseline that measure starts from, and at least one second measure that would move if the first one improved while the real outcome got worse — cost falling because quality fell, speed rising because steps were skipped.
Who wrote it?
A team that knows how to build something tends to describe the problem as the thing it knows how to build. That is not carelessness; it is what knowing a toolset does. If the build team drafted the specification, someone outside the team should have reviewed it.
Does the problem survive without the team's own tools?
Restate it in one sentence, in the words of the people whose work the system will do, without naming any model, platform, framework, or architecture. If the sentence falls apart, the specification describes a solution, not a problem.
Has the specification changed since building began?
Changing it is allowed. Each change is a new definition: write it down, date it, and check the system against both the old version and the new one. A measure that quietly moves toward the result is no longer measuring anything.
Who checks it, and when?
Who checks that the system still meets its specification — and were they part of building it?
The checker should not be the builder, should not report to the builder, should not share credit or pay for this system with the builder, and should not have helped write the specification. They can be inside your organisation. They just cannot be inside the build.
When is the next check, and was that date set before the system went live?
A check that happens “when someone asks” does not happen. Set the date in advance, and treat any of these as a reason to check early: the underlying model changes, the system's scope grows or shrinks, it is given a new source of data, or it is allowed to do more without a person reviewing it.
What is actually governing the system?
Read the instructions the system runs on. Where could a capable model follow them to the letter and still do something you did not intend?
The instructions, rules, and test criteria your team wrote are what the system actually obeys. A short, well-meant instruction — “be accurate,” “escalate complex cases” — can be followed in many different ways, and a capable model will pick one. Where the instructions say nothing about a situation that will come up, the model decides on its own. Honest instructions can still be too thin to govern.
Are “was this built with an interest in the result?” and “are its instructions specific enough?” answered separately?
They are different questions, and a clean answer to one says nothing about the other. “No conflict found” never means “safe.”
“A measure written and reported by the team that built the system is a claim, not a check.”