Church Abandoned privacy notice
Version CA-PRIVACY-2026-10-17-v3
Who operates the app
Church Abandoned operates this app for the church’s use. Soli Deo Software handles app support and privacy inquiries at support@solideosoftware.com. Church Administration handles chat-abuse reports through the administration dashboard. This notice covers the app and its supporting services; the SDS website has a separate privacy notice.
Church parent-rights contact: Church Abandoned, Mountain View Elementary School, 145 Co Rd 627, Etowah, TN 37331; (423) 404-1772; ChurchAbandoned@ChurchAbdanoned.org. Church Administration handles authenticated requests for the child’s records, consent copies, withdrawal and deletion. Do not email consent records to SDS.
Information and purposes
Accounts and church activities. Firebase Authentication handles sign-in credentials. The service uses email, account identifier, names, verification status, birthday and derived age/permission information for access. Family features hold links, relationships, invitations and names of relatives without accounts. Group membership and event registrations identify participants. Attendance tools record counts and optional notes that may identify people. Church involvement can reveal religious affiliation. Adding a relative or a “Guardian” label does not verify parental authority.
Chats and files. The service processes submitted messages, sender information, room membership, timestamps, read/unread state and uploaded photos/PDFs. Conversation participants and authorized dashboard readers can access content according to their permissions; dashboard access may extend beyond individual room membership. Recipients may save or share copies outside the app. Do not treat chat as confidential pastoral counseling.
Notifications. Device notification tokens and preferences support alerts. Apple APNs or Google FCM processes tokens and notification payloads. Device settings and preview preferences affect what appears in notifications.
Problem reports. A manually submitted report contains your description and diagnostic information such as app/build/platform/OS, attempted device model, display/locale/timezone, permission/grant information and bounded screen/request/error history. A hashed account reference remains linkable. Redaction does not remove everything you might type. Do not include private chat content, consent forms, passwords or identity documents. Diagnostic report access is restricted to Developer users. In the upcoming mobile update, failed chat requests also trigger automatic sanitized technical reports for troubleshooting, at most once per user per hour, through the same problem-report service and subject to its existing limits. These automatic reports exclude message and file contents and raw exception text. They are separate from manually submitted reports and moderation decision metadata. This feature requires the new mobile build and is not yet released.
Providers and external features
Google Firebase Authentication, Firestore and Cloud Functions support accounts and backend processing; chat files use private Google Cloud Storage. The administration dashboard at caappadmin.org uses Firebase App Hosting. The SDS policy website is hosted on GitHub Pages; its security logging is covered by the separate website notice. Ordinary support/privacy email uses Zoho. The app uses Resend to deliver generic administrative alerts with protected-dashboard links. Alerts contain no report, chat or consent content. Recipients follow current permissions and notification preferences; problem-report alerts go only to actual Developer-group members. Resend processes recipient addresses and delivery metadata. Local quota metadata can remain up to31days; Resend’s own retention remains to be verified. Email acceptance does not guarantee inbox delivery.
YouTube players connect to YouTube inside the app. Giving opens the church’s Church Center destination; the inspected app does not collect payment-card details. Map/social/scripture links connect to their destination services. Backend scripture and administrator sermon-analysis features include Crossway ESV and Google Gemini integrations.
Automated chat safety screening. Automated screening is enabled for the beta. The church uses Qwen software hosted privately on Google Cloud Run to check submitted or edited text and captions, together with up to six recent messages from the same room that the sender can access. Removed, expired or inaccessible context is excluded; edits do not use later messages. This checks text and captions, not the contents of image, video or other binary attachments. Chat moderation does not send messages to OpenAI or a hosted Qwen or Hugging Face inference service.
Automated decisions can be wrong. A blocked message is not delivered and creates a restricted moderation incident for authorized administrator review. Five distinct blocked messages within 30 minutes restrict chat until an authorized administrator lifts the restriction. You can request review through the app. A model decision is not a finding that a person has confirmed abuse. A request for review is not automatically a block or strike. Checking failures, timeouts or inputs exceeding the model’s limit preserve the draft and do not count as violations. Older beta versions may require an update before sending.
The model uses in-memory prefix caching to reuse matching portions of its input. Saved whole-prompt and response caches are disabled; model requests are not written to disk or copied into the inference service’s application logs. This does not mean request-derived state is immediately erased from memory. Google infrastructure request, startup and audit metadata have separate retention rules. Restricted moderation incident records and debugging metadata are described below.
Optional safety-rule improvement. This optional feature requires a compatible app release with the choice and Settings control, and enabled service safeguards. Availability may vary by app version. Until those controls are available and you explicitly opt in, your messages are excluded. The following rules apply when the feature is available. Adults whose age is verified as 18 or older may separately choose to help improve chat safety rules. With their permission, we use eligible review-decision categories from messages confirmed to have been incorrectly blocked to select proposed changes from fixed rules and temporarily read eligible reviewed messages to test those rules. Only messages written while the author was an adult and after their current permission took effect qualify. A false-positive review does not itself give permission. Declining or withdrawing does not affect ordinary chat access, safety screening or review requests.
Messages from anyone under 18, anyone whose age cannot be confirmed, and anyone without current permission are excluded. We also exclude messages containing identifiable information about children or other people, including identifiable quotations and private details. We exclude all surrounding conversation from this optional process. If a message cannot be evaluated fairly on its own, we exclude the case.
This work runs on the church's existing private Google infrastructure. We do not train model weights on members' messages, send them to OpenAI or an external training service, or put message text or private review details into saved rules or test datasets. We also use fictional tests. An authorized administrator must approve a tested change before it affects live screening; the system does not automatically learn or change live rules from reviews.
You can turn off optional improvement use in your account settings or contact Church Administration using the details in this notice. We stop further optional use and remove source-linked improvement records through our deletion process. General rules and results that cannot identify anyone may remain within the schedules below. Ordinary safety screening and incident review continue under their separate purposes.
Retention and deletion
Active chat messages and attached photos/PDFs have a server-side 90-day retention rule measured from original message creation. Access ends at the cutoff; physical cleanup runs asynchronously and may retry. Rooms and memberships are preserved. For eligible messages still unexpired when an event/standalone room is archived, the separate archive window runs for 90 days from archival; already-expired content cannot revive. This is not a universal 90-day maximum across archived records.
Restricted automated-moderation incidents, including blocked text and decision information needed for administrator review, follow the separate approved 90-day incident schedule. After incident text and details expire, minimal room/restriction associations can remain so an authorized administrator can review and lift an existing restriction; this does not extend retention of the expired text. Moderation debugging metadata is available for 30 days and then expires into cleanup. It records message/room references, edit versions, model decisions, timing and error/status information, without copying message or conversation bodies into those debugging records or general logs. These references can remain linkable to source records. Developer access to debugging metadata does not by itself authorize access to chat content: viewing original text or context also requires the applicable review permissions and remains subject to source retention, removal and edit-version checks. The 30-day debugging period does not extend the source content’s retention. User-filed abuse-report evidence has a separate 90-day-from-report schedule. Problem reports have a 30-day availability cutoff and scheduled cleanup. Manually saved pending report attempts expire on access after seven days. In the upcoming mobile update, automatic chat-error reports use a separate secure on-device retry queue with a 24-hour delivery window. Delivery is attempted immediately and retried after a later successful chat request; expired queued reports are discarded when the queue is next checked, rather than guaranteed to be physically erased at exactly 24 hours. The inventoried global cloud-log buckets have 30-day and 400-day retention settings. These provider and administrative metadata schedules are separate from application-content schedules. Active profiles, family/membership/registration/attendance records do not have a universal age-based expiry established by the audit.
Account deletion locks access and initiates resumable cleanup of account/profile, membership/family links, registrations, device/notification records, owned files and associated reports. Other people’s shared records can remain. Own messages are removed or reduced to technical remnants as the applicable cleanup runs. A nonidentifying completion receipt lasts 30 days. Cleanup is not guaranteed to finish in one worker interval, and cannot erase recipients’ exports or screenshots.
Optional improvement does not restart a message or incident's retention period. Source-linked improvement records expire no later than 30 days after first selection and earlier if the source expires, is deleted, permission is withdrawn, or eligibility ends. Candidate and evaluation records have a maximum 30-day period from creation, shortened by applicable source deadlines. We stop access at the cutoff and remove records through scheduled cleanup. We do not keep copied message text, private review details or message embeddings for improvement.
We keep your current optional-use preference and the version and time of that choice while needed to honor it for your account. Turning the feature off keeps it off; it does not extend retention or use of messages. Account deletion removes the preference through the account-deletion process. Temporary withdrawal markers expire after 30 days; their expiry does not change your choice or permit reuse. Approved general rules and minimal administrator approval records may remain while active or needed for a designated rollback version; we remove them within 30 days after that need ends. Retained aggregate results must not identify or single out members and follow the corresponding candidate or active-rule schedule. We do not promise immediate physical erasure from every system.
Children and parents
New child activation is currently disabled. The completed process is for children under 13; people13 and older use ordinary signup. Disabled activation does not mean the service has no family or other information about children.
The versioned parent notice describes the future verified-consent flow. The parent links the pairing request, reads and signs the notice using a verified adult account and supplies a separate required phone for verification. An authorized church leader independently confirms the known parent's identity, authority and specific consent. The phone is removed from the verification contact record at the decision; it is not a recovery phone. The signed notice, signature and version remain intact. Approval and account creation must pass the configured gates.
After verified consent, the parent provides the child's first and last name, birthday and a separate username/password. Account identifiers, private credential verification, parent/family links and security/session information support authentication, age rules and recovery. This is not a child-only core account: ordinary permissions can include family/profile management, group/event participation and chat messages; room membership limits readership and attachment upload needs extra permissions. YouTube and external links currently have no child-specific exclusion. Enabling the parent flow does not substitute for a versioned parent notice and verified consent covering the automated chat safety screening described here. Historical signatures retain their original scope.
Consent to account use does not authorize every optional disclosure. Separate parental consent is required for a disclosure that is not integral to the requested service; it must be supported and enforced before that disclosure occurs, or the disclosure must remain unavailable. The current one-assent interface does not implement separate choices.
Unlinked requests expire24hours from original creation; linked unfinished requests, including unused approvals, expire30days from original first linking. Recovery, replacement QR codes and activity do not reset those clocks. Necessary signed consent/verification evidence remains while the under-13 account relies on it. On withdrawal, deletion or the actual13thbirthday, keep only necessary minimal evidence for up to90days from original closure, with valid earlier deletion. The limit does not extend retention of child content. Access expiry and bounded physical cleanup are distinct.
At13, consent reliance ends independently of parent management. Parent reset/suspend/delete authority continues only until the account holder is also server-verified as owning their recovery email. It then ends even if password setup was skipped; verified-email password recovery is available as the fallback. Removing the email later never restores parent authority. Suspended, withdrawn or deleted accounts do not reactivate through this transition. A separate minimal live recovery link never extends closed-consent retention.
Parents can request review of their child's information, a copy of the consent record, refusal of further collection/use and deletion through the church contact above. The church must authenticate the request before securely providing information.
Contact and changes
Soli Deo Software handles ordinary app support/privacy inquiries at support@solideosoftware.com. Do not email consent forms or verification records to SDS. Use the Church Administration contact above for authenticated child-record and parent-rights requests. We will post revisions to this notice and update its effective date.