A use case stalls. The team’s first instinct is to reach for a bigger model — swap the 13B for a 70B, add a reasoning tier, prompt harder. Sometimes that closes the gap. More often it burns compute against a ceiling the model was never going to lift, because the ceiling is the data. A data-centric approach to AI is the discipline of holding the model fixed and systematically improving the quality, coverage, and labelling of the data the use case depends on. It is the opposite of the reflex above. And in feasibility terms, it is the single most useful lens we have for telling apart a use case that is genuinely speculative from one that is merely data-starved — a distinction that decides whether a project gets budget, gets deferred, or gets scoped into a bounded research phase. This is not a promise that data work rescues every use case. It is the mechanism that tells you whether the constraint you are hitting is the data or the model — before you commit a development budget to the wrong one. What a data-centric approach actually means in practice The clearest way to see it is by what changes and what stays fixed. In a model-centric workflow, the dataset is treated as a given and the engineering effort goes into the model: architecture, size, fine-tuning recipe, prompt design, decoding strategy. In a data-centric workflow the model is treated as a fixed baseline — often a capable off-the-shelf model like a Vicuna variant or a hosted frontier model — and the engineering effort goes into the inputs it consumes. In practice that means a specific set of moves. You audit whether the data that describes the task even exists in a usable form. You measure label quality and inter-annotator agreement rather than assuming the labels are correct. You look for coverage gaps — the classes, edge cases, and long-tail inputs that the production distribution contains but the training or retrieval corpus does not. You clean systematic noise. You improve the annotation guidelines and re-label, rather than adding a second model to paper over ambiguous labels. The reason this works is not ideological. Modern generative models are largely commoditised at the capability tier most enterprise use cases need. When two teams start from the same base model, the one with cleaner, better-covered, better-labelled data will produce a system that behaves better on the task — and no amount of prompt engineering closes a gap that comes from the data missing the relevant signal entirely. We see this pattern regularly: the difference between a demo that impresses and a system that survives production is almost always in the data, not the checkpoint. If you want the failure-mode counterpart to this argument — how GenAI systems that pass a lab demo collapse the moment they meet real production data — our companion piece on why GenAI fails on production data walks through the mechanism in detail. This article stays on the feasibility question: how a data-centric review changes the decision to build. How is a data-centric approach different from a model-centric one? The two are not rivals in the abstract; they are two hypotheses about where a stalled use case is blocked. The divergence point is the moment a use case underperforms. A model-centric team reads underperformance as evidence the model is too weak and escalates capability and compute. A data-centric team reads the same underperformance as a question — does the data support this task at all? — and measures before spending. Here is the contrast made concrete. Dimension Model-centric response Data-centric response Diagnosis of a stalled use case Model is too small / too general Data may not carry the signal the task needs First lever pulled Bigger model, more fine-tuning, harder prompts Label audit, coverage analysis, data cleaning What is held fixed The dataset The base model Dominant cost Compute and inference spend Annotation and data-preparation effort Failure it guards against Under-powered model Data-starved task masquerading as a model gap Feasibility output “We need a better model” (vague) “We need N labelled examples of class X” (costable) The last row is the one that matters for a decision-maker. “The model isn’t good enough” is not a budget line — it has no defined end state. “We are missing labelled coverage of these three input classes, and preparing it costs roughly this much” is a budget line the buyer can approve or decline. A data-centric assessment converts a vague capability complaint into a measurable data-readiness estimate. That conversion is the practical value, and it is why data labelling and annotation services sit directly on the GenAI feasibility path rather than being a downstream chore. How data readiness changes the feasibility classification When we run a GenAI feasibility assessment, we classify each candidate use case as automatable, speculative, or research. Those labels are not judgments about the model — they are judgments about the whole system, and data readiness is the dimension that most often moves a use case between them. Automatable — the data exists, is reasonably clean, covers the production distribution, and is labelled well enough that a capable off-the-shelf model can perform the task with acceptable reliability. The constraint here is engineering and integration, not capability. Speculative — the use case looks appealing but something structural is unproven. Critically, “the data doesn’t support it” and “no model can do this” both land here under a superficial review, even though they are completely different risks. Research — the task genuinely sits at or beyond the current capability frontier, and closing the gap requires investigation with an uncertain outcome. The whole point of the data-centric review is to split that middle bucket. A use case that a superficial review flags as speculative because “the model isn’t good enough” frequently turns out to be blocked only by a fixable data gap. Once that gap is named and costed, the use case is no longer speculative — it is bounded research, or even automatable pending a defined data-preparation step. The uncertainty has a price tag and an end state. This is an observed pattern across our GenAI feasibility work, not a benchmarked conversion rate; the exact proportion depends heavily on the domain and the maturity of the client’s data. The inverse is just as important. If the data-centric review shows the data does carry the signal and the labels are clean, and the task still fails, that is strong evidence the ceiling is genuinely the model or the problem formulation — which keeps the use case honestly in the research bucket rather than letting a team spend a year cleaning data that was never the constraint. What does data-centric work involve inside the assessment? The data-centric review is a defined step within the feasibility assessment, run before a use case is classified. It is diagnostic, not remedial — the goal is to establish readiness, not to fix everything on the spot. A practical version of the checklist looks like this. Data-readiness diagnostic checklist Existence — Does data describing this task exist at all, in any form the organisation controls or can license? A surprising number of use cases fail here, quietly. Access — Can the data actually be used, given contractual, privacy, and governance constraints? Data that exists but cannot be touched is, for feasibility purposes, absent. Coverage — Does the available data span the input distribution the system will see in production, including the edge cases and long tail? Gaps here produce systems that demo well and fail on real traffic. Label quality — Where labels exist, what is the inter-annotator agreement? Are the annotation guidelines specific enough that two competent annotators produce the same label? Signal presence — Does the data actually contain the information the task requires, or are you asking the model to infer something the data never recorded? This is the check that separates data-starved from model-limited. Preparation cost — For each identified gap, what is the rough effort to close it — new collection, re-labelling, cleaning, or guideline revision? The output of this step is not a yes/no. It is a readiness estimate per use case: which gaps exist, whether they are fixable, and roughly what fixing them costs. That estimate is what lets the assessment classify honestly. When the constraint is labelling, the data-quality gate behind most GenAI failures becomes the concrete work item rather than an abstract worry. How do you tell whether a stalled use case is limited by the model or the data? This is the question the whole approach exists to answer, and there is a reasonably clean test. Hold the model fixed at a capable baseline. Then deliberately improve one thing at a time on the data side — clean a known-noisy slice, re-label an ambiguous class, add coverage of an under-represented input type — and measure whether task performance moves. If targeted data improvements move the metric, the data was the binding constraint, and you now have a lever with a known cost. If you have cleaned, covered, and correctly labelled the data and performance still sits below the requirement, the ceiling is the model or the problem itself. That is a genuinely different situation, and it is where a larger model, a different architecture, or a reformulated task is the right response — not before. The mistake we see most often is skipping this test entirely and jumping straight to a bigger model. It is an expensive way to learn that the data was the problem, because the bigger model usually produces a small, noisy improvement that is easy to over-interpret. The data-centric test is cheaper and more diagnostic: it tells you which wall you are hitting. For teams weighing a base-model swap against data investment, the underlying trade-off is the same one we unpack in the comparison of when a larger-capacity model genuinely fits a use case — capacity helps only when capacity was the limit. When does better data move a use case into research — and when doesn’t it? Improving data moves a speculative use case into a bounded research phase when three things hold: the missing data is identifiable, it is acquirable within a defined effort, and there is a credible reason to expect the task becomes tractable once the gap is closed. Under those conditions the uncertainty is scoped — you know what you are buying and roughly what it costs, which is exactly what makes it a bounded research phase rather than an open-ended one. It does not move the use case when the constraint is not the data. If the task requires reasoning or generation the model class cannot perform regardless of input quality, no amount of data preparation changes that — you are then in genuine research or the use case is simply not yet feasible. It also does not help when the “missing” data cannot be acquired at any reasonable cost, or when the data that would be needed does not exist anywhere because the phenomenon was never recorded. In those cases the honest answer is that the ceiling is real, and a data-centric review’s job is to say so plainly rather than to keep the hope alive. Data readiness at the use-case level connects upward to a broader question. An organisation can have a use case whose data is fixable in principle but whose data infrastructure, governance, and access are not yet in place to support it — which is why use-case feasibility should be read alongside a wider enterprise AI readiness assessment that gates whether it is sensible to start at all. FAQ How does a data-centric approach actually work? It means holding the model fixed at a capable baseline and putting the engineering effort into the data instead — auditing whether the data exists, measuring label quality and inter-annotator agreement, closing coverage gaps, and cleaning systematic noise. In practice you improve the inputs the model consumes rather than reaching for a bigger checkpoint, because when two teams start from the same base model the one with better data produces the better system. How is a data-centric approach different from a model-centric approach to a GenAI use case? They are two hypotheses about where a stalled use case is blocked. A model-centric team reads underperformance as a weak model and escalates capability and compute; a data-centric team asks whether the data supports the task at all and measures before spending. The key practical difference is the output: model-centric gives you “we need a better model” (vague), data-centric gives you “we need N labelled examples of class X” (costable). How does data quality and readiness change whether a use case is classified automatable, speculative, or research? Data readiness is the dimension that most often moves a use case between those buckets. Under a superficial review, “the data doesn’t support it” and “no model can do this” both look speculative even though they are different risks. A data-centric review splits them: a use case blocked only by a fixable, costable data gap moves from speculative to bounded research or even automatable, while a task that fails despite clean, well-covered data stays honestly in research. What does data-centric work actually involve during a GenAI feasibility assessment? It is a diagnostic step run before classification, working through a readiness checklist: does the data exist, can it be accessed under governance constraints, does it cover the production distribution, are the labels of measurable quality, does it actually contain the required signal, and what does closing each gap cost. The output is a per-use-case readiness estimate — which gaps exist, whether they are fixable, and roughly what fixing them costs — not a simple yes/no. How do I tell whether a stalled use case is limited by the model or by the data? Hold the model fixed and improve one thing at a time on the data side — clean a noisy slice, re-label an ambiguous class, add coverage of an under-represented input — then measure whether performance moves. If targeted data improvements move the metric, the data was the constraint and you have a costable lever; if performance stays below requirement after the data is clean and complete, the ceiling is the model or the problem formulation. When does improving data move a speculative use case into a bounded research phase, and when does it not? It moves the use case when the missing data is identifiable, acquirable within a defined effort, and there is a credible reason to expect tractability once the gap closes — then the uncertainty is scoped and priced. It does not help when the model class cannot perform the task regardless of input quality, when the needed data cannot be acquired at reasonable cost, or when the phenomenon was never recorded anywhere; in those cases the ceiling is real and the review should say so. The naive spend conversation — bigger model versus better data — is the wrong frame. The right question is narrower and more answerable: for this specific use case, is the ceiling the data or the model, and what would it cost to find out? That is the classification a data-centric review inside a feasibility assessment is built to deliver, before development commits a budget to the wrong constraint.
