Author: Karthik Ogirala

Picture a stainless steel water bottle that your enterprise resource planning (ERP) system lists at 380 grams and your supplier portal lists at 4,560. An AI agent preparing a retailer feed reads both values, picks one, and publishes it. Nothing in the feed shows the choice, and the retailer’s shipping estimate reflects it weeks later.

A conflict rule settles that choice in advance. It tells the agent which source wins, how large a difference matters, when to stop, and what to record.

In Brief

• An AI agent that finds two values for one attribute has to write one of them, and without a rule you cannot see which one it chose.
• A conflict rule has four parts: source priority for each attribute, a tolerance, a stop condition, and a decision log.
• Master data management settles most conflicts upstream, and the conflict rule covers the ones that surface when the agent acts.
• The rule lives in a versioned lookup that the agent calls before it writes a value.
• Replaying past conflicts through the rule shows how often the agent would stop and whether that rate is workable.
• Two named signers and a review date keep the rule accurate as your sources change.

Why Conflicting Master Data Is Different for an AI Agent

Conflicting master data is different for an AI agent because a person who sees two values stops to ask, while an agent has to return an answer and therefore writes one of them.

Think about the last time you caught a mismatch in a product record. You saw two weights, sensed something was off, and walked over to the person who owns the supplier data. That small pause protected your catalog for years, and nobody wrote it into a process because nobody needed to.

Hand the same task to an AI agent and the pause disappears. The agent reads both values and returns one, because the task requires an answer. The record goes out either way, and nothing in the output tells you that two values existed or which one won.

Gartner’s AI-ready data research shows what is at stake across a whole portfolio. Gartner predicts that through 2026, organizations will abandon 60% of AI projects unsupported by AI-ready data, and it describes AI-ready data as data representative of the use case, including its errors and outliers. Two records that disagree are one example of such an error, and your use case decides what the disagreement costs.

The pattern shows up again in Gartner’s agentic AI forecast. Gartner expects organizations to cancel more than 40% of agentic AI projects by the end of 2027, and it names escalating costs, unclear business value, and inadequate risk controls as the reasons. Every conflict an agent resolves without a rule is a small gap in risk control that nobody sees.

Where a human checkpoint disappears from a workflow is a broader question that a readiness assessment answers. The question here is narrower, and it is the one you will face on the day the agent goes live. What should the agent do at the moment two records disagree?

The Four Kinds of Master Data Conflict an AI Agent Faces

An AI agent meets four kinds of master data conflict, and each one calls for a slightly different answer in your rule.

• Two values for one attribute. The ERP says 380 grams and the supplier portal says 384 for the same bottle.
• A stale value against a current one. The supplier revised the specification last month, and only one of your systems received the change.
• Two records for one entity. The same supplier appears twice under slightly different names, each with its own payment terms.
• One field with two meanings. The ERP stores the weight of one bottle, while the supplier portal stores the weight of a case of twelve.

You have probably seen all four in your own data. The first two ask which value is right, while the third asks whether two records describe the same thing and the fourth asks whether the two values measure the same thing. A rule that covers only the first two leaves the other two to the agent’s judgment.

The Four Parts of a Conflict Rule for AI Agents

A conflict rule for an AI agent has four parts: source priority for each attribute, a tolerance, a stop condition, and a decision log. Together they answer the four questions the agent cannot answer for itself. Which value should it trust, how much disagreement should it accept, when should it stop, and what should it leave behind for you?

Source Priority for Each Attribute in a Conflict Rule

Source priority names, attribute by attribute, which system wins when two values disagree.

Ranking whole systems feels simpler, and it breaks the moment one system is authoritative for one attribute and weak for another. Your ERP may hold the best logistics data and the thinnest marketing copy, while the supplier portal may hold the reverse. A single ranking forces one of them to lose on attributes where it should win.

For each attribute, write down three things:

• the source that owns the attribute
• the fallback source when the owner has no value
• the tie-break between two values of equal rank, usually the most recent update

Start with the attributes your agent writes most often. A priority list for twenty attributes that carry real consequences serves you better than a list of two hundred that nobody reviews.

The Tolerance Before a Difference Counts as a Conflict

Tolerance is the size of difference below which the agent treats two values as the same and moves on.

Weights of 380 and 384 grams disagree on paper without needing a person, while 380 and 4,560 deserve attention before anything reaches a retailer. The tolerance is the line between those two situations, and without it the agent has no way to tell a rounding difference from a real one.

Set tolerance for each attribute, because a one percent gap on weight and a one percent gap on a regulated specification carry different risks. Most rules settle on three bands:

• a gap small enough to resolve by source priority without comment
• a middle gap resolved by source priority and flagged in the decision log
• a gap large enough to stop the agent

Each business sets its own band edges. Text attributes need an equivalent test, such as whether two descriptions state the same specification.

The Stop Condition That Sends a Conflict to a Person

A stop condition is the circumstance in which the AI agent writes nothing and hands the conflict to a person.

McKinsey’s agentic AI playbook lists defining triggers for escalations as part of governing agents, and your conflict rule is where those triggers become specific.

MIT Sloan’s AI Decision Matrix, developed by researchers at MIT CISR, gives you a way to choose them. It rates a decision on ambiguity, meaning how clearly the data determines the answer, and on risk, meaning the cost of a wrong decision and how easily a person can reverse it.

Two disagreeing sources raise ambiguity by definition, so your task is to score the risk. A wrong shipping weight on a low-cost accessory corrects itself in the next feed. A wrong value on a compliance attribute reaches a retailer and sometimes a regulator. One of the companies in the MIT Sloan article requires a person for every pricing decision, because an inaccurate price is a constraint it will not trade away. Your rule can draw the same kind of line for the attributes where an error costs you most.

Four triggers cover most catalogs:

• any conflict above the top tolerance band
• any conflict on an attribute your business marks as always reviewed, such as price, compliance, or safety data
• any conflict of the third or fourth kind, meaning two records for one entity or one field with two meanings
• any conflict the agent cannot match to a row in the rule

A stop condition works only when a named person receives the stopped conflict. Write down who that is for each group of attributes, how quickly they must answer, and what the agent does in the meantime, which is usually to leave the last published value in place. When the person answers, the answer goes back into the rule as a new row or a changed priority, so the same conflict does not stop the agent twice.

The Decision Log for Each Resolved Conflict

The decision log records, for every conflict the AI agent resolves, which values it saw, which rule row it applied, and which value it wrote.

The same McKinsey playbook asks for traceability mechanisms from the outset, and it warns that low-quality data silently affects decisions across agents. The log is how you make that silent effect visible in your own catalog. Five fields are enough:

• the entity and the attribute
• the values and sources the agent saw
• the rule row and the version it applied
• the value it wrote, with the time
• whether a person took part

With these fields, the question “why does the retailer have this weight?” becomes a lookup and stops being an investigation. A monthly read of the log also shows you which rows fire most often and which attributes keep stopping the agent, and that tells you where your upstream data needs work.

Conflict Rules Versus Match and Merge Rules

A conflict rule differs from the match and merge rules inside a master data hub because it governs the moment an AI agent acts on records, while match and merge rules govern how the hub builds them.

Survivorship is the rule inside a master data hub that decides which value survives when records for the same entity merge into one. If you run a hub, it already settles many conflicts before an agent ever sees them, and the golden record, the single trusted version of each record, carries the survivors. The conflict rule starts from those survivorship rules and does not replace them.

Conflicts still reach the agent for three reasons:

• the agent reads a source that never passed through the hub, such as a supplier portal
• the survivorship rules cover some attributes and leave others open
• the hub holds a value that is older than the latest change in a source system

If you do not run a hub yet, the conflict rule is the first place these decisions get written down. That makes it a useful early step toward one, and the written priorities carry over when the hub arrives.

Where a Conflict Rule Lives for an AI Agent

A conflict rule lives in a versioned lookup table that the AI agent calls before it writes a value.

Pasted into a prompt, a rule reads like advice, while a table lets you test it row by row, version it, and have the data owners review it. A paragraph of instructions supports none of that. The table needs one row for each attribute, with columns for the owning source, the fallback source, the tie-break, the tolerance bands, the stop flag, the receiver, the version, and the review date.

Every log entry names the version of the table it applied. That lets you answer a retailer’s question about a value written in March with the rule as it stood in March, and it shows exactly which change to the table altered the agent’s behavior.

A One-Page Conflict Rule Template

Copy this template for each attribute group, and fill in every blank before the agent receives write access.

• Attribute and kind of conflict covered: ________
• Owning source: ________
• Fallback source: ________
• Tie-break: ________
• Band 1, resolve quietly: gap up to ________
• Band 2, resolve and flag: gap from ________ to ________
• Band 3, stop: gap above ________
• Always reviewed: yes or no
• Receiver of a stopped conflict: ________
• Response time: ________
• Value held while waiting: ________
• Rule version and review date: ________
• Signed by (data owner and business owner): ________

A Worked Example of an AI Agent Resolving One Product Weight

Say you run product data for a consumer brand that sells stainless steel water bottles through retailers, and an AI agent prepares the weekly retailer feed. Your rule for shipping weight, written with the template above, has these entries. The figures here are illustrative, and your own bands depend on your products and your retailers.

• Owning source: the ERP logistics record
• Fallback source: the supplier portal
• Tie-break: the most recent update
• Band 1: a gap up to 2%, resolved quietly
• Band 2: a gap from 2% to 10%, resolved and flagged
• Band 3: a gap above 10%, stop
• Receiver: the logistics data steward, the person who maintains that data, who answers within two working days
• Value held while waiting: the last published weight
• Rule version: 12

The agent meets three bottles in the same feed.

Bottle A. The ERP says 450 grams and the portal says 454. The gap is about 0.9%, which falls in Band 1. The ERP owns the attribute, so the agent writes 450 and logs the conflict as resolved quietly.

Bottle B. The ERP says 620 grams and the portal says 660. The gap is about 6.5%, which falls in Band 2. The ERP still wins, the agent writes 620, and the log entry carries a flag. At the weekly read, the steward sees that the supplier switched to a heavier lid ahead of your ERP and asks the buyer to refresh the ERP record.

Bottle C. The ERP says 380 grams and the portal says 4,560. The portal value is twelve times the ERP value, far past the 10% line for Band 3, and it matches the fourth kind of conflict. The agent writes nothing, keeps the last published weight, and sends the conflict to the logistics steward with both values and both sources.

The steward divides 4,560 by 380 and gets exactly 12. The portal lists the weight of a case of twelve, and the ERP lists the weight of one bottle. The steward adds a row to the rule stating that this supplier’s portal weight is a case weight, which the agent must divide by the pack quantity before it compares the two values. The table moves to version 13.

The next feed contains the same bottle. The agent applies version 13, converts the portal weight to 380 grams, finds no gap, and resolves it in Band 1 without involving anyone. The log shows when the row changed and who made the change, which is the answer you need if a retailer ever asks about the weight published in the earlier feed.

Without the rule, the agent chooses between 380 and 4,560 with nothing to guide it, and the wrong choice reaches the retailer. With the rule, the worst outcome is a short delay on one product.

Testing a Conflict Rule Before an AI Agent Uses It

Test a conflict rule by replaying conflicts your team already resolved and checking what the rule would have done.

Replay Past Conflicts Through the Rule

Gather a set of conflicts from sources you already have, such as retailer feed rejections, steward queue history, and reconciliation spreadsheets. Run each one through the rule and compare the rule’s answer with the decision your team made at the time.

Every mismatch points to a row that needs work. Some mismatches expose a priority set in the wrong order, and others expose a kind of conflict the rule did not anticipate, like the case weight in the example above.

Read the Stop Rate

Count how many of the replayed conflicts the rule would send to a person. That count is your stop rate, and both extremes carry information.

If the rule stops most conflicts, your steward becomes the bottleneck the agent exists to remove, and the bands or the upstream data need attention. If it stops almost none, check that the bands are not wide enough to hide real problems.

Sign Off the Rule

Two roles sign the rule. The domain data owner answers for the source values and confirms the priorities. The business owner of the output, such as the head of ecommerce for retailer feeds, confirms which attributes always go to a person, because that owner pays for a wrong value.

Write the date of the next review beside both signatures. A rule without signers and a review date has no one to correct it when a source changes.

Keeping a Conflict Rule Current

A conflict rule stays current through a review date on every row, a monthly read of the decision log, and a short list of events that trigger an early review.

The values in your sources keep moving, a pattern covered in depth in the post on AI-ready product data drift, and the rule has to move with them. These events call for an early review:

