A complete Bible, in any language,
built on a single portable database file
that can be used 100% offline.

I.What Is GOI?

GOI stands for Global Ordinal Index. It's the idea this entire project is named after — the single integer key that lets every verse, in every edition and every language, be addressed, compared, and joined the same way. Everything else on this page — the database, the translation pipeline, the audit trail — exists to fill in and verify the text attached to that index.

Every Bible has a versification scheme — book, chapter, verse. The problem is that versification schemes don't agree with each other. The Hebrew Masoretic Text splits some Psalm headings as verse 1; English translations often don't. Different canon orderings place books in different sequences. Comparing "verse 14503" across two editions is meaningless if the two editions don't number things the same way.

The Global Ordinal Index (GOI) solves this with one idea: assign every verse, in every edition, a single sequential integer based on its position in that edition's canonical reading order.

SELECT
    *,
    ROW_NUMBER() OVER (
        PARTITION BY edition_id
        ORDER BY conical, chapter, verse
    ) AS goi
FROM verses;

(conical is the actual column name in the current schema — a long-standing typo for "canonical" that's been left as-is for backward compatibility within the database.)

Because the GOI is computed per edition from canonical order, it turns "is this translation structurally complete?" into a single query, and — once two editions have been mapped onto the same canonical ordinal sequence — it turns "what is the corresponding verse in another edition?" into a join. GOI doesn't eliminate the work of reconciling divergent versification; what it does is give that reconciliation a single, durable target representation, so it only has to be done once per edition rather than re-derived for every comparison. (The Hebrew WLC edition in this project is a live example of that reconciliation being incomplete — see the status box below.)

Two editions, two different versification systems, one shared integer key. Structural divergence becomes a query, not a manual diff.

The project needed one edition to serve as the reference ordinal sequence — the canonical book/chapter/verse order that every other edition's goi is ultimately checked against. The King James Version was chosen for this role: 66 books, 31,102 verses, goi values 1 through 31,102. It's not chosen for its wording — the AI translation doesn't copy it — but because its versification is the most widely recognized "common denominator" ordering, making it the most useful fixed yardstick for spotting where another edition's verse count diverges.

Why start from WLC + TR1550 — and why MIT?

The two source texts behind every translation in this project — the Westminster Leningrad Codex (Hebrew Old Testament) and the Textus Receptus 1550 (Greek New Testament) — are both public domain. That choice wasn't incidental; it's what makes the rest of the project possible. Starting from a source text that is itself unencumbered means the resulting translations, databases, and pipeline code can be released under a genuinely permissive license — MIT — with no upstream copyright to worry about, no royalty chain, and no clause that quietly restricts who can copy, fork, or redistribute the result.

"MIT" here means what it always means: anyone — a seminary, a single developer, a mission organization with no budget — can take the database, the code, or the translated text, use it, modify it, ship it, and give it away again, without asking permission or paying anyone. A Bible project built on a restrictively-licensed or copyrighted source text could never offer that. Public-domain in, MIT out is the whole supply chain.

What the GOI gives the project, concretely:

• Version-to-version diffing — align any two editions without a versification-mapping table.
• Divergence detection — a gap or duplicate in the goi sequence flags a structural problem immediately.
• Missing-verse detection — the verse count for an edition is MAX(goi); an incomplete translation is visible at a glance.
• Cross-language alignment — once a new language's verses are loaded with the same canonical ordering, its goi values line up with English, Hebrew, and Greek automatically.

II.Background & Motivation

Why does the world need another Bible project?

Bible translation is traditionally one of the most expensive, slowest forms of literary work that exists. A single language can take a trained team a decade or more, and the result — for all its care — is usually locked away in a format (a printed book, a denomination's proprietary database) that resists comparison, search, or machine-assisted review.

The GOI Bible project starts from a different premise. Large language models are now competent — not perfect, but competent — at producing a first-pass translation from a tagged source text. The interesting problem is no longer "can an AI translate the Bible?" The interesting problem is: can the result be checked, at scale, with the same rigor we'd apply to a codebase — automated tests, integrity gates, regression tracking, and a visible audit trail of every correction?

That reframing is what GOI is built around. Every verse is a row. Every translation is an edition. Every noun, clause, and number is a checkable fact against the source language. And the whole thing — text, cross-references, audit metadata — fits in a single file you can copy to a USB stick.

The goal isn't to claim the AI got everything right the first time. It almost never does. The goal is to make every place it got something wrong findable, fixable, and re-verifiable — and to publish the receipts.

III.Why SQLite

The entire project — source texts, translations, cross-references, audit tables — lives in one SQLite file. That choice is deliberate, and it isn't about being trendy. It's about the opposite: durability and portability over the lifespan of a text that is, by nature, meant to outlast any particular piece of infrastructure.

• Offline by default. No server, no network, no account. Copy the file, open it, query it. A Bible should not require an internet connection to read.
• The same file, everywhere. SQLite runs natively on Android, iOS, desktop operating systems, and inside a browser via WebAssembly. The exact database that powers a website can be bundled into a phone app or opened directly on a personal computer — it's just as easy to use in a phone app as it is on a website or on a private computer, with no server in between any of them.
• Small. The published cross-edition index database (GOI_bible.sqlite3) is about 23 MB. The full set of generated text editions (English, Chinese, Greek source) shipped alongside it totals roughly 280 MB. The internal pipeline database, which carries per-word audit and provenance data and is not part of the public release, is larger still — but the public artifact remains a Bible that fits on a phone with room to spare.
• Portable. SQLite databases are a single file with a documented, stable on-disk format. No migration scripts, no version-locked server. The file you download today will open correctly in twenty years.
• Virtual tables & views as objects. SQLite's VIEW mechanism lets the database present pre-joined, pre-resolved "objects" — a verse with its correct word-sense already resolved for a given language, for example — without any application code. The database is the API.

That last point matters more than it sounds. In the project's preferred stack (SQLite views → PHP passing the view's rows directly → htmx altering the DOM), the "business logic" of which word to use for a given language and context lives entirely in the database as a view definition. The application layer becomes almost embarrassingly thin — which means it's also almost nothing to maintain, replace, or port.

Why start with one verse, one file?

Before any of this lands in SQLite, the translation pipeline itself works on the corpus as one plain-text file per verse — e.g. 001_GEN_002_004.txt. That's an unusual level of sharding, and it's deliberate:

• Guard-railed translation. Each call to the LLM is scoped to exactly one verse's worth of source text and context — not a chapter, not "keep going from where you left off." That bounds the model's working context tightly enough to make hallucinated or drifted content (extra sentences, merged verses, invented transitions) immediately visible: the output for one file is either a faithful rendering of one verse, or it's obviously wrong.
• The file count is the progress bar. 31,102 files in, 31,102 files out. "How much of the Old Testament is translated?" is ls | wc -l, not a query against a progress-tracking system that has to be kept in sync.
• Tautological filenames. The filename is the address — book, chapter, and verse are encoded directly in 001_GEN_002_004.txt, so there's no separate index to go stale, no mismatch between "what the file is called" and "what verse it contains." Anyone can `grep`, sort, or diff the corpus by filename alone and get meaningful results.

Once that sharded corpus is loaded into SQLite, the rigidity disappears and the flexibility shows up on the output side instead. The one-row-per-verse structure that made translation safe to shard also makes reassembly trivial — a chapter, a whole book, with verse numbers or without, is one SQL query away:

-- Whole chapter, with verse numbers (e.g. for study/reference view)
SELECT verse, rendering FROM v_effective_rendering
WHERE book='JHN' AND chapter=3 AND lang=:lang ORDER BY verse;

-- Same chapter, reading view — no verse numbers, just flowing text
SELECT group_concat(rendering, ' ') FROM v_effective_rendering
WHERE book='JHN' AND chapter=3 AND lang=:lang
GROUP BY book, chapter ORDER BY verse;

-- A whole book, concatenated, for export/printing
SELECT group_concat(rendering, '

')
FROM v_effective_rendering
WHERE book='JHN' AND lang=:lang
GROUP BY book, chapter ORDER BY chapter, verse;

Same underlying rows, three different presentations — verse-numbered study text, flowing reading text, or a print-ready book export — none of which required a different data format, export step, or reformatting pass. The sharding that kept translation honest and the flexibility that makes presentation cheap are two views of the same one-row-per-verse design.

Want to try this yourself? See SQLite Examples for copy-paste queries — generating the whole Bible, pulling a single chapter, building a word-frequency heatmap, and proximity-searching "light" near "dark" with an FTS5 virtual table.

IV.GOI + Virtual Tables: Why It's Powerful

The GOI gives every verse, in every language, the same address. SQLite views turn that shared address into pre-resolved "objects" that an application can read directly — no translation logic in the app layer at all.

Example: the sense-resolution view

Many words are ambiguous depending on context. Greek κύριος can mean "the Lord" or simply "master/sir." Hebrew אֱלֹהִים can mean "God" or "gods" or, in some constructions, "judges." Rather than re-litigate these calls for every new language, the New Testament pipeline resolves each ambiguous occurrence once, language-neutrally, and stores the decision as a sense key (e.g. KYRIOS.HUMAN_MASTER). A view then resolves, per word and per language, which actual word to render:

Status note: the sense-key view below describes the New Testament pipeline. The Old Testament's noun anchoring currently runs through a more direct noun_translations lookup table rather than this view; the two are being unified as the OT audit progresses.

CREATE VIEW v_effective_rendering AS
SELECT
    o.book, o.chapter, o.verse, o.word_pos,
    COALESCE(
        sr.rendering,              -- 1. sense-specific word for this language
        dr.rendering               -- 2. fall back to the language's default
    ) AS rendering
FROM verse_rendering_overrides o
LEFT JOIN sense_renderings   sr ON sr.sense_key = o.sense_key AND sr.lang = :lang
LEFT JOIN strongs_lang_renderings dr ON dr.strongs_num = o.strongs_num AND dr.lang = :lang;

The payoff: 1,060 contextual word-choice decisions across the New Testament were made once. A brand-new language inherits every one of them automatically by filling in just 16 rows — one per distinct sense. Sixteen decisions, made once, resolve a thousand contextual judgment calls forever.

Example: a "heat map" of any word across the whole Bible

Because every verse has a single integer position (its goi), counting how often a word appears and where is one query — group by a bucket of consecutive goi values and count matches. No separate search index, no precomputed table: the verse text and the ordinal axis are already in the same row.

SELECT (goi / 100) AS bucket,        -- ~100-verse "bins" across the whole Bible
       COUNT(*) AS hits
FROM v_effective_rendering
WHERE rendering LIKE '%light%'
GROUP BY bucket
ORDER BY bucket;

Plot bucket on the x-axis and hits as color intensity and you have a heat map of where "light" clusters across Genesis, the Psalms, John, Revelation — generated on the fly, in any language, because the bucket boundaries are the same ordinal positions for every edition.

Example: "find every 'light' within 4 verses of a 'dark'"

Proximity search — a notoriously awkward query in most text-search engines — becomes a self-join with an arithmetic range, because "4 verses away" is just ±4 on the goi axis:

SELECT a.goi AS light_goi, a.rendering AS light_verse,
       b.goi AS dark_goi,  b.rendering AS dark_verse
FROM v_effective_rendering a
JOIN v_effective_rendering b
  ON b.goi BETWEEN a.goi - 4 AND a.goi + 4
 AND a.lang = b.lang
WHERE a.rendering LIKE '%light%'
  AND b.rendering LIKE '%dark%';

This is the kind of question — "where do these two themes sit close to each other?" — that normally requires a dedicated search/indexing service. Here it's a join condition, because GOI already made "distance between verses" into ordinary subtraction.

Built on open addressing standards: OSIS and BCP 47

GOI is a project-internal ordinal — but the columns it's computed from are deliberately ordinary, standards-based identifiers, so the database speaks the same language as other Bible software:

• Book codes follow OSIS (Open Scripture Information Standard) conventions — GEN, PSA, MAT, REV, and so on — the same three-letter codes used by Bible software, OSIS-XML texts, and most public-domain Bible datasets. Anyone importing or exporting against this schema is working with identifiers they likely already have.
• Languages follow BCP 47 — the IETF standard used by browsers, HTML lang attributes, and CLDR locale data. language_subtag values like en, zh-Hant, or cmn-Hant-TW are valid BCP 47 tags, so a new edition's language identity plugs directly into web front-ends, font selection, and locale-aware sorting without a translation table of its own.

The combination matters: goi handles the "where is this verse, structurally" problem (which versification schemes disagree on), while OSIS book codes and BCP 47 language tags handle the "what is this verse, in standard terms" problem (which everyone else's tooling already understands). GOI doesn't replace those standards — it's the ordinal index built on top of them.

V.The Case for GOI Bible — and Its Audit Trail

Yes — the translation is 100% AI-generated. That is precisely why it is audited the way it is.

A traditional translation committee's working notes rarely survive publication. The GOI Bible takes the opposite approach: every verification pass, every flagged verse, and every correction is logged, reproducible, and re-runnable. We're not claiming the result is finished or scholarly-grade — we're claiming the process is unusually transparent, and publishing the evidence so that claim can be checked rather than taken on faith.

The current workflow, stage by stage

This is how a language goes from nothing to a released edition today. It is written as a sequence of gates: each stage has to pass before the next one starts, and every stage is a script in the repository that can be re-run. The order below is the order we actually work in.

Stage 0 — Principles that govern every stage

• Translate only from the original languages. Hebrew (Westminster Leningrad Codex / MorphHB) for the Old Testament and Greek (Textus Receptus 1550) for the New Testament. KJV, WEBUS, public-domain national Bibles (Louis Segond 1910, Riveduta 1927, and so on) and sibling GOI editions are references for checking only. They are never a translation source and never overrule the source text.
• One verse, one file. Each of the 31,102 verses is generated, stored and checked on its own, so any single verse can be regenerated, diffed or rolled back without touching its neighbours.
• A prompt is not a gate. Instructions to the model are never trusted to enforce a rule. Rules are enforced by code that runs before a verse is written, and a verse that fails is never counted as translated.
• Zero is a state we can check. When a measure has a literal zero (open flags, missing nouns, undocumented misses), we push to zero, or to a documented human-review blocker, and never stop at “good enough percent.”
• AI is a draft, not an authority. The product of this project is the evidence trail around the draft, not trust in the model.

Stage 1 — Sharding: one verse, one file

Every Bible text in the project, whether source, reference or finished edition, is first broken (“sharded”) into its smallest unit: a single verse per file. A verse file is named by book number, book code, chapter and verse plus the edition tag, for example 001_GEN_001_001_KJV.txt, and one directory holds all 31,102 of them for that edition.

• Why shard. A verse can be generated, checked, diffed, regenerated or rolled back on its own without touching its neighbours. Runs resume from the first missing file, and a failure costs one verse, never a chapter.
• Atomizing is scripted per source. Each reference text arrives in whatever shape its publisher uses (verse-per-line exports, zipped archives); a small per-edition script atomizes it into the same one-file-per-verse layout, so every edition looks identical to the tools downstream.
• Files are checked as files. File counts, naming, exactly one line per verse, nothing empty and canonical punctuation are validated across the whole directory (see the integrity gates below).

Stage 2 — Alignment to the KJV spine: 31,102 verses

Before any word is translated, every edition is aligned to one shared verse spine: the King James Bible’s 31,102 verses. Each position gets one integer, the Global Ordinal Index (GOI), and every edition in every language is keyed by it.

• The spine. 66 books, 1,189 chapters, 31,102 verses: 23,145 Old Testament and 7,957 New Testament. “Does this edition have every verse in the right order?” becomes a database query.
• Source texts are realigned onto it too. The Hebrew Westminster Leningrad Codex and the Greek Textus Receptus are mapped onto the same GOI addresses, so a Hebrew verse, its English verse and its French verse are the same row. An earlier naive row-order alignment of the Hebrew was found to be 81.1% mismatched (it diverged at Genesis 32:1) and was replaced with an explicit, verified one.
• Versification seams are mapped, not guessed. Hebrew and English number some verses differently (Psalm titles, Isaiah 63/64, Joel 2/3, Malachi 3/4). Each seam is recorded as an explicit map.
• Count equality is never trusted. An edition with the right number of verses can still be shifted (a national Bible that mixes Hebrew and English numbering, for example Psalm 13 in the Louis Segond). Alignment is therefore verified by content, chapter by chapter, against the Hebrew and Greek directly, not against KJV as a proxy.
• Result. Every aligned edition covers all 31,102 addresses with none missing, extra or duplicated, and a chapter-level report shows 1,189 of 1,189 chapters matching.

Stage 3 — The tagged source layer

• Every source verse carries Strong’s numbers and morphology for each word: Hebrew (Westminster Leningrad Codex / MorphHB) for the Old Testament and Greek (Textus Receptus 1550) for the New. This lets a machine enumerate exactly which source concepts must appear in a translated verse without anyone re-reading it.
• Textual-policy brackets are decided once and applied identically in every language: [ ] marks a conflicted reading and { } a supplemental traditional reading.
• Every proper name gets a canonical source entity independent of any translation’s spelling, so names can be grounded in the prompt and checked afterwards.

Stage 4 — A public-domain Bible, used purely for noun matching

For each target language we line up an old, public-domain Bible in that language, aligned verse for verse to the same 31,102 positions. Its only job is to check nouns and names.

• Examples. English: KJV and WEBUS. French: Louis Segond 1910. Italian: Riveduta 1927. Russian: Synodal 1876. Vietnamese: the 1934 Bible. Others follow the same pattern per language.
• What it is used for. Does a proposed rendering for a Strong’s noun actually appear in a real Bible in that language? Is a proper name spelled the way that language’s tradition spells it? Is a default the wrong sense (a word the reference never uses for that concept)? It is the evidence behind the noun-table validation and the “corroborated absence” test in triage.
• What it is never used for. It is never a translation source, never allowed to overrule the Hebrew or Greek, and it is kept out of the translator’s prompt, because supplying it measurably increased copying. It only corroborates after the fact.
• Public domain only. No modern copyrighted translation is ever used as a reference. That is both a licensing line and the reason the finished editions are free to publish.

Stage 5 — The noun table

Before any translation, each language gets its own noun table: one row per source Strong's number (every Hebrew noun and every Greek noun), holding the approved rendering in that language, with a status, a confidence, and where the rendering came from. The table is the contract between the source and the translator: it says which target word a given source noun is expected to become.

• Defaults and the sense layer. Most nouns have one default rendering. A set of 16 high-polysemy senses (words whose meaning splits) carry a separate rendering per sense, so the right word is chosen by default instead of being repaired verse by verse later.
• Homographs are separate entries. A common noun and a proper name that share a Strong's number (a “storm” and a place named for it) are different lexemes. Mixing them once caused a wrong default to be forced into 16 verses.
• Where the table is complete and where it is not. Every language has a New Testament noun table. A per-language Old Testament noun table exists for French, Italian, Russian, Japanese, Korean and Chinese. Spanish, Portuguese, Vietnamese and English do not have one yet, so their Old Testament noun coverage, plurality and gender checks cannot be run; that gap is open work, not a pass.
• Singular defaults. The table stores the singular and lets the matcher derive the plural. Plural-only defaults caused false rejections in French.
• Pre-run sweeps. Before a run we scan the table for English words that leaked into a non-English lexicon, for two different source nouns collapsing onto one target word within a verse, and for defaults that look wrong against a real translation.
• Reference-text validation. For French and Italian we align a public-domain Bible (Louis Segond 1910, Riveduta 1927) to all 31,102 positions and measure whether each default actually appears in it. For French this flagged 764 low-agreement defaults before a single verse was translated; 421 were corrected up front. The reference is used only to corroborate, and is deliberately kept out of the translator’s prompt, because it measurably increased copying.

Stage 6 — The language cube (the vector system)

The noun table is stored in a language cube: a SQLite database plus two vector indexes, built so the translator and the checkers can retrieve the right evidence for any noun in any verse.

• Built in a fixed order: a complete Hebrew Old Testament cube first (168,100 rows), then a complete Greek New Testament cube (36,846 rows), and only then the target-language cube. A full target cube is those same 204,946 rows: one per source noun occurrence, each with the verse it sits in and a local window of words around it.
• SQL is authoritative. Every occurrence, Strong's identity, source morphology, target rendering, observed target form, provenance and review status lives in ordinary SQL tables. The vector indexes are disposable and can be rebuilt from SQL at any time.
• Sparse index (exact). A deterministic 4,096-dimension hashed-feature vector over words, character n-grams, Strong's IDs, morphology, gender, number and case. It answers exact questions: “every occurrence of this Strong's number in this grammatical form.”
• Dense index (semantic). A Qwen3-Embedding-8B embedding, truncated from 4,096 to its first 1,024 dimensions, L2-normalized and stored as 16-bit floats. It answers fuzzy questions: “verses that use this word in a similar sense.” It is retrieval evidence only. It never overrides the grammar, the Strong's mapping or a review decision.
• A hard gate. The translation script refuses to start unless the cube is complete, current and its dense index finished. Rebuilding a cube invalidates its dense index until embedding finishes again, so a stale cube cannot silently feed a run.
• Across languages the project currently holds seven cube profiles (Hebrew, Greek, English, Arabic, French reference, Italian reference, Chinese) totalling about 1.2 million vectors.

Stage 7 — Plurality and gender

Grammar is stored as explicit, queryable columns, not left to the model’s instincts.

• Plurality. Each noun records the source number (Greek exactly from the morphology tag; Hebrew from the word ending, with a closed list of exceptions such as “his father,” which looks plural but is singular, and the plural-of-majesty Elohim used of the one God), the number of the target citation form, and the reviewed plural forms including irregular ones. Hebrew and Arabic also have a true dual, kept as its own value. The translator is told to render meaning, not copy form: a source plural can legitimately be a target singular (“water,” “face”).
• Gender. Source grammatical gender is not expected to survive into the target; it is a formal property, not something to preserve. What we check is agreement inside the target language: does the article, adjective or participle agree with its own noun. The cube stores the target noun’s lexical gender for exactly that purpose.
• Human referents are handled as sense, not gender. A human messenger rendered “angel” (342 verses fixed), or ruach “wind” rendered “spirit” (158), are swept as wrong-sense defects.
• Language profiles. Each language is registered with which categories it even has (number, gender, case, dual, classifiers). Vietnamese, Chinese, Japanese and Korean do not mark number on the noun, so they are checked for the right classifier or particle instead of a singular/plural flip.
• What is and is not automated today. Every language has a plurality verification table: the source number (Greek morphology, Hebrew word ending) against the number of the word actually found in the translated verse, with off-diagonal cells listed as candidates for review, never as proven errors. Languages that do not mark number on the noun (Chinese, Japanese, Korean, Vietnamese) are checked for the plural marker instead. Every language that has grammatical gender (Spanish, Portuguese, French, Italian, Russian, Arabic) has a gender table of its nouns, and for Spanish, Portuguese, French and Italian we check that the article or demonstrative directly before the noun agrees with it. Adjective agreement is still only a candidate list, because free word order and participles make it unreliable; Arabic’s tables are being finished separately. These tables are built by an LLM and checked by rule, so a wrong gender entry is possible; none has had native review.

Stage 8 — The translation run

• Model and provider. Automated translation and audit calls use one approved provider and model (DeepSeek). Every batch logs the provider, exact model, prompt version, temperature, source commit, request count and token totals.
• Per verse. The model gets the source verse, the required noun anchors from the noun table, the cube’s grammar features for those nouns, and the approved name spellings from the names database. Temperature is low, one verse per response, no commentary.
• The anchor gate. Before the verse is written, the language’s matcher checks that every required anchor is present (with inflection and stem matching). A miss triggers a targeted rewrite; a second miss is a hard failure that goes to quarantine instead of the corpus.
• Supervised, resumable runs. A single-worker lock, an append-only log, resume from the first incomplete coordinate after any failure. Existing validated files are skipped.
• Rollout order for every language: the four Gospels first as the New Testament test corpus; the rest of the New Testament only after those pass every gate; then the Torah as the Old Testament test corpus; then the rest of the Old Testament.

Stage 9 — Coverage verification

• Every source noun occurrence must have its expected rendering, an approved synonym or a per-verse override present in the translated verse. The release threshold is 100% after documented textual-policy suppression and narrow, reviewed overrides. A partial percentage is a failure report, never a completion metric.
• Per-verse overrides over global synonyms. When a word is right almost everywhere but wrong in one verse, we fix that verse only. Adding a global synonym fixes the miss everywhere it could ever occur and slowly makes the checker permissive, so it is the last resort.
• Documented misses. A miss that survives is only acceptable with a recorded review receipt. French finished with every remaining miss documented (45 in the New Testament, 754 verses in the Old Testament) and 0 undocumented.
• The checker is a substring-presence proxy, not a proof of correctness. That is why the later stages exist.

Stage 10 — Quarantine and the red / orange / yellow / green triage

Verses that fail the anchor gate are not discarded; they are quarantined with their draft and sorted by a deterministic, re-runnable triage into four tiers:

• Red — the draft is defective. It fails a lint rule (a foreign script, commentary, unbalanced quotation marks), is empty, or its length is wildly out of proportion to the Hebrew or Greek source.
• Orange — probably a real content problem. A required anchor is missing from our draft even though the reference Bible uses that word, and it is a proper name, or there are two or more such misses, or the draft is also short.
• Yellow — secondary issue, translation likely fine. A related form of the anchor is present (a matcher gap), or the anchor is absent from both our draft and the reference (the default is probably the wrong sense here), or a single common noun is worth a glance.
• Green — promotable as is. Every anchor now matches under the current matcher and the draft passes lint.

Each verse then ends in exactly one of three states: fixed (regenerated or hand-corrected, with the defect fed back as a hint), accepted with a written review note (the checker was wrong), or closed as a false positive. The triage reads the current matcher and defaults every time it runs, so fixing a default turns whole groups of verses green without touching them. French Old Testament: 893 quarantined verses resolved to 0 (550 accepted with review, 268 green after matcher and default fixes, 75 hand-fixed). Russian Old Testament: 23,145 of 23,145 verses green.

Stage 11 — Clause and meaning checks

• A second model pass compares each translated verse back against the Hebrew or Greek, looking for dropped clauses, reversed negations, wrong numbers, swapped subject and object, and false friends (for example ἀφίημι rendered “forgive” where the sense is “leave”).
• Every flag is reviewed. Results so far: English Old Testament 1,276 flags reviewed (1,133 fixed, 143 closed as false positives); Chinese Old Testament 604 reviewed (214 fixed); New Testament English and Chinese 98 flags (3 genuine fixes; the rest traced to a response-length cap in the checker itself, which we then fixed).
• Lesson recorded: before a multi-pass checking run, the checker’s own configuration (token limits and so on) is verified, so noise from the checker is not mistaken for noise in the translation.

Stage 12 — Wrong-sense sweeps

Because the coverage check can pass a wrong word that happens to match, we also sweep for systematic wrong-sense defaults across a whole language: a human messenger rendered “angel” (342 verses), wind rendered “spirit” (158), a stave rendered “alone” (27), a rock hyrax mistaken for another animal, offering lists in Numbers 7 and 29. Russian closed its sweeps to zero (Old Testament 6,220 fixed and 948 kept; New Testament 429 fixed and 65 kept).

Stage 13 — Script, structure and integrity gates

• Script gate. Each language has an allow-list of Unicode scripts. Anything else (Cyrillic in the French, Korean in the Chinese, leaked English scaffolding) fails the run. We never add a foreign script to the allow-list to make a failure go away.
• Structural validation. File counts, naming, one line per verse, nothing empty, canonical punctuation, and, for Chinese, an exact Traditional/Simplified mirror check.
• Matcher-table duplicate check. The hand-edited synonym tables are scanned by syntax tree for repeated keys, because a repeated key silently discards an earlier fix. This once hid 15 fixes in the Korean table.
• Ordinal integrity. Every released database must contain exactly the expected verses with ordinals running 1 to 31,102 with no gaps, duplicates or empty verses.

Stage 14 — The cross-language regression ledger

A defect found in one language is written once to a shared ledger and then checked in every language that could share it. A fix to the wrong word for a rock hyrax, a flock-offspring phrase in Deuteronomy or the Numbers 7 offering lists is therefore not left to be rediscovered language by language. The most recent release closed 30 such ledger issues across all editions at once.

Stage 15 — Release and deployment

• A guarded release script rebuilds the edition’s SQL and download database, rebuilds the shell and manifest, and proves that every flatfile matches its database. A release is accepted only when the integrity check passes for every active edition (14 at present).
• Each download database is published with its size and SHA-256 in a manifest. The Android and desktop apps read that manifest, so a new edition appears for existing installs with no new app build.
• The website’s online reader and the EPUB e-books are rebuilt from the same databases. Deployment to the server is preceded by a timestamped rollback copy, and the live result is queried afterwards.

Stage 16 — Current status and honest limits

• No native-speaker review has been done. Everything above is automated checking plus AI review. A native reader will find things this process cannot.
• Gender and plurality checks are table-driven and flag candidates; they are not proof. A flagged verse is reviewed by a person (or a second model pass), and many flags are legitimate translation choices (a Hebrew collective singular rendered as a plural, for instance).
• The Chinese cube’s semantic index is still being built.
• Coverage is a presence check, and the reference Bibles used for corroboration are themselves human translations with their own choices.

What the audit has found so far

Live status — what's actually done

The table below is the page's attempt to say, in one place, exactly what stage each part of the pipeline is at — so a visitor (or a reviewer) doesn't have to infer it from prose.

Honest caveats — published, not hidden

• This is a first-pass AI translation. It is readable and the mechanical checks above have passed, but it is not a substitute for a peer-reviewed scholarly translation for doctrinal study.
• The numbers above are a snapshot of an active, ongoing audit — they will change, in both directions, as passes are rerun and scope widens (e.g. the OT clause-check flag count has moved as the checker itself has been refined).
• Where the AI translation is closely worded like the public-domain KJV or WEBUS (used only as QA references), those overlaps are measured and reported (mean Jaccard similarity ≈0.55–0.64 corpus-wide) — and because both reference texts are public domain, this does not encumber the result.

The case for GOI Bible isn't "trust the AI." It's "don't trust the AI — check it against the source automatically, log every check and every fix, and let anyone re-run the checks."

For the full write-up of this pipeline — including the sense layer, reviewer checklist, and FAQ — see the Methodology page.

VI.The Bigger Picture: A Bible in Every Language, Under $10

There are over 7,000 living languages. Roughly 1,500 of them have no Bible translation at all, and many more have only partial translations. The traditional cost of closing that gap — in person-years — is enormous.

The GOI pipeline reframes the cost structure entirely:

• Draft translation cost: ~31,000 verses, run through an LLM API at commodity per-token pricing. At current rates, a full Old + New Testament first-pass draft for one language costs single-digit dollars in compute. (Verification and correction — the work described in the audit section above — is additional, ongoing compute plus human review time, not included in this figure.)
• Sense disambiguation cost: 16 rows per language — a few minutes of bilingual review — unlocks correct contextual rendering for over a thousand previously-resolved ambiguous positions.
• Audit cost: the same noun-coverage and clause-check pipeline that audited English and Chinese runs against any new language's Strong's-tagged renderings, for the same marginal cost as the original translation pass.
• Distribution cost: effectively zero. The output is rows in a 23 MB SQLite file. Adding a language adds a few megabytes of text, not a new deployment.

None of this replaces the work of native-speaker reviewers, linguists, and communities who will ultimately decide what a faithful translation in their language looks like. What it does is remove the first-draft bottleneck — and hand reviewers a draft that has already been checked for the mechanical failure modes (missing words, dropped clauses, flipped negations, wrong numbers) that used to consume a large share of review time.

Audio: coming soon. Text-to-speech has reached the point where a clean, per-verse text corpus is most of the work of producing an audio Bible. Because every verse is already a single, addressable row — checked, GOI-indexed, and language-tagged — generating a full spoken edition is the same "fill in one more column" pattern as everything else in this pipeline, in any of the supported languages, not just the handful that traditionally get audio recordings.