Pattern 65
Support access accounts for monitored devices
Treat screen traces, notifications and stored disclosures as part of the safety problem.
Concrete takeaway
Offer a quick exit and clearly explain its limits: changing the screen does not erase history, network logs or monitoring.
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 · Exit with honest limits | The person needs to leave the screen quickly | Exit does not erase monitoring or browsing traces |
| B · Control traces | Stored content or notifications could reveal a disclosure | Privacy claims must match actual backend behaviour |
| C · Safe contact choice | Opening a support destination could expose activity | The person decides whether the contact method is safe |
The problem
An abusive person may have access to the user’s device, accounts or notifications. An innocent-looking reminder or saved summary can reveal a disclosure.
The pattern
Offer a quick exit and clearly explain its limits: changing the screen does not erase history, network logs or monitoring. Let users control storage and sharing; a private-looking interface is not proof of privacy. Avoid sensitive notification previews and unsolicited follow-ups. Ask whether it is safe to continue before adding identifying material or opening external services. Do not recommend sudden account or device changes as universally safe; refer to specialist safety guidance. Deletion and no-retention claims must reflect actual server, backup and analytics behaviour.
Compare the alternatives
Treat screen traces, notifications and stored disclosures as part of the safety problem.
A · Exit with honest limits
The screen changes; privacy is not guaranteed.
B · Control traces
The real storage policy is stated before claiming privacy.
C · Safe contact choice
Opening a service remains a deliberate action.
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
A quick exit presented as invisibility; automatic crisis reminders; sensitive lock-screen text; promising deletion while retaining logs; an unsafe device-security checklist.
What to validate
Review with digital-safety specialists. Test shared devices, push previews, account access, browser history, exports, analytics and backend retention. Avoid real survivor disclosures in routine test fixtures.
Sensitive design proposal · Safeguarding review required. 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.
- Ruth AI Chatbot FAQProvider FAQ reviewed on 5 October 2026 · Provider documentation, not independent safety or efficacy evidence; no assumption that another product shares its safeguards.
- Technology-Facilitated AbuseOfficial resource reviewed on 5 October 2026 · US service context; device-specific advice needs specialist review.
- Process personal data lawfullyOfficial guidance reviewed · Specific lawful basis, retention and DPIA decisions require the actual data flows.
Common scenarios and flows
- Respond to a sensitive disclosure with accountable support — Keep disclosure, present safety, user choice and service responsibility distinct.
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?
- Bridge — What does this experience enable beyond the session, and is the next step voluntary, accessible and safe?
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.
Could functionality, marketing or reasonable expectations make this a companion or mental-health service? Define the human role, health claims, escalation capability and locally verified support route before selecting dialogue UI.
Start with EU and Germany, then review the relevant market:
- US · California — Enacted AI-specific law
- US · New York — Enacted AI-specific law
- US · Utah: mental-health chatbots — Enacted AI-specific law
- US · Illinois — Enacted AI-specific therapy restrictions
- US · Texas — Enacted AI-specific law; effective 1 January 2026
- 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
Use the jurisdiction decision guide to record the trigger, source version and resulting product requirement.