# Every recommendation deserves a why.

How provenance, confidence, memory status, and negative results turn a recommendation into something a person can use.

- **Canonical URL:** https://vidhata.me/notes/every-recommendation-deserves-a-why
- **Author:** Vidhatanand V. (Vid)
- **Role:** Fractional CTO and AI Systems Architect

**Published:** 01 Sep 2026 | **Reading time:** 9 minute read

## Why I hold this position

A recommendation is easy to generate. A useful reason is harder. The reason has to survive questions from a person who did not build the system: What did you see? How recent is it? Which assumption did you make? How confident are you? What would cause the answer to change?

I do not think explainability means printing a paragraph of model reasoning. That can sound persuasive without being traceable. I care about product evidence: sources, timestamps, confidence, rules, comparisons, and the path from an observation to an action.

## Memory needs governance before it needs intelligence.

In a personalisation system, a temporary signal can easily harden into permanent truth. A visitor reads one article, and the system decides they care about the topic forever. A sales team corrects the assumption, but the next model call retrieves the old memory again. The problem is not a weak model. It is a data model with no concept of source, status, confidence, or expiry.

I prefer memories and inferences as explicit records. Each one should say where it came from, whether it is observed or inferred, how strongly it is believed, who confirmed or rejected it, and when it should be reconsidered. This gives the product a way to forget, challenge, and repair what it thinks it knows.

## A reason should be connected to the decision.

If a system recommends a piece of content, changes a journey, or prioritises an account, the reason should name the evidence that mattered. A vague statement such as based on your interests is not enough. The interface can show the topic signals, recent behaviour, confidence, and the business rule that made the recommendation eligible.

The same applies to quantitative products. Hard safety or eligibility rules should be visible as rules. Preference scoring should show which tradeoffs it negotiated. Generated language can explain the result, but it should not invent the basis for it. The explanation belongs to the decision system, not to a storytelling layer added afterwards.

## Negative results belong in the evidence.

Teams naturally preserve successful runs and quietly discard failures. That creates a false picture of system quality. I want rejected outputs, failed evaluations, missing sources, and uncertain matches to remain visible. A protected negative result prevents the next run from rediscovering the same bad path and calling it new evidence.

This is also how technical leadership stays honest. If a model, detector, or architecture did not meet the human bar, the decision record should say so. Passing a mechanical test does not convert an unusable output into success. What failed, why it failed, and what was not measured are part of the recommendation.

## Reasons create a better learning loop.

When a person can see and challenge the basis for an action, feedback becomes specific. They can correct the source, lower the confidence, change the rule, or reject the recommendation. The system learns from an attributable correction instead of receiving a vague thumbs down.

That is the deeper value of a why. It is not a compliance paragraph or a way to make AI sound thoughtful. It is an operating interface between the system and the people responsible for it. A recommendation with evidence can be debated and improved. A recommendation without evidence can only be accepted, ignored, or feared.

## What I take into the next build

- Store observations and inferences with source, status, confidence, and time.
- Generate explanations from decision evidence, not free-form persuasion.
- Preserve rejected outputs and missing evidence as useful system state.
- Design feedback so a person can correct the reason, not only the result.

## Continue reading

[All Fractional CTO field notes](https://vidhata.me/notes)

## Work with Vid

Start with the actual technical pressure: [bring the problem](https://vidhata.me/hire).