Methodology

The People's Open Bible is produced by a pipeline that treats every verse as auditable. Each rendering is committed alongside the source text behind it, the draft/revision metadata that shaped it, and any later edit with its rationale. This document is a reproducibility map: it shows the sources, review layers, and public artifacts someone would need in order to inspect or reproduce the results without replaying our internal work log step by step.

Source-distinction checkpoint (2026-09-06)

Drafting and the main review lanes now require an explicit source-distinction check, including concrete full-verse English proposals where a source pattern is hidden. An unchanged verdict alone is not a fidelity certification. Pending proposals are retained outside publishable translation files for maintainer review; they are not automatically applied. Existing records are not silently relabeled as having passed this new checkpoint.

See the John 21 root-cause investigation and tools/prompts/source_distinction_policy.md. A read-only heuristic scan is available with python3 tools/source_distinction_audit.py --output /tmp/pob-distinction-leads.json. It detects review leads, not every semantic issue, and never rewrites Scripture.

Pipeline overview

  source text  ──▶  first draft  ──▶  revision pass    ──▶  spot fix         ──▶  publication
  (SBLGNT,         (GPT-5.4,          (Gemini 3.1 Pro       (Claude Opus 4.7      (commit +
   WLC, UHB,        prompt             reads draft           on individual         tagged
   Swete LXX,       anchored           against source;       verses needing        release +
   Charles APOT,    in DOCTRINE)       applies edits         targeted rework)      CDN publish)
   Bensly Latin,                       or marks
   Charles 1895                        unchanged)
   Ge'ez,
   Coptic NHC)

Model diversity is a deliberate quality layer: any revision pass run by a different model from the first drafter helps fight same-model bias. Cross-pollinating model families gives the strongest reasoning and best outcome; spot fixes are an additional targeted pass when a verse needs more scrutiny.

Per-verse stages 1–4 are described below. For revision policy and what triggers a post-publication change, see REVISION_METHODOLOGY.md. For doctrinal and lexical defaults, see DOCTRINE.md and PHILOSOPHY.md. For the source-licensing inventory, see REFERENCE_SOURCES.md.

For selecting between ancient source readings, use the source-wording adjudication method. It gives older manuscripts a modest preference without making age decisive, separates witness transcription from critical-text selection, and requires explicit alternatives and uncertainty. Its first applied pilot is the multi-witness Hebrew report.

Reproducible workflow at a glance

The translation came together across four overlapping corpora. The details below are not meant as a run-by-run history; they name the source families, repeatable checks, and durable outputs that matter for reproducing or auditing the work.

Chapter 1 — Canonical corpus

The internal pilot and milestone order are preserved in commit history and older operational docs, but they are not the important thing to reproduce. For a reader or outside reviewer, the repeatable unit is the verse record: source evidence, draft metadata, review result, and published artifact.

Chapter 2 — Deuterocanon

The deuterocanon broke the canonical pipeline because no openly-licensed scan-grounded source corpus existed. Source preparation became its own project before drafting could even start.

Chapter 3 — Extra-canonical witnesses

Extra-canonical material is translated for transparency about the Jewish/early-Christian textual world — not claimed as scripture, but surfaced so readers can see what existed alongside the canonical books. Each language family forced a different OCR + parser stack.

Chapter 4 — Standing review pipeline

Public reader surfaces deliberately separate those numbers. The large total_revisions value means all accepted applied edits, including machine-assisted review-pass fixes. The small homepage badge uses approved_significant_revisions (with approved_proposed_revisions kept as a backwards-compatible alias): approved reader/maintainer proposals plus major source-grounded review findings that were accepted into the public text. It intentionally excludes routine Tier-1 cleanup, grammar-only polish, and the much larger machine-assisted full-pass total, so the badge represents revisions that materially changed meaning, source fidelity, doctrine alignment, verse boundaries, or restored broken/truncated text.

The standing review pipeline is the project's current center of gravity. If you load a verse YAML at random today, the most likely thing you'll see beyond the original draft is a revision block from this pass.

Stage 1 — Source text preparation

Source texts are vendored under sources/ with their original licenses and verifiable provenance. The headline sources:

