elizatrinity.tech launch series · Part 2
I Turned One YouTube Sermon Into 379 Study Notes. Here's the Pipeline Behind It.
Part 1 ended with me stuck. Three days lost trying to make n8n talk to Wix, and no automated way to turn a sermon into a published study note.
This is the part where it actually started working.
What follows is the real pipeline running Revealed Insight today — not a simplified version for the article. Fourteen stages, three tools doing the heavy lifting, and a framework called AIOS holding it all together. Here's the architecture, then I'll walk through why each piece exists.
The Ingestion Problem
A sermon on YouTube is, to a computer, just a video file. Nothing about it is structured, searchable, or reusable. Before any AI can extract theology, themes, or quotable lines from it, that video has to become text — accurate text, in the preacher's actual words, not a paraphrase.
That's the entire job of the first stage. Everything downstream depends on getting this part right, because a transcription error at the start becomes a wrong scripture reference or a garbled quote by the time it reaches a reader.
yt-dlp + Whisper — And the Constraint That Shaped Both
Stage 0 downloads the video with yt-dlp and transcribes it with Whisper, OpenAI's speech-to-text model. Both run locally — no per-video API cost for this part.
Here's the honest part most people skip when they talk about their AI pipeline: the Whisper model size wasn't my choice. It was forced down by hardware. The laptop running this has about 8GB of free RAM, and Whisper's larger models — medium, even small — kept getting killed mid-transcription by memory pressure, unpredictably, sometimes twenty minutes into a forty-minute sermon.
The fix wasn't a bigger machine. It was tiny — Whisper's smallest model — paired with two things: chunking every sermon into 15-minute segments, and writing a .partial checkpoint file after each chunk completes. It isn't automatic resume — if the process gets killed partway through, re-running it starts Whisper over from chunk 1, not from wherever it died. What the checkpoint actually buys me is that the chunks it already finished survive on disk instead of vanishing with the crash. That's not theoretical: a 164-minute sermon got killed on chunk 8 of 11 this week, and the fix was just running it again — it finished clean on the second pass.
It's not the setup I'd have picked if the constraint didn't exist. It's the one that actually works within it, every time, without me babysitting it.
A validator (Stage V) checks the raw transcript immediately after — word count sanity, repeated segments — before anything downstream touches it.
The Claude-Driven Stages
Stages 1 through 3 clean and segment the raw transcript — nothing AI-heavy yet, just preparing text that's readable and chunked by topic.
Stage 5 onward is where Claude does the real work:
- Stage 5 extracts the sermon's actual theological structure — its outline, core argument, and prayer moments — in the preacher's own framing, not a generic summary template.
- Stage 6 pulls out topics for tagging and search.
- Stage 7 generates the full study note draft — the piece a reader actually sees.
- Stage 7B is a validator, not a model call: it checks the Stage 7 draft against structural rules and returns FAIL, WARN, or PASS before a human ever looks at it.
Two different Claude models do this work, on purpose. Stages 5, 6, 8, and 9 run on a cheaper model, because the task is extraction — pull structure out of text that's already there. Stage 7 — writing the actual draft a reader will read — runs on a stronger model, because that's where reliability on long sermons matters most and cutting cost isn't worth the quality risk.
After the draft passes, Stage 8 extracts verbatim quotes — what I call Golden Nuggets — into a Notion database, and Stage 9 builds out a knowledge graph of themes and scripture references, also in Notion. Every sermon gets tracked end-to-end in a master index — validated, drafted, published — so I always know exactly where each one is in the pipeline.
Stage 10 handles every image a study note needs — hero image, content images, quote cards, wallpapers — automatically, pulling the best match from a pre-built symbol library. Most sermons never need a person to touch this step.
But not every sermon has a good match sitting in the library. When nothing fits well, Stage 10 doesn't just fail quietly — it picks the closest image it can find as a placeholder, and surfaces a prompt on the dashboard asking me to generate a proper one. I generate the image, click upload, and the pipeline takes it from there: applies a watermark, refreshes the dashboard, marks that image as ready, and the prompt disappears. It's a small manual step, but it only fires when the automation genuinely doesn't have a good answer — not on every sermon.
Only after all of that does a human — me — actually look at it, through a Streamlit review dashboard. Two checks run right there before I can approve anything: the structural validator from Stage 7B, which checks mechanical things — required sections present, correct block placement, formatting rules — and a QA Agent that reviews the judgment calls a validator can't, like whether a Golden Nugget is genuinely self-contained and applicable, or whether a scripture reference is formatted correctly. Both only flag what's actually failing; a clean run just shows a single green line.
Approve, and RI-Publisher takes over: stamps final assets, uploads to Cloudflare R2, commits and pushes the code, updates Notion, and sends a Telegram alert.
Reject, and it goes into a manual pending folder instead.
That human review is the one deliberate gate in the entire pipeline. Everything else — download through publish — runs without me touching it.
AIOS: The Framework That Was There From Day One
I want to correct something I might have implied in Part 1: AIOS wasn't bolted on after the fact to organize a pipeline I'd already built by hand. It was there from the very first commit, back in March — the workspace structure, the context system, the git workflow — before a single sermon had been processed. The pipeline was built inside that framework from the start, not retrofitted into it.
That matters because it's the difference between "I automated my blog" and "I built a system, and the blog is one thing it produces." The second one is what actually scales past one project.
What Broke Along the Way
None of this worked perfectly on the first try, and I'd rather tell you what actually broke than pretend it didn't.
A title-extraction bug corrupted a sermon's assets without anyone noticing — for a while. A sermon's [Hero Image] placeholder got mistaken for a markdown heading, which corrupted the slug and, with it, every downstream asset folder for that sermon. That's exactly why Stage 7B exists now — a structural validator that runs on every draft before a human review, specifically so this class of bug gets caught by a machine instead of a reader.
A quality regression sat in production for months before I caught it. An audit of the Golden Nuggets — verbatim quotes pulled from sermons — found 1,856 already-published quotes across all 359 teachings that were grammatically fine but had no actual value: dangling pronouns, narrative trivia, personal testimony miscategorized as universal truth. I wrote a strict five-point qualification test afterward — verbatim, self-contained, universal truth (not personal testimony), carries an applicable takeaway, memorable — and cleaned the backlog against it.
An entire planned layer got built, then quietly dropped. Early on, the plan was a semi-autonomous agent layer — one orchestrator managing separate publishing, newsletter, and social-distribution agents, running on its own schedule. In practice, running Claude Code sessions directly turned out simpler and more reliable than maintaining a standing agent process. The functions that layer was meant to provide — automated publishing, Telegram distribution — still exist and still work. They just run when I trigger them, not on their own heartbeat.
That last one is probably the most useful lesson in this whole article: the more autonomous-sounding architecture wasn't the better one. The one I actually kept running is the one where a person still starts each run and reviews before it goes live.
(Continued in Article 3 — Before vs After.)