• a new source system joins the feed
• a new supplier portal uses different units or field meanings
• a retailer adds or changes a required attribute
• a row stops the agent repeatedly
• the stop rate shifts sharply from one month to the next

Read the log monthly at first, then quarterly once the stop rate settles. Each read should end with one of two outcomes: the rule stays as it is, or a named person changes a specific row and the version number increases.

Signs a Conflict Rule Is Not Ready

A conflict rule is not ready when it shows any of these signs:

• Priority ranks whole systems, with no attribute-level exceptions.
• Tolerance is missing, so every difference counts as a conflict or none does.
• The stop condition has no named receiver.
• The rule lives in a document or a prompt that nobody tests.
• The log records the written value and omits the values it replaced.
• Nobody signed the rule, and no review date exists.

If you recognize two or more of these, hold the agent’s write access until you fix them. In the meantime, let the agent propose values for a person to approve, which gives you the same speed on the easy conflicts and keeps a person in front of the hard ones.

Key Takeaways

• When two records disagree, an AI agent writes a value, so a rule has to make the choice before the agent runs.
• A conflict rule combines source priority for each attribute, a tolerance, a stop condition, and a decision log.
• Source priority works attribute by attribute, because most systems own some attributes and lack authority over the rest.
• A stop condition needs a named receiver and a held value, and the receiver’s answer returns to the rule as a new row.
• The rule belongs in a versioned lookup, and replaying past conflicts through it shows the stop rate before go-live.
• A data owner and a business owner sign the rule, and a review date on every row keeps it accurate.

A business leader asks the data team for a model that sets the right price for a product. The team builds a model that finds the price that sells the most items, delivers it on schedule, and confirms that it performs exactly as designed. The leader wants the price that earns the greatest profit margin, so the model answers a question that nobody needed answered.

That example comes from RAND’s study of failed AI projects, which draws on interviews with experienced data scientists and engineers, and it shows the pattern at its simplest. The request means one thing to the person who makes it and another to the person who builds it, and nobody finds out until the work is finished. A short written scope, agreed in one working session before any data work begins, closes that gap. It also produces the list of data requirements that every later decision depends on.

In Brief

• A written AI scope is a one-page statement, agreed by the business owner and the technical lead, that fixes what the model decides, who uses its output, and how success is measured.
• RAND’s research ranks miscommunication about a project’s purpose above every other cause of AI project failure.
• The scope has six parts: the decision, the use of the output, the cost of a wrong answer, the success metric, whether AI is needed at all, and the time commitment.
• The scoping session follows a set order and ends with a signed one-page scope, which the team reviews whenever priorities or data change.
• Each part implies data requirements, and the team assesses the data against those requirements.
• A scope is ready when the business owner and the technical lead, asked separately, describe the same model.

Why AI Scoping Comes Before Data Work

Data work is the most visible and most expensive part of an AI initiative, which is where teams naturally start. Cleaning, integrating, and labeling data all feel like progress, and all of them pay off only if the model they feed answers the right question.

RAND interviewed 65 experienced data scientists and engineers about why AI projects fail, and its authors conclude that misunderstandings and miscommunications about the intent and purpose of a project cause more AI projects to fail than any other factor. The study’s recommendation for business leaders is specific. They need to help technical staff understand what the project must achieve and how the finished product will be used, because they cannot assume the engineering team will discover on its own which design choices make the product useful in its business context.

A scope is the written form of that explanation. It is a statement of the problem the model solves, short enough to fit on one page and specific enough that two people reading it separately would describe the same model. Without one, teams spend a data budget against a problem nobody has defined, which is the precondition failure that sits upstream of every data readiness decision.

Who Needs to Attend an AI Scoping Session

A scope written by one person is a guess. The session works because four perspectives meet in the same room, and each one holds information that the others lack.

• The business owner is accountable for the result and can say what the business actually needs from the model.
• The technical lead is the data scientist or machine learning engineer who will build the model, translates the request into what can be built, and flags what cannot.
• The person who acts on the output is the dispatcher, analyst, or agent whose daily work changes when the model gives an answer, and who knows how the output would really be used.
• The data owner knows where the relevant data lives and who maintains it, and can say early whether the data exists at all.

RAND notes that leaders can do without deep technical knowledge of AI themselves as long as they employ staff with a strong data science background when selecting objectives for AI product teams. That is why the technical lead sits in the room while the objective is still being shaped.

The aim is a single working session. When the group cannot agree on the decision or the metric during the session, that disagreement is the most useful finding it produces, because it would otherwise surface much later and at a much higher cost.

The Six Parts of a Written AI Scope

A written scope has six parts. Each part has an answer of a few sentences in plain business language, and a part that nobody can answer marks the work that remains before data work should begin.

The Decision the Model Informs

The first part names the specific decision that changes because the model exists. A usable statement sounds like “release a shipment as planned or hold it for document review”, and an unusable one sounds like “improve logistics performance”. The decision needs a moment when it is made and a person who makes it, because a model without a named decision has no job to do.

The opening pricing example shows why this part comes first. A request for “a model that sets the price” hides a choice between maximizing volume and maximizing margin, and naming the decision forces that choice into the open before anyone builds anything.

How the Output Gets Used

The second part describes where the model’s output appears, who sees it, what they do differently because of it, and what happens when they ignore it. RAND places this on the business leader, who needs to explain how the completed product will be used and cannot assume the engineering team will work it out.

This part also states the value pathway, which is the route by which the output turns into higher revenue or lower expense. A May 2026 MIT Sloan article on research from its Center for Information Systems Research names launching projects without clear value pathways as one of five common mistakes in AI initiatives. A model whose output reaches nobody who can act on it has no pathway, however accurate it is.

The Cost of a Wrong Answer

Every model gives wrong answers some of the time, because AI algorithms are inherently probabilistic. RAND’s interviewees point to the inflated expectations that senior leaders hold about what AI can achieve, often driven by hype, as a recurring cause of failure. The third part states what a wrong answer costs in each direction. A model can say yes when the answer is no, or no when the answer is yes, and the two errors rarely cost the same.

Writing both costs down in business terms decides how the model is tuned and which success metric fits. It also gives the person who acts on the output an honest picture of how often the model is expected to be wrong, which protects trust in the model on the first day it makes a visible mistake.

The Success Metric in Business and Model Terms

The fourth part defines success twice, once in the language of the business and once in the language of the model. RAND describes failed projects in which business leadership did not realize that the metrics measuring the success of the AI model did not represent the metrics of success for its intended purpose, and the opening pricing example is the plain case, where items sold stands in for profit margin.

The business owner writes the first definition, such as fewer shipments held up at the border each month. The technical lead writes the second, naming the model measurement that approximates it, and states the conditions under which the two diverge. Both people sign both lines, so a good model score is never reported as business success without the link between the two being visible.

Whether the Problem Needs AI at All

The fifth part tests whether a simpler tool already answers the decision. RAND reports interviewees who received instructions to apply AI to datasets with a handful of dominant patterns that a few if-then rules could have captured quickly.

If a rule or a standing report answers the decision acceptably, the team builds the rule and stops there. If the rule answers it only partly, the rule becomes the baseline that any model must beat to justify its cost, and for problems whose data is still being captured it can serve as the first stage of a staged build, an approach in which a rule runs first and a trained model replaces it as the data accumulates.

The Time Commitment for an AI Problem

The sixth part states how long the organization commits to the problem and who funds it for that period. RAND reports that leaders underestimate the time and cost of acquiring, cleaning, and exploring data, and that shifting priorities lead to projects being abandoned before they can show results. Its recommendation is that leaders be prepared to commit each product team to a specific problem for at least a year, and that a problem unworthy of that commitment is probably not worth pursuing at all.

A problem whose data has not been captured yet takes longer to reach a trained model, and the written commitment is what keeps that effort from being cut short when priorities shift.

How to Run an AI Scoping Session

A scoping session has three stages, and the preparation and the sign-off matter as much as the meeting itself.

What to Prepare Before the Session

Preparation is what makes one working session enough.

• Send the original request, in the words it was first made, to all four attendees.
• Ask each attendee to write down, separately, the decision the model should change and how they expect its output to be used. The differences between those answers become the agenda.
• Ask the data owner to list the systems that might hold the data the decision depends on, without judging its quality.

The Order to Work Through the Six Parts

The parts build on each other, so the order matters.

1. The decision comes first, because every other part depends on it.
2. The use of the output comes second, because it shows whether the decision can actually change.
3. The cost of a wrong answer comes third, because it sets what the success metric must protect.
4. The success metric comes fourth, because it can only be chosen sensibly once the cost is in view.
5. Whether AI is needed comes fifth, because it can only be judged once the decision, the use, and the metric are clear.
6. The time commitment comes last, because it depends on everything above, including how much data the problem needs.

After each part, the technical lead restates the answer in their own words and the business owner confirms or corrects it. A misunderstanding corrected in the room costs little, and the same misunderstanding found during the build costs far more. When the two versions of an answer differ, the group records both and resolves the difference before moving on, with the business owner holding the final word on what the business needs and the technical lead holding the final word on what can be built.

Signing Off the Scope

One attendee writes up the scope on the template below soon after the session, and the business owner and the technical lead each confirm it in writing. The signed scope then lives where the build team works, and it becomes the reference for every later question about what the model is for.

A One-Page AI Scope Template

The template holds the six parts, the data requirements that follow from them, and the sign-off.

• Decision. The decision that changes, who makes it, and when.
• Use of the output. Where the output appears, who sees it, what they do differently, and what happens if they ignore it.
• Cost of a wrong answer. The cost if the model says yes and is wrong, the cost if it says no and is wrong, and which one is worse.
• Success metric. The business definition, the model measurement that approximates it, and the conditions under which the two diverge.
• Simple alternative. The rule or report tried or ruled out, and the baseline the model must beat.
• Time commitment. How long the organization commits, who funds it, and the dates when the scope is reviewed.
• Data requirements. The inputs, the outcome records, the delivery needs, the quality priorities, and the history required.
• Sign-off. The business owner, the technical lead, and the date.

Turning an AI Scope Into Data Requirements

Once the six parts are written, each one implies something about the data. Working through them in order produces the list of requirements that a data team can act on.

1. The decision defines the inputs. The model can only use facts that are available at the moment the decision is made, so the scope lists what the decision maker could know at that point.
2. The success metric defines the outcome records. Measuring success requires a record of what actually happened after each decision, such as whether a shipment was delayed.
3. The use of the output defines freshness and delivery. It sets how quickly the output must reach the person and how current the inputs must be for the output to be useful.
4. The cost of a wrong answer defines where data quality matters most. Errors in the fields that drive the costliest mistakes matter more than errors elsewhere.
5. The time commitment defines how much history is available. It also shows how much must still be collected.

The team assesses the data against that list. The case for assessing readiness against a specific initiative depends on someone having stated what the initiative needs, and the scope is the document that states it. The assessment itself starts with the six-question diagnostic that separates data quality from data availability. A quality finding leads to scoping a data quality fix to the use case, and an availability finding leads to a staged build around new data capture.

A Worked Example of Scoping a Customs Delay Model

A logistics company that appears in the quality versus availability diagnostic and in the staged build example shows the whole sequence. Its operations leadership wants AI that forecasts which shipments will face customs delays before they are dispatched, and the first request in the room is “a model that predicts customs delays”. The scoping session turns that request into six answers.

1. The decision. Whether the customs desk releases a shipment as planned or holds it for extra document review before it leaves. The customs desk makes the decision at dispatch.
2. The use of the output. The model’s score appears next to each shipment in the dispatch queue, and the customs desk reviews flagged shipments before they go out. The dispatch coordinator points out that a flag with no reason attached will be ignored, so the scope requires each flag to show the shipment attribute that drove it.
3. The cost of a wrong answer. A missed delay leaves a shipment stuck at the border with a customer waiting. A false flag sends a shipment to extra review, which costs desk time and can delay a shipment that would have cleared. The group decides that missed delays hurt more, so the team tunes the model to flag generously, with desk capacity as the limit.
4. The success metric. The business owner defines success as fewer shipments held up at customs each month among those dispatched. The technical lead names the model measurement, how well flagged shipments match the delayed ones, and records that it approximates the business outcome only while the desk has the capacity to review every flag.
5. Whether AI is needed. A rule that flags routes with a history of delays exists today. The group agrees that this rule is the baseline the model must beat.
6. The time commitment. The group commits to the problem for at least a year, because the model needs examples of delayed shipments to learn from, and those examples accumulate at the pace shipments are delayed.

Applying the requirements list to this scope gives the data team five requirements.