• SBLGNT (CC-BY 4.0) — Michael W. Holmes, ed., The Greek New Testament: SBL Edition. Society of Biblical Literature, 2010.
• Westminster Leningrad Codex — transcription of the Leningrad Codex (1008 AD).
• unfoldingWord Hebrew Bible (CC-BY-SA 4.0) — morphologically tagged Hebrew OT.
• Swete LXX (public domain) — Henry Barclay Swete, ed., The Old Testament in Greek According to the Septuagint, 3 vols. (Cambridge University Press, 1909–1930). Vendored as our own OCR transcription under CC-BY 4.0 at sources/lxx/swete/.

For the deuterocanon and extra-canonical works, source preparation is a substantial project of its own — the per-book table below.

Stage 1A — Per-book source strategy

Different corpora demand different OCR engines and different witness strategies. The choice is empirical, not aesthetic. The current defaults reflect the 2026-04-22 OCR bake-off; earlier choices are preserved in the phase docs for historical completeness.

Default, in one sentence: Gemini 3.1 Pro for non-Greek and difficult layouts; Azure GPT-5.4 for clean Cambridge polytonic Greek; the other serves as second-pass reviewer.

Stage 1B — Three-tier scan-grounded adjudication

Every deuterocanonical verse is adjudicated against multiple witnesses at full scan resolution before it is allowed to feed the drafter:

1. Tier 1 (4-source comparison at ≥3,000 px). Our Swete transcription is compared against three independent witnesses: First1KGreek TEI, the Rahlfs-Hanhart digital edition (consulted as reference, see Zone-2 policy below), and Amicarelli/BibleBento. The verdict is scan-grounded: confidence is rated by visual legibility of the Cambridge page, not by witness agreement alone.
2. Tier 2 (Gemini cross-check). Verses that remain uncertain after Tier 1 are escalated to Gemini for a second opinion against the scan.
3. Tier 3 (content-based page re-identification). When running- head parsing has missed a page, the verse text itself is used to relocate the correct printed page and the rescue runs against the right scan.

The confidence rubric:

• high — printed form unambiguous; witnesses agree or disagree for explainable reasons; we trust this verse.
• medium — character-level ambiguity remains (ligature, breathing mark, faded ink); honest residual uncertainty.
• low — unverifiable from the available scans; deferred or held out of the drafter input.

The deuterocanon source rescue ended with 98.9% high (3,425/3,464 adjudicated), 1.1% medium, 0% low. The full rescue methodology — including the failure taxonomy (wrong-page targeting, verse-number drift, edition-specific numbering, true paleographic ambiguity) — is documented in docs/PHASE8_CORPUS_QUALITY_RESCUE.md.

The tooling: tools/adjudicate_corpus.py, tools/adjudicate_escalated.py, tools/adjudicate_escalated_gemini.py, tools/rescue_manual_pages.py.

Stage 2 — First draft

A primary LLM produces the draft using a prompt anchored in DOCTRINE.md. The draft includes:

• English rendering
• Lexical decisions (key words, chosen glosses, alternatives, lexicon entry consulted)
• Theological decisions (contested readings, alternatives preserved in footnotes)
• Source-text citations (edition + pages, archive.org-linkable where possible)

The drafter prompt loads, in addition to the verse, the relevant doctrinal-anchor excerpt from DOCTRINE.md, the relevant philosophy excerpt from PHILOSOPHY.md, and any per-book apparatus or witness parallels recorded for that book.

Draft metadata recorded per verse:

• model_id — e.g., gpt-5.4, gemini-3.1-pro-preview, claude-opus-4-7 (used for occasional spot fixes)
• model_version — knowledge cutoff + release tag
• prompt_id — versioned prompt identifier (e.g., nt_draft_v1)
• prompt_sha256 — hash of the exact prompt used
• temperature — generation parameter
• timestamp — ISO 8601 UTC
• output_hash — sha256 of the model's raw output

The drafting script is tools/draft.py. Source text, model metadata, and prompt/output hashes are recorded for inspection. A prompt hash alone is not the prompt, and rerunning a hosted model is not guaranteed to produce an identical draft; there is no enforced byte-for-byte AI reproducibility check.

Stage 3 — Revision pass

What actually runs on every verse today is a two-stage pipeline: a primary drafter, followed by an independent revision pass on a different model family. The original design document called for running three frontier models in parallel and scoring agreement on edit distance and lexical-key overlap. We still use that comparison selectively for high-uncertainty verses, but it is not the default per-verse path. The honest description is:

