Product Domain & Content Model¶

Sources (fetched 2026-06-25): - "What we are building — end of week 4" Notion page (3894dccd9d8b8055a0a9ed38ed43eb88) - "Foundational Architecture" Figma board (3ivmGpow1xs7q9k81ea6OL, node 892-1798 / 578-1345)

One-sentence pitch¶

A reading app for C.S. Lewis's work where every piece is connected to every other piece by shared themes — so you can either follow a curated path (a Journey) or wander the connections yourself (Explore).

App structure (4 screens)¶

Core mechanic¶

The library is a graph, not a list. Every text piece is a node; edges are computed at runtime from shared theme tags. Navigation is deterministic tag-overlap traversal — the "Wikipedia rabbit hole" feeling. No hand-built relations between pieces (except editor hero-pins).

AI drafts tags at ingest; editors QA before publish. Tagging is build-time, not runtime. Tag axes (load-bearing — see 00-constraints.md):

• Themes — category-level moods. Finite controlled vocabulary. Working v1 set (clarified 2026-06-30): Imagination, Joy/Longing, Myth, Grief, Faith, Friendship, Wonder, Reason, Love — 9 themes "for now", may grow before launch. Each theme has bespoke portal imagery + colour scheme; theme pages are taxonomy-driven, not editorially curated per page. Architecture should let editors add themes via the CMS in v2 even if the v1 set is fixed. (Earlier "~19" from the IA stand-up was a rough guess; this 9-theme list supersedes it as the current working set, still pre-launch.)
• Motifs — fine-grained tags that cut across works; powers the surprise jumps
• Life stage — single tag per piece (youth → grief)
• Register — bedtime | morning | anytime
• Tone depth — meaning (default) | theological (opt-in)

How content connects — two mechanisms, kept visually distinct¶

1. Tag-overlap (computed) — deterministic. Two pieces are related because their tag axes overlap. Powers Explore and the "related content" surface. Two flavors:
2. Further in — same thematic thread, going deeper
3. Connects across — same theme in a different work or format
4. Editorial curation (hand-arranged) — a human editor picks specific pieces and orders them into a Journey's chapters.

The same piece can sit in both at once. The UI must never make them look like the same kind of "next."

Sequencing flag (IA stand-up 2026-06-30): the team called "related content" a gap and deprioritized it for now. This is in tension with the graph being the stated core mechanic — it most likely means the related-content surface/UI is deferred within v1, not that the tag-overlap engine is cut. Whether the graph engine itself stays in the v1 build is unresolved — see flags / 05-feature-backlog.md.

Content types — only three¶

The product model collapses passages/letters/essays into one text-piece type distinguished by tags. The CMS still has separate Passage and Article collections today (see docs/cms-architecture.md) — that is an implementation-level split worth revisiting if the unified-type vision holds.

Open decision (live): Lina's CMS Content Model pre-read keeps Passage / Letter / Essay / Podcast as separate collections (field-level reasons: plain vs rich text for audio sync, Letter recipient/date, Essay author/Substack). The data-model call (2026-06-29) leaned the other way — a Passage with a content-type field (letter / poem / nonfiction), i.e. a discriminator on one type. Unresolved; see the data-model plan draft (docs/design/data-model-plan.html) for the proposed synthesis (separate storage + a uniform Content Item traversal interface).

Unified-attributes signal (IA stand-up 2026-06-30): the team described every content piece as sharing the same spine — topic tags, theme tags, a "thought provoker" question, bookmarking, and reflections. That leans toward the unified text-piece view above (uniform interface across types), with passage/quote as the core product unit. Per-type specifics from the stand-up: Essays are ingested from Substack (featurable on Home or in Journeys); Letters are a subtype of Lewis's works whose in-app inclusion needs client confirmation (see flags); Books are source-reference only in v1 (no e-reader — cover, synopsis, publication date, future Amazon CTA); Podcasts are a later phase.

1. Text piece — one unified type - Two key tag axes: - Provenance — evergreen (Lewis's existing corpus: letters, passages; fixed, rights-cleared) vs editorial (produced into the CMS — Substack essays now, commissioned work later) - Format — passage / letter / essay / etc. - A "passage" is just a short evergreen Lewis text; nothing is structurally reserved to it. Reflections, graph links, voice clone, and deeper meaning all apply to any text piece.

2. Podcast — separate type - Audio forces a different shape: embed link + duration + transcript. Cross-cutting rather than theme-siloed. Embedded, not CMS-hosted.

3. Journey / Portal — editorial container (not user-generated content) - Same object, two faces: Portal is the doorway, Journey is the experience inside. Model as one thing. - Holds references to text pieces plus its own metadata: name, copy, colour, icon, portal shape (from a preset list), opening + reflection questions, featured flag. - Chapter slots point at pieces — they do not hold their own copy. - Journey detail page (IA stand-up 2026-06-30): title, overview, chapter list, and length. Chapters are ordered reading lists; any content type can appear in a chapter. - A user can have multiple journeys in progress simultaneously; progress is gated behind account creation (an account is what persists journey state).

Portal metaphor clarified (call 2026-06-29): the "portal" is the entry animation — splash animates through a door into a master homepage, which is the first touchpoint and is not theme-filtered (curated content + journeys + a top passage). Themes are mood/thematic filters; switching a Theme recolors the whole UI. Journeys are curated reading lists/courses that can span multiple Themes. (This nuances the older "Portal = Journey doorway" framing and the Lina-model "Theme = world"; reconcile in the data-model plan.)

Things that attach to a text piece (not content types of their own)¶

API surfaces (MVP)¶

The app surfaces the backend must feed: heroed Journey + carousels (Home), graph traversal + search (Explore), source ladder (passage → chapter audio → book link), community reflections (ambient counts), saved items, and the Soul Map (Profile). Full screen flow lives in the Notion mobile spec / Figma.

Key terms (use consistently)¶