Ignite AI · Our Portfolio Built with AI

Collect the Text

We gathered commentaries, lexicons, journals, and sermons into one library on our own computer. We added public-domain works from the Christian Classics Ethereal Library, Project Gutenberg, the Early English Books transcriptions, Wikisource, and the Internet Archive, and journals that publishers post free, such as Tyndale Bulletin, Themelios, and the Journal of the Evangelical Theological Society.

Every resource has an entry in a register with its author, dates, tradition, and era, so every search result says who wrote it and when.

Divide It into Sections and Tag the Verses

Each resource is cut into short sections, all stored in one database file. Each section is linked to the Bible verses it discusses. A request like “everything the library says on Romans 7:24” becomes a single lookup. It returns our own saved study notes first, then study Bible notes, commentaries, sermons, and the other works that cite the verse.

We also tag sections with theological and pastoral topics, such as assurance, grief, and perseverance. Blind hand checks show the tags are a strong starting point but not complete, so we use them to find more material, never to filter search results.

Search Two Ways at Once

Keyword search. A full-text index (SQLite FTS5) finds exact words and phrases. It keeps quoted phrases together, drops common words, and strips accents and vowel points, so a Greek or Hebrew word matches with or without them. Lexicons are also searched by headword.

Meaning search. An embedding model, Qwen3-Embedding 4B, runs on the Mac mini through Ollama. It turns each section into a list of 1,024 numbers that describe what the section means. A question about burnout then finds a sermon on being “weary in well doing” even though the word “burnout” never appears. A compact copy of those vectors stays in memory, so a meaning search doesn’t have to read the whole database each time.

The two result lists are merged by rank, and the best candidates go to the next step.

Rerank the Candidates

A second local model reads the question beside each candidate section and scores how well the section answers it. We use Qwen3-Reranker 4B, which the search engine starts on demand with llama.cpp. On our test questions, the reranker puts the right source near the top far more often than search alone. We switch models when a better one proves itself on the same tests.

Connect Claude Through Our Own MCP Server

MCP, the Model Context Protocol, is the standard way to give Claude a tool. We wrote a small MCP server in Python that gives Claude eight tools: search the library, list everything on a passage, show what the church has said on a passage era by era, list sections on a topic, read a passage in several Bible versions, list the resources, start a sermon research report, and save a study note.

The server runs on the Mac mini as a background service. Our laptops reach it over Tailscale, a private network that only our own devices can join, so the library is available from home, the office, or a conference without being open to the internet.

Test It and Fix What Breaks

We keep a set of test questions whose right answers we checked by hand: topics, word studies, lexicon headwords, and passages. After every large import we run the whole set. The report shows how often the right source made the top results, and at which stage each miss was lost: keyword search, meaning search, merging, or reranking. Then we fix the weakest stage and run the tests again.

Other checks run alongside it. An audit checks each saved resource for missing pages. A script checks every quotation word for word against the library. Another check confirms the fast in-memory copy of the vectors ranks results the same way as the full copy. Before any script changes, we save a backup copy so the change can be undone.