Retail

The Markdown Nobody Could Explain

Retailers let AI set prices, allocate stock and approve returns every day. When one of those calls goes wrong, the question is not whether the model was good. It is whether anyone can show what it saw.

October 2026· 5 min read· KrisVen

Picture a merchandising lead at a mid-size apparel retailer. Call her Priya. On Monday, the markdown engine cuts a winter jacket by 40% across sixty stores. By Friday the jacket has sold out, at a loss, and the replenishment order that would have covered full-price demand is still sitting at the distribution center.

The CFO asks a fair question: why did we mark down a product we didn’t have too much of?

Priya’s team spends the next week finding out. The engine had read an inventory snapshot that was three days old. It still counted 2,000 units that had already been moved to the outlet channel. The pricing rule it applied had been changed mid-season, and nobody can say which version was live on Monday. Two flagship stores had been excluded by a regional manager, in a chat message that never made it into any system.

None of this is a model problem. The model did exactly what it was built to do, on facts that were wrong and rules nobody could pin down. This scenario is illustrative, but most retail teams will recognise every part of it.

Retail runs on thousands of small decisions

Retail is rarely regulated the way lending is, so decision records feel optional. But the volume is enormous, and more of these calls are now made or drafted by software every season.

Price and promotions

Markdowns, promo depth, competitive price matches and clearance timing, often recalculated daily per store or per channel.

Allocation and replenishment

Which store gets the last 400 units, which orders get rushed, which supplier gets the next purchase order.

Returns and exceptions

Refunds outside policy, fraud holds, goodwill credits for a loyal customer. These are the calls that most often go to a person, and the ones least often written down.

Each one is small. Together they decide margin. And each one can be questioned later, by someone who wasn’t in the room.

Why these decisions are hard to explain afterwards

When Priya’s team tried to reconstruct the markdown, four gaps slowed them down. They show up in almost every retail AI workflow.

The facts were stale

Inventory, sell-through and competitor prices change by the hour. A decision made on Monday from Friday’s stock count is a decision about a store that no longer exists. Nothing in the system flagged the age of the data it acted on.

The rule changed mid-season

Promo calendars and markdown floors are edited constantly. If the decision does not record which version of the rule produced it, the team ends up arguing about what the rule was, not whether it was right.

The exception lived in a chat thread

The regional manager’s override was sensible. It was also invisible: no named owner, no reason, no link to the decision it changed. Next season, the same override will be made again by hand.

The record was scattered

Pricing logs in one tool, inventory history in another, approvals in email. Each piece exists. None of them is tied to the others, so a five-minute question becomes a week of archaeology.

The model wasn’t wrong. It was right about a world that had changed three days earlier.

What a trustworthy markdown looks like

The fix is not a better pricing model. It is making sure every pricing, allocation and returns decision carries its own evidence, from the moment it is made.

The same markdown, with KrisVen in the path

Capture. The decision records the inventory snapshot it used, with its timestamp and source, so a three-day-old count is visible as three days old.

Reason. The current markdown rule is applied, and retired versions are blocked, so the decision always names the rule version that produced it.

Guide. When sources disagree, for example the warehouse count against the store count, the decision waits and goes to a named owner with the conflict laid out, instead of guessing.

Seal. The facts, the rule version, any override and who approved it are sealed into one record in the Decision Ledger. Priya’s week of reconstruction becomes one lookup.

Someone will ask, even without a regulator

Retail rarely gets an examiner’s phone call. The questions come from other places, and they are just as specific.

“Why did we lose margin on this line?” Finance, leadership

A markdown that can be traced to its inputs is a lesson. One that can’t is just a loss.

“Why was my product discounted below our agreement?” Brand and vendor partners

When a supplier disputes a price, showing the exact rule and data behind it settles the conversation quickly, in either direction.

“Why was my return refused?” Customers

A refusal that cites the policy in force on the purchase date, and who reviewed it, is defensible. A refusal nobody can explain usually ends in a refund anyway.

Start with one decision

You don’t need to govern every pricing call on day one. Pick the decision that costs the most when it goes wrong, often markdown approvals or out-of-policy refunds. Measure how long it takes today to explain one of those decisions after the fact, and how many of them a person has to review by hand. That baseline is what a pilot improves on.

ContextEvidenceFreshnessExceptionsReplay

Retail decisions don’t need a regulator to need a record. They need one because someone will always ask why.

Start with one decision workflow: get your AI Decision Trust Score in three minutes, then discuss your workflow with us.