• Inputs before dispatch. Route, shipment volumes, and the customs documentation that accompanies each shipment.
• Outcome records. Whether each shipment was delayed at customs.
• Delivery. A score and a reason visible in the dispatch queue before the shipment leaves.
• Quality priorities. The customs documentation field and the delay outcome matter most, because a wrong or missing value in either one corrupts the examples the model learns from.
• History. Enough delayed-shipment examples to train and evaluate a model, collected over the committed period.

Running the diagnostic against these requirements gives a clear result. The company holds years of clean data on volumes, routes, and delivery times, and it holds no record of customs documentation, because that information was never required before. The data does not exist, which makes this an availability-bottlenecked problem and points to a staged build around new data capture.

The scope does two jobs at once. It stops the team from building a general delay predictor that nobody at dispatch would use, and it exposes the data gap before anyone spends money on cleaning data that was never the constraint.

Keeping an AI Scope Current

A scope that the team writes once and files loses its value, because the problem, the priorities, and the data all change after the session, so four events call for a review.

• Each gate in a staged build. A gate is the checkpoint where the team decides whether to move to the next stage, and the team rereads the scope at each one to confirm that the decision, the use of the output, and the success metric still hold.
• A shift in priorities. RAND reports that rapidly shifting priorities lead to projects being discarded before they can show results, and to finished projects being ignored because they no longer address what leadership considers most important. A written scope makes the shift visible, because the business owner must either update the scope and the commitment or end the project on purpose.
• A change in what the data allows. A missing field or an unreliable source discovered during the build is a reason to revise the scope, and a scope revised in the open keeps both sides describing the same model.
• A sponsor who is hard to reach. RAND describes failed projects in which business leadership does not make itself available to discuss whether the technical team’s choices match its intent, and it advises technical teams to keep business stakeholders informed of progress and interim discoveries. The scope names the business owner as the person who answers, and its review dates are calendar commitments for that person.

Signs an AI Scope Is Not Ready

Any one of the following means the session is not finished, and data spending should wait.

• The business owner and the technical lead describe the decision differently when asked separately.
• The success metric exists only as a model measurement, with no business outcome attached to it.
• Nobody who acts on the output has been consulted.
• Nobody can say what a wrong answer costs in either direction.
• A simple rule has been neither tried nor ruled out.
• The project exists because a technology is available, and the team searches for a problem to fit it.
• The commitment ends before the data collection does.

The simplest final check is to ask the business owner and the technical lead to describe the model independently, in writing. Matching descriptions mean the scope is ready, and differences mark exactly where the next conversation should happen.

Key Takeaways

• Hold the scoping session before any data cleaning, integration, or labeling budget is committed.
• Put the business owner, the technical lead, the person who acts on the output, and the data owner in the same room.
• Prepare in writing, work through the six parts in order, and sign off a one-page scope.
• Build the simple rule first when one answers the decision, and make the model beat it.
• Derive the data requirements from the scope, then run the quality versus availability diagnostic against them.
• Review the scope at every gate and whenever priorities or data change.

If the data your AI initiative depends on has never been captured, how do you move the initiative forward? One answer is to wait until the data exists, which stalls the initiative for as long as that takes. The other is to build against a hand-prepared sample in place of the missing data, which produces a model that looks fine in testing and struggles on live records.

A staged build is a third option, and it works in three steps:

1. Start capturing the missing data now.
2. Launch a simple rules-based version using the data the organization already has. It follows fixed rules, such as flagging any route that has had delays before, so it does not need the new data.
3. Launch an AI model trained on the new data once enough of it has been collected, then widen what the model covers as more data arrives.

The team agrees in advance what counts as enough, as a set of conditions that together form a gate.

Staging is worthwhile because this kind of data cannot be collected faster than the business produces it. A supplier’s lead-time history, a season of returns, or a quarter of customs outcomes each grows one record at a time, and no budget speeds that up.

This is why capture should start as early as possible: every day capture waits is a day of history the model never gets to learn from.

In Brief

• Staging applies when the needed data is not being captured today. Data that existed once and has since disappeared is a recovery job.
• The length of the wait depends on how often the outcome you want to predict occurs.
• Capture starts with a one-page specification that lists each field, its source, its trigger, its format, and a coverage target.
• Staging fits predictive use cases that learn from history. A generative use case needs the gap captured and does not need a history of outcomes.

---

---

Why Data You Are Not Yet Capturing Takes Time to Accumulate

Once capture is running, the data grows at a pace with two inputs. The first is how often the relevant events happen: shipments cleared, returns processed, deliveries received. The second is the share of those events the capture actually records. For illustration, a business that clears a thousand shipments a month with capture covering half of them gains five hundred usable records a month, and coverage is the input the team can raise.

Google’s own engineering guidance on machine learning advises starting early for this reason: track as much as possible in the current system before the machine learning system is formalized, since historical data on anything that might matter later is better collected now.

That makes the missing data a quantity that grows at a rate the team can estimate, and a quantity can be planned around in a way a yes-or-no condition cannot.

When Staging an AI Build Is the Right Approach

That growing-quantity view applies to one specific kind of gap: the data the use case needs is not recorded anywhere today, usually because nobody needed it until the AI initiative came along.

Data that exists but conflicts across systems is a quality problem with its own fix, and data that existed once and has since disappeared is a recovery job. Six diagnostic questions tell these cases apart, and a “never tracked” answer is what points here.

Staging fits predictive use cases, where a model learns from history to forecast a delay or score a risk, because that history has to accumulate. A generative use that reads attributes at the moment it answers needs the missing information captured for the records it reads. It does not need a history of past outcomes to learn from.

Take a logistics company that wants a model to predict which shipments will face customs delays. It holds years of clean data on volumes, routes, and delivery times, and it has never recorded which customs documentation goes with which shipment.

Working Out How Much Data the Use Case Needs

For that company, and for any use case in this position, the first task is defining what enough data looks like, since every later decision depends on it: what to record, when a stage is ready, and what to tell the business.

Which Attributes the Model Needs

Start from the decision the model will make and list what a person making that decision by hand would look at. Each item that is not already recorded becomes an attribute to capture.

In the logistics example, the model needs to know which documents accompany a shipment and when they were submitted. Suppose the outcome it predicts, whether a shipment faced a customs delay, can be read from delivery records the company already holds. That leaves the documentation as the missing piece.

How Much History the Use Case Needs

History length depends on how much the pattern changes across the year. If shipments behave differently in a peak season, a model trained only on quiet months has never seen the pattern it will be asked to handle, so the plan has to include a stretch of history that covers it. Ask the business which cycles matter for this use case, and treat the answer as a minimum.

How Many Examples of the Rarest Outcome You Need

What limits the model is the count of the outcome you want to predict. Each record whose outcome is known, such as a shipment marked delayed or on time, is a labeled example, and most records show the normal case. Only the rare outcomes show the model what it needs to learn.

MIT Sloan Management Review describes the same limit in its discussion of scarce data: when an outcome is uncommon, such as a rare cardiac event or defects from a factory that has produced few of them, labeled examples are few and cannot be increased on demand.

Your data science team can estimate how many examples of the rarest outcome the model needs. Divide that estimate by the number of usable examples of that outcome you expect to capture each month, and the result is a first read of how many months the wait runs, which you revise as real capture rates come in.

What Can Shorten the Wait and What Cannot

Data-efficient techniques, such as starting from a pretrained model (one already trained on a large body of similar data), can reduce how many labeled examples a model needs. The MIT Sloan Management Review article describes cases where a fraction of the usual number is enough. These techniques address a shortage of labels.

A field the organization never recorded is a missing input, and no technique supplies an input nobody wrote down. The article does not discuss inputs that were never recorded, so this limit is our own reading. It has a planning consequence: a pretrained model may shorten how long the outcomes take to accumulate, and capture still has to start on the same day.

Start Data Capture Before the AI Build Starts

Capture goes first because it sets the schedule, and a simple capture that starts now gives the eventual model more history than a thorough one that starts a quarter later. The team’s first deliverable is a capture specification, one page that says what gets recorded and how you will know it is working:

• Field: each attribute the use case needs, taken from the attribute list above.
• Source: the system, or the person at the moment of the work, where the value is first known.
• Trigger: the event that causes the record to be written.
• Format: a controlled set of values, so records can be compared months later.
• Coverage target: the share of relevant events that must carry the field before it counts as usable.

Two design choices decide whether the captured data is usable:

• Record the cases that seem easy to skip. Google’s guide describes logging only what a user saw, which leaves no examples of what was not seen. The same trap applies when documentation is recorded for delayed shipments and skipped for the ones that cleared.
• Record at the point of the work. A value entered from memory a week later can carry errors the model then learns from.

Coverage needs watching once capture is running, since it can fall without any alarm. Google’s guide notes that a feature populated in most examples can drop sharply after an implementation change and go unnoticed, so a coverage figure reported on a set schedule belongs on the same page as the specification.

Staging an AI Build From a Rules-Based Version to a Trained Model

With capture running, the build itself proceeds in three stages. Capture and the build run at the same time, as our data readiness and AI sequencing guide recommends, and the release is staged, so the model at full scope goes live last.

A Rules-Based or Human-Assisted First Version

The first stage is a rules-based or human-assisted version that uses only the data the organization already holds. In the logistics example, a simple rule flags shipments on routes with prior delays, and a person reviews each flag before anything happens. Google’s guide is direct that machine learning requires data, and that a simple rule, or even human editing, can get a product out the door until that data exists.

This stage earns its place in three ways:

• It gives the business something usable early.
• It sets the baseline every later model has to beat.
• Each reviewed flag, together with what happens to that shipment afterward, adds a labeled example the model will later learn from.

The value of this stage depends on the review being genuine, since checkpoints that handle more items than a person can examine become a formality.

A Simple Model Sized to the Data

The second stage introduces a trained model once the gate in the next section is met. Google’s guidance recommends a simple first model and a solid pipeline around it, and it links the complexity a model can support to how much data is available. A few carefully chosen attributes on a modest dataset are a sound start, and the rules-based version keeps running as the fallback and the baseline.

Wider Scope Once Coverage Holds

The third stage widens the scope as coverage holds: more attributes, more routes or product lines, and more automation of the decisions a person reviewed.

Where the model makes its errors, capture more examples from those areas first. The MIT Sloan Management Review article recommends this targeted approach, since errors tend to cluster in particular regions of the data. If the errors point to an attribute the model lacks, that attribute joins the capture specification, and each widening has to pass a gate again.

The Gates That Decide When to Move to the Next Stage

A gate is three conditions that must all hold. The same three apply before the trained model goes live and again before each widening.

Coverage, Volume, and a Test on Newer Records

• Coverage: the capture specification’s target is met, and the figure has held there for a stretch you agree in advance.
• Volume: the count of the rarest outcome reaches the estimate from the earlier section, revised with real capture rates.
• A test on newer records: a model trained on records up to a chosen date is tested on records captured after it, and it has to beat the rules-based baseline on those newer records. Google’s guide recommends testing this way because it better reflects what happens in production. Testing only on hand-prepared samples can make a model look fine and then fail on live records.

What to Commit to on the Timeline

When the business asks for a date, the answer has two parts:

• Dates for what you control: the day capture starts and the day the rules-based first version goes live.
• Gates, with a forecast range, for what the data controls: build the range from the estimate of examples needed divided by the usable examples captured each month, and revise it monthly against actual capture.

Leadership gets firm dates for the parts within your control and a forecast that sharpens each month for the rest.

What Happens If a Gate Is Not Met

Sometimes a gate stays closed longer than the forecast. Three responses are available, and the right one depends on why:

• Stay at the current stage. The rules-based version keeps delivering as the data builds, and nothing has to be withdrawn.
• Widen the capture. If coverage is the problem, add sources or events to the specification. If volume is the problem, look for more places the outcome is recorded.
• Narrow the use case. Scope the model to the routes or segments where the data is already sufficient.

Occasionally the outcome is too rare for a trained model to reach the volume it needs in any useful time. In that case the rules-based version may be the finished product, and Google’s guide says a team should choose the simple rule when it does better than the model on the metrics that matter.

A Worked Example of Staging a Customs Delay Model

Take the logistics company from earlier. The sequence starts with a definition of how much data is enough. The model needs the documents that accompany each shipment and when they were submitted, and suppose the delay outcome can be read from existing delivery records.

In this example customs delays are the uncommon case, so the count of delayed shipments sets the pace. The data science team estimates how many delayed shipments the model needs and divides by the number of usable delayed-shipment examples expected each month, which gives a forecast range for the second stage.

The capture specification then reads:

