Why Your AI Recommends Things That Cannot Happen
A model sees your features one at a time. Feature relationships let you declare which combinations exist in the real world, so every recommendation is one your team can actually action.
The offer nobody could action
A retention model flags a customer at high risk of leaving. The recommended action comes back: add Online Security to the account, and churn probability drops by eleven points. The agent opens the account and finds the customer has no internet plan. Online Security is an internet add-on. The recommendation was never possible.
That single row does more damage than it looks. The agent now checks every recommendation by hand, which removes the time saving the model was bought for. Worse, they stop believing the ones that were fine.
As of 2026, roughly nine in ten organisations use AI in at least one business function, yet only about six percent capture significant enterprise value from it.
The gap is rarely accuracy. It is whether the output survives contact with the person who has to act on it.
Why a model misses something so obvious
Xplainable models are additive by design. Each feature carries its own transparent contribution, which is what makes a prediction explainable and fast to score. It is also what makes this blind spot structural rather than accidental: no feature knows anything about any other feature.
Two things follow.
Combinations that cannot exist. The model learns that Online Security is associated with lower churn. It has no way to know that Online Security requires an internet plan, because that rule lives in your product catalogue, not in the statistical structure of the data.
Values that stop agreeing with each other. Most datasets carry columns calculated from other columns: lifetime value from tenure and monthly charges, a rate from two counts, an engagement score summed from opens and clicks. Change tenure in a scenario and the lifetime value column sits there unchanged, quietly describing a customer who does not exist.
The usual workaround, and where it leaks
The common answer is to filter afterwards. Rank everything, then strip out whatever breaks the rules on the way to the campaign tool.
Business constraints include frequency caps, channel eligibility, margin floors, inventory availability, compliance and consent rules.
Filtering works, up to a point. It leaks in three places.
- You keep the leftovers, not the best plan. If the top recommendation is removed after ranking, you are left with whatever survived, not the best feasible option the model could have found.
- The budget was already allocated. Budget-constrained optimisation spreads spend across the whole portfolio. Remove rows afterwards and the allocation no longer matches the plan that was approved.
- Nobody can explain the gap. An action disappears somewhere between the model and the campaign, and the person asking why gets pointed at a rules engine in a different system.
Declaring the relationships once
Feature relationships move those rules to where the model and the optimiser can both see them. You declare them once against a dataset, and every model trained on it afterwards carries them.
There are three kinds.
You do not have to write them from memory. Ask xplainable to scan the dataset and it proposes candidates with the evidence behind each one: how many customers support the pattern, which combinations never occur, and how surprising each absence would be if the two columns were unrelated.
That leaves you the part only you can do, which is deciding which patterns are true about your business and which are coincidences in this particular extract. A combination that never appears in five hundred rows might be a hard product rule, or it might be luck.
Save the ones you keep. From that point:
- Every model trained on the dataset inherits the rules
- Optimisation will not recommend a combination the rules forbid, in either direction
- Derived columns are recalculated whenever a recommendation changes one of their inputs
- Models trained before you declared the rules can pick them up without retraining
What changes in the output
Same customer, same model, same budget. The difference is what comes back.
The third row is worth dwelling on. A direction you set on a feature now applies to that feature's whole effect, including the interactions it takes part in. Previously a constraint could hold for the model overall while quietly reversing inside one segment, which is exactly where a retention team would notice it and lose confidence.
The return is trust, not accuracy
None of this makes the model more accurate. Accuracy was rarely the blocker.
56% of CEOs report zero measurable ROI from AI in the past twelve months, and only about 21% of adopters have redesigned any workflow around it.
Workflows get redesigned when people stop double checking the output. In one financial services deployment, adoption fell to 12% after users could not reconcile the system's suggestions with their own numbers, and the team went back to spreadsheets. Once a recommendation is wrong in a way that is obvious to the person reading it, every other recommendation inherits the doubt.
Feature relationships are a small piece of governance with an outsized effect on that. Every xplainable recommendation already cites its drivers, a what-if, and the constraint it respected. Now those constraints include the ones that come from your product, your policy and your data model, not only the ones about budget.
Where to start
You do not need to map your whole schema. Start with the dataset behind the model your team acts on most, and look for two things:
- Columns calculated from other columns, usually the ones named total, rate, score or lifetime
- Products or statuses that depend on another product or status being present
Run the scan, keep what is true, and train. The next set of recommendations your team opens will be ones they can act on without checking first.
Ready to see this on your own data? Book a demo and we will walk through a costed action plan built on your rules.
