About This Project

Project origins

The AI Bible Commentary website is a project that Neil Baulch developed for his own study, and it grew into a major work online.

Neil has been working constantly with AI since OpenAI released its first public versions. He understands the great danger that AI presents to mankind, but he also understands that it is the most extraordinary tool for research and study ever created.

He believes that AI is a gift from God, but also that it will eventually be used for evil purposes and will become a major means by which the freedoms of mankind are damaged or destroyed.

For that reason, this website was not built on naive trust in AI. It was built on suspicion, restraint, interrogation, correction, and governance. While AI remains controllable for a given task, it can be used as a tool; but one must be constantly suspicious and ready to abandon AI whenever it refuses to be trained, governed, or controlled for the task at hand.

About Neil Baulch

Neil grew up in country Victoria, in the south-east corner of Australia. His parents were Christians, and he made a deep commitment to Christ at an early age.

After some rebellious teenage years, he recommitted his life to Christ and settled into a local church, where he served in various areas of ministry, including Sunday school, youth ministry, deacon service, home church leadership, and lay preaching over many years.

Neil does not claim to be a biblical scholar. He is a Christian layman who has had a passion for knowing and serving God for more than 50 years. This project is therefore not presented as academic authority, but as a carefully governed Bible-study aid created under conservative evangelical convictions and strict quality controls.

How to read the project protocols

To understand the process involved in creating the resources on this website, the following in-depth protocols explain how biblical safety, theological restraint, prompt engineering, structured data, review stages, QA-linting, and publication checks were built into the work.

The central point is simple: AI Bible Commentary was not produced as a casual one-click AI writing project. It was developed through a controlled, staged, conservative, Scripture-governed workflow intended to reduce error, speculation, overstatement, malformed data, and careless publication.

The Main Research Blend Behind This Project

The research structure behind this project is a blended approach. I drew especially from Dr. Bob Utley’s hermeneutical principles, Dr. Kevin Conner’s principles in Key of Knowledge and Interpreting the Scriptures, the YWAM School of Biblical Studies approach, and my own concern to present a deeper and wider reading of Scripture while still keeping the text in control.

All research for this project was done with a very strict structured prompt in order to force AI to remain conservative evangelical and theologically restrained, rather than drifting into liberal theology or vague spiritual language.

Theological and Methodological Posture

This project begins from a deliberately defined standpoint: a conservative evangelical, Free-Choice, conditional-security New Testament exegete with a moderate dispensational framework, avoiding both covenantal flattening and extreme dispensational fragmentation, a cautious continuationist of the gifts of the Spirit, and working with a grammatical-historical method.

That posture is there to keep the commentary stable, text-governed, and doctrinally conservative. It is not there to replace Scripture, but to constrain the AI and make it answer inside clear boundaries.

What Each Paragraph / Literary Unit Commentary Includes

The aim is not simply to say what a passage mentions, but to show how the literary unit works, what features shape the reading, where interpretation becomes disputed, what background is actually relevant, how theology arises from the passage itself, and where modern readers commonly misread the text.

Executive Summary: How Biblical Safety and Quality Control Were Built into AI Bible Commentary

AI Bible Commentary was not developed as a casual AI writing project. It was built as a structured, conservative, Scripture-governed Bible study system with multiple layers of prompt control, theological restraint, data validation, specialist review, QA-linting, and publication checks.

The goal was never to make artificial intelligence a spiritual authority. The goal was to use modern language-model tools in a carefully governed way to help organize, explain, and cross-reference biblical material while keeping Scripture itself, sound doctrine, responsible interpretation, and Christian discernment in their proper place.

This website was therefore developed under strict biblical, theological, editorial, and technical controls. The commentary was generated, reviewed, corrected, and published through a multi-stage process designed to reduce doctrinal carelessness, unsupported speculation, overconfident claims, malformed data, broken links, and reader-facing errors.

1. The Foundational Principle: Scripture Is the Authority, Not AI

The first and most important safeguard is theological. AI Bible Commentary does not treat artificial intelligence as inspired, infallible, prophetic, pastoral, or authoritative.

The controlling conviction behind the project is that Scripture is the final written authority; God’s Word must govern interpretation; AI can assist study, but it must never replace the Bible, prayer, the local church, qualified teachers, or responsible Christian discernment; any interpretation must remain accountable to the text itself; where the Bible is clear, the commentary should speak clearly; and where the Bible allows legitimate interpretive debate, the commentary should identify the issue carefully and avoid pretending that all questions are settled.

The system was therefore designed to help readers study the Bible more carefully, not to outsource spiritual judgment to a machine.

2. Conservative Biblical and Theological Guardrails

The commentary was developed within a conservative evangelical framework.

The prompt system required the commentary to respect the authority, truthfulness, and unity of Scripture; the grammatical-historical meaning of the biblical text; the canonical context of each passage; the distinction between original meaning, later biblical development, and modern application; historic Christian orthodoxy; the difference between doctrine, inference, application, and speculation; and the need to avoid novelty, sensationalism, and theological overreach.

The system also required restraint when dealing with difficult subjects such as prophecy, typology, messianic interpretation, textual criticism, historical reconstruction, divine judgment, covenant theology, and debated interpretive cruxes.

