> ## Documentation Index > Fetch the complete documentation index at: https://docs.thefaithapp.com/llms.txt > Use this file to discover all available pages before exploring further. # Privacy, safety, and current scope > Understand who can see Discipleship data, how publishing protects learners, and which capabilities are intentionally partial. # Privacy, safety, and current scope Discipleship is designed around a simple boundary: > The church may provide structure, teaching, and support without turning the > admin dashboard into a window onto a member's private spiritual life. This page should be part of staff onboarding—not only a technical reference. ## What staff can see Authorized staff can see information needed to run a shared ministry workflow: * Pathway enrollment, required lesson progress, quiz outcome, and completion. * Published-version history and certificates. * Mentor pairings and check-ins that are explicitly shared with both people. * A gifts result only when the member shares that specific result with their assigned mentor. * Anonymous or aggregate participation where a practice explicitly provides it, such as a fast participant total. * A Wall of Tears author's identity only when the author requested pastoral follow-up. ## What remains member-private Staff cannot inspect: * Personal goal wording, updates, or private progress reflections. * General or class-linked private journal entries. * Gifts instrument answers or unshared results. * Rule of Life drafts, covenants, commitments, or closing reflections. * Daily Office bell preferences, identities, or attendance history. * Guided Examen responses or participation. * Fast choices, health reasons, or daily check-ins. * Private writing composed inside a lament liturgy. * Church Calendar participation or completion. * Rest participation history. * Promise Ledger items, notes, due counts, or review activity. ## Visibility matrix | Experience | Church configures | Staff may review | Member-private data | | ------------------- | ----------------------------------------- | ---------------------------------------------- | ------------------------------ | | Pathway | Content, quizzes, enrollment, certificate | Enrollment and learning progress | Private journal reflection | | Mentorship | Program and shared prompt | Shared check-ins within authorization | Separate goals and journal | | Personal goals | Optional templates | Templates only | Goal, updates, reflections | | Gifts and serving | Instrument and skill mapping | Deliberately shared result only | Answers and default result | | Rule of Life | Seasonal template | Template only | Covenant and commitments | | Daily Office | Plan, hours, liturgy | No identities or attendance | Bell choices and participation | | Guided Examen | Template and deletion window | No responses or activity | Full session until deletion | | Congregational fast | Campaign and daily guide | Aggregate participant count | Choice and check-ins | | Lament | Liturgy and wall moderation | Moderated offering; identity only with consent | In-liturgy private writing | | Church Calendar | Seasons and practices | No member activity | No activity record is created | | Sabbath and Retreat | Guides | No participation analytics | Current private rest window | | Promise Ledger | Invitation and interval | Invitation only | Items, notes, and reviews | ## Privacy-aware staff habits * Explain whether a field is shared before a person writes in it. * Do not ask members to copy private journal content into a shared check-in. * Do not use quiz scores as a measure of spiritual maturity. * Do not widen staff permissions to solve a convenience problem. * Do not export, screenshot, or copy sensitive formation content into another system. * Use the dedicated pastoral-care workflow for confidential care—not a mentorship check-in. * Treat anonymous totals as ministry context, not evidence about individuals. ## Publishing and version safety Publishing a pathway or gifts instrument creates an immutable version. Learners and results remain attached to the version they began. Later edits create a new version instead of silently changing past or in-progress data. This protects: * The questions and answers used in a quiz attempt. * The curriculum a learner was asked to complete. * The certificate wording issued at completion. * The questions and scoring behind a gifts result. ## Deletion and retention behavior | Data | What happens | | --------------------- | ------------------------------------------------------------------------------------------------------- | | Private journal | Member may permanently delete an entry | | Guided Examen | Member may delete early; otherwise the complete session is permanently deleted at the configured expiry | | Fast participation | Leaving permanently removes that participation record | | Wall of Tears | Member may delete early; remaining offerings are permanently deleted on the fixed schedule | | Rest window | Ended and expired windows are removed | | Promise Ledger review | Removed when the original commitment is no longer current | | Certificate | Revocation preserves the audit record but invalidates public verification and download | ## Current partial or dependent capabilities These boundaries are visible in the product so staff do not promise behavior that does not exist yet: * **Sabbath and Retreat notification protection is partial.** Church-wide broadcast-topic notifications are muted, but direct chat, care, prayer-room, volunteer, and other token-targeted alerts are not. * **Clergy-device rest enforcement is partial.** It depends on a signed-in staff mobile identity and unified notification preferences. * **Lay-volunteer mentor eligibility is dependent.** It needs an appropriate vetting and safeguarding workflow. * **Cohort-linked journals are dependent.** Class-linked private reflections work now; a dedicated Discipleship cohort workflow does not yet exist. “Partial” means the documented working portion can be used now, but the full intended behavior depends on another feature. “Dependent” means the product does not present that capability as available yet. ## Public API availability Discipleship currently runs through TheFaithApp's first-party admin dashboard and member apps. It is not yet included in the supported public partner `v1` API. Do not build third-party integrations against admin or internal mobile routes. They are private implementation surfaces and may change without partner API versioning guarantees. Read [Discipleship API availability](/api-reference/discipleship) for the public integration boundary. ## Staff launch checklist * Staff understand the difference between shared mentorship and private formation. * Permissions match real ministry responsibilities. * Published content and correct answers have been reviewed. * Members receive an honest privacy explanation. * Staff know which data is intentionally unavailable to them. * Partial capabilities are described accurately. * A support and safeguarding path exists for members who need help.