Validation Framework for AI: Decide Before You Choose the Model

Most failed AI projects don't fail because the model was wrong. They fail because the team chose a model before deciding whether AI was the right tool for the problem in the first place. The demo works. The benchmarks hold. Six months later, the system is shelved — not because the engineering broke down, but because nobody had asked, before code, whether the business outcome it was supposed to produce was real, measurable, or large enough to justify the build.

An AI validation framework is the structured assessment that closes that gap. It is not a model evaluation checklist. It runs earlier than that. Before any architecture is locked, before any vector store is provisioned, before anyone benchmarks a foundation model — the framework asks five questions. Is this commercially significant? Is the data ready? What does "good enough" accuracy look like? What happens when the AI is wrong? And — the question most teams skip — is AI actually the right tool for this, or would a simpler approach do?

The framework sits inside P01 — The Right Problem — of EB Pearls' Built to Last™ 2.0 framework. It is the AI-specific complement to the Discovery Workshop™. Where the Discovery Workshop locks the commercial problem and scope for any product build, the AI Validation Framework decides whether AI is the right way to address that problem at all. This article walks through the five decisions, the criteria that drive each one, and the scoring approach that turns the assessment into a go/no-go output a team can actually act on.

The Cost of Skipping Validation

The damage from skipping AI validation rarely shows up at launch. It shows up at the budget review six months later, when the system has been running, the invoices have arrived, and a leadership team is trying to articulate what business metric has actually moved. Often, the answer is none — because none was defined at the start.

This is the most common failure mode in enterprise AI. A team builds something technically credible: a retrieval-augmented generation system over internal documents, an agent that can navigate a workflow, a classifier with strong test accuracy. The engineering is fine. The framing is not. The use case was chosen because it was technically interesting, not because it produced a number a CFO would defend in a board meeting. The data was assumed to exist, was assumed to be clean, and turned out to be neither. The accuracy target was never defined, so "is it working?" became a matter of demo-day enthusiasm rather than measurement.

The cost compounds across three dimensions. There is the direct cost of the build: months of engineering, infrastructure expenditure, and the model API charges that scale with usage. There is the opportunity cost — a team that could have shipped a non-AI version of the workflow in a fraction of the time. And there is the credibility cost: the harder-to-quantify damage to the organisation's appetite for the next AI project, which now has to argue past the last one's results. EB Pearls runs the AI Validation Framework before model selection precisely because the failure pattern repeats across industries, and the fix is upstream of code.

Five Decisions to Make Before You Choose a Model

The framework is a sequence of five decisions, scored independently, then combined. Each decision is binary in spirit — proceed, address, or walk away — though the criteria behind each are qualitative. The order matters: each decision changes the inputs to the next.

Decision 1: Is the problem commercially significant?

The first question is the one most AI projects never explicitly answer. What business metric will move if this system works? By how much? On what timescale? Is the answer large enough to justify the build and the ongoing operational cost?

The criteria here are concrete. There needs to be a metric the business already tracks — support ticket volume, fraud rate, sales conversion, time-to-decision. There needs to be a plausible mechanism by which AI affects that metric: not "we'll add intelligence", but "the AI classifies tickets and routes the majority of them without a human, reducing average handling time by a measurable amount". And the size of the prize needs to clear the cost of building, running, and monitoring the system. AI infrastructure is not free, and model API costs scale with usage.

A common failure pattern: the use case is chosen because it is technically demonstrable rather than commercially valuable. An internal knowledge-base assistant is a frequent example. It demos well, the engineering is interesting, and few of the people who didn't already have the knowledge will ever use it enough to move a business metric. The validation framework forces the question: which decision does this system change, how often, and by how much?

Decision 2: Is the data ready?

The second decision is whether the data the AI will operate on is actually ready to support the use case. This is a separate question from "do we have data". Most organisations have data. The question is whether it is the right data, in the right volume, with the right freshness, in a form the model can use, with the legal basis to use it.

Five dimensions matter here. Volume — is there enough to train, fine-tune, or retrieve from? Recency — is the data current enough to be useful for the decision the AI is supporting? Labelling — for supervised use cases, are labels present, consistent, and accurate? Lineage — can you trace where the data came from and how it was processed? Legal usability — does the data carry the consents and contractual rights you need to use it the way you intend?

This is where many AI projects fail silently. The team assumes the data is ready, builds the system, and discovers in production that the corpus is inconsistent, the labels are noisy, or the consents do not cover the intended use. A data audit at validation time, before architecture is locked, is significantly cheaper than discovery during the build.

Decision 3: What does "good enough" accuracy look like?

The third decision is the one that determines whether the system can ship at all. What level of accuracy is required? On what types of input? Measured how? Agreed by whom?

The criteria vary by use case. A medical diagnostic suggestion may need near-perfect accuracy on positive cases, with conservative behaviour on negatives. A customer-support routing system may be useful well below that. A marketing-copy generator may not need a defined accuracy target at all — it needs reviewer satisfaction.

