AI as a Detector, Not a Decision-Maker

Designing Scribe AI’s live path: offline speech recognition, rule-based scripture detection, and a human approval step that keeps a wrong guess off a church screen.

Scribe AI listens to a church service and tries to catch scripture references as they are spoken — “turn with me to John chapter three, verse sixteen” — so the verse can be put on screen without a volunteer scrambling to type it.

It is a small system, but it operates in an unforgiving environment: whatever it gets wrong is projected in front of the whole room.

Two constraints shaped nearly every design decision: the system must keep working without the internet, and nothing it detects should reach the screen without human approval.

In the settings Scribe is designed for, a dropped connection in the middle of a service is ordinary, not an edge case. So everything in the live path runs locally against local data: microphone capture, speech recognition, detection, Bible lookup, and display. There is no network call anywhere in this path.

Speech recognition uses Faster-Whisper’s small model on the CPU, quantised to int8, with greedy decoding (beam_size=1) and voice-activity filtering to skip silence. Audio is captured at 16 kHz and transcribed in five-second chunks.

These are deliberate trade-offs for the kind of laptop a church production desk actually has: a smaller, faster model designed to keep up with speech, rather than a potentially more accurate one that falls behind it.

Offline operation is not simply a convenience. If the internet connection fails during a service, the system should still be able to do its job.

It would have been easy to reach for a learned model to find scripture references in the transcript. I did not, because the detection problem does not require one.

Spoken references tend to follow a limited number of patterns. The detector covers four common forms:

John 3:16 John chapter 3 verse 16 John 3 16 John 316

The last example matters because speech recognition can compress a spoken reference into a run of digits.

The patterns match against all 66 Bible book names and common abbreviations. Each match is then checked against the actual number of chapters in that book. For example, Genesis 60 is rejected because Genesis has only 50 chapters.

That validation is particularly important for compressed references, where the detector must decide where the chapter number ends and the verse number begins.

The benefit is not accuracy for its own sake. It is inspectability. When the detector fires—or fails to fire—the logic behind the decision can be examined. There is no confidence score, and I have not pretended there is one. The detector checks whether a reference is valid according to its rules.

This is a useful reminder that not every component in an AI system needs to be another learned model. Sometimes a small, explicit rule set is easier to understand, test, and maintain.

References Don't Respect Chunk Boundaries

A preacher does not pause neatly every five seconds.

“John chapter three” might land at the end of one audio chunk, while “verse sixteen” arrives at the beginning of the next. If each chunk were processed independently, the detector could miss the complete reference.

To address this, when a chunk produces no detection, the system carries the last 60 characters of its transcript forward and prepends them to the next chunk.

When a chunk does produce a detection, the carried text is cleared to reduce the chance of detecting the same reference twice.

It is a small implementation detail, but it reflects a broader engineering problem: real-time systems have to account for the difference between how data is processed and how events actually occur.

The audio arrives in chunks. Human speech does not follow those boundaries.

A detected reference never goes straight to the screen.

Instead, it appears in an operator console: a separate, always-on-top window where a person can approve the detection, dismiss it, or type a reference manually. Only an operator's action—approving a detection or entering a reference themselves—puts a verse on the display.

This is the system's answer to a simple question:

A misheard reference costs the operator a click. Without the approval gate, it could mean displaying the wrong verse in front of an entire congregation.

Manual entry is equally important. The operator is never dependent on the detector. If the system misses a reference, the service can continue without waiting for the AI to recover.

The implementation also separates audio processing from the user interface. Audio capture and transcription run on a background thread, while the console and display belong to the Tkinter UI thread.

The audio thread never manipulates the interface directly. Instead, it schedules work on the UI thread with root.after, helping prevent the two threads from interfering with the same widgets.

The design principle is broader than this particular application: automating detection does not require automating the final decision.

Scribe also contains a service-state machine—keyword rules that track whether the service is in worship, sermon, prayer, or announcements—and a lyric detector that fuzzy-matches transcript text against a song library.

Both are implemented and tested. Neither is connected to the live microphone path yet. They run together in a separate pipeline driven by simulated text.

It would be easy to describe the modules the system contains and leave readers with the impression that everything operates live. But having a working module is not the same as integrating it into the complete application.

There are other limitations, too. The lyric matcher's threshold has only been tested on clean text, and the song library contains placeholder data.

These limitations belong in the description of the system, not in a footnote. A clear account of what works, what has been tested, and what remains disconnected is more useful than a broader claim that the implementation cannot yet support.

There are three main priorities for the next stage of Scribe AI:

Build a real-world evaluation set. Use recordings from actual services, including accents, crosstalk, and music, to measure detection performance under the conditions the system will encounter. Integrate the separate pipelines. Create one live entry point that includes service-state tracking and lyric detection, replacing the split between the live path and the simulated pipeline. Make speech recognition interchangeable. Introduce an interface that allows other models—including models better suited to African languages—to be swapped in and compared fairly.

These steps move the project beyond demonstrating that its components work in isolation and towards evaluating how well the complete system performs in practice.

The general lesson I keep returning to is this: the most important design decision in an applied AI system is often not the model.

It is where the model's output is allowed to go, what happens when that output is wrong, and who gets to say no.

In Scribe AI, speech recognition proposes what it heard. Rules check whether a scripture reference is valid. A human operator decides whether the verse reaches the screen.

That separation is intentional. In a live environment where an incorrect output is immediately visible to everyone in the room, a useful AI system is not simply one that produces answers quickly. It is one designed to handle uncertainty without taking control away from the person responsible for the outcome.

Project: Scribe AI — an offline-first system for detecting scripture references during church services, with human approval before display.