A running list of AI projects that shut down or missed expectations includes Apple's repeatedly delayed Siri AI and OpenAI's messy "super app" launch. What criteria should a company use to decide whether to continue or end an AI project missing expectations?

WHAT WAS ASKED

A company's AI project is underperforming. The question is what criteria should govern the continue-or-kill decision. Two examples anchor the question: Apple's delayed Siri modernization and OpenAI's troubled super-app launch. SimulQ deliberated on the clean question: what is the right decision framework, and what does it actually require that generic project management does not?

WHERE THE PANEL DISAGREED

The panel agreed on the broad categories. The disagreement was structural, not factual, and it matters for how a company actually uses the framework.

One position argued that the framework should be comprehensive: eight or more criteria, scored and weighted, reviewed by stakeholders, with scenario planning across stop, continue, pivot, and scale-down options. The instinct here is completeness. The vulnerability is that a framework with eight equally weighted criteria produces deliberation, not decisions. When every factor gets a column, the hardest call, does this project deserve to exist at all, gets diffused across a spreadsheet.

A second position pushed back on comprehensiveness in favor of primacy. It identified one criterion that overrules the others: whether the failure is a fixable execution problem or a fundamental technical limit. If it is the latter, no amount of strategic alignment or stakeholder enthusiasm changes the verdict. Kill it. This is a stronger claim than the comprehensive list because it tells you what to do when the criteria conflict, which they will.

A third position treated the decision as a financial instrument. Define the metrics before reviewing the results. Set kill conditions at project launch, not at the post-mortem. The practical rule it offered, continue only when strategic importance, improving measured value, credible scale economics, and controllable risk all hold simultaneously, is the most operationally useful formulation in the panel. Its vulnerability: it assumes companies set those gates at the start, which the Apple and OpenAI examples suggest they do not.

The fourth position was consistent with the others but added one specific claim the others soft-pedaled: brand damage from a failing consumer-facing AI is not a lagging indicator. It is a leading one. A user who learns to distrust your AI assistant does not reset when you ship version two. This is not a minor dissent. It changes the risk weighting on consumer-facing projects relative to enterprise or internal ones.

None of these positions contradict each other directly. The disagreement is about which criterion has veto power when the rest of the framework produces ambiguity.

HOW STRONG THE AGREEMENT IS

The panel agreed that sunk cost is not a criterion. Past spend is irrelevant to the forward decision. This agreement is strong and independently reached.

The panel agreed that opportunity cost is underweighted in most corporate AI reviews. Keeping a failing project alive does not just cost money. It consumes the specific talent, ML engineers, data scientists, product managers with AI fluency, that higher-potential projects need. This agreement is strong.

The panel agreed that criteria should be defined before results are reviewed, not after. Setting kill conditions after the project misses targets invites rationalization. This agreement is strong.

The area where agreement is weakest: the panel treated "strategic importance" as a near-automatic reason to continue. The Siri example breaks this. Siri is unambiguously strategically important to Apple. Apple's entire hardware ecosystem depends on a competitive AI assistant. Strategic importance did not resolve the problem. It may have extended the delay by making termination unthinkable. Strategic importance is a reason to fund the project aggressively, not a reason to tolerate indefinite underperformance.

What the panel collectively underweighted: the distinction between projects that are late and projects that are wrong. A late project has a credible technical path and a resource problem. A wrong project has neither, the architecture, the scope, or the user model is the error. The OpenAI super-app case looks less like a delay and more like a scope error: the concept preceded a clear user need. The Siri case looks less like a scope error and more like an organizational one: the capability was understood but the internal systems to deliver it were fragmented. The criteria for late-and-fixable differ from the criteria for wrong-in-conception, and the panel did not draw this line cleanly.

The strongest objection to the panel's consensus: a framework of eight criteria with equal standing will be used to justify continuation in most corporate environments, because the political cost of killing a project with eight checkboxes is lower than the political cost of admitting the project was misconceived. The framework, as presented, is optimized for rigor. It is not optimized for institutional honesty.

WHAT THIS MEANS

There is one clear answer, but it requires accepting something the panel circled around without stating directly.

The continue-or-kill decision is not a scoring exercise. It is a classification exercise. Before any criteria are applied, the company must determine which of two situations it is in.

Situation A: The project is correctly conceived but incorrectly executed. The user need is real and validated. The technical path exists. The failure is in resources, talent, organizational structure, or timeline management. Here the criteria are: is the execution problem solvable within a defined budget and time ceiling? If yes, continue. If not, find out why not before continuing.

Situation B: The project is incorrectly conceived. The user need is assumed rather than validated. The technical path is speculative. The failure is in the original premise, the scope, the architecture, or the market assumption. Here no execution fix resolves the problem. The criteria for continuation no longer apply. The question becomes: can the underlying assets, the data, the model work, the infrastructure, be redirected to a correctly conceived project? If yes, pivot. If no, end it.

The reason this distinction matters for Apple and OpenAI specifically: both companies appear to be in Situation B on the specific projects cited, not Situation A. Apple's Siri problem is not primarily a delay. It is an organizational design problem, Siri was built on a fragmented architecture that makes it structurally unable to integrate with the on-device intelligence Apple's other systems require. No deadline extension resolves an architectural error. OpenAI's super-app problem is not primarily an execution problem. The concept of a single app that integrates AI across all use cases preceded clear evidence of what users actually wanted the integration to do. No additional sprint resolves a use-case ambiguity.

The framework that works is therefore a two-stage structure, not an eight-criteria scorecard.

BOTTOM LINE

Classify before you evaluate.

Before applying any decision criteria, determine whether the project is late or wrong. Late means the concept is sound and the execution failed. Wrong means the concept is the problem. The criteria used to assess a late project, ROI trajectory, technical feasibility, team readiness, are not useful for assessing a wrong project. Applying them creates the appearance of rigor while avoiding the real question.

For a late project: the decision gate is whether a specific execution fix, with a defined budget ceiling and a defined time ceiling, will produce measurable value improvement against a pre-set threshold. That threshold is set before reviewing current results. The decision options are: fund the fix, reduce scope to what is actually deliverable, or end it.

For a wrong project: the decision gate is whether the underlying assets, model work, data, infrastructure, team knowledge, can be redirected to a correctly conceived use case. If yes, pivot immediately. If no, end it and document what was learned.

In both cases: strategic importance is not a reason to continue. It is a reason to be rigorous about the decision. Brand damage from a failing consumer AI is a leading indicator, not a lagging one. Opportunity cost is measured in people and compute, not just money. Kill conditions are set at project launch, not at the review meeting.

The decisive factor: the classification error. Most companies apply the criteria for a late project to a project that is actually wrong. That is how Siri delays stretch across years and super-app launches ship half-formed. The framework fails not because the criteria are wrong but because the prior classification question was never asked.

What would change this verdict: evidence that Apple's Siri delays are primarily a resource or timeline problem rather than an architectural one, or that OpenAI's super-app concept had pre-validated user demand that execution failed to serve. The available record does not support either reading.

Classify first. Then evaluate. Then act inside a defined ceiling.