Bible To Strong

Internal-only multi-agent review for a generated Bible

Use this workflow when the user explicitly wants Codex sub-agents only and no AI Gateway/provider calls. Internal sub-agents are independent review turns, but the runtime does not attest that they are distinct model identities. Their agreement is therefore a strong suggestion, not by itself the two-provider production proof required by strong:review:gaps:batch.

Before sending any candidate to an agent, normalize the STEP identity model at the original-token level:

• group annotations by exact originalTokenId and STEP token identity;
• distinguish multiple lexical occurrences from alternate strong, eStrong, dStrong, and uStrong identities of one occurrence;
• keep one carrier question for one original lexical occurrence;
• expose compact identities as metadata on that question, never as separate missing Strong candidates;
• do not ask an agent to decide whether an alias is another occurrence;
• preserve textual variants and edition support in the packet;
• when a classical Strong and STEP extended identity share one token, plan one product carrier such as <w strong="G0528" estrong="G5221">…</w>;
• detect merged or shifted verse clauses before review and quarantine any occurrence whose target verse cannot be established safely.

The OST Acts 16 pilot documented in reports/internal-agent-gap-review-ost-acts16.md exposed why this is mandatory: G0528 and G5221 were variants of the same TAGNT token, but the unnormalized lexical packet presented them as two missing occurrences. Two proposers and an arbiter all made the same bounded mistake because the correct product-level choice was absent from the packet.

Prioritize a generated Bible's review queue in this order:

1. visible relocations with a better open content carrier;
2. suspicious stacking and profile over-budget carriers;
3. missing reader occurrences with an open high-confidence direct candidate;
4. ambiguous high-confidence carriers;
5. multi-word French expressions where the Strong belongs on a phrase;
6. original-only or grammatical items, normally retained in advanced/empty unless strong evidence supports reader visibility.

Keep packets chapter-sized and normally cap them at 20-30 candidates. Every packet must contain target context, current reader/advanced state, exact STEP occurrence metadata, witness carriers rather than inventories alone, bounded word/phrase/empty/duplicate/technical choices, open/occupied/blocked targets, and placement warnings.

Run two proposers in parallel with deliberately different review roles:

• proposer A is occurrence/evidence-first: STEP identity, morphology, source order, textual editions, and independent Strong witnesses;
• proposer B is French/safety-first: syntax, semantic carrier, phrase scope, open targets, generic words, and stacking risk.

Keep roles independent per packet, even when a long run rotates a limited pool of internal threads. An agent that proposed a packet must not arbitrate or audit that same packet. The root agent may serve as the fourth safety auditor only if it did not propose or arbitrate the packet; record that provenance explicitly.

Validate both outputs locally before arbitration. Require one bounded choice per stable candidate id, exact word/phrase indexes, matching normalized text, allowed Strong inventory, and zero malformed or missing decisions. Send only disagreements and sensitive agreements to the arbiter. Sensitive agreements include aliases, original-only items, verse shifts, generic carriers, occupied-target stacking, weak function words, and visible choices with no exact witness or direct lexical evidence.

