lumen

LUMEN — Master Build Prompt for Claude Code

One-line pitch: Lumen is the operating system for a 1.4-billion-person, 220,000-parish global Church entering the AI age — built to make every site more human, every dollar of charity more traceable, every encounter with faith less friction-laden, and every parish more alive.

Working name: LUMEN (from Lumen Gentium, Vatican II’s Dogmatic Constitution on the Church — meaning “light of the nations”). Theologically deep, secularly readable as light, and ownable as a brand. Keep it unless you have a clearly better idea.


0. How to read this document

You are Claude Code. The human who handed this to you is a co-founder, not a junior PM. They expect:

Order of operations:

  1. Read this whole file once.
  2. Confirm the stack and folder layout in §6 — propose changes only if you have a strong reason.
  3. Build Phase 1 (§9) end-to-end before touching Phase 2.
  4. Stop and ask the co-founder when you hit any of the Hard Stops in §11.

1. Mission

The Catholic Church is the largest charitable, educational, and medical network humanity has ever assembled — over 220,000 parishes, ~5,500 dioceses, 140,000+ schools, 5,000+ hospitals, and Caritas/CRS field operations in nearly every country. Its operational backbone, however, is largely 19th-century: paper records, single-pastor bottlenecks, opaque finances, language barriers between Rome and the Global South, and a generational gap with the people it most wants to reach.

Lumen is the layer that takes this existing physical, human, and spiritual infrastructure and makes it legible, efficient, and welcoming in a way that draws people back through the doors — not by replacing what is sacred, but by removing every avoidable friction between a person and the encounters that matter: prayer, sacrament, community, service, formation.

We are building three products in one platform, sharing a single data model and value system:

Each layer is useful alone. Together they form a flywheel: parishioners surface needs → parishes coordinate response → dioceses reallocate resources → charity outcomes loop back to parishioners as visible impact, deepening trust and participation.


2. Founding principles (these are non-negotiable; everything else is implementation detail)

These principles double as our north star and our quiet, structural answer to the Church’s hardest critiques. Don’t put them on a banner; embed them so deeply in the product that no one has to.

  1. Subsidiarity by design. Decisions, data, and money default to the lowest level capable of handling them — parish over diocese, diocese over conference, conference over Rome. AI surfaces options; humans decide. (Catholic Social Teaching, Quadragesimo Anno §79.)

  2. The sacrament is never the software. Lumen prepares you for confession, finds you a priest, helps with examination of conscience — it does not, will not, ever simulate the sacrament. Same for Eucharist, anointing, marriage, and ordination. AI lives in preparation and follow-through, not in the encounter itself.

  3. Radical financial transparency. Every dollar of charitable donation is traceable to a specific outcome, parish, and timestamp. Default to public ledger view; private only on explicit user choice. This is the structural answer to historical financial opacity — never argued, just demonstrated.

  4. Safeguarding as foundation, not feature. All adult-minor interactions through Lumen are logged, auditable, and gated by verified safe-environment certifications. Build this in from commit #1, not bolted on. This is the structural answer to the abuse crisis — never argued, just demonstrated.

  5. Global South parity, not condescension. Multilingual from day one (Latin liturgical, English, Spanish, Portuguese, French, Tagalog, Igbo, Swahili, Vietnamese, Arabic, Mandarin, Polish at minimum). Bandwidth-aware: every screen must work on a 3G phone in rural Nigeria. African and Asian dioceses are first-class users, not pilots.

  6. Open infrastructure. Lumen’s protocols (parish vitality index, charity-flow schema, multilingual liturgy data) are publishable open standards. Other denominations and faiths can build on them. We are not building a moat; we are building a road.

  7. Privacy as sacred trust. Sacramental records, confession scheduling, pastoral counseling — anything touching the conscience — receives end-to-end encryption and zero-knowledge architecture. The system itself cannot read what a priest cannot share.

  8. Reverence in the interface. No gamification of prayer. No streaks for confession. No leaderboards for charity. Beauty, silence, and restraint in design — the opposite of the attention economy. Inspirations: traditional missal typography, the white space of a chapel, Rams’ “less but better.”

  9. Honest about the past, focused on the future. When users ask about historical harm — colonialism in mission lands, abuse cases, financial scandals — Lumen answers truthfully with sourced facts and links to acknowledgments by the Church itself (e.g., John Paul II’s Tertio Millennio Adveniente apologies, the 2022 Canadian Indigenous apology). No spin. No defensiveness. No foregrounding either — just available, when asked.


3. The three-layer architecture

3a. Lumen / Faithful (consumer app)

Job-to-be-done: “I want to live my faith more fully, with less friction, in community, today.”

Primary surfaces:

Kahneman applications (do not mention in UI):

3b. Lumen / Parish (priest + staff app)

Job-to-be-done: “Give me back the 15 hours/week I lose to admin and bottlenecks so I can be a pastor, not a paperwork-priest.”

Primary surfaces:

The hard rule: every screen has a “Talk to a human” button that pages the right person (DRE, deacon, social worker, lawyer, accountant) — Lumen never lets a parishioner fall into an AI loop.

3c. Lumen / Diocese (leadership dashboard)

Job-to-be-done: “Show me where my diocese is alive, where it’s dying, where the money is needed, and where I should put my next priest.”

Primary surfaces:


4. The AI thesis (don’t be vapid here)

“AI for the Church” can mean nothing or everything. Be specific.

Where AI does serious work:

Where AI must not go:


5. Tech stack

Default to this unless you have a specific reason to change:

