Write the rejection criteria before the requirements

A head of engineering at a marketplace told me he changed one habit and it changed how his AI projects went. He used to start every project the normal way. A requirements doc. What the feature must do, what it should do, what would be nice. The list grew, everyone added to it, and the project rolled forward carried by its own momentum. Some of those projects should have died in week one and instead died in month six, expensively.

So he flipped the first step. Before writing what the project had to do, he made the team write down what would make them kill it. The conditions under which walking away was the right answer. He called it the rejection criteria, and he insisted it go on the first page, before requirements, before design, before anyone got attached.

It felt strange at first. You are supposed to be excited about a new project, not planning its funeral. What it did was force honesty at the only point where honesty was cheap. Naming the deal-breakers up front meant everyone knew, from day one, exactly what evidence would end the project, and that made the whole thing sharper.

Requirements pull you in, rejection criteria let you out

A requirements list is a machine for commitment. Every item you add is a reason to keep going. By the time you have fifty requirements, quitting feels like waste, even if the core idea is dead, because look at all this work we specified. Requirements accumulate sunk cost before you have spent anything.

Rejection criteria do the opposite. They are the pre-committed reasons to stop, written while you are still clear-headed, before the sunk cost exists. If the data turns out to be too messy to fix in scope, we walk. If the accuracy we need is higher than the model can reach, we walk. If the destination system cannot accept the output, we walk. Deciding those lines in advance means the decision to stop is already made when the evidence arrives. You just have to honor it.

The marketplace team’s list was short and specific. If the fraud we are trying to catch happens fewer than a certain number of times a month, not worth building. If we cannot get labeled examples of the bad cases, we cannot train or evaluate, so we walk. If a wrong automated decision would block a seller’s payout with no fast appeal, we do not ship it automated. Each line was a tripwire, agreed to before anyone had a reason to argue past it.

The criteria discipline everything downstream

Writing the rejection criteria first does something to the requirements that follow. It makes them concrete. If “we walk if we cannot get labeled bad cases” is a deal-breaker, then “get labeled bad cases” is now a real, prioritized task, not an assumption buried in someone’s head. The things that could kill the project become the things you check first.

A head of product at a logistics firm adopted the same practice and told me the biggest value was social. When a project hit one of the pre-written rejection lines, killing it was not a fight and not a failure. It was the plan working. The team had agreed, in writing, that this exact condition meant stop. Nobody had to be the person who lost faith. The document lost faith on schedule, and everyone moved on to something with a pulse.

The MIT study that made the rounds in 2025 found that around 95 percent of enterprise GenAI pilots delivered no measurable return. A lot of those pilots did not fail at the end. They failed at the start, on conditions that were knowable in week one, and nobody had written down what those conditions were. Rejection criteria are how you catch that failure while it is still cheap.

How we approach it at Density Labs

In the AI Opportunity Assessment, our two-week fixed engagement at $2,500, we help teams write the walk-away conditions before the requirements, because the fastest money we can save a client is on the project that should not exist. If the diagnostic hits one of those conditions, we say so plainly, and a clear no in week two is worth far more than a hopeful yes that unravels in month six. The point of scoping is not only to plan the build. It is to find out whether there should be one.

Before you list what the project must do, list what would make you walk away. Then watch for it.