Internal proposer artifacts must use the current full raw-decision contract, not the historical compact OST shape. Alongside id, choiceId, confidence, reason, and evidence, materialize ref, decision, strong (containing only the candidate's own Strong), wordIndex, normalized, startWordIndex, endWordIndex, and normalizedPhrase from the exact selected packet choice; use explicit null values where the choice has no such coordinate. Run the non-mutating strong:review:gaps:apply validation before freezing the file.

Freeze each locally validated proposer artifact before arbitration and record its SHA-256 in the arbitration input/manifest. A proposer must never silently edit a file that has already been declared validated or handed to the arbiter. If later context exposes an error, write an explicit revision, validate the whole revised packet again, update the recorded hash, and restart or explicitly invalidate the affected arbitration/audit. Downstream decisions are valid only for the exact frozen proposer hashes they reviewed.

Create the immutable manifest only after both proposer turns have reached a completed status and both final files pass parseSemanticRefillLlmResponse. A proposer file already visible on the shared filesystem is not final while its proposer is still running. Rerunning the command against an existing manifest fails closed. If a hash changes, mark that freeze series superseded, revalidate the final file, create a new immutable freeze series, and never restore or silently rewrite the old manifest. Use --verify before arbitration, audit, and consolidation:

npm run strong:review:gaps:freeze -- \
  --packet <packet-number> \
  --output <freeze-manifest.json> \
  --source packet=<packet.json> \
  --source evidence=<proposer-evidence.json> \
  --source french=<proposer-french.json>
npm run strong:review:gaps:freeze -- \
  --output <freeze-manifest.json> --verify

In a durable review decision, the strong array must contain only the candidate's own strong value. stepIdentity.associatedStrong, eStrong, dStrong, and uStrong remain occurrence metadata; do not copy them into the decision's allowed Strong inventory. The exact occurrence link and publisher preserve those identities. This distinction prevents a valid same-token alias from being misread as an additional target Strong during pre-application validation.

Pre-application validation must evaluate the accepted decision set as a batch, not only one decision at a time against the unchanged ledger. When two or more decisions in the same batch create a word-level stack on a carrier that was previously open, move every involved decision to pending-human with suspicious-batch-stacking-on-same-word. A linguistically plausible compression or textual-variant pair is still a durable human decision; agent agreement and an initially open target do not make the new stack auto-safe.

The arbiter receives the packet, both proposals, validation results, and local STEP/reference evidence. It may choose only a bounded packet choice and must not invent an unvalidated third carrier. A fourth internal auditor examines only proposed production-safe decisions and can return safe, hold, or block; it does not propose a new carrier.

After the independent audit, build the contract-v2 safe subset mechanically. The command rejects unbounded arbiter choices, missing audits for green decisions, and arbiter/auditor choice mismatches; yellow and red decisions are never emitted:

npm run strong:review:gaps:internal-safe -- \
  --packet <packet.json> \
  --arbiter <arbiter.json> \
  --auditor <auditor.json> \
  --output <safe-reviewed.json>
npm run strong:review:gaps:apply -- \
  --bible <id> \
  --input <safe-reviewed.json> \
  --output-dir <validated-preview-dir> \
  --ledger-dir outputs/strong/<id>

Omit --apply here. The preview is required to exercise whole-batch stacking guards while leaving the canonical ledger untouched.

After every bounded packet has a validated non-mutating preview, consolidate only the generated accepted.json files with the previously approved-review candidate artifact. Use the approval-bundle command rather than concatenating JSON manually. Pass the earlier artifact first so an exact decision reviewed again by a later queue keeps the earlier provenance; exact duplicates are recorded and collapsed by Bible, reference, Strong inventory, target, indexes, and normalized carrier. The output is still only an approval candidate:

npm run strong:review:gaps:approval-bundle -- \
  --bible <id> \
  --output <human-approval-candidate.json> \
  --source previous=<previous-approval-candidate.json> \
  --source packet-001=<validated-preview-001/accepted.json> \
  --source packet-002=<validated-preview-002/accepted.json>

Record the bundle's source hashes, raw source decision count, unique decision count, duplicate ledger, and decision-payload SHA-256. The bundle status awaiting-explicit-human-durable-approval is not approval. Never pass it to an applying transaction until the human explicitly approves that exact durable payload hash.

Before requesting that approval, freeze the read-only chapter transaction plan. This command replays every source hash and count, reconstructs the exact deduplication result, verifies the payload hash, checks the canonical SQLite, and records one immutable payload hash per chapter scope. It refuses to overwrite an existing plan and does not mutate overrides or the ledger:

npm run strong:review:gaps:approval-plan -- \
  --bible <id> \
  --bundle <human-approval-candidate.json> \
  --output <human-approval-application-plan.json> \
  --ledger-dir outputs/strong/<id>

The plan remains awaiting-explicit-human-durable-approval. Its scope count is the exact number of locked chapter transactions and scoped refreshes required after approval; generating the plan is never equivalent to approving or applying it.

Verify the complete execution path in read-only mode before asking for or recording approval. This replays the sources, bundle, plan, canonical SQLite, metrics, input fingerprint, and current curated-override fingerprint and always reports appliedOverrideCount: 0:

npm run strong:review:gaps:apply-approved -- \
  --bible <id> \
  --bundle <human-approval-candidate.json> \
  --plan <human-approval-application-plan.json> \
  --ledger-dir outputs/strong/<id>

Only after the human explicitly approves the exact payload SHA-256 may the same command receive --apply --approved-sha256 <exact-hash>. The approved runner replays all frozen inputs, serializes writes under the review lock, backs up both curated overrides and the human-approval ledger, applies one chapter scope, refreshes only that scope, runs every metric/integrity/visibility and residual-auto-safe gate, and rolls back both state files plus the scope on failure. A verified approval receipt is written inside the same transaction, so a restart can reconcile the narrow commit-before-manifest crash window. Use --max-scopes <n> for a bounded resumable slice. Add --finalize only when the run should perform the final complete regeneration and reader/advanced exports after all planned scopes are verified. Never pass --apply merely to test the command.

Both plan creation and read-only execution verification recompute the current Strong-ledger input fingerprint; comparing only the SQLite byte hash is not enough. If either command reports approval-plan-input-fingerprint-drift, the old plan is invalid even when SQLite itself is byte-identical. Do not weaken that guard and do not attempt scoped refresh. Before human approval, record the invalidation and leave the canonical ledger untouched. After explicit approval of the unchanged decision payload, a full canonical regeneration with the then-current stable pipeline may establish the new baseline; freeze a new plan, rerun read-only verification, and only then begin chapter application.

Classify results as follows:

• green: exact proposer agreement, mechanically valid, direct same-target evidence or exact witness support, no alias/verse/stacking/generic risk, and auditor safe;
• yellow: disagreement, arbiter-only choice, sensitive agreement, or weak support; retain for human/viewer review;
• red: malformed identity, unresolved verse mapping, invalid occurrence, or unsafe carrier; keep advanced/empty or reject the candidate itself.

Never bypass the existing production transaction because internal agents agree. Preview internal decisions first. Production mutation requires either the existing distinct-model batch proof or an explicit human-approved durable decision. Apply accepted decisions chapter by chapter with a backup, exact scope refresh, and rollback on any gate failure.

For every applied scope require: unchanged verse count; SQLite integrity ok; no increase in placementRiskCount; no decrease in original representation or reference coverage; no new same-token identity duplication; no residual lexical auto-safe item; and an auditable before/after report. The sole bounded exception to the aggregate placement-risk delta is a newly created same-word stack in which every Strong is distinct, every resulting annotation carries llm-review:human-approved, and the exact approved payload assigns every one of those Strong identities to that exact verse and word. This covers genuine compound lexical carriers such as OST Saint-Esprit without weakening the duplicate or over-budget guards. Prove this from the scoped before/after verses inside the approval executor; do not change a fingerprinted generation metric mid-application. After all scopes, regenerate the complete ledger once, rerun global gates, and only then publish the STEP-aware compact JSONL. Agents choose French carriers; STEP and the publisher remain authoritative for estrong, dstrong, and ustrong.

For experiments and inspection, two validated model reviews on the same lexical packet can be combined into a strict visible high-confidence consensus and run through the post-consensus filter:

npm run strong:review:gaps:consensus -- \
  --left-review outputs/gap-review/<id>/agent-review/<left>.json \
  --right-review outputs/gap-review/<id>/agent-review/<right>.json \
  --left-validation-dir outputs/gap-review/<id>/agent-review/<left>-validated \
  --right-validation-dir outputs/gap-review/<id>/agent-review/<right>-validated \
  --output outputs/gap-review/<id>/agent-review/<consensus-visible-high>.json \
  --min-confidence 0.84
npm run strong:review:gaps:filter -- \
  --review outputs/gap-review/<id>/agent-review/<consensus-visible-high>.json \
  --output outputs/gap-review/<id>/agent-review/<consensus-visible-high>-auto-filtered.json \
  --report-json reports/llm-gap-review-<id>-<scope>-post-consensus-filter.json \
  --report-md reports/llm-gap-review-<id>-<scope>-post-consensus-filter.md

These standalone commands are preview/validation only. Production application must be performed by strong:review:gaps:batch, which recreates and verifies the two-model consensus/filter artifacts inside its locked v2 transaction.

Then write a benchmark report with the explicit output flags:

npm run strong:review:gaps:report -- \
  --packet outputs/gap-review/<id>/agent-packets/agent-packet-<id>-<scope>-lexical.json \
  --review outputs/gap-review/<id>/agent-review/<consensus-visible-high>.json \
  --validation-dir outputs/gap-review/<id>/agent-review/<consensus-visible-high>-validated \
  --applied-dir outputs/gap-review/<id>/agent-review/<consensus-visible-high>-applied \
  --before-metrics outputs/gap-review/<id>/baseline/bible-<id>-strong-metrics-before-<scope>.json \
  --after-metrics outputs/strong/<id>/bible-<id>-strong-metrics.json \
  --metrics-scope <scope> \
  --output-json reports/llm-gap-review-<id>-<scope>.json \
  --output-md reports/llm-gap-review-<id>-<scope>.md

Give that packet to two independent proposer agents. Prefer chapter-sized packets for normal books; use book-sized packets only when the book is short or the candidate count is low. For the benchmarked reference-style workflow, use gpt-5.4-mini with reasoning medium as proposer A, gpt-5.5 with reasoning low as proposer B, and gpt-5.5 with reasoning medium as arbiter. This Gen.1 benchmarked combo is called combo A in reports/gap-review-model-benchmark-gen1.md. Do not silently upgrade proposer A to xhigh: the point is to test whether the ordinary proposer pair can solve the chapter without a hand-written rule. Each proposer must write a JSON review file, then validate it:

For a single-model AI Gateway pilot, use the packet runner first, then validate the review before applying anything:

set -a; . ./.env; set +a
AI_GATEWAY_TIMEOUT_MS=120000 npm run strong:review:gaps:llm -- \
  --input outputs/gap-review/<id>/agent-packets/agent-packet-<id>-<scope>.json \
  --output outputs/gap-review/<id>/agent-review/llm-review-<id>-<scope>.json \
  --model deepseek/deepseek-v4-flash
npm run strong:review:gaps:apply -- \
  --bible <id> \
  --input outputs/gap-review/<id>/agent-review/llm-review-<id>-<scope>.json \
  --output-dir outputs/gap-review/<id>/agent-review/llm-review-<id>-<scope>-validated \
  --candidates outputs/gap-review/<id>/<scope>/gap-review-candidates.json \
  --finalize-reference-style

npm run strong:review:gaps:apply -- \
  --bible <id> \
  --input outputs/gap-review/<id>/agent-review/<proposer>.json \
  --output-dir outputs/gap-review/<id>/agent-review/<proposer>-validated \
  --candidates outputs/gap-review/<id>/<scope>/gap-review-candidates.json

Use an arbiter only after both proposer outputs are validated. For the reference-style workflow, default to gpt-5.5 with reasoning medium as the arbiter. Use gpt-5.5 high as a quality-reference baseline, escalation path, or explicit experiment, not as the default production choice. The arbiter should choose between defensible proposals and inspect local validation results; it should not invent a third unvalidated path when both proposers are weak. Validate and preview the arbiter output after converting every valid unresolved reference-style Strong to a placed decision (word, phrase, or empty) with a confidence score:

npm run strong:review:gaps:apply -- \
  --bible <id> \
  --input outputs/gap-review/<id>/agent-review/<arbiter>.json \
  --output-dir outputs/gap-review/<id>/agent-review/<arbiter>-validated \
  --candidates outputs/gap-review/<id>/<scope>/gap-review-candidates.json \
  --finalize-reference-style

Never add --apply to this standalone reference-style command. If the preview contains useful decisions, feed the current lexical report to the batch runner; only its exact two-model filtered transaction may mutate production overrides.

The agent packet is procedural. It includes auditKind, currentTarget, sourcePlacement, nearbyOpenTargets, blockedTargets, openContentTargets, occupiedTargets, availableTargets, and placementWarnings. auditKind="missing" means the Strong is not visible yet. auditKind="relocation" means the Strong is already visible but may be attached to the wrong French carrier. Agents must treat blockedTargets as forbidden for decision="word" when a semantically plausible open target exists. This prevents errors such as stacking a missing Strong onto a word that already carries a different Strong when a nearby unoccupied carrier exists.

For relocation candidates, agents must compare currentTarget with deterministicCandidates. Use duplicate only when the current placement is correct. If a better visible carrier exists, output word or phrase; if no reliable carrier exists, output empty. Do not rely on hand-written semantic equivalence lists for cases such as NBS Gen.1.27 (homme vs humains); solve those only with auditable external lexical evidence or bounded LLM review.

For reference-style candidates, do not use pending-human as a final preview state and do not use reject for a legitimate Strong simply because no French carrier is found. The objective is to copy the reader style of Darby, DarbyR, and Sg1910: first try word, then phrase; if no reliable visible carrier exists, output empty at the candidate's sourcePlacement.insertAfterWordIndex so the Strong remains visible as a small empty tag in original/reference order. Every final decision gets a confidence score. The product vocabulary is high confidence vs low confidence, not accepted vs pending. Use low confidence for uncertain word/phrase placements, suspicious stacking, or empty fallbacks. Reserve reject only for invalid candidates, duplicate drift, bad ids, or mechanically impossible decisions. The final arbiter preview may pass --finalize-reference-style; this converts valid unresolved, unsafe, or missing agent decisions into low-confidence empty preview entries instead of leaving them pending. It does not make them production-eligible. The review/preview must show low-confidence decisions in yellow and empty decisions inline, with a reason such as "no reliable French carrier found".

Native/canonical versification alignment

Before any LLM gap-review on a Bible whose verse boundaries may differ from STEP or the Strong witnesses, generate and freeze a versioned correspondence manifest:

npm run strong:versification -- --bible <id>

The v2 manifest is full-scope and monotone. Its blocks support identity, merge, split, resegment (N:M), shift, chapter-boundary, omitted, and added. The detector compares three local Strong witnesses and records both the best path and its ambiguity margin. A book-level low margin does not erase a locally strong structural block: production may retain the best path only when every non-identity block clears the local evidence threshold. Otherwise, retain only the exact top-two intersection and fall back to identity outside it. Empty canonical witness rows are valid source coordinates, not malformed text.

Generation must validate exact target and canonical coverage before writing the manifest. The accepted report records the manifest SHA-256, block counts, detector version, thresholds, witnesses, and per-book resolution policy. Add the frozen manifest path to the Strong-ledger input fingerprint; a changed manifest always requires a full regeneration before scoped refresh.

For each non-identity block, align the concatenated target text once against the deduplicated STEP tokens and combined witnesses, then project back to the Bible's native verse refs. Require all of these invariants:

• every French word index belongs to exactly one native verse;
• a phrase may not cross a native verse boundary;
• every empty anchor has one deterministic native owner;
• every physical STEP occurrence is represented exactly once;
• all Strong identities of one physical STEP token are co-located on one carrier;
• witness inventories are partitioned, never copied into every verse;
• curated overrides remain native-ref/local-index decisions and are applied only after block projection;
• a targeted refresh expands to every native verse in the touched block.

Run non-mutating canaries before activating a manifest. Include at least one 2:2 clause transfer, one merge/split, one chapter/count exception, and one same-token multi-identity case. Verify unchanged total occurrence inventory, 100% original representation for the canary scope, and zero same-token duplication. Only then place the frozen manifest at data/bibles/bible-<id>-verse-correspondence.json or pass its exact path with --verse-correspondence for a full regeneration. Do not start LLM carrier review until that regeneration and its SQLite/integrity/quality gates pass.

14. Run full checks before finalizing:

npm run format:check
npm run typecheck
npm run lint
npm test
npm run build

15. When changing deterministic lexical placement rules, run or resume the 10-book first-5-chapters regression audit:

npm run strong:audit:plan
npm run strong:audit:run
npm run strong:audit:verify
npm run strong:audit:residuals

The default audit is intentionally capped at 10 books to keep regeneration fast during iterative work. Use --books <n> only for explicit broader stress tests.

If the audit changed intentionally, inspect outputs/strong-audit/nbs/manifest.json, then refresh the committed metrics/hash baseline:

npm run strong:audit:snapshot -- --snapshot tests/fixtures/strong-audit/nbs-10x5-snapshot.json

Use strong:audit:residuals after a successful audit run to write outputs/strong-audit/nbs/residuals.json and .md. The residual report is for human inspection only and stays in ignored outputs/; it groups remaining lexical candidates into actionable categories such as group auto-safe leftovers, compound STEP proper-name candidates, clean single open high candidates, blocked single open high candidates split by medium-only vs high-candidate blockers, high candidates that use inferred seed evidence, high-scoring medium candidates, ambiguous high candidates, and relocation better-open candidates. Treat clean single-open items as the first deterministic audit queue. Treat compound proper names, inferred-seed high items, blocked items, and high-scoring medium items as evidence for review, not as automatic insertion candidates.

Lexical auto-safe insertion is iterative. Keep rerunning candidate generation until no more placements are applied, within the bounded pass limit. Some group-auto-safe placements become visible only after earlier lexical passes remove competing residual candidates.

Decision Rules

• Prefer strong:generate for the production artifact because it keeps a canonical SQLite reader/advanced ledger, applies validated lexical auto-safe placements, writes the residual lexical candidate report, and explains every Strong placement.
• Keep original-complete word guesses and empty occurrences in advanced/debug view. Only the calibrated reader pipeline, validated lexical auto-safe, or a bounded reviewed decision may add a reader carrier.
• Treat placementQuality as a structural risk proxy, not semantic accuracy. Use masked-gold carrier-exact F1 as the primary quality measurement.
• Count independent witness families, not filenames: Darby and DarbyR are one family for consensus bonuses, learned word/phrase frequency thresholds, and editorial empty placement. Within one family and verse, take the maximum correlated-edition count before summing evidence across verses/families.
• Prefer SQLite store reads for any scoped workflow. Commands with --only <Book|Chapter|Range> must read only matching rows from bible-<id>-strong.sqlite, not parse the whole Bible.
• Keep strong:kaikki:index and strong:phrase:index prepared on production machines. They turn the two largest lexical/reference lookups into targeted SQLite reads.
• Prefer strong:export -- --view reader or strong:export -- --view advanced for TSV views.
• The diagnostic backend includes learned multi-word phrase transfer from the local Strong references. Keep this deterministic and original-confirmed.
• Use STEP TAHOT/TAGNT as the production original inventory. Treat WLC/SBLGNT suffixed Strong values (H6960a, etc.) as audit provenance only, not lexicon lookup keys. Render and compare the canonical Strong (H6960), prefer STEP dStrong/eStrong for lexical disambiguation, and keep any non-STEP source suffix only as metadata.
• Treat local French Strong dictionaries as deterministic evidence for review and future scoring, not as a license to place tags without original/reference inventory support.
• When reading strong_lexicon.full.production.sqlite, keep proper-name gloss evidence but do not use proper-name meaning text as French carrier evidence. Do not let a row's uStrong feed another classical Strong unless the normalized uStrong equals the row's eStrong, except for pronominal morphology where cross-uStrong forms are grammatical variants. This prevents related-name/group definitions from placing false carriers while preserving pronoun variants.
• Do not add hand-written synonym or semantic-equivalence entries to generation because a hard verse was discussed. Production placement may use exact learned reference evidence, dictionary evidence, algorithmic stemming, STEP inventory, validated lexical auto-safe evidence from external French sources, or bounded LLM review; see docs/french-lexical-sources-for-strong-placement.md.
• Treat synonym-only candidates as review material. A candidate can be high only when it has direct evidence such as seed-term, seed-stem, kaikki-gloss, STEP proper-name evidence, or STEP numeric component evidence. Synonym-only candidates may keep their numeric score for sorting, but their confidence is capped at medium and they still count as ambiguity blockers for generic auto-safe decisions. Auto-safe production insertion requires direct evidence or a French auxiliary-plus-participle phrase whose participle has direct lexical evidence. A synonym-only high-score competitor outside a strong auxiliary-plus-participle phrase does not block that phrase, but a direct-evidence outside competitor does. When both a French auxiliary-plus-participle phrase and its contained participle are independently auto-safe, prefer the phrase because it preserves the visible French verbal construction without adding semantic assumptions. Numeric component evidence may stack on occupied compound-number carriers, including relocation from a simple occupied number to a later richer compound number and duplicate empty numeric occurrences that have one richer occupied compound carrier; French compounds such as douze, quatre-vingt-*, and soixante-dix-* are decomposed into STEP-compatible numeric components. Repeated empty occurrences of the same Strong may be group-auto-safe when the same open French lexeme appears the same number of times with high-confidence direct evidence and source order maps cleanly to text order. The duplicate lexical group rule uses relative order and exact cardinality; it does not require the French carriers to appear after the empty source anchors, because translated clauses can move the visible carrier before the original-complete insertion point. Ambiguous STEP proper-name sequences may also be group-auto-safe when same-verse source order and French token order provide a one-to-one monotonic assignment across open high-confidence proper-name carriers; do not use this to replace simple proper-name auto-safe placements that are already unambiguous.
• Lexical auto-safe placement is a stabilization loop, not a single pass. Do not lower the pass limit unless the 10x5 audit proves that no validated auto-safe placements remain stranded in the residual report.
• Use calibrated translation profiles: one common backend, but profile-aware generation and diagnostics by translation family.
• Interpret metrics through the Bible's translation profile. Dynamic translations such as BDS are expected to have lower token coverage than formal translations such as Martin.
• Profiles are active generation inputs, not just labels: they control learned enrichment strictness, maximum Strong codes per word, empty-word consensus, and hard-verse thresholds.
• Report visible Strong rate, empty Strong rate, multi-Strong word rate, original representation rate, original unrepresented Strong occurrences, and profile token-coverage status.
• Use strong:evaluate after changing reader, phrase, or empty-tag behavior.
• Prefer strong:llm:transfer over free LLM arbitration. It is measurable: source Strong Bible -> masked gold Bible.
• Do not use --llm-apply until suggestions have been reviewed on a small sample.
• Promote good LLM suggestions through strong:review:llm + strong:review:llm:apply into data/curated-strong-overrides.json rather than repeatedly paying for the same decision.
• Prefer LLM batches by book (--only Gen, --only Exod, etc.) instead of whole-Bible LLM runs.
• For semantic improvement batches, prefer compact lexical packets and exact two-model consensus. NBS now has a validated full-Bible high-confidence lexical batch path via strong:review:gaps:batch, but it is still bounded suggestion generation: exact consensus plus the post-consensus filter is required before any application.
• Require two distinct model identities, the same stable candidate id and bounded choice id, the current filter policy, contract v2, and the active batch lock/transaction before production application. Direct strong:review:gaps:apply --apply is forbidden, as is combining standalone --finalize-reference-style with --apply.
• Treat plain semantic-refill:llm and semantic-refill:llm-reference-style as quarantined provenance only. Only semantic-refill:llm-consensus-filtered may enter production, either from a current batch transaction or from the strict current-proof artifact migration.
• After the first controlled batch, require a post-consensus safety filter before application. Generic auxiliary/function carriers, suspicious same-word stacking, and any positive per-book placementRiskCount delta should be held for review instead of silently promoted. Same-word stacking review must inspect the Strong witnesses before deciding which side to keep.
• Prefer internal-agent gap-review batches by chapter when the target is to place Strong codes already present as advanced empty/technical annotations. Chapter packets preserve local context while keeping the decision surface small. Use the benchmarked combo A by default: gpt-5.4-mini medium + gpt-5.5 low as proposers and gpt-5.5 medium as arbiter. Keep gpt-5.5 high for quality-reference runs, escalation, or explicit experiments.
• Do not send agents a free-form "find the best word" task. Use strong:review:gaps:packet so they see blocked/occupied/open/nearby targets and can avoid false multi-Strong stacking.
• Treat suspicious stacking as low-confidence unless it is mechanically invalid. If a proposed word target already carries a different reader Strong and another open content target exists, the arbiter should either choose the open target or output a low-confidence empty/word decision with the warning preserved.
• For reference-style candidates, prefer empty over reject when the Strong is valid but unrendered in the target French. Place the empty tag according to sourcePlacement.insertAfterWordIndex and keep the reason auditable. Do not leave valid reference-style candidates as final pending. Reject only token-index drift, invalid Strong ids, duplicate over-tagging, or candidates that are not actually supported by the verse/reference inventories.
• Keep generated copyrighted/full Bible outputs in outputs/; do not commit them.

When More Detail Is Needed

Read references/workflow.md for:

• command matrix;
• metrics interpretation;
• LLM transfer evaluation;
• full gold evaluation reporting;
• quality gates;
• expected reports and final response checklist.

Read docs/best-strong-generation-workflow.md for the current research-based recommendation: deterministic canonical ledger first, LLM only for bounded review.