Two failures are common. The first: nobody defines an accuracy target until launch, at which point the discussion becomes adversarial. The second: the target is defined but the test set isn't, so accuracy is measured on whatever inputs happen to be at hand — typically the inputs the system handles best. The validation framework requires both the target and the representative test set to be defined upfront, written into the Locked Scope Document™, and treated as the contract the system is built against.

Decision 4: What happens when the AI is wrong?

Every AI system is wrong some of the time. The validation question is whether the cost of wrongness is bearable, and what the failure path looks like when it happens.

For some use cases, wrong is cheap — a recommendation a user can ignore, a draft a human will edit. For others, wrong is catastrophic — an automated decision that affects access to credit, healthcare, or legal status. The framework requires the team to map the cost of failure, define the escalation path when the system is uncertain, and decide which decisions need a human in the loop.

This is also where regulatory exposure surfaces. Under the EU AI Act, certain use cases — biometric identification, credit scoring, employment screening — are classified high-risk and require specific human oversight, documentation, and auditability. ISO 42001 and the NIST AI Risk Management Framework provide governance structures for the same questions. If the answer to "what happens when this is wrong" is anything beyond "trivial cost", validation needs to identify the oversight mechanism before the model is selected — because the regulatory tier changes what you are allowed to build.

Decision 5: Is AI actually the right tool?

The fifth decision is the one that gets skipped most often. Could a simpler approach solve this problem at a fraction of the cost?

Many AI use cases are better served by rules, heuristics, or simple statistical methods. A classifier with eight features and a decision tree may outperform a fine-tuned large language model at a small fraction of the operational cost. A search problem may be better solved by a well-indexed database than by a vector store. An automation problem may not need intelligence — it may need an integration.

The framework forces the comparison explicitly. The team specifies what the non-AI version would look like, how well it would perform, and what it would cost. If the AI version doesn't materially outperform that baseline on the criteria that matter, the recommendation is to walk away from AI for this use case. This is rarely the answer leadership wants. It is consistently the answer that saves the most money.

Putting the Decisions Together

Each of the five decisions produces an output: a green (proceed), an amber (address before proceeding), or a red (walk away from AI for this use case). The combined result determines what happens next.

Five greens is rare. A common pattern is three greens, an amber on data readiness, and an amber on accuracy target. That combination is workable — it surfaces what the team needs to do before architecture is locked. A red on commercial significance or on the not-AI question is a project-killer. The validation has done its job.

The scoring is not the point. The discussion is. The framework's value is in forcing five conversations that AI projects routinely skip, in the order that lets each one inform the next. Commercial significance frames why data and accuracy matter. Data readiness changes what accuracy is achievable. Accuracy targets shape the human oversight design. Oversight design shapes the architectural constraints. And the not-AI option remains live throughout — the team can walk away at any point if the simpler approach starts to look better.

The validation output goes into the same Locked Scope Document the Discovery Workshop produces. The architecture session that follows starts with the validation result, not with a blank page. Model selection, when it happens, is constrained by decisions already made — and that is the point.

A Tale of Two AI Projects

An enterprise team we worked with built a retrieval-augmented generation system over its internal policy documents. The engineering was strong: hierarchical chunking, re-ranking, citation surfacing. The demo was impressive. The system shipped to a target audience of roughly two hundred internal employees, most of whom rarely needed to look up policy and, when they did, knew which colleague to ask. Within a year, the project was shelved. No business metric had moved because none had been defined at the start. The validation step that would have surfaced the low commercial significance had been skipped because the use case felt obviously valuable.

Contrast that with an Australian logistics team we worked with. Before any architecture was locked, the team ran AI validation. Commercial significance was clear — a high-frequency routing decision affecting fleet utilisation, made hundreds of times daily, with a measurable cost-per-decision and a measurable improvement target. Data readiness was strong: years of clean, labelled routing data already feeding existing dashboards. The accuracy target was set at a level meaningfully above the existing rule-based baseline. The failure path was defined: when the model was below a confidence threshold, the decision routed to a dispatcher. The not-AI option was tested explicitly and rejected because the heuristic baseline plateaued well below the achievable model accuracy. The team built a smaller, faster model than they would have without validation — and hit positive ROI inside six months.

Same engineering capability. Different validation. Different outcomes.

When Validation Is Essential, and When You Can Move Faster

Validation is essential when the AI build represents real budget, an externally-visible deployment, or a use case touching regulated decisions. If the system is going to make or materially influence a decision that affects a customer, a regulator, or your own compliance posture, run the framework. The cost of a half-day assessment is a fraction of the cost of a six-month build aimed at the wrong target.

Where you can move faster: internal proofs-of-concept aimed explicitly at learning rather than shipping, throwaway experiments scoped to a fixed time-box, and AI features being added to an existing product where commercial significance and data readiness are already established. Even there, the five questions are worth asking — they take an hour and they catch the proofs-of-concept that were quietly heading toward production without the validation that production requires.

What to Do Next

If you have an AI project in flight without a defined commercial metric, ranked data readiness, an agreed accuracy target, a mapped failure path, and a tested non-AI baseline, the AI Validation Framework is the half-day exercise that surfaces what's missing. For the architecture and infrastructure questions that follow, see how we approach building agentic AI systems end to end.

Frequently Asked Questions