Are you ready for an 8-week AI build? A readiness checklist

Score yourself honestly across the five areas below. A 'no' is not a disqualification — it is a thing to fix before the clock starts. The point of the checklist is to surface the gaps now, when they are cheap to close, rather than in week three of a build, when they are expensive.

Strong across all five means you are build-ready. Weak in one means close it first. Weak in two or more means start with a Diagnostic, which exists precisely to resolve these unknowns.

1) Data readiness — does representative data exist, is it accessible, and is it good enough to build evals from? 2) Stakeholder alignment — is there one decision-maker who owns the outcome, not a committee? 3) Success criteria — can you state what 'working' means in measurable terms? 4) Infrastructure access — can a team provision in your environment without a months-long approval chain? 5) Commercial commitment — is the budget and the eight-week calendar genuinely committed?

These map directly onto the four principles: data and success criteria feed evals; infrastructure access enables owned infrastructure; commitment makes the fixed clock real.

If you are strong on all five, a Build can start with confidence and the fixed price is low-risk. If data or success criteria are weak, those are exactly what a Diagnostic produces — it maps the bottleneck and writes the eval spec, turning a 'not yet' into a 'ready'.

If stakeholder alignment or commitment is the gap, fix that before spending on engineering at all. No methodology survives a build that the organisation has not actually committed to.

A strong score means your next step is a Diagnostic to lock scope and price the Build — short, because you are already prepared. A mixed score means the Diagnostic does double duty: it closes the readiness gaps and produces the build plan.

Either way, the checklist has done its job if it moved a problem from week three of a build to the week before it starts.

The checklist reads as five independent scores, but in practice they interact, and the interactions are where the real judgement lives. Strength in one area can compensate for weakness in another — or expose it. A committed decision-maker with a cleared calendar can pull messy data into shape fast, so a 'no' on data alongside a strong 'yes' on stakeholder alignment is a recoverable position. The reverse is not: pristine data behind a committee with no owner tends to stay unused, because nobody is empowered to decide what 'good enough' means.

The two areas that cannot be compensated for are stakeholder alignment and commitment. They are upstream of everything else — they are what funds the work that fixes the other gaps. Data, success criteria, and infrastructure access are all things a Diagnostic can resolve, because they are engineering and information problems. Alignment and commitment are organisational, and no amount of method substitutes for them. If you are weighing a mixed score, weight those two heavily and treat the technical three as closeable.

There is also a hidden coupling between data and success criteria: you often cannot write a measurable definition of 'working' until you have looked at representative data, and you cannot judge whether your data is good enough until you know what you are trying to measure. They are chicken-and-egg, which is exactly why the Diagnostic tackles both in the same two weeks rather than sequentially — the eval spec and the data assessment are written together because each depends on the other.

The rule — strong on five, build; weak on two or more, diagnose first — holds in the ordinary case, but a few situations break it, and they are worth naming plainly. The first is the false 'yes' on data. Many operators score themselves strong because the data exists somewhere, only to discover in week two that it is unlabelled, inconsistent across systems, or locked behind an export that takes legal six weeks to approve. Existing is not the same as accessible-and-representative; if you cannot put a sample in front of an engineer this week, score it honestly as a 'not yet'.

The second is the false 'yes' on success criteria. A target like 'reduce handling time' feels measurable but is not an eval — it is an outcome with no per-input definition of a correct answer. The genuine test is narrower: for a single representative input, can you say what the system should output and how you would score whether it did? If you cannot, you have a business goal, not a success criterion, and the gap is larger than the checklist score suggests.

The third edge case is the inverse: a perfect five-out-of-five on a problem that is too small to need an eight-week Build at all. Readiness measures whether you can build, not whether you should. A fully ready company with a one-week problem is better served by a tightly scoped piece of work than by paying for a clock it does not need — and an honest Diagnostic will say so rather than upsell the Build.

The first misuse is grading optimistically to justify a decision already made. The checklist only works as a diagnostic if you let it return an uncomfortable answer; scored to confirm a build you have already committed to internally, it becomes theatre. The discipline is to treat every 'yes' as a claim you would have to defend with evidence in week one — if you would struggle to produce that evidence, it is a 'no'.

The second is treating the five areas as a gate to clear once rather than a state to maintain. Readiness can decay: the accountable owner gets reassigned, the budget gets re-allocated mid-quarter, the data source you assessed gets migrated. A score taken three months before a build started can be stale by the time the clock starts. Re-run it close to the actual start date, because the cost of a precondition that quietly lapsed is the same whether it was never there or simply went away.

The third misuse is using the checklist to grade a vendor rather than yourself. It is built to assess your side of the engagement — the preconditions you control. The vendor's method, evals discipline, and infrastructure stance are a separate question. A strong readiness score and a weak vendor still produces a poor build; the checklist removes the half of the risk that is yours to own, not the half that belongs to whoever you hire.

The checklist is not a substitute for the Diagnostic — it is the input that determines what the Diagnostic costs you in time and attention. A clean five-out-of-five does not mean you skip scoping; it means the two-week Diagnostic spends its time confirming and locking rather than discovering, and the resulting Build quote arrives faster and with a tighter range. A mixed score means the same two weeks do double duty, closing the open preconditions and producing the build plan in one pass, which is precisely what the Diagnostic is scoped to absorb.

What changes between the two cases is where the Diagnostic's effort goes, not whether you need it. With strong data and criteria, the Diagnostic concentrates on architecture and the eval thresholds; with weak ones, it spends its first days on data access and on turning a business goal into a scorable definition of done. Either way the deliverable is the same — a mapped bottleneck, an eval spec, and a fixed-price Build scope — but the readiness score tells you in advance which conversations will be hard.

This is also why more than 60% of Diagnostics proceed to a Build: by the time the Diagnostic ends, the readiness gaps that would otherwise have surfaced mid-build have already been resolved or named. The honest limit of the checklist is that it cannot do this resolution itself — it can only tell you whether the Diagnostic will be a short confirmation or a longer piece of groundwork. Both are legitimate starting points; the only wrong move is starting the Build clock with the gaps still open.