In practice, this means the commentary was not allowed simply to produce impressive-sounding theological reflections. It had to stay anchored to the passage.

3. Prompt Engineering Was Used as a Theological Safety System

The project used detailed master prompts rather than loose, open-ended AI requests. These prompts acted like a theological and editorial rulebook.

The prompts required the AI to work through structured categories such as passage context, historical setting, central idea, context and flow, exegetical analysis, covenantal and redemptive location, theological significance, prophecy, typology and symbols, Eastern thought and culture, canonical and Christological trajectory, practical and doctrinal implications, textual-critical notes when relevant, interpretive cruxes, application boundaries, key Hebrew or Greek terms, and interpretive cautions.

This structure helped prevent the commentary from becoming vague, devotional, disconnected from the text, or doctrinally careless. The prompts also required the system to identify areas of uncertainty rather than hiding difficulties.

4. The AI Was Required to Distinguish Meaning from Speculation

One of the most important safety rules was that the commentary had to distinguish between what the passage clearly says, what the passage probably implies, what is possible but debated, what should be treated as speculation, and what should not be claimed from the passage.

This was especially important in areas such as prophetic interpretation, typology, messianic connections, Old Testament background, symbolism, theological application, historical reconstruction, word studies, and textual variants.

The commentary was not permitted to turn every detail into a hidden symbol, a prophetic code, or a doctrinal proof text. It had to respect genre, context, and the authorial flow of the passage.

5. Structured Output and Schema Control

The commentary was not merely generated as loose prose. Much of the production process used structured data fields and schema-controlled outputs.

This means the AI had to produce content in defined categories rather than uncontrolled paragraphs. Structured fields allowed the project to check whether required categories were present, whether data was malformed, whether important sections were missing, and whether commentary could be safely converted into web pages and JSON sidecars.

This also made it possible to separate reader-facing commentary, editorial notes, QA findings, routing decisions, machine-readable JSON data, and publication metadata. That separation prevented internal review material from being confused with public commentary.

6. First-Pass Commentary Was Not Treated as Final

The initial AI-generated commentary was only the first stage. It was not treated as publish-ready merely because it was complete.

For the Old Testament commentary project, the approved literary-unit baseline contained 946 Old Testament units. The first-pass generation completed all 946 units, but that was only the beginning of quality control.

After first pass, the content went through additional routing, second-pass review, QA-linting, minor cleanup, and publication testing. This prevented the project from assuming that the first AI answer was good enough.

7. Second-Pass Routing Identified Higher-Risk Passages

After first-pass generation, the project identified rows that needed additional specialist review. Not every passage carried the same risk level. Some biblical passages are more doctrinally sensitive, interpretively difficult, prophetically complex, or historically debated.

For the Old Testament project, 185 of the 946 units were routed for second-pass review. These included passages with major prophetic complexity, major messianic significance, interpretive cruxes, dense poetry or wisdom material, difficult historical questions, debated typology, and difficult legal interpretation.

The highest-priority rows included passages such as Psalm 22, Psalm 40, Isaiah 52:13–53:12, Daniel 7, Daniel 9, Ezekiel 37, Zechariah 11, and other passages where interpretive caution is especially important.

8. Second-Pass Review Corrected and Strengthened the Content

The second-pass stage did not simply rewrite everything. That would have risked unnecessary instability. Instead, the rule was to review and improve only what needed improvement.

The second-pass layer focused on correcting overstatements, adding interpretive cautions, clarifying prophetic or typological claims, tightening messianic connections, preserving original historical context, preventing application from outrunning the text, flagging remaining areas of legitimate debate, and confirming whether the passage was ready for publication.

This stage was especially important for passages where conservative interpreters may agree on the authority of Scripture but differ on details of fulfillment, symbolism, chronology, or theological emphasis.

9. QA-Linting Was Run Across the Entire Corpus

After second-pass review, the project used a QA-linting stage. This was a quality-control pass designed to evaluate whether the commentary was safe and publishable.

The QA-lint process checked for doctrinal overstatement, speculative interpretation, weak handling of difficult passages, insufficient caution in debated areas, reader-facing ambiguity, problems with application, need for minor editorial correction, and whether a passage should be published, revised, or held.

The QA process was first applied to the second-pass-routed rows, then extended across the full Old Testament corpus. This meant that even passages not originally routed for second pass were still reviewed before publication. For the Old Testament project, all 946 commentary units were eventually QA-linted.

10. Revision Rows Were Rechecked Rather Than Blindly Accepted

When QA-linting marked a row as needing revision, the project did not automatically accept that result as final. Those rows were investigated.

Some apparent revision flags turned out to be QA anomalies where the QA result gave no substantive issue. Those rows were reset and rerun through QA to see whether the concern was real. If a rerun confirmed the concern, the row would require targeted repair. If the rerun cleared the row, it could be accepted.

This mattered because quality control itself must also be controlled. A QA system can be useful, but it should not be treated as infallible. The project therefore checked the QA output instead of blindly trusting it.

11. Minor-Warning Rows Were Cleaned Rather Than Ignored