• Field: the customs documentation that accompanies each shipment.
• Source: the customs filing step.
• Trigger: submission of the filing.
• Format: a controlled list of document types.
• Coverage target: the share of shipments that must carry the field, set with the business.

It records documentation for shipments that clear without delay as well as for the delayed ones. The build then proceeds in three stages:

1. Stage one goes live once capture is running. A rule flags shipments on routes with prior delays, using data the company already holds, and a reviewer examines each flag. The business gets usable flags, and each reviewed flag adds a labeled example once the shipment’s outcome is known.
2. Stage two opens when coverage holds at target, the count of delayed shipments reaches the estimate, and a model trained on shipments up to a chosen date beats the rule on shipments after it. A simple model then goes live for a limited set of routes, with the rule running beside it.
3. Stage three adds more routes and attributes, with the same gate at each step, and the model’s errors show where capture focuses next.

The message to leadership has three parts:

• Capture starts on one date.
• The rules-based version goes live on another date.
• Each later stage opens when its gate does, with a forecast that sharpens each month.

If delayed shipments turn out to be too rare for the second stage to open in a useful time, the rule stays in place and the company has a working process with a growing dataset behind it. That position is stronger than a model launched early on hand-prepared samples.

When the Foundation Has to Come First

Staging suits a narrow gap, one field from one source, like the customs documentation above. A gap that needs data integrated across many systems is a different project, and the foundation comes first. McKinsey’s article on scaling AI in manufacturing describes a pharmaceutical site that first built three integrated data platforms connecting about a dozen IT systems and more than 150 sensors, and then built applications on that base.

Three signals suggest the foundation has to come first. These reflect practitioner judgment, and no published threshold backs them:

• Capturing the field means integrating several source systems.
• Several use cases depend on the same missing data, which makes it a platform need.
• The new records have no shared identifier that connects them to the records the organization already holds.

If none of these apply, the staged approach fits, and the first step is the capture specification.

Key Takeaways

• The trained model goes live when its gate is met: capture coverage at target, enough examples of the rarest outcome, and a win over the baseline on newer records.
• A rules-based first version delivers early value, sets the baseline, and produces the labeled examples a model later learns from.
• Testing on records captured after the training window catches what hand-prepared samples hide.
• Commit dates to what you control, such as the capture start and the first release, and commit gates with a forecast to what the data controls.
• A pretrained model may shorten the wait for outcomes, and capture still has to start on the same day.
• When the missing data requires integrating many systems, the foundation comes first.

Somewhere in the process of figuring out why an AI initiative is producing unreliable results, sometimes the problem narrows down to one specific type: the data it depends on exists, it is simply not accurate or consistent enough to trust yet, distinct from the other common cause, where the data needed was never captured in the first place. That distinction tells you what kind of problem you are dealing with, but it does not yet tell you which of your records actually need correcting, how far that correction has to go, or when the work is genuinely finished, and that gap is exactly where a fast, contained fix quietly turns into something much bigger than anyone planned or funded.

In Brief

• A confirmed quality-bottleneck diagnosis names the problem. It does not scope the fix, and that is a separate decision most teams skip.
• Gartner’s own guidance states directly that data quality efforts should never target everywhere at once, scope gets set by which specific use case actually needs it.
• How widely a piece of data is shared across the organization, not just how broken it is, determines how large the fix should be.
• This piece covers scoping the fix for one diagnosed AI use case specifically. A separate, larger question, building lasting organization-wide data quality, is covered elsewhere.

Why “Just Fix the Data” Is Not a Real Plan

That gap does not close itself, and it is not for lack of trying. Data and analytics leaders often reach for two familiar responses, starting with whichever records happen to look worst, or deciding the fix should touch every system that could conceivably feed the AI initiative, just to be safe. Neither response is wrong exactly, they are both just guesses standing in for a scope that was never actually set.

Gartner’s own guidance on data quality is direct about this: setting a program’s scope too wide taxes resources without producing business benefit, since not all data carries equal importance to your use case. Scoping determines whether your fix stays fast or becomes its own multi-quarter initiative, not something to settle informally before the real work starts.

Where This Fix Fits

Before scoping can start, it helps to be clear about where the diagnosis itself came from, since that shapes how much of this piece applies directly. Whether the distinction between data that exists but cannot be trusted and data that was never captured came from a structured set of diagnostic questions built for exactly this purpose, or from a different assessment entirely, a gut read, a retailer rejection that made the pattern obvious, the starting point from here is the same: a confirmed quality bottleneck, and a second question most teams skip, which of the records actually need attention, and which ones are simply sitting nearby the problem without being part of it. That second question is what this piece answers.

Why Fixing Everything Is the Wrong Default

The instinct to widen your fix comes from a reasonable place. If the customer records feeding your AI initiative are inconsistent, you can probably find that same inconsistency somewhere else in your organization too, so why not fix it everywhere while you are already looking.

That instinct produces a specific, predictable outcome: the fix stops being fundable as a fast, contained project and starts requiring the budget, timeline, and cross-functional buy-in a genuine organization-wide data quality initiative needs, the sustained, multi-year kind that changes how records get created in the first place, not just how the existing ones get corrected. Those are not the same project, and treating them as one guarantees your fast fix never actually finishes fast.

If your real goal is building lasting, organization-wide product data quality, system enforcement paired with genuine cultural ownership across every team touching the data is a real and worthwhile undertaking, and it deserves its own dedicated plan rather than becoming an accidental side effect of fixing one AI initiative’s data.

Mapping the Fix by Value and Risk

Once you decide to stay bounded to your use case, your next question is which records, inside that use case, actually need attention first, since even a scoped fix usually touches more data than you have time to fix all at once.

Gartner’s guidance gives you a direct way to sort this: map the data your use case touches along two dimensions, the value you get from getting it right, and the risk you take on from getting it wrong. A field that barely affects your model’s output but would cause real damage if wrong deserves your attention before a field that affects the output constantly but carries little consequence either way.

Applied to your quality-bottlenecked AI use case specifically, this looks like asking, for each data element your model actually consumes, what happens if this value is wrong when the model uses it. A wrong customer name might produce an awkward but harmless output. A wrong price or a wrong compliance attribute might produce a costly or even a legally risky one. Those two fields do not deserve equal priority from you, even if both currently show the same inconsistency rate.

How Widely Shared Is the Data You Are Fixing

Value and risk tell you what to prioritize, while a second question, how widely the data is actually shared, tells you how large the fix itself needs to be, a distinction Gartner draws between three categories.

Centralized Data

Shared master records used across many teams and systems fall into this category, and they hand you an inherently larger fix. Correcting centralized data well means coordinating with everyone else who also depends on that data being right, since a change made without their knowledge can break something downstream that has nothing to do with your AI initiative. This is the category that most often turns a fast fix into a slower one, not because the correction itself is harder, but because the coordination is.

Regional Data

Data shared within one business unit sits in the middle. The fix is smaller and more contained than centralized data requires, and it is usually one you can lead yourself if you already own that team’s data, without needing sign-off from stakeholders outside your immediate group.

Local Data

Data used by a single process or a single team is the smallest and fastest category to fix. One person can usually own the correction from start to finish, since nothing outside that one process depends on the data staying a particular way while the fix is underway.

If your quality-bottlenecked use case turns out to depend on centralized master data, you are looking at a genuinely bigger undertaking than one depending on a single team’s local records, even if the inconsistency itself looks identical on paper. Knowing which category you are in before you start is what keeps your estimate honest.

What the Fix Actually Involves Day to Day

With priority and scale set, the actual work in front of you is more concrete than it sounds standing outside it. Gartner’s own methodology names two practical steps worth borrowing directly: profiling and dimension selection.

Column-Based Profiling

This gives you a statistical read on the data as it currently stands, patterns of missing values, formatting inconsistencies, and outliers across a given field. It tells you what the data looks like, without necessarily telling you whether it is correct against any specific business rule.

Rule-Based Profiling

This checks your records against the specific business logic your use case actually depends on, rather than against general statistical patterns. It is usually the more useful of the two for a scoped fix, since it tests the exact thing your AI initiative needs to be true, not just whether the data looks internally consistent.

Dimension selection means resisting the urge to fix every possible kind of data problem you find. Out of the nine recognized data quality dimensions, accuracy, completeness, consistency, and the rest, your use case genuinely only needs two or three addressed to get unblocked. If your use case is bottlenecked by conflicting customer names, you need consistency and accuracy fixed. You do not need a full audit of timeliness or precision unless those are also demonstrably part of what is breaking your model’s output.

Scoping One Fix, Start to Finish

Take the retailer whose return-prediction model was struggling because customer records disagreed across three systems and product listings carried duplicate SKUs with conflicting prices. The diagnosis already confirmed this as quality-bottlenecked. Scoping it starts with the value-and-risk question: a wrong customer name is awkward but low-stakes, while a wrong price feeding into a return-prediction model risks the model justifying refunds based on figures that were never accurate to begin with. The price and SKU inconsistencies get priority. The customer-name variants can wait.

Next comes the data-expanse question. Product pricing at this retailer lives in a system shared across the catalog, e-commerce, and returns teams, centralized data, not something one team can correct alone. That single fact changes the shape of the fix: this is not a task one person finishes in an afternoon, it needs sign-off from whoever else depends on that pricing data staying stable while it gets corrected.

That leaves two dimensions worth actually working on, accuracy and consistency, not all nine. The scope, once written down, reads as something concrete: correct pricing and SKU records for the specific product lines feeding the returns model, coordinated with the catalog and e-commerce teams that also touch that data, timeline measured in weeks. Customer-name formatting stays out of scope entirely, it does not affect the model this fix exists to support.

That is what a properly scoped fix looks like once the frameworks have actually been applied to something real, rather than staying at the level of principle.

How to Know the Fix Is Actually Bounded, Not Creeping

Prioritizing by value and risk, sizing the fix by how widely the data is shared, and narrowing the work to two or three dimensions all point toward the same outcome, a fix that stays fast because it stayed small. Holding that shape once work is underway is its own separate discipline, since scope drift is quiet, it rarely announces itself as a decision, and instead shows up as a series of small, reasonable-sounding additions that each make sense on their own and add up to a different project than the one you started.

The Use Case Still Has a Name

You can still name the specific use case the fix serves, without needing to reference other initiatives to justify the work. The moment the justification shifts from “this fix supports X” to “this fix supports X and also helps with Y and Z,” the scope has already started moving.

The Records Match the Mapping

The records you are correcting are the ones your value-and-risk mapping actually flagged, not every record that happens to look messy to you along the way. Fixing an unrelated inconsistency just because it is visible while you are already in the data is scope creep, even when it feels efficient in the moment.

The Owners Have Not Multiplied

The people involved are still the ones who owned this data to begin with, not a growing list of stakeholders you are pulling in because the fix started touching their systems too. A widening circle of people needing to sign off is one of the clearest early signs that a bounded fix has stopped being bounded.

The moment any of those three starts slipping for you, your fix has stopped being the bounded project this piece describes and has started becoming the larger, organization-wide undertaking that deserves its own separate plan, its own budget, and its own timeline.

Key Takeaways

• Setting a data quality effort’s scope too wide taxes resources without producing business benefit, a principle Gartner states directly in its own guidance.
• Mapping your affected data by value and risk determines what actually needs fixing first, not every inconsistent field carries equal priority.
• Whether your data is centralized, regional, or local to one team changes how large the fix needs to be and who needs to be involved.
• A bounded fix stays scoped to your diagnosed use case. A fix that starts touching unrelated systems or unrelated teams has quietly become a different, larger project.

Two organizations can have the exact same complaint, our AI initiative is not working, and be describing completely different problems. One has data that is wrong, the other has data that simply does not exist yet, and treating those as the same problem is why so many AI budgets get spent solving nothing.

The distinction matters because the fix is different in each case, and most teams never actually check which one they have before reaching for a solution. They assume, usually based on instinct or whichever problem they dealt with last time, and spend weeks or months acting on a guess.

There are six questions that get you there, and answering them honestly about your own initiative is usually enough to know which problem you are actually solving before you spend another dollar assuming.

In Brief

• A data quality problem means the data exists but cannot be trusted. A data availability problem means the data was never captured in the first place. The fix for each is different.
• Six direct questions determine which one applies to a specific AI initiative, based on what is actually happening in the organization’s own systems today.
• Quality problems and availability problems produce different symptoms in production, inconsistent outputs versus initiatives that succeed in testing and fail once they go live.
• The diagnosis takes under an hour and determines which of two entirely different next steps is the right one.

The Diagnosis Most Teams Skip Before Blaming the Model

