A complete Bible, in any language,
built on a single portable file.

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 pipeline

Every arrow in this diagram corresponds to a script in the repository. Nothing here is a one-time manual pass — the whole chain can be re-run.

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.