1. Primary drafter. Most canonical books were drafted by GPT-5.4; Ge'ez and Coptic books were drafted with Gemini 3.1 Pro feeding off Gemini 3.1 Pro OCR transcripts; specific verses with content filtering issues were redrafted with Gemini 3.1 Pro as a fallback (97 Azure-blocked verses in 4 Maccabees and other martyrdom passages, processed 2026-04-23). Claude Opus 4.7 has been used for occasional spot fixes on individual verses needing targeted rework or another independent model-family pass.
2. Revision pass. Gemini 3.1 Pro reads each draft against the source text, identifies lexical disagreements, awkward English, and category-1 grammar issues, and adjudicates whether to apply a change or mark the verse unchanged. Every verdict is logged. Every applied edit is recorded in the verse YAML's revisions array with from, to, rationale, and reviewer_model.
3. Tier-3 adjudicator. Verses where the primary drafter and the revision pass disagree on something doctrinally salient are escalated to Azure GPT-5.4 for a third opinion. The deuterocanon drafting pass produced 451 such adjudications.
4. Doctrine + grammar lint. A regression layer catches cases where an automated revision silently violates a documented project policy (e.g., Χριστός being changed back to "Christ" against DOCTRINE.md). Reverts are visible in the same revisions array.

This is the project's strongest defense against hallucination. A draft from one model family, read against the source by a different model family, with a separate adjudicator on disagreements and a mechanical lint on policy violations, produces a more trustworthy verse than any single model run in isolation. Disagreements are not a bug — they are the signal we want to surface.

For verses that the lint or adjudicator has flagged repeatedly, a selective comparison-of-three-models run is invoked, scored on edit-distance + lexical-key overlap. The scoring thresholds and escalation rules live with the tooling rather than on this page; see tools/cross_check.py. The revision-pass tooling lives in tools/gemini_bulk_revise.py and tools/adjudicate_escalated_gemini.py.

Stage 4 — Publication

Drafted and revised verses are committed to the main branch. Each commit message references the related source range and the model that produced the draft. Earlier preview tags exist in the git history as historical milestones; current state of the translation is well beyond them.

Every verse in the repository is marked status: draft. The Cartha Open Bible does not currently have a formal scholarly review process; published drafts are the AI's output, with the full rationale visible alongside each rendering. Revision happens after publication, in the open, with full provenance preserved (see REVISION_METHODOLOGY.md).

The website and mobile apps do not read this repo directly for Bible text. They both pull a compiled JSON snapshot from the CDN at https://bible.cartha.com, regenerated whenever new drafts or revisions land on main.

Per-verse provenance schema

Each verse YAML at translation/<testament>/<book>/<chap>/<verse>.yaml records:

• source.text — the Greek/Hebrew/Ge'ez/Latin/Coptic string
• source.edition — named edition (e.g., lxx-swete-1909, charles-1913-apot-vol1, charles-1895-ethiopic)
• source.pages — archive.org-linkable page numbers
• source.confidence — high/medium/low (scan-grounded for deuterocanon)
• adjudication (if scan-grounded) — which witnesses agreed, which didn't, rescuer's verdict
• translation.text — the English rendering
• lexical_decisions — per-word gloss + rationale + alternatives
• theological_decisions — contested readings, alternatives, footnotes
• ai_draft — model_id, prompt_hash, output_hash, timestamp
• revisions — array of {from, to, rationale, reviewer_model, timestamp} entries; the original draft is preserved alongside every applied edit

Schema definition: schema/verse.schema.json.

A reader who wants to verify any verse can pull the Zone-1 source edition from archive.org, find the cited pages, compare the printed text against source.text, and inspect the confidence and adjudication fields to see what was uncertain.

Revision policy

Drafts are not the final word. Every phase is followed by a revision pass that runs in three layers (REVISION_METHODOLOGY.md, docs/REVISION_PROCESS.md):

• Layer 1 (during drafting). tools/consistency_lint.py can be run on drafted records to flag same-lemma-different-gloss without rationale, contested-term policy gaps or overrides, and empty source text. This editorial lint is not yet a required merge check. Reader-corpus and catalog validators provide separate structural checks.
• Layer 2 (per-phase revision). After a phase draft is complete, the corpus is revised in thematic batches. The Pauline runbook (docs/PHASE1_REVISION_RUNBOOK.md) defines five batches: (1) Pauline core vocabulary (πίστις, δικαιοσύνη, σάρξ, νόμος, χάρις, κύριος, Χριστός), (2) Eucharistic and body-of-Christ passages, (3) OT citation handling, (4) readability sweep, (5) cross-reference verification.
• Layer 3 (whole-Bible). Once a full draft exists across both testaments, voice is unified across OT/NT and cross-phase inconsistencies are resolved.

