Three assumptions kill most vertical AI projects before month three. None of them are checked before architecture is chosen, before engineering begins, and before the budget is committed.
The first assumption: the data exists and is clean enough to use. The second: the process is stable enough to automate. The third: there is a decision owner who will act on AI output. All three are frequently wrong. The cost of discovering they are wrong in month eight is not the same as discovering it in week two.
A discovery sprint is the mechanism for validating or invalidating these assumptions before they become expensive. It costs four weeks of structured work. It saves the rest.
The Three Assumptions That Kill Vertical AI Projects
Data exists and is accessible. Most enterprise data is siloed, inconsistent, undocumented, or access-controlled in ways that block the intended use case. The dataset that was described in the kickoff meeting as “readily available” turns out to require approval from three departments, extraction from a system with no documented API, and cleaning work that was scoped at two weeks and takes four months.
The AI system that was designed around that data cannot be built as designed. The options at month six are: rebuild the data pipeline (which changes the timeline), reduce the scope (which changes the value), or cancel. All three are more expensive than a two-week data inventory in the discovery phase.
The process is stable enough to automate. The process as documented and the process as practiced differ. They differ in every organization that has been operating for more than five years. The AI system trained on documented procedures encounters real operators who have developed workarounds, informal taxonomies, and exception-handling that exists nowhere in writing.
The result is a system that performs well in controlled testing and fails in the hands of actual users. Not because the model is wrong. Because the model was trained on a process that the users do not follow.
There is a decision owner who will act on AI output. An AI system without a decision owner is a research project. The system can produce excellent recommendations, and nothing changes, because nobody is empowered or accountable for acting on them. Ghost deployments accumulate in enterprises this way: systems that generated good output that nobody was structured to use.
What a Discovery Sprint Actually Produces
A discovery sprint does not produce a slideware roadmap with phases and milestones. It produces a set of validated or invalidated hypotheses about a specific use case.
The five outputs are concrete deliverables, not analysis:
Process map. What actually happens, documented from observation, not from the process documentation. This includes the exceptions, the workarounds, the undocumented judgment calls. It is built by talking to the actual operators, not the process owners.
Data inventory. What exists, where it lives, who controls access, what quality issues are present, and what transformations would be required to make it usable. Every data assumption is tested against reality, not against what someone believes to be true.
Decision owner map. For each proposed AI output, who makes that decision today, who will make it after AI is introduced, who is accountable when the AI is wrong, and what the escalation path is for low-confidence outputs. This is a people and governance deliverable, not a technical one.
Value estimate. What does the problem cost today in staff time, errors, missed opportunities, or external services? This is the basis for a realistic ROI conversation and a reality check on whether the use case is worth the investment.
Risk inventory. Regulatory constraints, data privacy requirements, integration complexity, rollback requirements, and the failure modes that must be handled before deployment.
The sprint duration is typically two to four weeks. It requires domain expertise, an AI architect who can translate findings into system constraints, and access to the decision-makers who own the process. It cannot be delegated entirely to IT.
The Data Reality Check
The most common discovery finding is that the data powering the intended use case does not exist in usable form.
The specific forms this takes matter for scoping what follows. Data exists in PDFs without reliable text extraction. Data requires joining three systems with no documented schema. Data exists but the approval process for access takes longer than the project timeline. Data exists but is too sparse in the relevant domain to support the intended use.
Each of these is a different problem with a different solution. Knowing which form the gap takes before committing to a system design is the difference between a buildable scope and an undeliverable promise.
The data maturity gradient applies across most enterprise environments. Some organizations have structured, accessible data where AI projects can move fast. Most have structured but siloed data that requires integration work before a retrieval layer is useful. Many have unstructured, dispersed data that requires an ingestion pipeline as a prerequisite to everything else.
Scoping the first project to what data is actually available, not what data theoretically should exist, is the data discipline that discovery enforces. Building a system that depends on data that does not yet exist is a timeline risk that compounds with every sprint.
The Process Fidelity Problem
Standard process documentation describes the ideal process. AI trained on it learns a version of the process that employees recognize but do not follow.
The discovery technique that surfaces the real process is process shadowing: observing or interviewing the actual operators, not the process owners. The goal is to record the exceptions, the workarounds, and the undocumented heuristics that distinguish how work actually gets done from how it is documented to be done.
A document classification system trained on the formal taxonomy misclassifies documents that practitioners label using informal shortcuts. A customer support AI trained on the knowledge base fails on queries that experienced agents handle using information that lives in practice but not in any documented source.
The process fidelity deliverable from a discovery sprint is a map of where documented process and actual practice diverge. That map drives the most important decision before engineering begins: which version of the process should the system be trained to follow? The documented version, which is cleaner and maintainable but may not match user behavior? Or the practiced version, which matches reality but is harder to document and maintain?
There is no universal answer. Both have costs. The discovery sprint is what makes the decision deliberate instead of implicit.
The Decision Owner Prerequisite
An AI system without a decision owner is a research project. This is not a critique. It is a structural property.
The decision owner is the person, or defined role, who acts on AI output, reviews edge cases, approves high-stakes recommendations, and is accountable when the system is wrong. Without this role defined and staffed before deployment, several predictable failures follow.
The system is used inconsistently, because different people apply different thresholds for when to trust the output. Edge cases accumulate without feedback, because no one is responsible for reviewing them. The system quietly degrades until a failure forces a shutdown.
Minimum viable governance before launch: one named decision owner, a defined review cadence for low-confidence outputs, and a documented escalation path. This is not a compliance exercise. It is the structural condition for a system that improves over time rather than one that drifts toward irrelevance.
Discovery as a Paid Product
The discovery sprint is not a loss-leader or a consulting freebie preceding the real engagement. It is a paid product with a defined deliverable.
The five-output package, process map, data inventory, decision owner map, value estimate, and risk inventory, is valuable regardless of whether an AI project follows. A business that wanted to automate a process and discovers in week two that the data is insufficient has saved a twelve-month project budget. That is a concrete result, not a preliminary.
Scoping discovery by process rather than by day rate aligns incentives: the deliverable is the output, not the time spent. The follow-on engagement, if it happens, is scoped from the discovery findings, not from the initial assumptions that turned out to be partially wrong.
The clients who resist paying for discovery tend to be the ones who most need it. The assumption that everything will be validated during the build phase is expensive. Discovery externalizes that cost to a point in the project where the information is cheapest to acquire.
The five outputs of a discovery sprint are worth more before the build starts than the same information is worth after month six. Scope defines what discovery covers; the process map is where most surprises live.
Related: Vertical AI Wins Where Generic AI Fails and Your Industry Does Not Need an AI Platform