What “personalized” AI should explain.

Personalization is a result, not a method

Two products can both promise personalized guidance while doing very different things.

One may use only the current message and a saved plan. Another may combine history, inferred interests, account activity and connected tools. Both can sound tailored.

It does not tell you:

• which information entered this response;
• whether it was supplied by you or inferred by the system;
• whether it applies only here or persists;
• what happens when a saved fact is wrong;
• or where the system’s intended use ends.

Personalization should be inspectable at two levels: this output and the information lifecycle behind it.

Ask for a five-line context receipt

A useful explanation can be short but must be specific.

For an everyday reading plan, a context receipt might say:

This is an editorial example, not a description of any current product. Its documentation and privacy notice must provide the real categories and controls.

Separate four things products often blur

1. Information you supplied

This includes a current message, onboarding answer, saved plan or preference you approved. The product should show whether an item applies to one plan, one conversation or the account.

2. Information the system inferred

An item such as “prefers short answers” may be inferred rather than typed. Inferences can be useful and wrong; you should be able to identify, correct or reject them.

3. Information stored

Transcripts, memories and profile fields may have different retention rules. Deleting a conversation may not delete a separately saved memory; do not assume one switch covers every layer.

4. Information used now

For one answer, ask what context actually reached the model or decision system. A product may store more than it uses, or supply a memory not visible in the transcript. Storage and request context are related, not identical.

Use the buyer’s checklist before you opt in

You do not need a technical architecture diagram. You do need answers you can act on.

Scope

• Is personalization limited to this plan, this conversation or the account?
• Does it use connected services or only this product?

Provenance

• Can you tell whether each saved item was entered, imported or inferred?
• Can an answer identify which items materially shaped it?

Control

• Can you inspect and correct individual items—not only turn personalization on or off?
• Can you start a fresh session, and are deletion consequences clear?

Output boundary

• Does it distinguish a suggestion from a fact about you?
• Can it state uncertainty and accept a correction?

An answer need not reveal proprietary model weights or every engineering detail. It should reveal enough to understand what happened, make a choice and notice meaningful changes to providers, memory behavior or controls.

Run a harmless personalization test

User-facing tests cannot prove what every backend system stores or processes. They can show whether visible claims and controls behave coherently.

Use a harmless preference such as “I like plans on index cards.” Do not use private information.

1. Add it. Ask the product to use or remember the preference. Save the confirmation.
2. Inspect it. Find the memory, profile or personalization control. Is the exact item visible, and is its scope clear?
3. Correct it. Change index cards to a pocket notebook. Check whether the visible record changes.
4. Ask why. Request a new planning suggestion and ask what information shaped the format.
5. Start fresh. In a new or temporary session, see whether the preference appears as documented.
6. Delete it. Remove the item and repeat after any stated processing period.

If the product produces inconsistent results, that is not proof of a particular hidden process. It is a reason to ask for clearer documentation or keep personalization off.

Red flags in a “personalized” claim

Be cautious when:

• the benefit is only “knows you better”;
• controls have no inspectable items or scopes;
• the product blurs history, memory and current context;
• a recommendation cites a preference you do not recognize, with no correction path;
• explanations are confident even when context is missing or contradictory;
• or deleting a visible item has no documented relationship to reuse or retention.

No single checklist proves that an AI system is accurate, private, fair or secure. NIST explicitly treats transparency, explainability, privacy and other trustworthiness characteristics as related but distinct. A transparent system can still be wrong. The point of the receipt is to make evaluation and control possible—not to award trust automatically.

What Meliorly should promise

For everyday habit coaching, personalization should stay close to the current job: action, cue, versions, recent pattern and approved preferences. It should not require a vague lifetime profile.

The product bridge is simple: show the relevant context, name its effect on the reply, keep unrelated context out, and make removal understandable. The current Meliorly privacy notice and feature documentation—not this editorial guide—must remain the source of truth for actual processing, providers, retention and deletion behavior.

Evidence notes and sources

• NIST (2023). AI Risks and Trustworthiness. Distinguishes transparency, explainability, interpretability and privacy; transparency alone does not make a system accurate, private, secure or fair. The framework is voluntary, not a certification.
• NIST (2023). AI RMF Core. Includes documenting intended context and knowledge limits, monitoring behavior, examining privacy risk and enabling feedback.
• Phillips, P. J., et al. (2021). Four Principles of Explainable AI. Proposes explanations that give reasons, are meaningful, reflect the process and respect knowledge limits; it does not certify a product.
• This guide is a buyer’s evaluation tool, not legal or security advice. Product architecture, policies and laws change; verify current documentation for the service and jurisdiction involved.