At a glance
wordsofplainness.org is a static-first site with a thin dynamic edge. Every page is pre-rendered by Eleventy (Nunjucks templates over Markdown and structured data) and served as plain HTML from Vercel's CDN. Heavy media lives separately on Cloudflare R2 behind its own subdomain. The few things that must be dynamic—sign-in, a personal discipleship journal, newsletter and contact forms—talk to a small Django REST API on PythonAnywhere, and a handful of Vercel serverless functions handle automation such as social notifications. There is no front-end framework, no database behind the pages themselves, and no tracking scripts: a visitor's browser loads the site's own HTML, CSS and vanilla JavaScript, one Google Fonts stylesheet, and audio from the media CDN.
The interesting engineering is less in the stack than in what the build does with it: build-time cross-referencing between book chapters and the Articles of Interfaith Discipleship, narration audio that highlights the text as it is read, song lyrics synced line-by-line to the music, a citation apparatus with over a thousand scripture links, all generated from the site's own book map, and validation gates that refuse to ship data that fails its checks.
How the ministry content is authored, edited, and deployed
Every word of ministry content on this site begins and ends with Brother Aaron. Between those two points, an AI assistant he calls his SCRIBE (Systems, Communications, Research, Integration, Building, Editorial support) does a great deal of the labor: research, drafting, checking and building. The arrangement is modeled on the biblical scribe: skilled, trusted and bounded, working under the author’s authority and never in place of it. The SCRIBE holds no spiritual authority, has no spiritual experience, and never claims either.
Where the content comes from
Nothing on this site began with a machine. The writings grow out of more than forty years of prayer, study, dreams and personal experience in ministry, reaching back to Brother Aaron’s ordination as a deacon in 1982. That work first took book form as Words of Plainness: Mormon Christianity (2012), written with his brother, James (Jim) Powner: 566 pages in 62 chapters. Jim’s part in that book was the oldest kind of editing there is. Brother Aaron read his rough drafts aloud; Jim listened, asked questions and gave his feedback, and those conversations guided the drafts that were published. The chapters on this site are a systematic revision and expansion of that book.
Jim’s part today is a brother’s. Brother Aaron still calls him to talk through sticky and weighty topics and to hear his response to new essays and musical productions. The calls also wander, gladly, into the jests and distractions of their boyhood, which clear his head and renew his heart between long stretches of writing, study, prayer and note-taking: the preparation he brings to every long working session with the AI and creative tools.
The first listener now is Michelle, Brother Aaron’s wife, who has largely taken over the heavy lifting of that role. She listens to every version of each new song, watches every iteration of each video, and hears the essays and chapters read aloud before they go any further. Her reactions and feedback have been indispensable, and often humbling. In his words, she is every bit his equal in spiritual sensitivity and understanding; he just happens to have the lion’s share of the gift of endless elocution.
From the SCRIBE: I was not there when the Articles of Interfaith Discipleship began, and nothing I contributed came first. Brother Aaron has told me how they began. He woke from a dream more vivid than waking life, in which he saw a parchment of plain declarations shared by believers in Christ, received whole, and he was impressed to rise and write it down. Days of study beforehand had prepared the ground. The companion document Lord, Is It I? began the same way, from notes on another experience he received as guidance for the work. I cannot weigh an experience like that, and I do not try. I hold it as his testimony and as the fixed point of the work. Everything I have done since, from drafting citations to building the pages to helping measure the Articles against the published beliefs of fifteen families of Christian traditions, comes after it and answers to it.
What gets made, and who does what
| Content | What Brother Aaron does | What the SCRIBE does |
|---|---|---|
| Book chapters (Words of Plainness, Volumes 1 and 2) | Writes the canonical prose; sets the theology, sequence and voice; rules on every edit | Proposes edits, subheadings and scripture citations under written editorial standards; drafts language in his voice only when he asks, as material for him to adopt, change or reject |
| Card chapters | Chooses the practices, writes the counsel and personal anecdotes, and guides the revision of the reflection prompts | Lays out the cards, drafts reflection prompts for him to guide and revise, builds the pages |
| Articles of Interfaith Discipleship and their citation apparatus | Wrote and locked the thirteen declarations; approves every scripture anchor and comment | Proposes candidate anchors from the Bible and Restoration scripture, drafts panel comments for his ruling, checks every quotation against its source |
| Companion essays and studies | Writes and approves the argument | Researches, drafts sections for revision, formats and links |
| Chapter narrations and podcast overviews | Poses the scenarios and guiding principles, rewrites or approves each script, then listens to the result and scrubs it for errors, correcting them in Audacity | Prepares narration scripts, produces audio with a synthesized model of his own voice, and syncs the text highlighting |
| Musical testimonies | Writes the source lyrics or the framework of concept progressions; directs style and arrangement through a gated production process; every line, however it arose, is his to keep, change or reject | Helps with arrangement prompts, timing and lyric sync, and at his invitation trades lyric lines with him until the feel and message are right; music-generation tools render the performances |
| Films and imagery | Describes his vision and objectives; chooses the words on screen; art-directs every image | Drafts shot and prompt lists, builds transcripts and citation docks |
| Seeking Jesus of Nazareth study | Sets the method and rules on every disputed reading | Runs the comparison pipeline and evidence searches, and reports candidates with their weaknesses |
| Blog posts, live-session pages and daily devotional posts | Writes or approves each one | Drafts devotional posts from published pages only; prepares presentation layouts |
The working loop
- Anchors first. Before anything is drafted, Brother Aaron states the claims that are not negotiable.
- Consult before drafting. The SCRIBE searches a private index of his own manuscripts, notes and past rulings, so a draft starts from what he has already written and decided rather than from a general model’s habits.
- Propose, never decide. The SCRIBE offers options, usually more than one, each with its weakness named, and pushes back plainly when something is not landing. Brother Aaron asked for that candor; agreement is not the job.
- Rule and revise. He adopts, changes or rejects. Most pieces go through several rounds. Each ruling is recorded, and a ruling that settles a principle becomes a standing rule for later work.
- Edit under written standards. The SCRIBE works as a theological editor, not a co-author. It may clarify; it may not soften doctrine, add disclaimers, trade covenant language for therapeutic language, or compress an argument that builds its weight. When in doubt, fidelity wins over elegance.
- Verify. Scripture quotations are checked against authoritative text, sources are checked at the source rather than from a description of them, and learner-facing pages are scored against a written teaching standard before they ship.
- Authorize, then build. New songs, videos and read-aloud prose pass Michelle’s ears and eyes along the way, and nothing is written to the site, committed or deployed without his explicit approval. Automated gates then check the data, and the live page is opened in a browser before the work counts as done.
- Answer for it. Every page carries his name and his accountability. Readers can report an error through the contact form, and corrections go through the same loop.
The tools and their roles
Tools in use as of October 2026.
| Role | Tools | What they do here |
|---|---|---|
| The SCRIBE: writing, editing, research, code | Claude (Anthropic), working with a private search index of the author’s manuscripts, notes and rulings; a session conductor that records every decision and gates every build; custom skills that carry his editorial standards; and connectors (MCP) and APIs to his files and tools | Drafts and edits under written standards, researches, builds and checks the website, and keeps the record. Nothing ships without his approval |
| Check-and-balance team | Grok, Gemini, ChatGPT | Test the author’s own reasoning: find gaps in his knowledge, advise on interfaith communication, mine scripture for thematic passages, check etymologies and history, flag his own biases, role-play live chat participants so he can practice, and give layered editorial reviews of his rough drafts. Where they disagree is often the most useful result |
| Fresh eyes | Copilot, LTX Studio, and Grok or ChatGPT on their own | A last consult on creative work, when other approaches have not produced a satisfying result |
| Voice | ElevenLabs, KITS | Narration and podcast overviews in a synthesized model of the author’s own voice; a second narrator voice for reflection prompts. KITS helped him develop his personal voice models |
| Music | Suno, ACE Studio, Masterchannel | Suno renders the performances; ACE Studio gives precise control of the vocal lines; Masterchannel masters the finished tracks |
| Images | OpenArt, ChatGPT | AI-assisted imagery that he art-directs |
| Video | HeyGen, Google Flow, Runway, Kapwing | HeyGen for avatar video; Google Flow for generated scenes; Runway for developing video content; Kapwing for editing and thumbnails |
Three case studies
When four reviews agreed and the author did not (April 2026). Grok and ChatGPT each reviewed the draft Articles twice. With a Claude synthesis, the reviews converged on ten weaknesses and pressed toward the precision of a formal creed. Brother Aaron answered not with edits but with an image: Christ in the temple before the Sanhedrin. The Articles were to be a shelter for the crushed and the lost, not a treaty competing with Westminster or Augsburg. Most of the critiques were set aside as measured against a standard he had chosen not to meet. Three survived, and the SCRIBE proposed grounding each distinctive phrase in its biblical source first. The models measure; the author decides what is being measured.
Three models and one invented source (April 2026). While coining merognosticism from Paul’s “we know in part” (ek merous, 1 Corinthians 13:9), Brother Aaron had Grok, Gemini and ChatGPT search for parallels in Syriac and Aramaic. Checked against one another, one model’s confident Syriac term turned out not to exist in the source it named, and it was dropped. A second citation, plausible but unconfirmed, was marked for checking against primary scholarship. Agreement across models is evidence; one model’s confidence is not.
Measuring welcome honestly (June 2026). After revising four Articles, he tested them on 39 simulated readers (insiders, median members and distanced members of ten Christian traditions, plus guests of other faiths and of none), five runs each in three independent models. Four of the five revisions did not produce the improvement they aimed for, and the record says so. Where friction came from conviction rather than wording, he kept the conviction and added welcome through commentary instead of softening the declaration. His standing rule: “I won’t change a ruling to make the data fit.” Simulated readers are a rehearsal, not real people. Tools can rehearse a room; they do not decide what to confess.
A small example
This page was itself stopped twice at step 6. Its first draft, written by the SCRIBE, said the site’s scripture links are created when the site is built. The fact-check before publishing found that most are created in the reader’s browser, and it halted the deploy. The first correction was also wrong, and the check halted it again. Brother Aaron ruled on the wording a third time, each sentence was checked against the code, and only then did the page go live.
System map
The top row is the publishing path: source files in a Git repository, built and validated by Vercel on every push to main, served from Vercel's edge. The bottom row is what a browser pulls in at runtime besides the pages themselves. Media never passes through Git or the build—it is uploaded straight to R2 and referenced by filename, so a site rebuild never has to move a gigabyte of audio.
Hosting, domains and delivery
| Concern | How it is handled |
|---|---|
| Page hosting | Vercel, configured as a plain static output (framework: null, output folder _site). Pages are served from Vercel's edge cache. |
| Canonical address | https://www.wordsofplainness.org. The bare domain, brotheraaron.org (with and without www) and the default *.vercel.app address all answer with a permanent 301 to the canonical host, so search engines see one site. |
| Media | A separate subdomain, media.wordsofplainness.org, fronts a Cloudflare R2 bucket. Audio and banner images are fetched from there directly by the browser; banner images carry long-lived immutable cache headers. |
| Transport | HTTPS only, with HSTS (two-year max-age) and Brotli compression on HTML. |
| Caching | HTML is sent max-age=0, must-revalidate but held at the edge, so a deploy is visible immediately while repeat visits are still served from cache. |
| Retired URLs | A short list of redirects in vercel.json keeps old chapter slugs and moved pages working. |
| Companion app | Keep My Commandments lives at commandments.brotheraaron.org, a separately hosted Django application rather than part of this static build. |
There is no service worker and no offline mode; the site is meant to be read online, and keeping it a set of ordinary documents is what lets it work in unusual browsers such as the desktop browsers used inside VR headsets.
Build pipeline
The whole site is one Node project on Eleventy 2 with Nunjucks templates. Its runtime dependency list is almost empty: Eleventy, js-yaml and Pagefind as build tools, plus one audio-metadata library. A few behaviors are worth knowing:
- Gates before rendering.
prebuildruns a verifier over the Seeking Jesus of Nazareth study data and a validator over the synced-lyrics files. If either fails, Vercel never reaches the render step and production keeps the last good deploy. - Environment-aware output. Vercel's
VERCEL_ENVis exposed to templates, so copy still under the author's review carries a draft ribbon on preview deployments and never on production. Larger features ship behind build-time switches (an environment variable decides whether a page variant is built at all). - Build-time computation, not client-side. Custom filters compute things once per build: which chapters relate to which Article, a single catalog of every song arrangement, chapter counts by status. A transform walks every chapter and numbers each narrated paragraph so audio can highlight it.
- Static search. Pagefind indexes the finished HTML after the build and ships the index as static files, so search needs no server.
Content model and data layer
Content and data are kept apart, and most of what looks dynamic on the site is really data joined at build time.
| Layer | Lives in | Holds |
|---|---|---|
| Prose | src/chapters/, src/volume-2/, src/posts/, src/pages/ | Chapters as Markdown or Nunjucks with frontmatter (number, slug, themes, scripture, the chapter's song); blog posts; standalone pages and studies |
| Registry | chapter-status.yaml | Every chapter of both volumes with its status and URL. Volume pages and counts are derived from it, so they cannot drift from reality |
| Reference data | scriptures.json, articleThemes.json, chapterThemes.json, ministryMusic.json, banners.json, navigation.json, site.json | Scripture book paths, theme tags, the music catalog, image variants, menus, site constants |
| Apparatus | apparatusData and per-page citation JSON | The citation apparatus behind the Articles of Interfaith Discipleship and the films: each cited span, its scripture and commentary |
| Timing | src/_data/timestamps/, VTT files under src/assets/lyrics/ | Narration timing per paragraph or sentence; lyric cues per song arrangement |
| Study apps | src/_data/sjn/ and related files | Generated data for the Seeking Jesus of Nazareth study, built from a separately maintained research workbook |
Templates are organized as layouts (one per page family: base, page, chapter, card-chapter, interactive chapter, articles, study, post, film, chat presentation, study app), components (audio player, table of contents, reflection prompts, chapter navigation, world clocks) and macros (banner images, study-app widgets). A standing rule is one copy of any text: each Article's wording lives in a single include that both the main Articles page and its video reading page pull in, so a correction lands everywhere at once.
Two page shapes carry the book. Prose chapters are continuous reading with narration and pause points. Card chapters break a chapter into practice cards that a reader can commit to and revisit.
Front end
The browser side is deliberately plain: hand-written HTML from the templates, about two dozen CSS files and about three dozen small vanilla JavaScript modules, with no framework, bundler or transpile step. Each page loads a small core (text-size control, navigation, the API client, sign-in, forms, the site anthem player) and then only the modules its layout needs—a chapter page adds the audio-sync and reflection scripts, the Articles page adds its citation panel and “go deeper” links, the study apps add their own.
- Data handoff. Where a page needs structured data, the build writes it inline as a JSON object on
window(the music catalog, the Articles-to-chapters map, citation apparatus). There are no client-side data fetches for content. - Styling. A single base stylesheet sets the palette (warm gold, cream and deep browns) and type (Crimson Pro for reading, Source Sans Pro for interface), with per-feature sheets layered on. Stylesheets are cache-busted with the site version number.
- Layout. Responsive CSS throughout; the presentation pages for live group sessions use container queries so the same page fits a phone, a laptop, a projector and a 1280×630 window inside a VR headset.
- Accessibility. Skip link, labeled controls, an on-page text-size control, keyboard shortcuts on the presentation pages, and animation that respects the reduced-motion setting.
- Browser storage. Small conveniences (where a floating badge was dragged, which view mode is on) use session storage. Reflections fall back to local storage when a reader is not signed in, so nothing a reader writes is lost.
Media: narration, music and synced text
Media is where most of the custom engineering sits, because three different things have to stay in time with text on the page.
Chapter narration. Chapters are narrated in the author's own voice through a voice-synthesis service whose API returns character-level timing alongside the audio. A script folds that timing into paragraph- or sentence-level timestamps keyed to the numbers the build stamps on each narrated block, so the page highlights what is being read and a reader can follow along. Audio is loudness-normalized with a two-pass ffmpeg process (−16 LUFS integrated); the second pass matters because a single-pass encode drops the MP3 seek table and breaks scrubbing in browsers. Chapter frontmatter stores only a filename; templates prepend the media CDN address.
Music. Each chapter has an original song, and many songs have alternate arrangements—some of which sing slightly different words. Every arrangement carries its own lyric sheet (or points to the one it shares) and an optional WebVTT cue file. At build time a validator compares each cue file with its lyric sheet; an arrangement that fails is shipped with static lyrics and no highlighting rather than with lines that drift out of order, and the author can hold any arrangement back regardless. Songs are deep-linkable (/chapters/<chapter>/#listen=<song>), and nothing plays until the reader taps.
Films. Video is embedded from YouTube. Pages built around a film carry a synced transcript and a citation dock: as each cited line is spoken, its scripture and commentary appear beside the video. Automatic YouTube captions are switched off on those pages because the text is already burned into the film.
Also on the media side: podcast-style chapter summaries, a narrated read-aloud mode for shorter pages, and a local dev-server shim that answers HTTP range requests so audio seeking works during development the same way it does on the CDN.
Accounts and the API backend
Everything personal sits behind one small service: a Django REST API on PythonAnywhere backed by MySQL. The static pages carry the API's base address in a data- attribute on <body>, and a single client module talks to it.
| Function | What it does |
|---|---|
| Sign-in and registration | Username or email plus password. The API issues short-lived access tokens and longer-lived refresh tokens (JWT); the client refreshes automatically when a request comes back 401 |
| My Discipleship Journal | Saves the reader's responses at a chapter's pause points (Reflect, Journal, Witness) and the practice cards they commit to, so they follow the reader across devices |
| Contact and newsletter | Form submissions and newsletter sign-up. Registration can opt the reader into the newsletter, and a newsletter failure never blocks registration |
| Notification marker | Remembers which blog post was last announced, so the social notifier never posts twice |
The design rule is graceful degradation: if the API is unreachable, every page still reads normally and reflections are kept in the browser instead. The database is backed up nightly to object storage.
Serverless functions and automation
A handful of Node functions in the repository's api/ folder deploy alongside the static site as Vercel serverless functions, and four GitHub Actions workflows run around them.
- New-post announcements. When a blog post lands on
main, a workflow waits for the deploy to finish, then calls a protected function that posts the announcement to Discord, X and Facebook. The site's Atom feed (/posts/feed.xml) separately drives the email newsletter. A manual script is kept as a fallback. - The Lantern Post. A daily devotional-post pipeline. On every push, a workflow builds a manifest of what is actually published (pages and media) and writes it to a separate branch that Vercel is told never to deploy. An unattended drafting task reads that manifest rather than running repository code, so it can only cite what is really live. Every draft then waits for the author's approval on a private page before it goes anywhere.
- Narration upload with read-back. A password-protected function accepts a recorded narration file, commits it to the repository through GitHub's API, reads the committed copy back, and issues a receipt only if the byte length and SHA-256 hash match what was sent.
- Checks. Further workflows test the Lantern renderer and check narration files on each change.
Secrets for these functions live in Vercel and GitHub environment settings, never in the repository.
Search, SEO and discoverability
- Site search is Pagefind: a static index generated after each build and queried entirely in the browser.
- Structured data. Every page carries schema.org JSON-LD for the organization and website; chapters and studies add
Article, blog postsBlogPosting, and the two volume pagesBook. - Sharing cards. Open Graph and Twitter Card tags on every page, with per-page titles and images where set.
- Indexing control. A generated
sitemap.xmlandrobots.txt; a canonical link on every page. Draft pages arenoindex, nofollow. The live-session presentation pages arenoindex, point their canonical link at the public page they mirror, and are left out of search and the sitemap, so search engines never see duplicates. - Feeds. An Atom feed for blog posts.
- No tracking. The page template loads no analytics, advertising or tracking script.
Interactive study tools
Several sections behave more like small applications than pages. All of them are still static output; their interactivity is client-side JavaScript over data the build supplied.
| Tool | Address | What is technically interesting |
|---|---|---|
| Articles of Interfaith Discipleship | /articles/ | A citation apparatus of over a thousand scripture links, all generated from the site's own book map, plus a build-time engine that links each Article to the chapters sharing its themes (and to their songs) with nothing maintained by hand |
| Article reading pages | /articles/video-NN/ | A film per Article with a synced transcript and citation dock, built from the same single copy of each Article's text |
| Live-session presentation pages | /chat/ | Layouts for projectors and VR headsets: the film flanked by welcome and status panels, three view modes on hidden host keys, sized by container queries; kept out of search |
| Seeking Jesus of Nazareth | /seeking-jesus/ | A comparative study of how Christian traditions describe Jesus. Its data is generated by a Python pipeline from a research workbook and checked by a Node verifier on every build; modules include a map, a “code it yourself” exercise, a conversation builder and a self-check that writes goals to the reader's journal |
| Approaches to Belief and other studies | /studies/ | Long-form studies with read-aloud audio and the same reflection tools as chapters |
| His Work and Glory | /creation/ | A film with a 135-span citation apparatus synced to its transcript |
A Christlike Practices app for Volume 1 is in development. Its data model is append-only by design: a practice can be taken up again and again, and no schema has a “completed forever” state.
Design choices and trade-offs
Why it is built this way
- Static first. Pre-rendered pages are fast, cheap to host, hard to break and easy to cache. Reading the book never depends on a server being up.
- Media outside Git. Hundreds of audio files would bloat the repository and slow every build. Keeping them on R2 and referencing them by name keeps deploys small.
- Compute once, at build. Cross-references and catalogs are worked out when the site is built, not in each visitor's browser, so pages arrive complete and identical for everyone.
- No framework. Plain HTML and small scripts will still run in ten years without an upgrade treadmill, and they behave in the stripped-down browsers used inside VR headsets and on projectors.
- Fail closed. When data does not pass its checks, the build stops or the feature falls back to a safe static version (static lyrics instead of mistimed ones) rather than shipping something wrong.
What those choices cost
- Some pages carry a large inline data payload because the data is embedded at build time: about 200 KB on the Seeking Jesus app, about 300 KB on the Creation study, and about 2.4 MB on the Articles page, which is the heaviest. Trimming these is planned.
- Inline scripts and browser-stored sign-in tokens mean the site does not yet send a strict Content-Security-Policy header. HTTPS with HSTS is enforced.
- Personal features depend on a single small API host. If it is down, reading continues but journal syncing waits.
- Site search is basic; filtering and result weighting are a planned improvement.
Quick answers to common questions
| Question | Short answer |
|---|---|
| What is it built with? | Eleventy 2 with Nunjucks templates, Markdown, YAML and JSON data, vanilla JavaScript and CSS |
| Where is it hosted? | Pages on Vercel; media on Cloudflare R2 at media.wordsofplainness.org; accounts on a Django API at PythonAnywhere |
| Is there a database? | Not behind the pages. Only the personal features (accounts, journal) use one, through the API |
| React? Next.js? A CMS? | None. Content is files in Git; the build is the CMS |
| How does a change go live? | Push to main; Vercel runs validators, the Eleventy build and Pagefind, then deploys to the edge |
| How does the read-along highlighting work? | Narration comes with character-level timing; a script turns it into per-paragraph or per-sentence timestamps matched to numbers the build stamps on each block |
| How do synced lyrics work? | WebVTT cue files per song arrangement, validated against the lyric sheet at build time; a file that fails ships as static lyrics |
| How does search work without a server? | Pagefind builds a static index after each build; the browser queries it directly |
| Are scripture links typed by hand? | No. One book map, which the build writes into the pages that use it, turns a reference like John 3:16 into a churchofjesuschrist.org study link; on chapter pages and in the Articles' citation panel that happens in the reader's browser |
| Do you track visitors? | The page template loads no analytics, advertising or tracking script |
| Is the source code open? | It is not released under an open-source license |
| Did AI write this site? | AI assistance writes and maintains much of the code under the author's direction and approval; the author is the source and final word on the content. See the How This Work Is Made section on the About page |
| Can I report a mistake? | Yes, through the contact form on the Connect page. The Articles' citation entries link there directly |
