“Can I see it?”, “Is it kept?” and “Is it used?” are three different questions
Imagine you told an AI coach last month that you prefer reading on paper. That sentence might exist in several places:
- In the old conversation. You can scroll back and see the message.
- As a saved fact. The system may retain “prefers paper books” separately so it can use the preference later.
- In today’s model request. The system may include that fact when you ask for a new evening-reading plan.
None of those states guarantees the other two. Deleting a conversation may not delete a separately saved memory. Turning off a memory feature may not erase old conversations. Keeping a transcript may not mean the entire transcript is replayed with each new message.
This is why a single privacy toggle rarely tells the whole story. You need a map of the information flow.
<a id="six-layers"></a>
Read an AI feature in six layers
Use this six-layer check before you decide whether an AI coach’s personalization is proportionate to the job:
| Layer | What it means | What to ask |
|---|---|---|
| Current message | The words and attachments you send now | Does the product strip account identifiers or other unnecessary fields? |
| Recent thread | Prior turns supplied to keep this conversation coherent | How much of the thread is used? Can a new thread start cleanly? |
| Saved memory | Facts retained for possible reuse later | Can I see, correct and delete each item? |
| Plan context | Structured details such as a cue, small version or recent pattern | Is context limited to the habit I am discussing? |
| Account data | Email, subscription, device or profile information | Which of these fields, if any, reach the model request? |
| Processing and tools | Model providers, retrieval systems or connected services involved in answering | Where is the data processed, how long is it retained, and do connected tools have separate permissions? |
The important distinction is between information a product stores and information a product selects for this answer. A system can keep a large archive but use a narrow request. It can also show a short chat while quietly adding saved facts or retrieved records behind the scenes. Neither design is automatically good or bad. Both should be explainable.
<a id="context-receipt"></a>
Ask for a context receipt, not a promise of “personalization”
A useful explanation should be concrete enough to resemble a receipt. For a question about an evening-reading habit, it might say:
Included for this reply
- your current message;
- recent turns from this reading conversation;
- your approved reading cue and ordinary/tired-day versions;
- one saved preference you confirmed: paper books.
Not included for this reply
- your email address and billing details;
- conversations about other habits;
- deleted or rejected memory notes;
- unrelated journal text;
- a full lifetime transcript.
This example is a design standard, not a description of every AI product. If a company cannot name the categories, you cannot meaningfully judge whether “personalized” means the minimum useful context or a much broader profile.
<a id="controls-test"></a>
Test the controls with one harmless fact
Do not test privacy controls with information you would regret sharing. Use a harmless, distinctive preference—“I like planning on index cards,” for example—and run this small audit:
- Save: ask whether the product can remember the preference. Note any confirmation it shows.
- Inspect: open its memory or personalization controls. Can you see the exact fact, or only a master switch?
- Correct: change “index cards” to “a pocket notebook.” Does the visible memory update?
- Start fresh: open a new chat or temporary session. Ask for a planning format. Does the old preference appear, and is that consistent with the product’s documentation?
- Delete: remove the memory, then repeat the fresh-session test.
- Check history separately: confirm whether the original conversation still exists and whether deleting it is a different action.
This test cannot reveal every backend operation, but it shows whether the user-facing promises and controls behave coherently. For retention, model training, legal bases and deletion timelines, use the current privacy notice and product documentation.
<a id="choosing-boundary"></a>
Choose the smallest useful boundary
For everyday habit coaching, more context is not always better. A coach usually needs the current question, the plan it is helping with, recent same-topic conversation and a small amount of deliberately saved information. It rarely needs identity fields or unrelated conversations to suggest a smaller next step.
Before enabling memory, finish these sentences:
- The benefit I want is: “Remember the tiny version of this specific habit.”
- The information required is: “The plan and one preference I approved.”
- The information that should stay out is: “Other habit threads, identity data and free-form notes.”
- The control I expect is: “Show, edit and delete each saved item.”
If the benefit cannot be stated without “know me better,” it is too vague to evaluate.
<a id="meliorly-current-boundary"></a>
For Meliorly, check the current product explanation
Meliorly’s existing guide, What should an AI habit coach know about you?, explains the current categories used for a model-generated reply and links to the product’s privacy controls. Treat that page and the full privacy notice as the source of truth for Meliorly’s present implementation; AI features and provider behavior can change.
The broader buying rule is durable: history should not be mistaken for memory, memory should not be mistaken for the context used now, and none of them should be invisible.
Evidence notes and sources
- OpenAI, “Memory FAQ”: a product-specific example that explicitly distinguishes saved memories from chat history and documents current controls. It supports the distinction within ChatGPT only; it should not be generalized to every AI system.
- Meliorly, “What should an AI habit coach know about you?”: current Meliorly explanation of relevant context categories and product boundary.
- Meliorly privacy notice: source of truth for storage, retention, export and deletion details. Product documentation should be checked again at publication and after relevant feature changes.