Pattern 28
Sensitive memory by permission
Make persistent memory specific, inspectable and reversible.
Concrete takeaway
Default to the memory behaviour stated by the product.
Choose an approach
These are editorial decision conditions to validate. Some alternatives are successive states or can be combined; they are not always exclusive choices.
| Alternative | Use when | Tradeoff or requirement |
|---|---|---|
| A · Continue without saving | Saving is unnecessary or declined | Continuity may be lower but participation remains complete |
| B · Review proposed memory | A specific memory could help later | The exact wording and scope require review |
| C · Memory library | The person reviews stored memory | Deletion limits and derived data must be clear |
The problem
A personal disclosure can be stored invisibly and later reappear in an unexpected recommendation or opening message.
The pattern
Default to the memory behaviour stated by the product. Before any optional durable memory, show the exact proposed wording and purpose. Offer edit, decline, view and delete. Establish categories the product will not retain and rules for sensitive reuse.
Compare the alternatives
Make persistent memory specific, inspectable and reversible.
A · Continue without saving
The current conversation does not require durable memory.
B · Review proposed memory
A specific item and purpose can be accepted or declined.
C · Memory library
Saved items remain visible and manageable.
Original wireframe proposals · No live controls · Grey rows represent schematic text, not loading states · Labelled placeholders are not Scripture quotations
Download this wireframe as SVGFailure modes
Inferring denomination or health status; saving everything as personalisation; bundling memory, training and sharing; surprising users with a past loss.
Bible and faith considerations
Religious beliefs and health information can be special-category data. A toggle alone does not establish a lawful processing basis.
What to validate
Test declining, editing, deleting and later reuse. Verify the interface promise against storage, derived profiles, logs and retention processes.
Research-informed design proposal. These visual alternatives have not been tested with users in this atlas. Source findings, documented behaviour and this proposed adaptation are different kinds of evidence.
Sources and adaptation
This card is an original design synthesis. The following sources inform its content distinctions, interaction approach or review requirements; they do not validate the whole pattern.
- Memory Scope TogglePattern detail reviewed · A faith app still needs data governance and lawful processing.
- The Shape of AICatalogue and named entries reviewed · The site states CC BY NC SA. This atlas uses original text and original wireframes; it does not reproduce the source illustrations.
- Design Patterns CatalogueCatalogue and relevant automation entry reviewed · Broader than AI; data-control interfaces must be backed by corresponding storage and permission behaviour.
- Process personal data lawfullyOfficial guidance reviewed · Specific lawful basis, retention and DPIA decisions require the actual data flows.
Common scenarios and flows
- Prepare and participate in an AI-assisted practice — Use bounded adaptation while keeping Scripture, authorship and user choice inspectable.
- Receive prayer support without hidden profiling — Choose useful words or silence while retaining ownership of intentions.
Examples in use
Attributed app evidence with dates and review limits. A screenshot illustrates an implementation; it does not establish that the proposal works for every audience.
Design principles in this decision
Editorial application of Missional by Design. These values frame review questions; they do not validate a pattern’s effectiveness.
- Reverence — What does this interaction ask of the person, and can they understand, decline, correct or leave it without penalty?
Compare alternatives using the task and evidence above. Record competing needs instead of treating a principle as an automatic verdict.
Regional applicability
Design review questions · 5 October 2026. These prompts identify possible triggers; they do not classify this pattern or every faith app as a regulated service.
Where do prayer, religious, health and audio data actually go? Review memory, model-provider access, logs, analytics, training and exports as separate data flows; a private-looking screen is not a data policy.
Start with EU and Germany, then review the relevant market:
- US · Utah: mental-health chatbots — Enacted AI-specific law
- US · Federal health software and data — Existing law; regulator implementation guidance
- United Kingdom — Existing law + regulator guidance; policy statement
- Australia — Existing law + regulator guidance; national policy
- Canada — Existing privacy law + joint regulator principles
Use the jurisdiction decision guide to record the trigger, source version and resulting product requirement.