Only 7% of organizations say their data is completely ready for AI, and 27% say it is not ready at all, a gap Harvard Business Review Analytic Services documented in a 2026 study conducted with Cloudera, surveying more than 230 data decision-makers. Seventy-three percent describe preparing data for AI as genuinely difficult.

Those numbers hide something the survey itself was not built to capture, that “not ready” describes two entirely different situations, and a team can spend a quarter cleaning up records that were never the actual problem, or spend that same quarter waiting on a data initiative when the real gap was somewhere else entirely. From the outside, these two mistakes look identical, and both come from skipping the same step, a real diagnosis before a real fix.

Two Kinds of Data Problems, Briefly

This distinction exists because most organizations skip a scoping step before either problem ever gets diagnosed, a precondition failure that plays out the same way across most AI initiatives, and the short version of the split is enough to work with here. A quality-bottlenecked problem means the data exists but cannot be trusted, duplicated records, conflicting values, inconsistent formats across systems. An availability-bottlenecked problem means the data a specific AI use case needs was never captured or structured in the first place, simply because nobody needed that information until now.

Treating these as degrees of the same problem, rather than as two separate ones, is what makes the mistake expensive, since the fix, the timeline, and the resourcing required are different for each.

The Diagnostic Questions That Separate the Two

Run your AI initiative against these six questions and answer plainly, based on what is actually happening in your systems today. Each question is designed to isolate one signal, and it is the overall pattern across all six that points toward the actual bottleneck.

Does the data your use case needs already exist somewhere in your systems today, in some form?

This question works as the starting fork, since answering yes puts you in quality territory, evaluating data that exists but needs to be trusted, and answering no shifts the entire conversation to availability territory, whether that data was ever tracked in the first place. Be precise here, “exists in some form” means a real system of record, not a spreadsheet someone built once for a different purpose.

If it exists, do different systems or records disagree with each other about the same fact?

Three systems giving three different addresses for the same customer is a clear quality signal, and not a formatting inconvenience. It means there is no single trustworthy version of that fact anywhere in the organization, and any AI model trained on it will learn whichever version appears most often, regardless of which one is actually correct.

If it exists and agrees, has anyone actually verified it is current and accurate, or is that assumed?

Systems agreeing with each other is no guarantee they are correct, since multiple systems can consistently share the same outdated or wrong value, especially when one system was the original source and the others simply copied from it years ago without anyone checking since. This question catches quality problems that consistency alone would hide.

If the data does not exist yet, is that because nobody has ever needed to track it, or because it was tracked once and lost?

If the data was simply never tracked, that is a build problem, new capture has to be designed from scratch. If it existed once and disappeared, through a deprecated system or an integration that quietly stopped working, that is closer to a recovery and quality problem, worth investigating before assuming a full rebuild is necessary.

Would fixing existing records solve your problem, or would you still be missing something afterward?

This question works as an honesty check on the earlier answers, since it is possible to describe something that sounds like quality trouble when the real gap is actually availability. If a team could clean every existing record perfectly and the use case would still lack a piece of information it needs, that missing piece is an availability problem no amount of cleanup will touch.

Could a data team start cleaning tomorrow and make real progress, or would they hit a wall where the information simply is not there to clean?

This question serves as the practical test. A quality problem is workable immediately, since there is something to correct. An availability problem hits a hard wall almost right away, because there is nothing yet to act on. A team that reports being stuck within days of starting is usually describing an availability problem, not a quality one.

A pattern of answers across questions 2, 3, and 5 pointing toward inconsistency and conflict signals a quality-bottlenecked problem. A pattern across questions 1, 4, and 6 pointing toward genuine absence rather than inconsistency signals an availability-bottlenecked problem.

What a Quality-Bottlenecked Answer Looks Like

A mid-sized retailer wants AI to flag which products are likely to be returned before they ship. The company has years of return data, along with three systems that each record customer addresses differently, a product catalog with duplicate SKUs carrying different attributes, and a returns database that has never been reconciled against the original order system.

Running the six questions: the data exists in the point-of-sale, catalog, and returns systems (yes to question one). Those systems disagree with each other constantly, the same customer, the same product, three different values depending on which system is pulled (yes to question two). Nobody has verified which version is correct in years, each system has simply been trusted on its own terms (yes to question three).

Nothing here suggests information was ever lost, the raw signal exists, it is just contradictory (this points away from question four’s concern). Cleaning and reconciling the records would plausibly resolve the inconsistency and give the model something trustworthy to learn from (yes to question five). A data team could start reconciling these systems immediately, there is real, existing work to do starting tomorrow (yes to question six).

Every signal here points toward a quality-bottlenecked problem, and the fix is a targeted reconciliation project scoped to this specific use case, smaller and faster than a new AI capability build or a company-wide governance overhaul.

What an Availability-Bottlenecked Answer Looks Like

A logistics company wants AI to predict which shipments are at risk of customs delays before they happen. The company has clean, trustworthy data on shipment volumes, routes, and delivery times going back years. It has never once recorded which customs documentation was submitted with which shipment, because until this initiative, nobody needed that information for anything.

Working through the same six questions: the specific data this use case needs, documentation submitted per shipment, does not exist anywhere in the company’s systems (no to question one). Because it does not exist, there is nothing to compare for disagreement, and nothing to verify for currency or accuracy either, since there is no record at all (questions two and three do not apply). Nobody ever needed to track this before, the field was never tracked, not lost, which confirms question four’s answer.

Cleaning the existing shipment data, however thoroughly, would not surface documentation that was never captured in the first place (no to question five). A data team assigned to this would hit a wall almost immediately, there is genuinely nothing to clean until new capture exists (this confirms question six).

The pattern here points to an availability-bottlenecked problem, and the fix is building new data capture, integrating with whatever system tracks customs documentation and connecting it to the shipment record, on the same timeline as the AI build instead of a strict sequence.

Why Each Bottleneck Produces the Symptoms It Does

A model trained on inconsistent data tends to perform well in one test and poorly in the next, because it is learning from a signal that disagrees with itself. The signal is present, just corrupted, so the model produces an answer, just not a reliable one. That inconsistency is the fingerprint of a quality-bottlenecked problem.

Availability leaves a different fingerprint. An initiative built on missing data either cannot get off the ground at all, or performs surprisingly well in testing and falls apart the moment it reaches production, because testing environments are often built on hand-prepared sample data that quietly fills a gap the real environment does not have. The model was never actually learning the missing signal, since that signal was never there to learn from.

Recognizing which fingerprint is showing up is often a faster shortcut than running all six questions from scratch, inconsistency pointing toward quality, and absence, especially absence that only becomes visible once a project reaches production, pointing toward availability.

What to Do Once You Know Which One You Have

A quality-bottlenecked diagnosis points to a specific, scoped next step, cleaning and reconciling the exact records this use case depends on, not a broad governance program that touches everything, and scoping that cleanup correctly is where most reconciliation projects actually go wrong (Cluster 2 link, pending publication).

An availability-bottlenecked diagnosis leads somewhere different entirely, building the specific new data capture this use case needs, run alongside the AI build rather than treated as something that has to finish first, and that parallel build carries its own sequencing decisions distinct from a data cleanup (Cluster 3 link, pending publication).

Either way, the diagnosis itself is the highest-leverage thirty minutes available before committing real budget to either path.

Key Takeaways

• Data quality and data availability are two distinct problems that produce the same surface complaint, “our AI initiative is not working,” and require different fixes.
• Only 7% of organizations report their data as completely ready for AI, per a 2026 Harvard Business Review Analytic Services and Cloudera study, and 27% report it as not ready at all.
• Six direct questions, answered honestly, are usually enough to determine which bottleneck actually applies to a given AI initiative.
• Quality-bottlenecked problems tend to leave inconsistent outputs. Availability-bottlenecked problems tend to succeed in testing and fail once they reach production.

Your CFO wants a straight answer to a simple-sounding question. Where does next quarter’s AI budget go, into cleaning up the data or into building the AI itself. You have maybe twenty minutes in that meeting, and the uncomfortable truth is that most people in the room have not actually agreed on what problem the AI is supposed to solve in the first place.

That gap gets papered over constantly. Someone says “fix the data first,” because it sounds responsible. Someone else says “just start building,” because leadership wants visible progress this quarter. Both answers can be defended in a slide, and both skip past the decision that actually determines whether this initiative works.

There is a real answer to which comes first, and most organizations are asking a different question entirely.

Why Data Readiness Is Not the First Question to Answer

That real question starts with an instinct almost everyone in the room already has. Ask ten data leaders whether to fix data readiness before starting an AI initiative, and most will say yes without hesitating. It is the responsible answer. It is also, in a meaningful number of cases, the wrong first move. Data readiness still matters. The problem is that jumping straight to it assumes a decision has already been made that usually has not.

RAND Corporation interviewed 65 experienced data scientists and machine learning engineers to understand why AI projects fail. Their finding cuts against the instinct in that CFO meeting. Eighty-four percent of interviewees named leadership-driven failure as the primary reason projects collapse, ahead of data quality itself. Business leaders and technical teams frequently disagree, sometimes without realizing it, about what problem the AI is actually meant to solve or how success will be measured.

That is a scoping problem, sitting upstream of the data-first-or-AI-first debate entirely. Skip it, and the sequencing decision you make next stops mattering, because you end up optimizing the wrong thing regardless of which path you pick.

What an Unscoped AI Problem Actually Looks Like

That wrong optimization has a shape to it, and it rarely announces itself. Leadership asks for a model that predicts customer churn. The technical team builds one, optimized for prediction accuracy. Three months later, leadership asks why churn has not improved, because what they actually needed was a model that identified which at-risk customers were worth the cost of retaining, a narrower and more useful target than simply predicting who was likely to leave.

Both sides did their jobs, each one correctly by their own definition. The project failed because the target metric and the business objective were never the same thing, and nobody caught the mismatch until the work was already done.

A simple test cuts through this before a single dollar gets spent on data or infrastructure. Can leadership and the technical lead each independently write down, in one sentence, what business outcome this AI initiative is meant to change. That alignment has to happen before the sequencing conversation starts.

Two Different Data Problems Once the Use Case Is Scoped

Once leadership and the technical team agree on what problem the AI is solving, the real sequencing question finally becomes answerable, and it is narrower than most people expect. It comes down to which of two situations you are actually in.

In the first, the data your use case needs already exists somewhere in the organization, but it cannot be trusted. It is inconsistent across systems, duplicated, ungoverned, or simply wrong in ways nobody has caught yet.

In the second, the data does not exist yet in usable form. The specific use case is simply new, and the organization has never needed to capture, structure, or retain that information before now.

These are two different problems, each calling for its own first move.

When Data Exists But Cannot Be Trusted

This is the quality-bottlenecked path, and it is the one most content on data readiness already addresses, for good reason. Picture a customer record that shows three different names for the same account, a product catalog with duplicate entries carrying different prices, or a sales figure that changes depending on which system you pull it from.

RAND’s interviews found this pattern repeatedly. Organizations believe they have good data because they get weekly reports, without realizing that the data behind those reports was never built to support a new purpose.

When this is the actual bottleneck, fixing the data first is the correct sequence. The reason has little to do with feeling responsible. Building AI on top of untrustworthy data produces a faster path to a model nobody trusts, and that is a more expensive failure than a delayed start.

When AI Needs Data That Does Not Exist Yet

The availability-bottlenecked path looks different, and it gets far less attention in most data readiness conversations, which is part of why organizations mishandle it. Here, the data is simply incomplete. It does not exist yet, because the use case is asking a question the organization has never needed to answer before.

Picture a manufacturer launching a new product line and wanting AI to flag supplier risk before a shipment gets delayed. The company has years of clean, trustworthy sales data. It has never once tracked supplier lead-time variability at the granularity this use case needs, because nobody needed that number before. Cleaning existing records will not surface a number that was never captured, so the only real fix is building the data collection itself.

This is a real and growing constraint, and a significant one. Stanford HAI’s 2026 AI Index flags a broader version of this same problem at industry scale, noting genuine concern among researchers that the supply of high-quality training data itself may be approaching structural limits within the next several years. Synthetic data has not proven a full substitute. If data availability is becoming a binding constraint even at the scale of the entire AI industry, it deserves equal weight to quality inside a single organization, as a different problem in its own right.

When this is the actual bottleneck, spending months on a data governance program before touching the AI initiative solves a problem you do not have. The right move is building the specific data capture and structure the use case needs, alongside building the AI capability itself, on the same timeline instead of a strict sequence.

The Real Cost of Sequencing Data Readiness and AI Wrong

