Pattern 34
Notes have a library and an honest save state
Help people find personal work and resolve sync differences.
Concrete takeaway
Provide a library by passage, collection and date.
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 · Personal library | The person searches saved work | Organisation needs more than a chronological stream |
| B · Local save | A save has not yet synced | Local success and server sync are different states |
| C · Resolve a conflict | Two saved versions conflict | Manual comparison costs effort but avoids silent loss |
The problem
A note may be saved locally but not synced. Conflicting edits or deletion can become invisible data loss.
The pattern
Provide a library by passage, collection and date. Distinguish local save from pending sync. Offer undo where feasible and compare conflicting versions instead of silently overwriting them.
Compare the alternatives
Help people find personal work and resolve sync differences.
A · Personal library
Saved work is findable outside the original screen.
B · Local save
Local success and sync are separate states.
C · Resolve a conflict
Both versions remain available for inspection.
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
“Saved” interpreted as safely synced everywhere; losing offline notes; conflict resolution that deletes one version without review.
What to validate
Create a note offline, reconnect and introduce a second edit. Can users find their work and understand each save or conflict state?
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.
- Record your insights using NotesOfficial documentation reviewed · Documentation does not validate all proposed sync or overlap behaviour.
- Pattern CatalogueCatalogue entries and descriptions reviewed · A broad observational design catalogue rather than an exclusively AI or faith resource.
- AI Interaction AtlasOfficial repository and taxonomy reviewed · A taxonomy, not a prescriptive UI framework. The official repository is available at https://github.com/quietloudlab/ai-interaction-atlas under Apache 2.0.
Common scenarios and flows
Use this pattern within a complete journey: define the entry, preserve relevant state, plan recovery and name the endpoint. Explore the scenario library.
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.
- Honesty — Could this interface lead a person to infer more authority, certainty, privacy or human support than the service provides?
- Costliness — Who pays for this convenience through time, labour, privacy, risk or exclusion, and can the organisation support its promise?
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.