Skip to content

Domain Model

Core entities and rules for study, habits, and curriculum. API shapes should follow this document.

Use these terms consistently in product copy, planning docs, and user-facing API descriptions. Do not call a long-term study a “study session.”

TermMeaning
StudyThe main long-term object. Has a study method (type) and focus. Ends when the method’s criteria are complete—not after a fixed clock time.
Study sessionA short-term, mostly virtual period when the user is actively studying (often ~1 hour). Notes are optional. Later, meetings (mentorship) are one form of study session. Ideally triggers focus mode on the device. Not the same as a Study row.
Log entryA discrete record that study happened (summary, logged_at)—not a note. Often linked to a study; may stand alone (daytime meditation, sermon capture). Drives habits and streaks. A log entry does not require a note.
NoteOptional structured journaling (rich text envelope body, CRDT sync). May link to a study and/or log entry. Use when rich text is worth syncing; use a log entry when you only need to record activity.
Study (long-term)
└── many Study steps (plan snapshot; workflow only)
└── many Log entries (optional link)
└── many Notes (optional link)
Study session (active period, v1+)
└── optional link to one Study
└── may include Log entries and/or Notes (neither required)
Log entry
└── optional study_id (active study session link when modeled)
Note
└── optional study_id, optional study_log_entry_id

ER diagrams and migration-backed table detail: Developer architecture → Database schema.

ConceptTableGraphQL type
StudystudiesStudy
Study stepstudy_stepsStudyStep
MentorshipmentorshipsMentorship
Plan template (admin)study_plan_templatesStudyPlanTemplate
Log entrystudy_log_entriesStudyLogEntry
NotenotesNote
Study session (active period)Not stored yet

On a Study row:

  • study_method and focus — set at create; immutable except hypothetical focus may be edited.
  • started_at — when the study was opened (not a short “session” timer).
  • ended_at — when the study is marked complete (method criteria met), not end of a single sitting.
  • plan_template_id / plan_applied_at — which template was snapshotted at create (audit only; steps hold the live workflow).
  • track_id — set when the study is assigned from a mentorship track; null for ad-hoc studies.
  • satisfies_plan_template_id — for skip/noop track studies, points at the real plan module that was satisfied or skipped.
  • mentorship_id / participation_mode — mentored vs individual study; see Mentorship.

Study steps are copied from study plan templates at create. Completing a study cancels open steps; journals and log entries remain authoritative content.

Log entry vs note: a log entry records that study happened; a note holds optional long-form content. They can be linked (notes.study_log_entry_id) but are separate rows—create a log entry without a note for streaks and quick capture.

  • Platform-defined methods in v1: book, topical, word, hypothetical, character, guided, mentorship — see Study Methods. The mentorship method is used for intro pairing and checkup plans (Mentorship).
  • Each study stores study_method plus a single focus string (method-specific payload).
  • Guided studies reference a published study_plan_templates row by id in focus; templates declare one or more spiritualPhases via pivot (see Study Plans).
  • Method minimum level for the new-study UI lives in client config, not on the study row.
  • Users can suggest new templates (workflow TBD).
  • Note templates and fields depend on study method.

Study session (product, not yet in schema)

Section titled “Study session (product, not yet in schema)”
  • Represents “I am studying now” — distraction-free / focus mode when available.
  • May overlap multiple log entries and notes in one sitting.
  • Meetings (mentorship) will be a study-session subtype later.
  • v1: users study and log without a first-class session record; client may infer “active study” locally until the API exists.
  • Brief activity records (summary, logged_at); not notes.
  • May link to a study (study_id).
  • May exist with no study and no study session — e.g. daytime meditation, sermon notes, quick catch-up.
  • Streaks: a calendar study day counts when the user creates at least one log entry (Motivation).
  • Stored as the rich text envelope JSON string in the database; legacy markdown is migrated on read.
  • Body sync: CRDT document per note (Sync and Offline).
  • Structure varies by study method (e.g. OIA fields for some templates).
  • Optional links to a study and/or log entry; authoring often happens during a study session but notes are not required for a session to “count.”

Garrison Bible Study replaces external note tools (e.g. OneNote) for study journaling where structured notes fit; log entries cover lightweight activity and off-study capture.

Persist:

  • Book / chapter / verse ranges in a shortened, delimited format.
  • UI resolves to Logos or self-hosted reader per user preference.

Do not persist verse text snapshots in v1.

  • Global enum: milk → transition → meat (onboarding defaults), plus strong_meat, feast, and graduated for post-core specialization tracks (Tracks).
  • Initial assignment: self-assessment during onboarding.
  • Fields: spiritual_phase, date_of_birth, guardian_minor_links, is_minor (login block for young dependents), minor_account_type (guardian-set); content flagged adult_only (hidden from users under age of majority per DOB). See Identity and Access.
  • Tracks group ordered study plan templates per phase (hourglass: many in milk, fewer through meat, fan-out in higher phases). Phase is the only programmatic prerequisite in v1; funnel vs specialization is descriptive (tags/description), not a stored kind.

Ordered admin-defined tracks group published study plan templates in module order (required/skippable plans and elective groups). Funnel vs specialization is not a stored field — use tags and description (e.g. tag slugs funnel, specialization). Mentors assign tracks to active mentorships (mentorships.track_id); progress is inferred from track-linked studies. Full model: Tracks.

  • Streak counts when user makes a log entry for any study activity.
  • Server authoritative; cached offline on mobile for display.
  • Custom DB flags with polymorphic relations to users, groups, and churches.
  • Gradual rollout per target type.