Ask most teams what happens at a project checkpoint and you get the same answer: someone presents a slide deck. Progress since last time, blockers, next steps. That reading of a checkpoint is where AI engagements quietly go wrong. An Intermediate Checkpoint & Pivot Evaluation — ICPE — is not a status review. It is a formal go/no-go gate that tests whether the evidence accumulated so far still justifies continuing. The distinction sounds pedantic until you watch what happens when the honest answer to “should we keep going?” is no. A status meeting has no mechanism to stop. An ICPE gate does — and that mechanism is the whole point. Why a checkpoint and a pivot evaluation are not the same thing A status review reports against a plan. It assumes the plan is correct and measures distance to the finish line. The implicit question is “are we on track?” — and the socially easy answer is almost always “mostly, with some blockers.” Nobody in a status meeting is incentivised to say the project should not exist. A pivot evaluation asks a harder question: given what we now know that we did not know at kickoff, is continuing still the right decision? That reframing changes who is in the room, what evidence has to be on the table, and what outcomes are permitted. A status review can only produce “continue.” An ICPE gate can produce “continue,” “continue with a changed scope,” or “stop cleanly, here are your artifacts.” The reason this matters for AI specifically is that AI projects fail at an unusually high rate. Various analyst estimates put the share of AI initiatives that never reach production at roughly 85% (analyst estimate; directional, not an operational benchmark from any single deployment). When the base rate of failure is that high, an engagement structure that can only ever conclude “keep going” is structurally hostile to the buyer. The ICPE gate exists to make stopping a first-class, non-embarrassing outcome. What an ICPE gate actually evaluates At each gate, the engagement is re-tested against three things, and all three have to hold for a “go” to be legitimate. The first is the evidence produced since the last gate — not activity, evidence. A model that trained is activity. A model whose measured behaviour on representative data clears the threshold agreed at kickoff is evidence. Experiment tracking makes this distinction auditable rather than rhetorical; the difference between “we ran the sweep” and “the sweep produced a signed-off result” is exactly the difference a tool like a W&B table that logs POC evidence you can sign off on is built to record. The second is the risk structure established up front. Every serious engagement should open with a risk assessment — a map of where the project is most likely to fail (data quality, distribution shift, integration surface, regulatory exposure). An ICPE gate is where that map gets refreshed against reality. Risks that were speculative at kickoff are now either retired, confirmed, or newly visible. A gate that does not re-open the risk map is not a pivot evaluation; it is a status review wearing the name. The third is the outcome the buyer is actually paying for. This is where outcome ownership gets exercised in practice rather than promised in a proposal. The gate asks: is the outcome still reachable at acceptable cost, or has the evidence moved the cost estimate somewhere the buyer would not have signed off on originally? Who owns the go/no-go call? The go/no-go decision belongs to the buyer, informed by the delivery team’s honest read of the evidence. This is a deliberate asymmetry. The team that did the work has an obvious bias toward continuing — sunk cost, momentum, the discomfort of declaring their own work insufficient. Putting the final call with the party paying for the outcome, and requiring the team to present evidence rather than a recommendation dressed as fact, is what keeps the gate honest. In our experience, the engagements that stop well are the ones where “no-go” was named as a legitimate outcome at kickoff, not the ones where it had to be invented in the room under pressure. ICPE gate: status review vs pivot evaluation Dimension Routine status review ICPE gate (pivot evaluation) Core question “Are we on track to the plan?” “Does the evidence still justify continuing?” Permitted outcomes Continue Continue / re-scope / stop cleanly Evidence required Progress narrative Measured results vs kickoff thresholds Risk treatment Blockers list Full risk map re-tested against reality Decision owner Delivery team (implicit) Buyer, on evidence from the team What “no” produces Nothing — no mechanism Certified artifacts handed over, project stops Failure discovered At final delivery At the gate, months earlier The most consequential row is the last one. In an unstructured engagement, the moment of truth is final delivery — the worst possible time to learn a project cannot work, because the entire budget is already spent. An ICPE gate pulls that discovery forward. Instead of finding out at month six, the engagement can stop at month three with a data audit, a refreshed risk map, and a technical assessment already in hand. What happens to the buyer’s deliverables on a “no-go” This is the question that separates a real gate from a theatrical one. If stopping means the buyer walks away with nothing, then “no-go” is a punishment and no rational buyer will ever choose it — which means the gate does not actually function. A working ICPE gate is defined so that each checkpoint certifies a set of intermediate artifacts as complete and reusable before the go/no-go call is even made. Passing through a gate is what makes those artifacts final, whether or not the project continues. A data audit that exposed the integration problems, a labelled evaluation set, a risk map now grounded in evidence, a technical feasibility assessment — these have standalone value. They are frequently the input to a differently scoped second attempt, sometimes with a different vendor, sometimes in-house. That is the ROI logic in plain terms: the measurable outcome of a correct early stop is the fraction of budget preserved plus the reuse value of what each gate has already certified. A stop at gate two is not a failed project. It is a project that spent 30% of its budget to learn something that would otherwise have cost 100% to learn at the end. Scoping the work as [an AI engagement scoped to the problem rather than a fixed feature list](how we engage) is what makes this structure possible in the first place — you cannot gate an engagement that was sold as a guaranteed deliverable. How the gate re-tests the upfront risk assessment The link between the opening risk assessment and each subsequent ICPE gate is the mechanic that makes milestones into decision points rather than reporting rituals. At kickoff, the risk assessment is necessarily speculative — it names plausible failure modes ranked by likely impact. It cannot yet know which ones are real. Each gate refreshes that map against evidence. A risk flagged as “high: training data may not represent production distribution” is, by the second gate, either measured and retired, measured and confirmed as fatal, or replaced by a risk nobody anticipated. The gate’s job is to re-rank. A risk that was theoretical and is now demonstrated moves to the top; a risk that was feared and turned out benign drops off. The decision at the gate is made against the refreshed map, not the kickoff one. When AI project scoping is done well, the connection between the risk assessment and the pivot evaluation is explicit — this is the same discipline that performance-engineering research from venues like the ICPE conference signals for AI project scoping, where measured behaviour under realistic conditions, not projected behaviour, drives the decision. The pattern that connects the two is simple: decisions follow evidence, and evidence is re-collected at every gate. FAQ How does ICPE actually work? ICPE — Intermediate Checkpoint & Pivot Evaluation — is a scheduled go/no-go gate inside a structured AI engagement. At each gate, the accumulated evidence is tested against the outcome the buyer is paying for, and the engagement is explicitly permitted to continue, re-scope, or stop. In practice it means failure gets discovered mid-engagement, when most of the budget is still unspent, rather than at final delivery. What is an Intermediate Checkpoint & Pivot Evaluation within a structured AI engagement, and how does it differ from a routine status review? A status review reports progress against a plan and can only conclude “continue.” An ICPE gate asks whether the plan itself is still justified given new evidence, and can legitimately conclude “stop.” The difference is the permitted set of outcomes: a status review has no mechanism to end the project, while a pivot evaluation treats a clean stop as a first-class result. What decisions get made at an ICPE gate, and who owns the go/no-go call? The gate decides whether to continue, change scope, or stop, based on measured results versus the thresholds agreed at kickoff. The go/no-go call belongs to the buyer, informed by the delivery team’s honest read of the evidence. That asymmetry is deliberate — it keeps the decision with the party paying for the outcome rather than the party biased toward continuing. What evidence and artifacts must be in place before an ICPE gate can be passed? Measured results against kickoff thresholds — not a progress narrative — plus a refreshed risk map and whatever intermediate artifacts the gate is defined to certify, such as a data audit or a technical feasibility assessment. Experiment tracking makes the difference between “we ran the work” and “the work produced a signed-off result” auditable. A gate cannot be passed on activity alone. What happens to the buyer’s deliverables when an ICPE gate results in a ‘no-go’ and the project stops? Each gate certifies its intermediate artifacts as complete and reusable before the go/no-go call, so a stop leaves the buyer holding real, standalone value — a data audit, an evaluation set, a grounded risk map, a feasibility assessment. These are often the input to a differently scoped second attempt. A correct early stop preserves the unspent budget and hands over reusable evidence rather than nothing. How does an ICPE gate re-test the upfront risk assessment against real project evidence? The opening risk assessment is speculative — it names plausible failure modes ranked by likely impact. Each gate re-ranks that map: risks are retired, confirmed, or newly surfaced based on what the evidence now shows. The go/no-go decision is made against the refreshed map, not the kickoff one, which is how milestones become decision points instead of reporting rituals. How do ICPE gates change in regulated industries where checkpoints also serve as audit evidence? In regulated contexts like pharma, each ICPE gate doubles as a documented audit point — the pivot evaluation and its evidence become part of the compliance record. This raises the bar on what must be captured at every gate but also turns the engagement structure into an asset for regulatory review. It is one reason the cost of delaying AI adoption in pharma is easy to underestimate: structured, gated engagements produce the audit trail regulators expect. If you are scoping AI work and cannot describe, before kickoff, what evidence a “no-go” would require and what the buyer keeps when it happens, you do not have an ICPE gate — you have a status meeting with a more serious name. Getting that structure right is the core of how our R&D engagements are scoped around outcome ownership. The failure class it defends against is the one where a project runs its full budget only to discover at the end that it never should have started.
