The business context is not data: 

what your tool doesn't know

Data, rules, context: three different things

These three terms are often used interchangeably, and this confusion accounts for much of the disappointment surrounding pricing projects. Yet they refer to three distinct concepts, each of which is acquired in a different way.

• Data describes what has happened: sales, recorded prices, inventory levels, and realized margins. It is factual, dated, and extracted from a system, whether endogenous or exogenous.
• The rule describes what the system must do: not fall below a certain threshold, not deviate by more than a certain amount from a specific competitor. It is formalized, executable, and configurable: this is the mechanism we describe in “How an AI Pricing Engine Works.”
• Context explains why the rule exists and what would be absurd even without a rule to prohibit it. It is neither factual nor actionable. It exists in people’s minds, and it doesn’t come from anywhere in particular. This is one of the reasons why generative AI gets prices wrong: it reasons based onwhat it’s given, not on what the company knows.

Data quality is now a well-recognized issue, and we’ve devoted an entire article to it in the context of the “glass ceiling” in AI pricing. But perfect data only solves part of the problem. It helps answer the question, “What happened?” It says nothing about the question, “What isn’t working here?”

An example that sums it all up

Consider a slow-moving, low-turnover shelf-stock item with a decent margin, no competitors positioned on that shelf, and no regulatory constraints. A well-funded decision-making engine would logically recommend raising its price by a few cents. The recommendation is sound in every measurable respect.

And it’s inapplicable, because that reference is the one the regional director systematically cites in meetings to illustrate the brand’s positioning, because a local journalist used it as an example two years ago, and because the sales department has decided it won’t change. None of this exists in any database. All of this is well known to five people in the company.

This figure is generally interpreted as an assessment of the technical quality of the data. It deserves a broader interpretation: “AI-ready” data is not just clean and accessible data; it is data that comes with the information needed to interpret it.

The four context families that no database contains

1. Price Benchmarks

Not all products carry the same weight in the customer’s perception. A handful of them define the brand’s price image: those the customer knows by heart, those they compare across stores, and those featured in price comparisons. Sales data does not distinguish them from other products; they sometimes sell less well than run-of-the-mill items.

Some of this knowledge can be reconstructed statistically, and that is precisely the job of a well-designed engine. Other aspects cannot, because they are rooted in local history, a stated position, or a public promise.

2. Relationship Constraints

This supplier who will not agree to have its product line marked down before a certain date. This brand whose listing agreement stipulates a maximum price difference from the private label. This partner with whom sensitive negotiations are underway and with whom it’s best not to make any changes this quarter.

These constraints are real; they have direct financial consequences, and they are reflected in contracts, meeting minutes, and conversations. None of them are found in sales data streams.

3. Unwritten Taboos

These are the most dangerous, because no one thinks to mention them. We never go below a certain psychological threshold for this product line. We never run promotions on this product during this period. We never match prices with this specific competitor, because the brand doesn't compare itself to that competitor.

When asked directly, no one mentions them, because they aren't perceived as rules—they're taken for granted. They only come up when someone breaks them, during a meeting, with the phrase, "Of course we don't do that."

4. Shopping Intentions by Category

A category focused on market expansion is not managed the same way as a category focused on profitability. One is willing to sacrifice margin to gain market share, while the other does the opposite. This strategy changes over the course of the year; it is decided by a committee and is rarely translated into specific parameters within the system. As a result, the optimization engine applies the same objective across the board, even though the company pursues different objectives depending on the department.

How can you tell when an engine lacks context?

The symptoms are characteristic, and they are clearly distinguishable from those of a data problem.

• The recommendations are sound but have been rejected. No one disputes the calculation; everyone refuses to implement it. This points to a lack of context, not a lack of data.
• The acceptance rate varies significantly from one category to another, even though the quality of the data remains consistent. The categories that are accepted are those for which contextual information was provided, often because the person in charge of them participated in the configuration process.
• The same manual corrections come up every week. Each repeated correction represents a piece of context that hasn't been formalized: the team manually re-enters what the system doesn't know.
• Objections begin with “obviously.” This is the most reliable indicator of tacit knowledge. What is obvious to the team is not obvious to any system.

This last point should be treated as a working tool rather than a nuisance. Every time a team says “obviously,” it has just inadvertently revealed a rule it would never have thought to state. All you have to do is write it down.

How to extract a context that exists in people's minds

The naive approach is to ask teams to write down their rules. It almost always fails, for one simple reason: we don't know how to articulate what we've never needed to put into words. Three approaches work better.

Learning from Past Exceptions

The manual corrections made over the past twelve months are the company’s most valuable resource. Each one reflects a discrepancy between what the system suggested and what the team knew. Categorizing them by reason reveals patterns of context much more effectively than a writing workshop.

Use confrontation rather than questioning

Rather than asking, “What are your rules?”, present pricing proposals and ask which ones are unacceptable—and why. A refusal prompts a response where an open-ended question leaves people speechless. It’s the same logic as a simulation: you reveal a policy by testing it against concrete scenarios.

Capture it gradually, not all at once

Context isn't something you can gather in a two-day workshop. It builds up bit by bit, with every decision, provided someone is assigned to document it as it happens. It's a task that takes just a few minutes a week, but after a year, it's worth more than any formalization project.

Key Point: Context is not synonymous with a rigid rule

Turning every piece of context into a blocking rule in the tool is the best way to create the liability described in our article on the rule debt of a pricing engine. Much of the context should remain information displayed at the time of the decision rather than a constraint that is silently imposed. The difference between the two is considerable: one informs human judgment, while the other replaces it.

Why Context Outlives Models

Forecasting and optimization algorithms evolve rapidly. An approach that was state-of-the-art three years ago is now outdated, and today’s approach will be outdated in three years. This is good news, and it’s also why it’s risky to make the model the core of your investment.

The context, however, does not become outdated at the same rate. A retailer’s pricing benchmarks, supplier constraints, commercial restrictions, and category-specific objectives evolve over the course of years, not with each new version. A company that has formalized this foundation can switch platforms without starting from scratch. A company that has not done so must start from scratch every time it changes tools—and ends up paying twice.

What this means when it comes to making a choice

So the question to ask a vendor isn’t just “What can your model do?”, but also “Where does my context fit into your solution, and what do I get out of it if I leave?” A context buried within a proprietary configuration is a context that you’ve built but don’t truly own. That’s the focus of our article on the reversibility of a pricing solution.

To put it simply: data tells you what you’ve sold, the model tells you what might work, and context tells you who you are. The first can be repurchased, the second can be replaced, and the third is built once and for all.

FAQ