@@ -7,6 +7,16 @@ tagging for a German Bible by LLM alignment — license-clean, quality-measured,
77shippable in the data pack — instead of adopting the encumbered community
88modules.*
99
10+ > ** Reminder — first moves, before any bulk spend:**
11+ > 1 . * Afternoon spike:* hand-build a ~ 10-verse Luther jsonl (same header
12+ > schema, stamp ` lut1912-tok1 ` ) and load it through
13+ > ` pure_engine_open_from_bytes ` — the loader ignores ` format ` and accepts
14+ > any tokenization stamp, so German text renders in the reader today. This
15+ > proves the display path end to end.
16+ > 2 . * Pilot before corpus:* run Ruth + 1 John (~ 190 verses) through the full
17+ > prompt → verify → adjudicate loop and ** measure the error rate** (see
18+ > QA protocol below) before submitting the 31k-verse batch.
19+
1020### Background (why build our own)
1121
1222- The existing Strong's-tagged Luther 1912 modules are of unknown provenance;
@@ -76,6 +86,55 @@ makes it both tractable and mechanically verifiable.
7686 de-hardcoding work from the German-support assessment (corpus filename,
7787 ` TOKENIZATION_VERSION ` , book-name aliases, "Johannes 3,16" ref parsing).
7888
89+ ### Methodology recommendations
90+
91+ ** Prompt design (phase 2)**
92+ - Per-verse context: indexed German tokens; source tokens each with Strong's
93+ code, lemma, transliteration, short gloss, and morph code; plus the tagged
94+ KJV rendering of the same verse as a bridge hint (we already ship it — a
95+ cheap, strong disambiguation signal).
96+ - Keep the instruction block stable and modest (~ 1k tokens) so it prompt-caches;
97+ all per-verse content goes after it.
98+ - Include 3–5 hand-aligned few-shot examples in the instructions, chosen to
99+ cover the hard shapes: a separable verb, a compound, an untranslated
100+ particle, a one-to-many rendering.
101+ - Output: for each German token, an array of codes + a confidence (0–1) + a
102+ note only when uncertain. Enforce with a strict structured-output schema
103+ whose code values are enumerated per request from the verse's inventory —
104+ invention impossible by construction.
105+
106+ ** Decision policy (phases 3–5)**
107+ - Auto-accept where the LLM and the statistical aligner agree and
108+ confidence ≥ 0.8.
109+ - Queue for Opus adjudication: LLM/aligner disagreements, confidence < 0.8,
110+ coverage violations, consistency-matrix outliers.
111+ - The adjudicator sees both proposals plus the verifier evidence. If it still
112+ hesitates, the token keeps an ` uncertain ` flag and renders as unverified in
113+ the app until a human approves it (via ` patches/ ` ).
114+
115+ ** Statistical verifier (phase 4)**
116+ - eflomal in both directions (de→source, source→de), symmetrized
117+ (grow-diag-final-and); count only content-word links as votes.
118+ - Consistency matrix: P(code | German lemma) over the whole corpus; flag any
119+ assignment below ~ 1% probability for lemmas with ≥5 occurrences.
120+
121+ ** QA protocol (phase 6)**
122+ - Stratified random sample of ~ 400 token alignments (OT/NT × prose/poetry ×
123+ short/long verses), graded blind against the sources — don't look at the
124+ model's confidence while grading.
125+ - Ship bar: <2% error on content words in the auto-accepted set. The
126+ adjudicated set may be looser but must stay visibly flagged in-app.
127+ - The community-tagged module may serve as a disagreement detector during
128+ eval only — never copy an alignment from it.
129+
130+ ** Runbook mechanics (phase 3)**
131+ - Message Batches API with ` custom_id ` = the verse ref key (` "Gen 1:1" ` );
132+ results arrive in any order — key by ` custom_id ` , never by position.
133+ - One batch covers the corpus (31k ≪ 100k cap). Keep the raw batch results on
134+ disk; the pipeline must be resumable from them without re-spending.
135+ - Log every errored/refused/non-conforming response and re-queue those verses
136+ individually.
137+
79138### Cost estimate (Batches API, prices as of 2026-06)
80139
81140Assumptions: ~ 1.0–1.5k input tokens/verse (shared instructions + German verse
@@ -115,3 +174,19 @@ to "any public-domain MT/TR translation exists" — which is nearly always true.
115174
116175- The ` ../overlay ` checkout (SWORD → jsonl importer) for phase 1.
117176- An Anthropic API key for phases 2–5; eflomal or fast_align (CPU) for phase 4.
177+
178+ ## Weave coverage for allusive books
179+
180+ * Observed 2026-07-15: 17 books had zero weave endpoints (Esth, Eccl, Song,
181+ Lam, Jonah, Nah, Zeph, Col, 1-2Thess, Titus, Phlm, 1-3John, Jude, Rev; Josh/
182+ Job/Ezek/Dan near-zero). Cause: the harvested weaves track verbatim-quotation
183+ density, so books that allude without quoting (Revelation <-> Daniel/Ezekiel/
184+ Zechariah above all) fall through.*
185+
186+ - [ ] Revive the deferred ** cross-testament quotation/allusion detection**
187+ R&D tier with an allusion-sensitive method (n-gram + embedding hybrid),
188+ aimed specifically at Revelation's OT spine.
189+ - [ ] A first hand batch of widely-accepted suggestions landed in
190+ ` weaves/suggested/ ` (2026-07-15); Song of Solomon and Philemon left
191+ empty deliberately -- Song's typological readings are tradition-specific
192+ rather than verse-level consensus, and Philemon has no OT parallels.
0 commit comments