Whichever path actually applies, guessing wrong in either direction carries a real cost, and it shows up differently depending on which default an organization reaches for. Organizations that default to “clean everything first” often spend on a broad governance initiative when the actual use case only needed a narrow, targeted fix, delaying value for months over a problem that was smaller than assumed.

Organizations that default to “build now, fix data later” run into the opposite cost. They discover the trust problem only after the model is in production, when a bad prediction has already reached a customer or a decision, and the fix now requires unwinding both the data and the deployed system at once.

A third pattern is just as common, and often the most expensive of all. Organizations split the budget, funding a partial data cleanup and a partial AI build at the same time, without ever diagnosing which one the use case actually needed.

Both efforts end up underfunded, and neither one finishes. The AI initiative stalls waiting on data that was never fully fixed, and the data initiative loses priority the moment the AI timeline slips, leaving the organization with the appearance of progress on two fronts and real progress on neither.

All three defaults carry real risk. Diagnosing which path actually applies costs far less than guessing wrong in any of them.

How to Know Which Path Applies to Your Organization

The scoping check comes first. Confirm that leadership and the technical team can each state the target business outcome in the same terms, and resolve any gap in that alignment before anything else.

Once scoped, the diagnostic question is direct. Does the data your use case needs already exist somewhere, just inconsistent or untrustworthy, or does it not exist yet in usable form at all. That single distinction determines whether the right next move is a data quality initiative or a parallel build.

This is the exact question a Data & AI Strategy engagement is built to answer, replacing the guesswork with a clear sequencing plan.

Key Takeaways

• RAND’s interviews with 65 experienced AI practitioners found leadership-driven misalignment was the most cited primary cause of AI project failure, named by 84% of interviewees, ahead of data quality itself.
• Confirming what problem the AI use case solves, in terms both leadership and the technical team agree on, has to happen before any sequencing decision is meaningful.
• Once scoped, sequencing splits into two distinct paths: fixing data that exists but is not trustworthy, or building toward data that does not exist yet for the specific use case.
• Stanford HAI’s 2026 AI Index confirms data availability is a serious, industry-recognized constraint carrying equal weight to quality.
• Splitting the budget between partial data cleanup and a partial AI build, without diagnosing which one the use case actually needs, is common in practice and often costs more than committing to either path deliberately.

A customer searches your online catalog for their exact make, model, and year, looking for a part they already know exists. The listing itself looks complete everywhere else, price, description, photos. The one detail that actually decides whether the search returns a result, whether it fits their specific vehicle, was never entered.

The industry has a name for this gap: an app hole. What’s less obvious is why it exists on a catalog that passed a full fitment audit only months earlier.

The audit was accurate on the day it ran. What has changed since follows a specific, traceable pattern, and tracing exactly what moved is the difference between fixing this once and watching it come back.

---

In brief

• An app hole is missing or unverified vehicle fitment data attached to a part, industry shorthand for a gap that makes a part invisible to a customer’s search
• A catalog fully mapped at launch accumulates app holes as new parts, vehicle configurations, and supplier updates move faster than anyone is tracking them
• Two separate standards govern this data, ACES for fitment, PIES for the product itself, and a part can pass one while failing the other
• Closing this gap requires an ongoing owner for the update path, not a one-time cleanup or better software alone

An app hole, in this context, refers to a gap in vehicle fitment data, a part listed for sale with no verified match to the vehicles it should fit, using the Aftermarket Catalog Exchange Standard’s own terminology for the failure.

---

What an App Hole Actually Is

What is an app hole in automotive aftermarket data? An app hole is a gap in vehicle fitment data, a part listed for sale without a verified connection to the vehicles it actually fits. The term comes directly from the industry’s own data standard, not from a vendor or a consultant coining a phrase.

Fitment itself is governed by ACES, the Aftermarket Catalog Exchange Standard, maintained by the Auto Care Association. ACES structures exactly which part matches which vehicle, by year, make, model, engine, transmission, and additional qualifiers, so that every trading partner in the industry, manufacturer, distributor, retailer, marketplace, reads fitment the same way, machine to machine, without manual interpretation on either end.

That structure depends on shared reference data, not just a shared format. Two databases carry the actual weight. The Vehicle Configuration Database, VCdb, holds the master record of every vehicle configuration recognized by the industry, year, make, model, and every meaningful sub-variant. The Parts Configuration Database, PCdb, holds the corresponding structure for parts themselves. An app hole exists specifically at the point where a part in a catalog has no corresponding entry connecting it to a vehicle configuration in the VCdb, even though that vehicle configuration exists and is correctly defined elsewhere in the standard.

How an App Hole Is Different From a Data Entry Mistake

A typo is wrong data, present but incorrect. An app hole is absent data, no fitment record exists at all for that part-to-vehicle pairing, which means there is nothing for a search engine, a marketplace algorithm, or a customer-facing filter to match against. The part disappears from the search result entirely, rather than ranking lower within it.

Why “Missing” Is the Wrong Word for It

Calling this “missing data” undersells how checkable the failure actually is. It is a specific, verifiable fact, one a customer can test in seconds by searching their own vehicle and getting no result, and one a business can test systematically by running its full catalog against the current VCdb and counting exactly how many app holes exist right now. That precision is what separates this from most abstract data quality language. There is no interpretation required to know whether the gap exists.

---

Why a Complete Catalog Doesn’t Stay Complete

A catalog that passes a fitment audit on launch day is clean for exactly one moment, that specific day, against that specific set of vehicles, suppliers, and part numbers, all of which keep changing after the audit ends.

This is the same mechanism already true of any structured catalog. Data built to be correct at one moment does not stay correct as the conditions around it shift, unless something is actively maintaining it. A closer look at AI-ready product datatraces this exact pattern in a different setting, a record accurate in January quietly going stale by June, with nothing announcing the failure. Automotive aftermarket data follows the identical pattern, just with a more concrete, more immediately visible consequence, since the VCdb and PCdb themselves are living, industry-maintained references, updated on a schedule no single catalog owner controls.

What Actually Changes Underneath a Live Catalog

Three things move constantly, independent of whether anyone updates the catalog to match. New vehicle model years release annually, sometimes with mid-year trim or configuration changes. Suppliers revise part specifications without always notifying every downstream partner. New parts get added to a catalog faster than fitment data gets verified for them. Each of these, on its own, creates one small gap. Stacked across a full catalog, they explain why app holes accumulate steadily rather than appearing all at once.

---

Where Fitment Data Breaks First

Where does fitment data actually break down first in a live catalog? It breaks at three specific, recurring points, not randomly across the catalog. New part onboarding, vehicle configuration updates, and supplier feed changes account for nearly all app holes that accumulate after a catalog’s initial audit.

The most common point of failure is a timing gap, a new part enters the catalog before its complete fitment mapping is ready, and the listing goes live anyway because waiting costs sales.

New Part Onboarding

A part gets added to the catalog to capture a sales opportunity, with fitment data planned as a fast follow. The follow-up frequently slips past its schedule, and the part stays live with an incomplete or absent fitment field. This is the single most common origin point for a new app hole, since it happens at the exact moment commercial pressure to publish is highest and data completeness pressure is lowest.

The gap is rarely permanent by intention. A merchandiser adds the part, expecting fitment data to follow from a supplier feed or a manual mapping pass within days. Without a specific owner tracking that follow-up, “within days” becomes “whenever someone notices,” and the part sits live and unsearchable in the meantime.

Vehicle Configuration Updates

A new model year or trim configuration is released, entering the VCdb as a new, valid entry. Until someone maps existing parts against that new configuration, every part that should fit it shows no match, an app hole that exists purely because the vehicle side of the equation changed, not the part itself.

This category is distinct from the other two in one important way: the part’s own fitment data has simply become incomplete relative to a vehicle that did not exist when the mapping was last done. A catalog can be internally consistent and still generate new app holes every time the industry’s own vehicle database expands, which happens on a predictable, recurring schedule tied to model year releases.

Supplier Feed Changes

A supplier updates a part specification on their end, a trim revision, a discontinued application, a corrected fitment range. If that update does not propagate into the receiving catalog automatically, the fitment data on file becomes silently inaccurate, still present, just no longer correct.

This is the hardest of the three to catch, since the record stays populated with data that was once accurate but no longer is. A search still returns a result. The result is simply wrong, which means the failure surfaces downstream, as a return, a complaint, or a mismatched shipment, rather than at the point where it actually occurred.

---

The Second Gap: When PIES Data Fails Even After ACES Passes

Can a part pass fitment validation and still fail to sell? Yes, and this is the specific failure most catalog audits never catch, because ACES and PIES are checked as two separate compliance exercises rather than one connected requirement.

A complete, accurate ACES fitment mapping does not guarantee a part is ready for sale. It can still fail the customer because the PIES side of its record, the actual product information, is incomplete.

PIES governs everything about the product itself, descriptions, attributes, pricing, packaging, digital assets, and compliance detail like hazardous material information. A part with perfect fitment data but a missing product image, an incomplete description, or an absent compliance attribute still fails to convert, or worse, gets rejected outright by a retailer’s or marketplace’s ingestion requirements.

Why This Compounding Failure Gets Missed

Most catalog audits check ACES and PIES separately, if they check both at all. A part that clears fitment validation often gets treated as done, with nobody circling back to confirm the product data side is equally complete.

The Two Standards Were Built to Work Together, Not Checked That Way

ACES and PIES describe the same part from two different angles, one answers whether it fits, the other answers what it actually is. A part record is only genuinely complete when both are true at once. Most catalog management workflows route ACES validation and PIES validation through entirely separate teams anyway, with no single checkpoint confirming both passed for the same part on the same day.

A part can look fully ready in one system and quietly unsellable in the other. The cause is structural, two disconnected checkpoints, not a lapse by either team.

---

Why This Problem Keeps Returning

A cleanup project fixes every app hole that exists on the day it runs. New app holes begin accumulating the day after, from the next part added, the next vehicle configuration released, the next supplier update that does not propagate.

Treating this as a project with an end date guarantees the same gap returns, on a predictable schedule tied to how fast the catalog and the vehicle market both keep moving.

What a Maintained Catalog Actually Requires

Closing this gap for good requires three things working together, not a single fix. A named owner accountable for fitment completeness on every new part, not just at initial catalog load. A recurring check against updated vehicle configuration data, not a one-time audit treated as permanent. A feedback path from supplier updates directly into the catalog, so a specification change on their end reaches the fitment record without depending on someone remembering to update it by hand.

---

Is Your Catalog Accumulating App Holes Right Now? A Quick Self-Assessment

Six honest questions reveal whether your catalog’s fitment data is actively maintained or quietly accumulating gaps.

Fitment and Ownership

• Does every new part launch with complete fitment data, or does fitment data get added as a follow-up step?
• Is there one person accountable for updating fitment mappings when a new vehicle configuration releases?
• Would you know today how many app holes currently exist in your live catalog?

Process and Propagation

• When a supplier updates a part specification, does that change reach your fitment data automatically?
• Do you check ACES and PIES completeness together, or are they audited separately, if at all?
• If a customer searched their exact vehicle right now, how confident are you every eligible part would actually appear?

Outcome guide: Three or more “no” answers means your catalog is very likely accumulating app holes faster than anyone is catching them, and the gap is probably larger than what shows up in your last audit.

---

What Actually Closes the Gap

Day one and day ninety are two different questions, and a clean catalog only answers the first one. The organizations that keep app holes from reaccumulating treat fitment and product data completeness as a standing operational responsibility, not a project with a finish line.

That distinction, an owned, maintained update path instead of a periodic cleanup, is the same principle behind readiness in any structured catalog, just made concrete here in a way a customer can verify with a single search.

---

Key Takeaways

• An app hole is missing or unverified vehicle fitment data, industry shorthand for a gap that makes a part invisible to a customer’s search
• A catalog fully mapped at launch accumulates app holes as new parts, vehicle configurations, and supplier updates continue after the audit ends
• ACES governs fitment, PIES governs the product itself, and a part can pass one standard while failing the other
• Most catalog audits check ACES and PIES separately, which is exactly how the compounding failure gets missed
• Closing this gap requires a named owner, a recurring update check, and a direct feedback path from supplier changes, not a one-time cleanup

Reconciliation cost shows up as a line item finance already tracks, hours spent re-verifying data nobody trusts. What rarely gets tracked is where that distrust actually comes from.

It comes from one specific place. A handoff between two departments where nobody is accountable for confirming the data arrived correctly. Not a data category. Not a vague governance gap. One specific, nameable moment where responsibility passes from one team to another with no one owning the transfer itself.

