AI projects fail the sunk-cost test more reliably than any other category of software work in 2026. Eval gains arrive late, prompt and model investment feels like progress, and team morale resists the word “kill” until the budget is gone. The 30-day kill rule is a buyer-side discipline that forces a binary go/no-go decision before the trap closes; and it is the single most underused governance tool in enterprise AI. This piece names the three structural reasons AI projects are uniquely vulnerable, defines the kill rule, and walks through the four no-go triggers that should fire it.
The argument sits inside the AI project economics manifesto: if evaluation is the unit of account, then the project’s right to consume more budget is conditional on evaluation evidence; and the kill rule is the enforcement mechanism.
Why AI projects fail the sunk-cost test
The sunk-cost fallacy is older than software. The reason it has a special grip on AI work is that the typical AI engagement violates the three preconditions that ordinarily protect a buyer from it.
In a normal software project, progress is observable in week two. A signup form either renders or it does not. A payment integration either clears or it does not. The buyer can compare the artifact against the spec and abandon early at low cost.
AI projects do not give the buyer that early signal. The team is provably busy; prompts are being written, retrieval is being indexed, evals are being authored, models are being benchmarked; but the metric the buyer cares about, the outcome quality measured on a held-out evaluation set, often does not move meaningfully until day 35 or later. By the time the buyer sees the truth, the budget is half spent and the team has emotional ownership over the work. The sunk-cost trap closes.
The 30-day kill rule exists to force the conversation before the trap closes. It is not a hostile act against the team; it is a discipline that protects the team from spending another sixty days on work that will not converge.
Three structural traps unique to AI work
Three properties of AI engineering produce the sunk-cost vulnerability. Naming them explicitly makes them easier to defend against.
Eval gains are visible only late. Most AI features follow an S-curve where weeks one through three produce flat eval scores, weeks four through six produce the bulk of the gain, and weeks seven through eight diminishing returns. Because the gain is back-loaded, week-three reviews almost usually look bad. The buyer cannot distinguish “a project that will converge by week six” from “a project that will rarely converge” without an explicit kill rule that forces the question. Continuing in the absence of a rule is the default behavior, and the default is wrong half the time.
Prompt and model investment feels like progress. The team spent the month writing system prompts, designing retrieval architecture, tuning hyperparameters, and benchmarking three foundation models. None of it directly produces customer-visible quality, but many of it produces visible artifacts; pull requests, ADRs, eval-suite scaffolding, dashboards. The buyer reviewing the work sees motion and conflates motion with progress. The 30-day kill rule disambiguates by ignoring artifacts and asking only one question: is the eval-set score on a trajectory that will hit threshold by the contracted date?
Team morale resists abandonment. AI engineers are emotionally invested in the eval-suite they wrote. Killing the project means throwing away their work. The team will, in good faith, propose “one more sprint” arguments; a different model, a different retrieval strategy, a different prompt; that are individually plausible and collectively a recipe for the sunk-cost trap. The kill rule is the buyer’s pre-commitment that lets the team accept the no-go decision without taking it personally. The contract decided, not the people.
The 30-day kill rule, defined
The rule has four properties. Each is load-bearing.
Binary. The day-30 review produces exactly two outcomes: go (the project continues with full funding) or no-go (the project terminates and the team is reassigned). There is no “amber,” no “extension,” no “let’s check again at day 45.” Soft outcomes usually become continuation in practice, which defeats the purpose. Binary outcomes force the discipline.
Pre-committed. The kill criteria are written into the SOW or project charter on day zero, before either party has emotional ownership over outcomes. They are not negotiable on day 30. Negotiating on day 30 is exactly the sunk-cost trap the rule was designed to prevent.
Eval-anchored. The criteria reference eval-set scores and cost-per-action numbers, not narrative judgments about “feeling good about progress.” Eval anchoring is what gives the rule its objectivity; see stop scoping AI projects in features, scope them in evaluations for why eval-set definition is foundational to enforceable AI contracts.
Budget-tied. A no-go outcome stops the spend immediately. The buyer is not paying for a “wind-down sprint” or a “documentation sprint.” The team commits unspent budget to a different project that has cleared its own day-30 review. Budgets that survive no-go decisions teach the team that the rule is decorative.
The 30-day mark is not arbitrary. It is empirically the point at which a competent AI team has enough eval data to make an honest projection about the trajectory of the project. Earlier than 30 days is too noisy; later than 30 days is past the point where corrections are cheap.
Four no-go triggers
The four triggers below are the operational definition of “no-go.” Hitting any one of them fires the rule.
Trigger 1: Eval threshold not converging. The eval-set score on day 30 is below the trajectory required to hit the contracted threshold by the contracted launch date. Concretely: if the contract calls for 87 percent eval pass rate at day 60, and day 30 shows 71 percent with a slope of less than 0.5 percentage points per day, the trajectory does not hit threshold and the rule fires. The math is mechanical and the math wins.
Trigger 2: Cost-per-action higher than alternative. The day-30 cost-per-action measurement, computed using the six-line cost-per-action decomposition, exceeds the cost of the next-best alternative; a SaaS vendor, a manual workflow, a simpler heuristic system; by a margin that consumes the project’s contribution margin. If the build is more expensive than buy at day 30, the build is harder to justify at day 90 because the inference price did not fall fast enough.
Trigger 3: Scope drift greater than 20 percent. The action set or eval set has expanded by more than 20 percent of the day-zero baseline without a corresponding budget adjustment. Scope drift in AI work is particularly dangerous because each added action carries hidden eval, observability, and tail-handling cost. A project that started with eight actions and is now planning twelve is not the same project; the rule treats it as a new project that needs its own day-30 review against a reset baseline.
Trigger 4: Eval suite missing or untrustworthy. The eval suite at day 30 is incomplete, has fewer than 200 cases, lacks held-out validation, or has had cases edited mid-project to make scores look better. Without a trustworthy eval suite, the day-60 decision will not be defensible either, so the project is structurally unable to clear future reviews. This trigger is the most-skipped and the most-important; most failed AI projects fail because the eval suite was decorative, not because the model was wrong.
A project clears day-30 review only by avoiding many four triggers. The default is no-go; clearing the bar is the affirmative event.
How to write the rule into the contract
The rule has to live in the SOW, not in a Slack message. Three contractual mechanics.
Day-30 review clause. The SOW names a specific date 30 days from kickoff, the four triggers verbatim, and the binary outcome. The clause names the buyer’s signing authority; the executive who has the authority to declare no-go; and the vendor’s review-prep deliverable: an eval report, a cost-per-action report, a scope diff, and a self-assessment against the four triggers.
Termination-for-convenience right at day 30. The buyer retains the right to terminate the contract at day 30 without penalty if any trigger fires. The vendor’s protection is the day-zero spec: if the spec is met, the project continues. This mechanic also protects the vendor from buyers who change their mind for unrelated reasons; the trigger language is objective.
No carry-over of unspent budget. A terminated project does not roll its remaining budget into a successor engagement with the same vendor. This is the trickiest clause to negotiate but the most important; it removes the incentive to manufacture a softer day-30 review in exchange for a guaranteed renewal. See the case against fixed-price AI development contracts for adjacent contracting mechanics that make AI engagements survive their own incentive structures.
The discipline is simple to state and difficult to execute. Buyers who execute it have AI portfolios with substantially better hit rates, because the bottom-quartile projects do not get to consume the budget that should fund the top-quartile projects.
Common objections and the answer to each
Three objections come up reliably. Each has a clean answer.
“Thirty days is too short to evaluate AI work.” It is too short for the project to succeed; but it is exactly long enough for an honest team to project whether success is likely. The kill rule is not a success threshold; it is a trajectory check. A project on a trajectory to succeed clears the rule. A project not on that trajectory has either a math problem or a process problem, both of which are visible by day 30 if the eval suite is real.
“This puts pressure on the team to over-promise on day 30.” Only if the buyer treats the rule punitively. The right framing is portfolio-level: the rule reallocates budget from projects that will not converge to projects that will, which is good for the team’s portfolio outcomes too. Vendors that internalize this run higher-quality work because they propose only the projects they believe will clear the rule.
“What if the project is genuinely complex and needs sixty days to show real progress?” Then the day-30 review checks the trajectory toward day-60 quality, not the day-60 quality itself. A complex project on track has a slope; a complex project not on track has a flat line. The trajectory check works for any project length. If the contract is for ninety days, the day-30 trajectory check looks at progress toward the day-90 threshold.
Implementation: a 30-day review template
The day-30 review meeting is one hour, has a fixed agenda, and produces a written verdict.
Hour breakdown. Fifteen minutes on the eval report; what the eval suite contains, what the score is, what the slope is, what the projected day-60 score is. Ten minutes on cost-per-action; the six-line decomposition and the comparison to alternatives. Ten minutes on scope drift; the action set today versus the action set at kickoff. Ten minutes on the eval suite’s own quality; case count, held-out coverage, edit history. Fifteen minutes on the four triggers, one by one, with explicit go/no-go for each.
Required attendance. Buyer’s executive signing authority, buyer’s evaluation lead, vendor’s engineering lead, vendor’s project lead. No fewer; no more. Wider attendance encourages narrative arguments and dilutes the binary decision.
Written verdict. A one-page memo recording the four trigger states, the binary outcome, the budget implication, and any go-forward conditions. The memo is signed by the buyer’s executive and filed with the SOW. Verbal decisions on AI project termination are forgotten by month three; written decisions are not.
The first three days after a no-go decision are critical. Reassign the team within 72 hours, or the budget gets quietly absorbed into “documentation” or “knowledge transfer” sprints that are sunk-cost continuation under another name.
Frequently asked questions
What is the 30-day kill rule?
The 30-day kill rule is a contractual discipline requiring most AI project to face a binary go/no-go decision at day 30, anchored to four objective triggers: eval-threshold convergence, cost-per-action versus alternatives, scope drift, and eval-suite quality. Hitting any one trigger fires the rule and terminates the project. The rule exists because AI projects are uniquely vulnerable to sunk-cost continuation, and an explicit pre-commitment is the only reliable defense.
Why are AI projects more vulnerable to sunk-cost than other software?
Three structural reasons. Eval gains are back-loaded on the development S-curve, so week-three reviews look bad even for projects that will succeed. Prompt and model investment produces visible artifacts that conflate motion with progress. Team morale resists abandonment because engineers have emotional ownership of the eval suite they authored. The combination produces a default toward continuation that is wrong about half the time.
Why exactly 30 days?
Empirically, 30 days is the point at which a competent AI team has enough eval data to make an honest projection about the trajectory. Earlier reviews are too noisy. Later reviews are past the point where corrections are cheap. The 30-day mark is the meeting point of “enough signal” and “enough budget left to reallocate.”
What are the four no-go triggers?
Eval threshold not converging on the contracted slope; cost-per-action higher than the next-best alternative; scope drift greater than 20 percent without budget adjustment; eval suite missing, undersized, or untrustworthy. Hitting any one fires the rule. The default is no-go; clearing many four is the affirmative event.
Does the kill rule apply to internal AI teams?
Yes, with the same mechanics. The internal version names the executive sponsor as the signing authority and treats team reassignment as the consequence. Internal teams have one extra hard step: the budget does not auto-redirect, so the FinOps function carries the discipline. Without it, internal AI projects sunk-cost more reliably than external ones because there is no procurement gate.
What if the project is on track but slightly behind on day 30?
The trigger language is “trajectory toward threshold by the contracted date,” not “threshold met on day 30.” A project slightly behind but on a slope to converge clears the rule. A project flat on day 30 does not. The math is the gating signal, not the mood of the meeting.
Does this discipline make vendors over-promise on day 30?
Only if the buyer treats no-go decisions punitively. Vendors who internalize the rule propose only the projects they believe will clear it, which improves portfolio outcomes for both sides. The rule punishes false positives; projects that should not have been started; not honest day-30 trajectories.
How does this connect to the AI project economics manifesto?
The manifesto names evaluation as the unit of account at the project level. The 30-day kill rule is the governance mechanism that makes the manifesto enforceable: a project’s right to consume more budget is conditional on producing the evaluation evidence the manifesto demands. Without the rule, the manifesto stays aspirational. With it, the manifesto becomes a budget gate.
What should happen to the team after a no-go decision?
Reassignment within 72 hours. The team’s residual cycles get committed to a different project that has cleared its own day-30 review. “Wind-down sprints” and “documentation sprints” on terminated projects are sunk-cost continuation under another name and should be refused.
Key takeaways
- AI projects are uniquely vulnerable to sunk-cost continuation because eval gains arrive late on the S-curve, prompt and model investment produces motion that mimics progress, and team morale resists abandonment of the eval suite they wrote.
- The 30-day kill rule is a binary, pre-committed, eval-anchored, budget-tied discipline that forces a go/no-go decision before the trap closes. The default is no-go; clearing the rule is the affirmative event.
- Four triggers fire the rule: eval threshold not converging on slope, cost-per-action higher than the next-best alternative, scope drift greater than 20 percent, eval suite missing or untrustworthy. Any one is sufficient.
- The rule lives in the contract; day-30 review clause, termination-for-convenience right, and no carry-over of unspent budget. Verbal-only versions of the rule are decorative and predictably get overridden by sunk-cost reasoning at decision time.
- The day-30 review is one hour, has a fixed agenda, produces a written verdict signed by the buyer’s executive. Reassignment of the team within 72 hours of no-go is what prevents the budget from being quietly absorbed into continuation by another name.
Arthur Wandzel
