# Success criteria you must commit to before the AI pilot runs _A pilot without agreed success criteria does not end. It just runs until someone gets tired, and then the go or no-go call turns political instead of factual._ The success criteria to lock before an AI pilot starts, why an unnamed endpoint turns the decision political, and an anonymized founder story on starting from the problem instead of the tool. # Success criteria you must commit to before the AI pilot runs Most AI pilots do not fail loudly. They just never officially end. There is no line that says "if we hit this, we scale, and if we miss it, we stop," so the pilot drifts, and eventually the decision to keep going or shut down gets made by whoever has the most political weight that quarter. Success criteria, written before the pilot, are what keep that call factual. ## Start from the problem, then the criteria write themselves The founder of a software and automation shop told me the mistake he sees constantly now that AI is the default reflex: people go to AI first, then hunt for a problem to point it at. His discipline is the opposite. He starts from the real business problem, understands the human side of it, and he is willing to tell a client that AI is not the right fit. His phrase for it was simple. Is this the right solution for the problem. That order matters for measurement, not just scoping. When you start from a named problem, the success criteria are obvious, because the problem already has a shape. Reduce this cost. Cut this handling time. Lower this error rate below a threshold. When you start from the tool, you cannot write criteria, because you never defined what a win would look like. You just wanted to be doing AI. ## An unnamed endpoint turns the decision political The most common scoping failure is starting without agreed success metrics. The damage is not abstract. Without a defined endpoint, the go or no-go decision has nothing objective to anchor to, so it defaults to opinion and org politics. The engineer who built it wants to continue. The skeptic wanted it dead on day one. Neither can be proven right, because nobody set the bar. Agreeing the criteria in advance takes that power away from the loudest voice and hands it to the number. The pilot passes or it does not. That is the whole point of committing early. You are removing your future self's ability to rationalize. ## Three criteria worth locking Good pilot criteria usually cover three things. A performance bar: the quality level the output has to clear to be usable, defined in the terms the task actually needs, not a generic accuracy score. A cost ceiling: the point past which the economics stop making sense even if the quality is there. And a feasibility signal on the operational side: can this run inside the latency, integration, and workflow reality it will live in. Remember the pilot stage measures feasibility, not ROI. You are not proving return yet, you are proving the thing can stand up, so the criteria should test standing up, not profit. Write all three down before launch, get the budget owner and the builder to both sign, and date it. Criteria you can quietly loosen later are not criteria. ## How we approach it at Density Labs Our AI Readiness Assessment is a fixed two week engagement priced at $2,500. Part of the deliverable is a short, signed success sheet: the performance bar in task terms, the cost ceiling, the feasibility signals, and the baseline each is measured against. We push you to start from the problem, name the endpoint, and put the kill condition next to the win condition so both are decided while everyone is still calm. It is far cheaper to argue about the bar before the pilot than about the results after it. A pilot with no finish line cannot be won. Draw the line first, and the decision at the end makes itself.