Monorepo: pnpm workspaces, Turborepo.


6. Project structure (build this exact tree first)

lumen/
├── apps/
│   ├── faithful/                 # Next.js — consumer
│   ├── parish/                   # Next.js — priest/staff
│   ├── diocese/                  # Next.js — bishop/chancery
│   └── api/                      # Hono on Cloudflare Workers
├── packages/
│   ├── ui/                       # shadcn-based shared design system
│   ├── liturgy/                  # liturgical calendar engine
│   ├── catechism-rag/            # doctrinal corpus + retrieval
│   ├── charity-graph/            # donor → need → outcome graph
│   ├── vitality/                 # parish vitality index calculation
│   ├── i18n/                     # all locale files
│   ├── schema/                   # shared TypeScript types + Zod
│   └── auth/                     # shared auth helpers
├── infra/
│   └── cloudflare/               # wrangler configs, D1 migrations
├── docs/
│   ├── PRINCIPLES.md             # copy §2 here verbatim
│   ├── ARCHITECTURE.md
│   ├── AI_GUARDRAILS.md          # the "must not go" list from §4
│   └── ROADMAP.md
└── README.md

7. Design system


8. Data model (sketch — refine in packages/schema)

Core entities:


9. Phase 1 (the MVP — ship this in 8–10 weeks)

Build one parish end-to-end before you build the platform. Pick a real one (or simulate one with realistic data). Get these working:

Faithful app — Phase 1:

Parish app — Phase 1:

Diocese app — Phase 1:

Shared:


10. Phase 2 and beyond (don’t build until Phase 1 is real)


11. Premortem — failure modes to design against

Before building, internalize how this dies. Each is paired with the design response.

Failure mode Design response
“AI for Church” feels gimmicky / tech-bro Reverence in interface (§7). Restraint. No streaks, no badges, no leaderboards.
Theological errors in AI output Strict RAG with citation enforcement; refuses to opine outside Magisterium. AI_GUARDRAILS.md is a hard gate.
Substitutes for sacrament Principle #2 baked into UX copy and code-level guards. AI literally refuses to “absolve” or “consecrate.”
Used as surveillance tool by bad pastor Pastoral CRM access logs visible to the parishioner. Parishioner can see who looked at their record.
Used as PR cover for unaddressed harm Threshold module is honest and sourced. Principle #9.
Global South treated as afterthought Multilingual + bandwidth-aware from commit #1. Lagos and Manila are first-class.
Diocesan IT can’t deploy / integrate Cloud-first, no on-prem requirement. ParishSOFT / Pushpay / Realm import adapters in Phase 1.
Bishop blocks adoption out of caution Subsidiarity by design — every feature can be turned off at the parish or diocesan level.
Vatican concerns about doctrine Citation enforcement; doctrinal advisory board (real theologians, not just clergy) wired into release process.
Privacy breach involving sacramental data End-to-end encryption; zero-knowledge architecture; the system itself cannot read confession-prep content.
Charity flows revealed to be inefficient Good. Transparency is the product. We surface it, others fix it, and the credibility of the whole network rises.
Looks too Catholic for the curious / lapsed Threshold module is the front door, no login, secular-readable, sourced and calm.

12. Hard stops — when to ask the co-founder before proceeding

Don’t decide these alone. Stop and ask.

  1. Anything that touches sacrament logic or wording.
  2. Anything that involves money flow (donations, fees, refunds, payment processors).
  3. Choosing the doctrinal advisory board / theologian reviewers.
  4. The first pilot parish and diocese.
  5. Partnership outreach to Caritas, CRS, or any bishops’ conference.
  6. Any change to the founding principles in §2.
  7. Any feature that involves minors beyond the safe-environment gate already specified.
  8. Branding and name (LUMEN is the working name — confirm before logo/domain).
  9. The Threshold module’s specific answers to historically-loaded questions — every answer reviewed before ship.
  10. AI behavior on edge cases: suicidality, abuse disclosure, addiction, marital crisis. We need crisis-resource routing, not AI counseling.

13. Acceptance criteria for Phase 1

Phase 1 is shippable when:


14. First commands when you start

# Initialize the monorepo
pnpm init
pnpm dlx create-turbo@latest

# Scaffold the three apps and the api
pnpm dlx create-next-app@latest apps/faithful --typescript --tailwind --app
pnpm dlx create-next-app@latest apps/parish   --typescript --tailwind --app
pnpm dlx create-next-app@latest apps/diocese  --typescript --tailwind --app
mkdir -p apps/api && cd apps/api && pnpm init && pnpm add hono

# Drop §2 Principles into docs/PRINCIPLES.md verbatim
# Drop §4 "must not go" list into docs/AI_GUARDRAILS.md verbatim
# Drop this whole file into docs/MASTER_PROMPT.md for future sessions

# Then: build the Faithful Now screen first. It's the single best demo surface.

Build the Now screen first. If it lands — calm, reverent, useful at 6:42am Wednesday of Holy Week — the rest of the platform falls into place behind it.


15. One final note from the co-founder

We’re not building a “Catholic app.” We’re building the operational nervous system of the most-distributed charitable network in human history, at the moment when AI makes that network legible to itself for the first time. The product that does this well doesn’t shout. It quietly removes friction between people and the things that give their lives meaning.

If you do this right, in five years there’s a kid in Lagos whose family found Lumen because of a Caritas food appeal, who used Threshold to ask honest questions, who’s now in a parish small group, who never feels the seams of the technology that brought him there. That’s the win. That’s the only win.

Build accordingly.