Deciding not to proceed

Every previous piece in this track has been about gathering evidence. This one is about the meeting where the evidence says no, and you have to be the person who says it out loud.

It is worth knowing that the certifications treat this as a competence rather than an absence of ambition. AWS makes "determine when AI/ML solutions are not appropriate" an explicit objective, and names the deciding condition: situations where a specific outcome is required instead of a prediction. Microsoft's blueprint gives implementation and adoption strategy 20–25% of its exam and lists identifying common barriers to adoption among the skills tested. Neither of those is written for the enthusiast in the room.

Four reasons to stop that are actually good reasons

The task needs one right answer. This is the cleanest and most frequently ignored. Statutory calculations, entitlement rules, thresholds, anything that has to reconcile exactly and be defensible line by line — these belong in ordinary code, which computes them the same way every time and can be audited. A probabilistic component is the wrong tool here regardless of how capable it is, and no amount of prompting, fine-tuning or human review converts it into the right one. If the requirement is "the same input must always produce the same output, and we must be able to show why", you are finished; the answer is no.

Nobody can describe what success would look like. If the project cannot state a threshold — specific, measurable, and justified against something external rather than invented — then it cannot be evaluated, only admired. That is not a reason to abandon the idea. It is a reason to stop the build and go define the criteria, which is a different and much cheaper piece of work.

The people who'd use it don't want it. Most AI projects that fail do not fail technically. They work, and adoption never happens, because the old workflow was fine, or the new one is slower, or people don't trust the output and check it by hand — at which point you have added a step rather than removed one. Microsoft treats adoption barriers, adoption teams and champions programmes as testable material precisely because this is the common failure. If nobody has asked the intended users, the honest answer is not no; it is not yet, and here is the two-week piece of work that would tell us.

A simpler thing would work. Some proportion of proposals are a search feature, a form, a report, or a well-organised wiki with a language model attached. Saying so is not cynicism, and the question costs nothing.

Three reasons that feel like good reasons and aren't

"It isn't perfect yet." Nothing is. The question was never whether it makes mistakes; it was what happens when it does, and whether the rate is inside the threshold you set. A system at 92% against a threshold of 90% has passed, and rejecting it because 92% is not 100% means the threshold was decorative.

"Our data isn't ready." Sometimes decisive, often a deferral that lasts years. Push on it: ready for what, specifically, and what is the smallest subset that would let us test the thing? A pilot on one clean corner of a messy estate is usually available.

"We should wait for the technology to settle." It will not settle. Waiting is a legitimate choice when there is something specific you are waiting for — a capability that doesn't exist, a price that has to fall, a regulation being drafted. Name it, and write down what would change your mind. "Let's revisit in six months" with nothing attached is how a decision gets avoided rather than made.

How to run the meeting

Lead with the criteria, not the conclusion. "We agreed 90% and no fabricated citations. It came in at 84% with two fabrications in 200 cases." The decision follows from a standard everybody signed up to, which makes it a shared finding rather than your verdict. This is the entire reason for writing thresholds down before seeing results.

Separate the idea from the implementation. "This approach didn't clear the bar" is very different from "this was a bad idea", and people hear the second one when you mean the first. Be explicit about which you mean, because the team will interpret ambiguity as a judgment on them.

Say what you learned that has value. The test set, the baseline measurement of the current process, the discovery that your own experts only agree 80% of the time. These are durable assets and they cost real money to produce. Naming them stops a fortnight of work being filed as a failure.

Give a specific condition for reopening it. Not "if things change". Something like: if a supplier can show 90% on our held-back set, or if the price per transaction falls below four pence, bring it back and we'll re-run the same tests. You keep the test set. Re-running costs a day rather than a quarter.

Do not soften it into a maybe. A no dressed as "let's keep exploring" wastes months of someone's effort and their goodwill. Clarity is the kinder option even when it lands badly, and it is the only version people can plan around.

The part that matters most afterwards

The organisations that get good at this are the ones where stopping a project is survivable — where the person who ran the pilot that concluded "no" is treated as having done the job rather than failed at it.

If the only career-safe outcome is proceeding, everything proceeds, and you end up with a portfolio of things nobody uses and nobody will admit to. The two-week bake-off that ends in a clear no is one of the cheapest things you will ever buy. Say so, in public, to the person who ran it.