That single fact changes how this cost should be read. A labor problem invites more hands. A structural gap invites a different question entirely: who was supposed to own this moment, and what happened when nobody did.

---

In brief

• Reconciliation cost, the labor spent manually re-verifying data nobody trusts, has a specific, traceable root cause: the unowned handoff between departments
• Nobody owning the confirmation that a handoff happened correctly forces the receiving team to check everything themselves
• IBM’s research confirms distorted decision-making and eroded stakeholder trust as two of the direct consequences of poor data quality, both of which trace back to exactly this kind of unmanaged transfer point
• Closing the ownership gap at the handoff does not just fix accountability. It directly reduces the cost line item finance already tracks

Reconciliation cost, in this context, refers to the labor an organization spends manually re-verifying data it no longer trusts, a category most finance teams already log without realizing its root cause traces back to a single, specific organizational gap.

---

What Reconciliation Cost Actually Measures

Reconciliation cost is manual labor spent re-verifying data nobody trusts. A team spends real, billable hours cross-checking two systems that disagree, or rebuilding a report because the automated version cannot be relied on.

That definition explains what the cost looks like. It never explains why the trust disappeared in the first place. Data does not become untrustworthy on its own. Something specific happens upstream that makes a team stop believing what a system tells them.

IBM’s own analysis of data quality names erosion of trust among stakeholders as one of four distinct consequences of poor data, alongside distorted decision-making, automated amplification, and compliance risk. Trust erosion is not an abstract cultural symptom in that framing. It has a specific mechanism, and that mechanism is what this piece traces.

Where the Trust Actually Breaks

Trust breaks at a specific point, not a general one: the handoff, the exact moment data transfers from one department to another. Ownership assigned to a title survives inside a single department. It fails at the transfer point itself, because nobody is ever assigned to the moment of handoff, only to the categories sitting on either side of it. ThoughtSpark’s own reporting on cross-functional data ownership traces this exact gap in detail, the specific mechanism by which a named owner still leaves the transfer point uncovered.

That gap is where reconciliation cost actually originates.

---

Why Unowned Handoffs Produce Exactly This Cost

Follow the logic one step at a time, since each step is a direct consequence of the one before it.

A handoff has no named owner. Because nobody owns confirming the handoff happened correctly, the receiving team cannot assume the data arrived intact. Since they cannot assume it, they check it themselves before using it. That checking, by definition, is reconciliation cost.

Cause, Not Coincidence

This is worth stating plainly, since it is a stronger claim than simply noting the two ideas relate. Unowned ownership does not merely correlate with higher reconciliation cost. It produces it directly, as an unavoidable consequence. A team with no reason to trust a handoff has exactly one option available to them: verify everything by hand. There is no third path.

Deloitte’s 2025 Global Business Services Survey found that matrixed ownership structures, where accountability is distributed with genuine business-unit authority rather than concentrated centrally, consistently outperformed centralized models. The reason tracks directly onto this mechanism: a matrixed structure is more likely to assign someone specific to a transfer point, while a centralized one tends to assign ownership only at the category level, leaving the handoff itself uncovered.

---

Following the Money From the Handoff to the Ledger

Trace one specific handoff to see this play out concretely. A merchandising team updates a product record and passes it forward, assuming compliance will catch anything that needs review. Compliance assumes merchandising already handled what needed handling. Neither team is wrong about their own half of the process. The gap sits in the space between them, where the two halves are supposed to meet and don’t.

Weeks later, a data team notices two reports do not agree. Nobody told them to expect a discrepancy, so nobody flagged it before it reached them. They spend the afternoon manually tracing which system is right, hours that get logged against a dozen different task categories, never against the actual cause.

That afternoon is reconciliation cost. Its origin was never a data problem. It was a handoff nobody owned, three departments removed from where the bill eventually landed.

---

What Changes When Ownership Closes the Cost

Naming a data owner for a category does not, by itself, reduce this cost. A title covering “product data” in general still leaves the specific transfer point between merchandising and compliance untouched.

What actually closes the cost is narrower and more specific: a named owner for the handoff itself, someone accountable for confirming the transfer happened correctly, not just for the data sitting on either side of it.

The Same Fix, Read Two Different Ways

Described one way, this fix closes an accountability gap. Described another way, the identical fix reduces a line item, fewer hours spent on manual re-verification, because the underlying trust problem no longer exists. Both descriptions are correct, and both point back to the same single intervention: naming an owner for the moment of transfer, not just the data itself.

---

Is Your Reconciliation Cost Ownership or Effort?

Six honest questions separate a reconciliation cost problem that is genuinely about effort from one that is actually about ownership.

Tracing the Cost

• Could you name the specific handoff point most of your reconciliation hours trace back to?
• Is there one person accountable for confirming that handoff happens correctly, separate from whoever owns the data category itself?
• Would a missed handoff be visible before it reaches the team that has to manually fix it?

Testing the Fix

• If you named an owner for one specific handoff today, would reconciliation hours in that area actually drop, or just move somewhere else?
• Has your organization ever tried adding more people to reconciliation work, rather than adding ownership to the handoff producing it?
• If the answer to the first question was no, would anyone in your organization currently know where to start looking?

Outcome guide: Three or more “no” answers means your reconciliation cost is very likely an ownership problem still being treated as an effort problem, more hands doing the same manual work, rather than one handoff finally getting a name attached to it.

---

Key Takeaways

• Reconciliation cost, manual labor spent re-verifying untrusted data, has a specific, identifiable root cause rather than a diffuse one
• IBM names erosion of stakeholder trust as one of four direct consequences of poor data quality, and this piece traces the specific mechanism behind that erosion
• Deloitte’s 2025 research found matrixed ownership structures outperform centralized ones, consistent with the argument that transfer points need named accountability, not just category-level ownership
• An unowned handoff between departments removes the receiving team’s ability to trust that data arrived correctly, forcing manual verification as the only remaining option
• Naming an owner for a data category does not close this cost. Naming an owner for the specific handoff point does

Picture a regional Syndigo SI walking into a pre-sales meeting fully prepared on paper. Certified consultants, a solid delivery track record, every technical box checked. The prospect asks one specific question, how the platform handles a fitment-data edge case particular to their category. The room hesitates, and the confidence the deal needed to survive the next round goes with it.

Three weeks later, a competitor with a thinner delivery bench but a sharper answer to that exact question wins the business. The difference came down to something specific and fixable.

In brief

• Most lost Syndigo deals fail in the pre-sales conversation, before implementation ever begins
• Buyers now spend only 17% of the total purchase journey meeting with suppliers, leaving little room to recover from a generic answer
• 43% of B2B buyers report making defensive purchase decisions more than 70% of the time, favoring the SI that reduces their risk over the one with the most polished pitch
• The gap between winning and losing SIs usually comes down to the depth and specificity a team can bring to a single hard question, on the spot

The pre-sales depth gap, in this context, means the difference between an SI that can describe what Syndigo does in general terms and an SI that can answer a specific, category-level question with certainty, using Syndigo’s own history, architecture, and ecosystem standing as evidence.

Where Syndigo Deals Actually Get Lost

Where do most Syndigo implementation deals actually fall apart? They fall apart before implementation begins, in the pre-sales conversation, the moment a prospect asks a specific question and you answer with something closer to a platform overview than a real answer.

This matters more today than it did even a few years ago. Gartner’s own research confirms buyers now spend only 17% of their total purchase journey meeting with suppliers at all. Split across every SI a prospect evaluates, your window shrinks further still, and there is very little time inside it to recover from a generic answer.

What Buyers Are Actually Testing in Pre-Sales

Most pre-sales preparation focuses on proving delivery capability, certified consultants, past projects, a clean track record. That preparation answers a question the buyer has usually already settled by the time you’re in the room. The unsettled question is narrower and harder, and it follows your team into every conversation that comes next: does this specific group understand the platform well enough to be trusted with our specific problem.

Why Technical Capability Isn’t the Problem

That unsettled question is exactly where technical capability stops mattering as much as it should. A team can have genuine, deep implementation skill and still lose a deal in pre-sales, because implementation skill and pre-sales credibility are two different capabilities, built and demonstrated in different ways.

Delivery capability gets proven through a portfolio. Pre-sales credibility gets tested live, in the room, in response to a question nobody scripted for. Most SI training investment goes toward the first capability, since it is easier to structure, certify, and measure.

Why the Pre-Sales Depth Gap Exists

The imbalance has a clear cause. Delivery skill has a formal path, exams, credentials, and structured curricula all validate it in a repeatable way:

• Exams and certifications validate implementation competence in a structured, repeatable way
• Credentials give buyers an external signal of technical readiness
• Structured curricula teach delivery methodology step by step

Pre-sales product depth has no equivalent path. Nothing formally teaches the ability to answer an unscripted, category-level question on the spot, which is exactly why it develops unevenly. One or two people end up carrying the depth the whole team needs.

Why the Depth Gap Is Sharper in Regulated Categories

That unevenness shows up fastest in categories like healthcare or automotive aftermarket, where product attributes carry compliance weight. A prospect in these categories often opens with a compliance-adjacent question specifically because they are testing whether the SI understands the regulatory stakes behind the platform mechanics. A generic answer here reads as a double risk signal, both platform inexperience and category inexperience at once.

What Is a Skeptical Buyer Actually Asking?

That double risk signal is really a version of one question every buyer is quietly asking underneath whatever they say out loud. What is a skeptical buyer actually trying to learn in a pre-sales meeting? Whether choosing your team is the safer decision. Forrester’s own research on B2B buying found that 43% of buyers admit to making defensive purchase decisions more than 70% of the time, choosing the option that felt safest even when a more innovative one was on the table.

A specific product question, like the fitment-data edge case from the opening, works as a proxy test. The buyer is really asking whether your team has genuinely lived inside the platform long enough to be trusted with everything that comes up later, the parts of the project nobody has thought to ask about yet.

A Vague Answer Reads as a Risk Signal

A generic response to a specific question confirms the exact fear a defensive buyer already carries, that this team has not gone deep enough to be safe. That impression is harder to reverse than a single lost point in a longer conversation, since it colors how the buyer reads everything that follows it.

What Separates SIs Who Win From SIs Who Don’t

That colored impression is what separates the two outcomes this piece opened with. The SIs who consistently win Syndigo deals share one identifiable habit. They answer specific questions with specific, sourced detail, drawn from real product knowledge rather than a rehearsed talking point.

	Generic Pitch	Specific, Credentialed Answer
Platform history	“Syndigo is a leading PIM/MDM platform”	Names the platform’s actual scale and standing in the category
Ecosystem standing	“We are a certified Syndigo partner”	Names the specific role, Advisory Board seat, partner tenure, and what that access has produced
Product depth	“The platform handles that use case”	Walks through exactly how, naming the specific configuration or module involved
Track record	“We have delivered similar projects”	Names the recurring problem solved across multiple engagements
Objection handling	“We can work through that limitation”	Names the specific workaround or roadmap detail, showing the limitation was already anticipated

The Depth Gap in Practice

Return to the fitment-data question from the opening. A generic answer says the platform “supports complex attribute structures.” A specific answer names the exact module handling variant-level attributes, describes how it maps to fitment-specific fields, and states plainly what configuration work that requires.

The same gap shows up in how a track record gets described for that same client. A generic answer offers a list of similar past projects. A specific answer names the recurring pattern across them, three separate automotive aftermarket implementations that each required the same fitment-mapping configuration, and what was learned across all three.

The specific version of each answer takes only seconds longer to deliver, and closes the door on the buyer’s underlying doubt in a way the generic version never can.

Building a Business Case for Syndigo

That closed door is the actual goal, and it requires a different kind of conversation than most pre-sales teams are having. A pitch describes the platform. A business case connects the platform’s specific strengths to the buyer’s specific risk.

Lead With the Platform’s Own Credentials

Syndigo’s ecosystem standing and scale, its market position and depth in the category, is evidence a skeptical buyer weighs heavily. Citing this specifically does real credibility work in the room, well beyond gesturing at “a leading platform.”

Answer the Buyer’s Specific Question First

The instinct under pressure is to widen a hard question into a safer, more general answer. The stronger move answers the narrow question precisely first, then uses that precision to earn trust for the rest of the conversation.

Can Your Team Make This Case Today? A Quick Self-Assessment

Earning that trust is one thing to describe and another to actually be ready for. Six honest questions reveal whether your pre-sales team is prepared for the moment that decides most deals.

Depth and Readiness