Some rows passed QA but were marked “publish after minor edits.” These were not major doctrinal failures, but they still required attention.

A separate minor-cleanup pass was used to address these rows without rewriting stable commentary. This stage focused on small corrections such as moderating slightly overconfident language, removing unnecessary speculative phrasing, clarifying caution notes, normalizing publication status, and preserving useful interpretive cautions while removing blocking warnings.

The goal was not to polish everything endlessly. The goal was to bring all rows to a clean publishable state without destabilizing good content. For the Old Testament project, this process ultimately produced a final state in which all 946 units had QA Status: pass and Publish Recommendation: publish.

12. Word Studies Were Controlled and Linked to Further Tools

The commentary includes key Hebrew and Greek terms where relevant. These were not included merely for decoration. They were used to help readers see important words, transliterations, glosses, and Strong’s numbers.

The project also connected key terms to the All-In-One Bible Study Tool so that readers could study a term in its biblical context.

Those tool links were designed to include book, chapter, verse, word, Strong’s number, transliteration, polyglot parameter, and TWOT parameter where applicable. This mattered because biblical words should not be studied in isolation from their passage context.

13. Reader-Facing Pages Were Separated from Internal Development Notes

Another important safety decision was to prevent internal QA and development notes from appearing as normal commentary.

During development, the workbook contained fields such as QA summaries, review notes, final QA comments, status fields, and repair notes. These are useful for project governance, but they are not the commentary itself.

The publication builder was adjusted so that public pages do not display developer-facing QA text as if it were part of the biblical exposition. The public page is meant to show the reader the commentary, study helps, key terms, interpretive cautions, and machine-readable data links—not the internal production notes behind the page.

14. Publication Rendering Was Also Tested

The project did not stop once the workbook was clean. The website pages themselves had to be built and tested.

The publication builder generated Old Testament commentary unit pages, book index pages, the Old Testament index page, JSON sidecars, corpus index data, canonical URLs, page metadata, machine-readable data links, floating “Copy Content” functionality, and contextual All-In-One Bible Study Tool links.

The build was tested for incorrect footer content, broken or missing anchor links, malformed All-In-One Bible Study Tool links, double slashes in URLs, missing floating copy buttons, reader-facing QA text leaking into the page, footer cards not matching the intended site pattern, machine-readable JSON links pointing to the correct data, and page counts matching the expected build output.

15. Machine-Readable JSON Was Published for Transparency and Reuse

The website also publishes structured JSON data alongside human-readable commentary pages.

This supports indexing and search, allows future tooling to consume the data, keeps the content structured and auditable, separates content data from presentation, and supports future expansion, interlinking, dictionaries, tooltips, and AI-assisted study tools.

The JSON sidecars are not a substitute for reading the commentary, but they help make the site more organized, transparent, and technically usable.

16. The Project Used a “Publish by Evidence” Model

A major operating principle was that content should not be published merely because it exists. It had to pass defined checks.

For the Old Testament commentary, the development path included approved literary-unit segmentation, first-pass commentary generation, validation of all first-pass rows, repair of malformed or held rows, second-pass routing of higher-risk passages, specialist second-pass review, QA-linting of second-pass rows, corpus-wide QA-linting of all rows, investigation and rerun of revision flags, minor-warning cleanup, final normalization of publish status, publication builder testing, HTML, JSON, link, footer, anchor, and copy-button checks, and final build packaging.

This is a staged-control process, not a one-click AI content dump.

17. What the Project Was Designed to Avoid

The controls were designed to avoid several common dangers in AI-generated Bible content: confidently wrong interpretation, doctrinally careless claims, over-reading typology, mishandling prophecy, flattening Old Testament context into later theology, ignoring genre, treating speculative ideas as certain, using Hebrew or Greek terms superficially, creating broken study links, publishing internal QA notes as if they were commentary, generating attractive but unreviewed material, and replacing biblical discernment with machine fluency.

The commentary was built to be useful, but also restrained.

18. What Readers Should Still Understand

Even with rigorous controls, AI Bible Commentary should be used responsibly.

Readers should understand that this website is a study aid, not an inspired text; Scripture itself must be read directly; difficult passages should be studied with care; pastors, elders, teachers, and mature believers remain important; the commentary may help organize and explain, but it should not replace prayerful study; no AI-assisted work should be treated as beyond correction; and readers are encouraged to test all things by Scripture.

The aim is not to create dependency on AI, but to help Christians study more carefully and fruitfully.

19. Final Summary

AI Bible Commentary was developed through a rigorous, multi-stage process designed to make AI-assisted Bible study safer, more structured, and more accountable.

The project used conservative theological guardrails, strict prompt engineering, structured schemas, second-pass review, QA-linting, targeted revision checks, minor-warning cleanup, publication rendering controls, link validation, JSON sidecars, and final build testing.

The result is not an infallible commentary. No commentary is infallible. But the project was intentionally built to avoid the shallow, careless, speculative, and overconfident tendencies that often appear in AI-generated biblical material.

The governing purpose of the project is simple: to use modern tools carefully, under Scripture, for the service of serious Bible study—while keeping the Word of God, not artificial intelligence, as the final authority.