Methodology: How the GOI Bible Is Translated and Verified
The GOI Bible is an AI-assisted translation, and that fact is the reason it is checked the way it is. Rather than treating a single translation pass as a finished product, the project treats the pipeline as software — versioned, re-runnable, and auditable — and publishes the results of every check, flag, and correction along the way. This page explains the architecture and the verification pipeline in detail.
Verse-by-verse architecture
The corpus is built as one plain-text file per verse — for example
001_GEN_002_004.txt — rather than per chapter or per book.
That sharding is deliberate. Each call to the translation model is scoped
to exactly one verse's worth of source text and context, which bounds the
model's working context tightly enough that hallucinated or drifted
content (extra sentences, merged verses, invented transitions) becomes
immediately visible: the output for a given file is either a faithful
rendering of one verse, or it is obviously wrong. The filename itself
encodes the book, chapter, and verse, so there is no separate index that
can go stale, and the file count doubles as a literal progress bar —
"how much is translated" is a directory listing, not a query against a
separately maintained tracker.
Every verse, in every edition, is also assigned a Global Ordinal Index (GOI) — a single sequential integer based on its position in that edition's own canonical reading order. Versification schemes don't agree with each other across editions and languages, so comparing "verse 14503" across two Bibles is meaningless unless both editions number things the same way. The GOI sidesteps that by giving each edition its own ordinal sequence computed from canonical order; once two editions are mapped onto that same sequence, finding the corresponding verse in another edition becomes a join instead of a manual lookup, and a gap or duplicate in the sequence flags a structural problem — a missing, merged, or split verse — automatically.
Once the sharded, GOI-indexed corpus is loaded into a single SQLite database, the rigidity of "one verse, one file" disappears on the output side: a chapter, a whole book, or a flowing reading edition (with or without verse numbers) is one SQL query away, because every verse is already a row with the same shared key.
Multi-model verification
Translation and verification are deliberately separated. After a verse is translated, it is checked against the source language by an independent process rather than trusted on the strength of the model that produced it. The checks run in stages:
- Noun coverage verification. Every noun tagged in the Hebrew or Greek source (via Strong's numbers and morphology) is checked for presence — including inflected and stem forms — in the translated verse. For the New Testament English edition, this check found 28,889 of 28,889 source nouns accounted for: 0 missing, 99.7% exact match.
- Clause and meaning checks. A second pass compares each translated verse back against the Hebrew or Greek, looking for dropped clauses, reversed negations, wrong numbers, and "false friend" mistranslations — for example, Greek ἀφίημι rendered as "forgive" in a context where the sense is "leave" or "let".
- Negation and number integrity. Dedicated checks specifically target dropped or inverted negations and numeric errors — classes of mistake that can slip past a noun-presence check entirely, since the noun itself may still be present and correct.
- Triage and targeted repair. Every flag raised by the checks above is bucketed by severity. Clean lexical or structural fixes are applied by hand with an exact-match diff and logged to a per-batch backup record; verses that are more substantially garbled are regenerated from the source with the specific defect fed back to the model as a correction hint.
- Integrity gate. Before any change is considered finished, an automated validator re-checks a fixed set of corpus-wide invariants — file counts, verse-boundary alignment, GOI sequence continuity, and punctuation normalization — so a fix in one place can't silently break something else.
Every one of these stages corresponds to a script in the project's repository, and none of them is a one-time manual pass — the whole chain can be re-run at any time as the source data, the checks themselves, or the translation improve.
Strong's Concordance integration
The Hebrew and Greek source texts are tagged at the word level with
Strong's numbers and morphological data. Those tags are the anchor for
nearly every other check in the pipeline: noun-coverage verification is
a direct comparison against Strong's-tagged nouns, and the project's
multilingual sense layer resolves polysemous words —
Greek κύριος can mean "the Lord" or simply "master/sir"; Hebrew
אֱלֹהִים can mean "God," "gods," or, in some constructions,
"judges" — by recording a single, language-neutral decision (a
sense key, such as KYRIOS.HUMAN_MASTER) for each
ambiguous occurrence. A view in the database then resolves, per word and
per target language, which actual word to render. For the New Testament,
1,060 contextual word-choice decisions were made once, and a new language
inherits all of them automatically by filling in just 16 rows — one per
distinct sense.
Proper noun consistency checking
Biblical names are frequently rendered inconsistently across a literal, AI-assisted draft — the same person can surface under both a transliterated Greek form and an Anglicized form (Simon/Simeon, Elias/Elijah, Judas/Judah, Jonas/Jonah). The reviewer checklist used in this project explicitly flags proper-noun form variation as a category to check, alongside register inconsistency (mixing archaic and modern English within or across verses) and pronoun antecedent clarity, since a literal rendering can leave "he," "him," or "it" ambiguous where the source language's case or gender marking disambiguated it.
Independent auditing
The audit is designed to be checked, not taken on faith. Every verification pass, every flagged verse, and every correction is logged and reproducible. As of the most recent pass: New Testament English noun coverage is complete (0 missing, 99.7% exact match); the New Testament English and Chinese clause-check audits are complete, with all flags triaged; the Old Testament English clause-check audit (1,281 flags) is complete, with every flagged verse reviewed; and the Old Testament Chinese clause-check audit (604 flags) is likewise complete. New Testament Chinese noun string-matching is still in progress, and the Hebrew (WLC) edition's cross-edition GOI alignment has not yet been re-established after a prior naive alignment attempt was found to be roughly 81% mismatched and was withdrawn pending a corrected, content-based remap. These numbers are a snapshot of an active, ongoing audit and will continue to change as passes are rerun and scope widens.
Human review process
Automated checks can verify the presence of words and the structure of clauses; they cannot fully verify theological nuance, idiom, or register. Human review remains a required step for anything the automated checks flag, and for the dimensions the automated checks don't cover at all — clause and verb completeness is, by the project's own account, the weakest-checked dimension, since noun-presence verification can mask a missing verb. Where the project's own reviewers have made an interpretive judgment call — for example, choosing "wives" over "women" in 1 Timothy 3:11, or "propitiation" over "atoning sacrifice" in Romans 3:25 — those decisions are recorded rather than left implicit.
Error correction pipeline
When a check raises a flag, the response depends on what the flag turned out to be. A genuine error with a clean, exact-match fix is corrected by hand and logged with a diff against the prior text. A verse with more substantial corruption — a dropped clause, a mangled sentence — is regenerated from the source text, with the specific defect that was found fed back to the model as a hint so the correction targets the actual problem rather than producing an unrelated rewrite. A flag that turns out, on review, to be a checker false positive or a genuinely ambiguous, textually disputed reading where the existing rendering already follows established translation tradition is closed without an edit — but it is still recorded as reviewed, not silently dropped. This keeps the audit trail honest in both directions: corrections are visible, and so are the flags that didn't need one.
Frequently asked questions
Is AI used to translate the GOI Bible?
Yes. The translation is produced primarily by large language models, working one verse at a time from the tagged Hebrew and Greek source text. Every AI-generated verse then goes through automated verification before any human review.
Is the GOI Bible translated from Hebrew and Greek?
Yes. The Old Testament is translated from the Westminster Leningrad Codex (Hebrew), and the New Testament from the Textus Receptus 1550 (Greek). Both source texts are public domain. The King James Version and World English Bible (US) are used only as quality-assurance reference points during verification, never as translation sources.
How is the quality of the translation verified?
Every verse goes through automated noun-coverage checking against the Strong's-tagged source, a second-pass clause and meaning comparison back against the Hebrew or Greek, and dedicated negation and number-integrity checks. Flagged verses are triaged by severity and either hand-corrected with a logged diff or regenerated from the source with the specific defect fed back as a correction hint.
Is the GOI Bible project open source?
Yes. The translations, the cross-edition SQLite database, and the pipeline code are released under the MIT License. Because the source texts and QA reference texts are all public domain, the result carries no upstream copyright restrictions.
Where is the GOI Bible GitHub repository?
The repository is at github.com/goibible/goibible. It contains the English, Simplified Chinese, and Traditional Chinese editions, the cross-edition GOI database, and detailed provenance and verification documentation.