What triggers a revision: real English grammar awkwardness; rhetorical-force loss; wordplay the draft flattened; scholarly preference drift without a textual reason; corpus-level inconsistencies. What does not trigger a revision: stylistic preference, theological re-interpretation absent textual evidence, lexicon-entry quibbles. Full criteria in REVISION_METHODOLOGY.md.

Revision commits preserve the original ai_draft provenance — the prior rendering is visible in git log, not deleted from the YAML. Commit subjects start with revise, polish, normalize, rename, or consistency so the public progress dashboard can filter them.

Global normalizations

A small number of decisions apply at corpus scale, not per-verse. These are documented in REVISION_METHODOLOGY.md under "Global-scope normalizations" and include:

• Χριστός → Messiah (decided 2026-04-18, applied to ~68 verses). "Christ" preserved as alternative in footnotes. Liturgical carve-outs: Pauline benediction formulas (Rom 16:20, 2 Cor 13:13, Gal 6:18, Phil 4:23, 1 Thess 5:28, 2 Thess 3:18, Phlm 25, 2 Cor 8:9) and the Phil 2:11 confession revert to "Christ" because they are fixed liturgical forms in the early church.
• μετανοέω context-sensitive rendering (decided 2026-04-19). "Change of mind" / "change your thinking" in cognitive contexts; "repent" in specific-sin contexts. Per-context rule.
• יְהוָה → Yahweh throughout the OT and deuterocanon, against the traditional "LORD". The divine name is a name. Where the NT quotes an OT YHWH passage using Greek Κύριος, the NT verse uses "Lord" to preserve the Greek surface — these are quotation markers, not theological softening.

Each normalization has a commit history showing the mechanical change and a documented set of carve-outs.

Reproducibility verification

There is not yet a one-command, end-to-end verifier that re-runs the LLM drafts, revision passes, and source-image transcription. The per-verse records expose the cited source text, model and prompt identifiers, hashes, and revision history for inspection, but a hash alone does not preserve the exact prompt or guarantee that a hosted model will produce the same output later. Re-running an AI pass is a comparison, not a byte-for-byte proof.

The checks that can currently be repeated locally without model access are the catalog, Psalm-numbering, and reader-corpus validators described below. For an exact published edition, verify its release asset against the SHA-256 checksum in that edition's release notes and the associated source commit.

Consistency linting

tools/consistency_lint.py scans drafted verse records and flags:

• Same Greek / Hebrew word translated with different English glosses without a documented rationale
• Lexical decisions that contradict DOCTRINE.md's default renderings without explicit override
• Empty source text

This editorial lint is not currently a required merge check. The reader corpus validator (python3 tools/validate_reader_corpus.py --malformed-yaml error) checks YAML syntax and known reader-facing duplication regressions. python3 tools/lint_psalm_numbering.py --strict and python3 tools/extra_texts/validate_catalog.py --all check their respective corpus contracts. None of these checks establishes textual accuracy or scholarly approval.

Public disagreement workflow

Any reader — scholar, pastor, or lay — can file an issue against a specific verse using templates in .github/ISSUE_TEMPLATE/:

• verse_concern.md — general concern about a rendering
• lexical_disagreement.md — disagreement with a specific word choice
• theological_disagreement.md — disagreement with a contested- reading resolution

The reader's "Suggest Revision" form on cartha.com prefills these templates from the verse YAML so the issue is self-contained.

If one of those proposals is approved and committed, it can carry public credit metadata in the verse's revisions: block. Maintainer proposals are also marked through their adjudicator metadata. Together, those accepted proposals are what the public homepage counts as approved revisions; they are intentionally kept distinct from the larger machine-assisted applied-edit total.

The project commits to responding publicly to every substantive issue. Resolution may result in:

• No change, with rationale posted (and linked from the verse YAML)
• A revised rendering, committed with full provenance update
• Elevation of an alternative to main text with the original preserved in footnote (or vice versa)

All outcomes are documented publicly. Nothing happens in private email.