How It Works

Response Structure

Responses aren't plain text. Each one is a structured sequence of typed segments rendered differently in the UI:

• Interpretation — third-person commentary on what the theologian believed or taught.
• Quote — direct quoted text, set apart visually, always accompanied by a citation.
• Citation — title, author, work, locator, and URL when available. Tappable for full source detail.
• Limitation — explicit acknowledgement when a question is out of scope or a source can't be found.

Quotes are verified before display through a multi-stage grounding pipeline. If a citation can't be produced, the quote is omitted rather than fabricated.

The Theologians

Each avatar comes with a profile describing their tradition, characteristic reasoning modes, the kinds of questions they engage well, and acknowledged limits. Conversations are bound to a single theologian — switching avatars starts a new conversation so context never bleeds between voices.

• Augustine of Hippo — grace, sin, the City of God, autobiographical reflection.
• Thomas Aquinas — faith and reason, natural theology, scholastic synthesis.
• Martin Luther — justification by faith, scripture, the freedom of a Christian.
• John Calvin — sovereignty, providence, systematic exposition.
• C.S. Lewis — apologetics, suffering, imagination, the moral argument.

Core Invariants

The system enforces five rules server-side. They are non-negotiable:

• Third-person only — the theologian is referenced, not impersonated. Authored text never uses first-person pronouns.
• Quotes always cited — uncitable quotes are dropped, not invented.
• Interpretation and quotes are separated — commentary and quoted text are distinct segments, never mixed in a single block.
• One avatar per conversation — switching theologians starts a new conversation.
• Engine swappability — the LLM provider lives behind an interface; the client and database schema don't change when it does.

Trust Language

User-facing uncertainty is expressed in evidence tiers — well-supported, partially supported, interpretive — not numeric probabilities. The aim is for the interface to be honest about what it does and doesn't know without inventing precision it can't justify.

Stack

• iOS client — SwiftUI, iOS 17+, Supabase Swift SDK.
• Server — Express + TypeScript, Zod validation, Vitest for tests.
• Database — Supabase PostgreSQL with pgvector for semantic search and pgsodium for encryption.
• AI — Google Gemini with grounding via googleSearch, abstracted behind a provider interface so the engine can be swapped without touching the client.