Gross-profit explainability over a knowledge graph

Merchants at a global apparel retailer could see that gross profit had moved. What they could not see was which of the fifteen-odd levers underneath it had done the moving, or how many dollars each was worth. The driver tree existed — on a slide. Reconstructing it against actuals was several days of analyst work, by which point the next week had closed.

The design principle

Deterministic math wherever a derivation exists; predictive models only where one does not. That boundary is the architecture, and drawing it explicitly — rather than reaching for a model at every level — is what makes the output defensible in a meeting.

The tree has four levels and three different decomposition methods:

• Level 0, the root. Gross profit is an identity: demand plus returns minus cost of goods. Nothing to estimate.
• Level 1, additive. Each component's contribution is current minus baseline. Direct subtraction.
• Level 2, multiplicative. Demand is the product of door count, average per store, sell-through rate and average selling price. A product doesn't decompose by subtraction, so this uses LMDI-I — logarithmic mean Divisia index, an index-decomposition method from energy economics that leaves zero residual. The factor contributions sum exactly to the change.
• Level 3, merchant levers. Traffic, conversion, units per transaction, markdowns, promotions, price realisation, category and lifecycle mix. No closed-form equation links these to the level above, so this is the only level where a model earns its place: gradient-boosted trees with TreeSHAP for per-lever attribution.

Joining math to model without double-counting

The two methods have to produce one number. LMDI gives each level-2 factor a dollar figure. TreeSHAP gives each level-3 lever an importance score for the factor above it. Each lever's dollars are then its share of the SHAP magnitude within its parent factor, multiplied by that factor's LMDI dollars — so lever dollars sum to the factor total, and the factor totals sum to the change in gross profit. The attribution reconciles at every level.

Detecting what's worth explaining

Not every movement deserves a narrative. Anomalies are scored with a modified Z-score — median and median absolute deviation rather than mean and standard deviation. Standard Z is the obvious choice and the wrong one here: retail is seasonal and spiky, and a single promotional week drags the mean enough to hide the next month's genuine anomalies. The median-based version does not move. Scores bucket into four bands, from monitor-only through to immediate escalation.

Ranking causes the way a merchant would

Every node gets a composite score across four dimensions: dollar attribution, anomaly severity, how well the model explains that lever, and — the one worth stealing — actionability. A lever the merchant can pull this week scores full marks; one they partly influence scores half; a structural lever like door count scores zero.

This matters more than it sounds. Pure dollar ranking surfaces the biggest number, which is frequently something nobody can act on. Weighting for actionability means the top of the list is a to-do list rather than a post-mortem.

The system also reads the shape of the ranking. When most of the top causes route through the same part of the tree, it says so before the detail: if they run through demand it is a volume story; through price realisation, a pricing story. Merchants get the headline before the fifteen-row table.

Architecture

The driver tree is a graph, so it is stored as one. A weekly pipeline runs at fiscal close: full refresh from the warehouse, anomaly and variance computation, graph population, then model inference. The agent that answers questions traverses the graph — it holds no warehouse credentials and recomputes nothing. Every figure it quotes was written by the pipeline and is traceable to the run that produced it.

Prompts and responses are both screened before and after the model call, for injection, personal data and harmful content. The screening sits outside the agent, so it cannot be prompted away.

Decisions worth stealing

• The graph store was chosen on security posture, not benchmarks. A managed graph database was the natural fit and we evaluated it seriously — but its marketplace edition could not offer private connectivity, and onboarding a new data technology would have consumed a meaningful share of a fifteen-week phase. A graph extension on the platform's existing managed database gave IAM-authenticated access over private networking with no new vendor. A second native option was still in private preview with no committed date, which is not a thing to bet a fixed-scope phase on.
• Orchestration was sized to the problem. The pipeline runs weekly and calls managed services in sequence. That is a serverless workflow, not a scheduler cluster — and the client was actively retiring the heavyweight option elsewhere.
• Models are promoted, not deployed. Training is triggered by hand; inference is automated. Only versions clearing a quality bar get registered, so a bad training run cannot reach production by default.

What we would tell you before phase two

The models train on roughly a hundred and twenty chain-week rows. That is a small dataset by any standard, and it constrains how many features can be used without overfitting — the cross-validated fit is strong, but strong fit on a small sample is a reason for care, not confidence. Moving to store-week granularity takes the training set into the tens of thousands and is the single biggest improvement available.

Two of the four multiplicative factors have models; the other two are waiting on cost and inventory features that do not yet exist in the extract. We scoped them out rather than proxying them, because a lever with an invented attribution is worse than a lever marked "not yet explained".

All case studies