• Could your pre-sales team answer a specific, category-level platform question on the spot, without pausing to check with someone else?
• Does your team routinely cite Syndigo’s own history and ecosystem standing, or default to general platform language?
• Has your team ever lost a deal specifically because a narrow technical question went unanswered well?

Preparation and Process

• Is pre-sales depth something your team actively trains for, separate from delivery certification?
• Do you know which specific product areas your team is weakest on when questioned live?
• If a prospect asked the hardest possible question in your category tomorrow, would your team already know the answer?

Outcome guide: Three or more “no” answers means the gap costing deals is not visible yet, and is very likely showing up as lost opportunities currently attributed to price, timing, or fit.

What to Bring Into the Next Pre-Sales Conversation

That outcome guide is also a starting point for what comes next, since the next Syndigo opportunity will very likely include one hard, specific question, the same kind that stalled the room in the opening scenario. Preparing for it means building specific, sourced answers ahead of time, before the pressure of the room tests whether the general pitch holds up.

Name the platform’s credentials specifically. Answer the narrow question first. Treat pre-sales depth as its own discipline, trained deliberately, separate from delivery certification.

That specific kind of preparation, product knowledge deep enough to survive a hard question live, is what ThoughtSpark’s Business Creation work is built to strengthen, closing the gap between your team’s real delivery capability and how convincingly that capability gets proven in the room where the deal is actually decided.

Key Takeaways

• Formal certification paths exist for delivery skill. No equivalent path exists for pre-sales product depth, which means the gap has to be closed on purpose. It does not close by itself
• A specific answer takes only seconds longer to deliver than a generic one, and closes the exact doubt a generic answer leaves open
• Delivery capability and pre-sales credibility are different skills, and most SI investment goes toward the former, since a formal training path exists for it and none exists for the other
• A specific, sourced answer to a narrow question reads as far more credible than a longer, general one
• In regulated categories like healthcare or automotive aftermarket, a vague answer to an early question reads as a double risk signal, both platform and category inexperience at once

Every business exists to make money, and most executive rooms can tell you, without hesitation, that bad data is costing them some of it. What almost none of them can tell you is how much. The number was never built to be counted.

Picture a mid-size retailer that mismaps one attribute field during a catalog migration. Two thousand SKUs go live underpriced by an average of eleven percent. Nobody notices for six weeks. By the time finance flags the margin miss in a monthly review, merchandising is blaming the pricing team, the pricing team is blaming IT, and IT is investigating an integration issue that turns out to be one wrong field. The margin hit gets logged. The words “bad data” never appear on any document that describes it.

That is the actual shape of this cost, a hundred quiet failures rather than one dramatic one, each filed under someone else’s name.

In brief

• The cost of bad data is widely felt and rarely priced, because it lives in several departments at once and no single role is responsible for adding the pieces together
• IBM’s research confirms this pattern directly: 43% of chief operations officers now rank data quality as their top data priority, a sign the pain has reached far beyond data teams themselves
• PwC’s 2026 research on CFO priorities finds finance leaders under growing pressure to prove returns on every investment, which is exactly why an unverifiable estimate stalls before it’s understood
• The cost consistently splits into four categories, each tracked by a different team, which explains why it reads as several small problems rather than one large one
• Finance rarely rejects a data cost estimate because the problem isn’t real. It rejects estimates it cannot verify against its own numbers

The cost of bad data, in this context, means the total financial impact of inaccurate, incomplete, or inconsistent data across an organization, including decision errors, automation failures, labor spent on reconciliation, and regulatory exposure, whether or not any single department has measured its own share of it.

What Bad Data Actually Costs, Beyond the Team That Notices It First

A sales team living with a bad lead list calls it a sales problem. Finance, dealing with a forecasting error six weeks later, calls it a modeling problem. Compliance, filing an audit finding, calls it a governance problem. Three teams, one shared cause, three different names for it.

IBM names four distinct types of consequence sitting underneath these labels: distorted decision-making, amplification through automation, erosion of trust among stakeholders, and compliance risk. Four teams, four symptoms, one root failure, told in four separate vocabularies.

IBM also found that 43% of chief operations officers now name data quality as their single most significant data priority. An operations leader, not a data specialist, saying this out loud is a signal worth taking seriously.

One Root Cause, Four Different Names

Return to the mismapped attribute. Monday, a leader signs off on a promotional pricing plan built from the same flawed catalog feed, unaware the underlying numbers are already wrong. Tuesday, an automated repricing system ingests the same feed and applies the error across every SKU it touches, not just the original two thousand. Wednesday, a data analyst notices two reports don’t reconcile and spends the day manually cross-checking, hours nobody budgeted for. Friday, a routine compliance review flags an inconsistency in product attribute records, unrelated in the auditor’s mind to anything from earlier that week.

One record. Four consequences. Five days. Almost nobody in that building will ever connect Monday to Friday.

Why the Same Failure Never Adds Up to One Number

Each department’s reporting system tracks its own function well. None of them share a label for “this traces back to a data quality issue.” So the connection has nowhere to live.

The margin miss from the pricing error shows up in a revenue report, filed as underperformance. The compliance finding shows up in an audit log, filed as a governance gap. Both documents are accurate. Neither one mentions the other. Read separately, each tells half a story, and the missing half is the part that would reveal the actual size of the problem.

This is not a hidden cost. Hidden costs sit somewhere waiting to be found. This cost is dispersed, spread across four places at once, and dispersal is harder to solve than concealment, because nobody’s job is to look in four places simultaneously and add what they find.

The cost of bad data does not hide behind a single number. It exists between several small ones, none large enough on its own to justify action.

The Four-Category Framework for Pricing Bad Data

Naming the problem explains why it stays invisible. Pricing it requires four categories, translated into language a finance team already speaks.

“Why not just use an industry benchmark instead of building all this internally?” It’s a fair question, and the honest answer is that a benchmark tells you what happened somewhere else, not what happened here. The four categories below exist precisely because “somewhere else” never survives a room full of people asking about this specific balance sheet.

What are the four categories where the cost of bad data actually shows up? Decision cost, propagation cost, reconciliation cost, and regulatory cost.

Category	Where It Originates	Where a Finance Team Would Find It
Decision Cost	A strategic call made on a flawed dashboard or forecast	Missed revenue targets, mispriced offerings, misallocated budget
Propagation Cost	Bad data entering an automated or AI-driven system	The same error repeated across every output the system touches
Reconciliation Cost	Manual labor spent re-verifying data nobody trusts	Headcount hours logged against cleanup, folded into other tasks
Regulatory Cost	Weak governance exposing the organization to compliance risk	Fines, audit remediation, legal spend tied to data findings

Decision Cost

The eleven-percent underpricing example is decision cost in its purest form. A leader trusted a dashboard. The dashboard was wrong. Six weeks passed before the trust was tested.

That gap, between the decision and the discovery, is why this category resists tracing. By the time the consequence surfaces, the flawed data has usually been overwritten. Someone has to want to find the original cause. Most people, holding a plausible explanation already, don’t.

Propagation Cost

Bad data entering a human-reviewed process creates one mistake. Bad data entering an automated one creates a multiplier. The repricing system from Tuesday didn’t repeat the original error once. It repeated it across every SKU it touched, at machine speed, before any person saw a single output.

This is the category growing fastest right now. AI adoption means more decisions route through systems built for speed, not for the pause a person occasionally takes to ask whether a number looks wrong.

Reconciliation Cost

Wednesday’s analyst is the easiest character in this entire story to find inside a real organization. Someone, somewhere, is spending real hours right now reconciling two systems that disagree. That labor rarely gets logged as “data quality,” and instead gets folded into general task time, disappearing into a spreadsheet nobody built to catch it. That invisibility is the opportunity here, not the obstacle, since the underlying hours already exist in a timesheet somewhere and simply haven’t been tagged by cause.

Regulatory Cost

Friday’s compliance flag lands as a line item in a legal budget, disconnected from the pricing error four days earlier that shares its root cause. The fine gets paid. The upstream gap that produced it stays open, and produces the next fine on a similar timeline.

How Finance Actually Evaluates a Data Cost Estimate

Everything above explains where the cost lives. It doesn’t yet explain why a well-researched estimate still gets rejected in the room. This is the part most conversations about bad data skip, and it’s the part that decides whether any of the previous four sections ever turn into a funded initiative.

Finance Rejects Numbers It Cannot Verify, Not Numbers It Doubts

A CFO who hears “bad data costs us millions” is not doubting the claim. Most already believe some version of it. What stops the request is simpler: the number arrives with no visible math behind it, and finance’s job, structurally, is to interrogate math.

PwC’s own research into 2026 CFO priorities describes finance leaders operating under exactly this pressure, expected to prove returns on every AI and digital investment they approve, while managing what PwC directly calls fragmented data and shrinking budgets. A number without a visible source doesn’t just fail to persuade in that environment. It actively works against the person presenting it, since approving it would mean the CFO cannot in turn prove the return if challenged themselves.

An industry benchmark fails this test immediately, because it was never measured against this company’s own systems. A labor-cost figure built from actual logged hours passes it, because finance can trace every dollar back to a timesheet it already trusts. This is why reconciliation cost, the least dramatic of the four categories, is consistently the one that survives a first budget review. It’s the only category that arrives already speaking finance’s native dialect: hours, rates, totals.

What Actually Clears a Budget Review

Three things separate a request that clears review from one that doesn’t. A defensible floor, not a dramatic ceiling, since an inflated number invites the exact scrutiny that kills a request before it’s understood. A named source for every figure, so a skeptical question has a direct answer rather than a shrug. And a scope small enough to audit in one sitting, which is why a single measured category beats a sweeping company-wide claim almost every time.

Capital allocation decisions inside most finance functions favor the request that’s easiest to verify over the request that’s largest in size. That single fact explains more about why data initiatives stall than any argument about the size of the underlying problem ever will.

Building the Ledger, Starting With One Category

Start smaller than a company-wide audit. Prove the method works once before asking anyone to trust it everywhere.

1. Start with reconciliation cost. The data usually already exists in a timesheet or task tracker. The work here is retrieval, not collection.
2. Tag existing entries by root cause. Go back through recent logs and mark which hours trace to a genuine data issue, not general friction.
3. Convert the total into a dollar figure, using fully loaded labor cost, the exact unit finance already applies to every other line item.
4. Repeat for the remaining three categories, one at a time. Attempting all four at once is how these efforts stall before producing anything usable.

The first category, once actually measured, is often large enough on its own to justify the initial request. The other three become the case for staying funded.

Six Questions That Reveal Whether This Cost Is Priced or Just Felt

[Visual: Self-Assessment Card — light-background checklist card, consistent with the established site format.]

Visibility and Ownership

• Could anyone in your organization name a single dollar figure for the total cost of bad data today?
• Is there one person accountable for consolidating that figure across departments, or does each team track its own piece?
• Would a data issue in one department ever get connected to a cost showing up in a completely different one?

Measurement and Language

• Do you track reconciliation hours, incident frequency, or resolution time by root cause?
• Would a figure presented to your CFO today already speak in finance’s own terms, or need translation first?
• Is your current estimate, if one exists, a conservative floor or an inflated worst case?

Outcome guide: Three or more “no” answers means the cost currently exists as a felt pain, not a defensible figure. That’s the exact condition that stalled the pricing team’s funding request six weeks after the original error, and the exact condition most requests stall inside.

What to Bring Into the Room

The retailer from the opening never got the chance to prevent its pricing error. The next one can, but only with a repeatable way to build the ledger before the next mismapped field turns into six quiet weeks nobody can explain. That repeatability is the whole point. A single measured category proves the method works. A named owner, a finance-native vocabulary, and a conservative floor make it something a CFO can actually approve, and the four categories together give an organization a standing answer, not a one-time favor, the next time this question comes up.

That is exactly the capability ThoughtSpark’s Data & AI Strategy and Data Readiness Hub practice is built to provide, for finance and data leaders who would rather walk into that next conversation with a number than a feeling.

Key Takeaways

• Only 43% of chief operations officers name data quality as their top priority, despite its cost touching nearly every function, per IBM
• PwC’s 2026 CFO research finds finance leaders under mounting pressure to prove returns on every investment, which is exactly why unverifiable cost estimates rarely survive a budget review
• The cost splits into four measurable categories: decision cost, propagation cost, reconciliation cost, and regulatory cost
• Finance rejects estimates it cannot verify, not estimates it doubts, which is why labor-cost figures outperform industry benchmarks in a budget review
• A defensible number needs a named owner, finance’s own vocabulary, and a conservative floor rather than a worst-case ceiling
• Reconciliation cost is the fastest category to measure, since the underlying hours usually already exist in a timesheet, just untagged