Thoroughly evaluate the 4 PT9 interlinearizer choices

[imnasnainaec]

Make sure we fully understand and our model covers the functionality of the 4 "Create new" options:

Findings so far

Two model gaps have been identified for PT9 mode parity — both additive:

• modelProjectId?: string on InterlinearProject — PT9 Options 1 & 3 reference a model text (a major-language translation used only for generating suggestions). This is a separate concept from targetProjectId, which is the output/alignment target.
• interlinearMode?: 'back-translation' | 'adaptation' — Options 3 & 4 both produce output in a second project but differ in intent; a discriminator is needed for correct UI wording and suggestion behavior.

Implementation implications: interlinearizer.createProject command signature and CreateProjectModal need a mode/model picker.

Size: M (evaluation write-up + model fields; UI is a follow-up)

Priority: P1 — decides project-creation UX for PT9 users

[imnasnainaec]

PT9 Interlinearizer — Analysis of the 4 "Create new" Options

What PT9 offers

From the interlinear tool tutorial and the custom interlinears training video:

#	Option	Model text?	Output project?	Notes
1	Create glosses based on a model text	Yes — a major language translation used for statistical word suggestions	No (analysis stored locally)	Gloss DB grows as user accepts/corrects suggestions
2	Create glosses with no model text	No	No	Suggestions come only from previously created glosses; prevents model text from biasing translator choices
3	Create a back translation	Yes — reference translation for suggestions	Yes — a BT project where glosses are exported	Explicitly non-natural; documentation warns users
4	Create adaptation/revision	No (not mentioned)	Yes — a "daughter project" for the adapted/revised text	For related-language adaptation or same-language revision

Key distinction between modes:

• Options 1 & 2 differ only in whether a model text project is used for statistical suggestions.
• Options 3 & 4 both produce output in a second project, but differ in intent (BT vs. adaptation) and whether a model text drives suggestions.

---

What the current model covers

The InterlinearProject type already handles:

• Option 2 (no model text glosses): fully covered — just a sourceProjectId + analysis, no extra fields needed.
• Options 3 & 4 structurally: targetProjectId can represent the output project (BT project or daughter project), and AlignmentLink[] can represent token-level relationships between the two sides.
• Suggestion tracking: TokenAnalysis.status ('suggested' → 'approved') is sufficient to track gloss acceptance for the growing DB; no model changes required for that pipeline.

---

Gaps

1. No modelProjectId field

Options 1 and 3 both reference a model text — a second project (major language translation) used only for generating suggestions. This is a separate concept from targetProjectId (which is the output/alignment target). The current InterlinearProject has no way to record which project serves as the suggestion source.

Proposed addition:

// In InterlinearProject:
/**
 * Platform.Bible project ID of the model text — a reference translation used to generate
 * statistical gloss suggestions. Set for Options 1 (glosses with model) and 3 (back translation).
 * Distinct from targetProjectId: the model text is a read-only suggestion source, not an output.
 */
modelProjectId?: string;

2. No mode/type discriminator

Without a mode field there is no way to tell at runtime whether a project is a plain-glosses project, a back-translation project, or an adaptation project. This matters for:

• Future suggestion behavior (Options 1 vs. 2 behave differently)
• Export behavior (Options 3 & 4 send output to targetProjectId)
• UI rendering (which fields to show in Create modal, whether to display BT export controls)

Proposed addition:

// In InterlinearProject:
/**
 * How this project's output is used. Absent for plain-glosses projects (Options 1 & 2).
 * 'back-translation' = Option 3; 'adaptation' = Option 4.
 */
interlinearMode?: 'back-translation' | 'adaptation';

(Options 1 and 2 don't need a mode value — they're distinguished by presence/absence of modelProjectId.)

3. targetProjectId semantic question

Currently targetProjectId is documented for bilateral alignment projects (BT Extension imports), where AlignmentLink.targetEndpoints resolve to tokens in a second text. For PT9 Options 3 & 4, the "output project" plays a similar role structurally, but the relationship is one-directional export rather than two-way alignment. Reusing targetProjectId is fine as long as the interlinearMode field makes the intent clear.

4. CreateProjectModal needs restructuring

The current modal collects only name, description, and analysis language. A PT9-aligned create flow needs:

• A mode selector (4 choices)
• Conditionally: a model text project picker (Modes 1 & 3)
• Conditionally: a BT/daughter project picker (Modes 3 & 4)

And CreateDraftConfig / the interlinearizer.createProject command signature both need modelProjectId? and interlinearMode? parameters.

---

Summary

The data model's analysis layer (TextAnalysis, TokenAnalysis, etc.) is fully capable of storing glosses for all 4 modes. The two concrete model gaps are modelProjectId and interlinearMode. The larger gap is the Create modal, which currently has no concept of these modes at all.

[imnasnainaec]

The first model gap will be covered in our suggestion engine, following #127.

[imnasnainaec]

Broke the two remaining model gaps into concrete issues, both reframed away from project creation:

• Wire a model-text suggestion source into the suggestion engine #148 — model-text suggestion source. The model text becomes a detachable suggestion input feeding the Add engine to generate token gloss suggestions from previous glosses #131 engine, attached whenever it's useful rather than chosen as a creation mode. The source can be a sibling interlinear project (surface-form gloss reuse) or a major-language Scripture project — the latter is required to fully support importing PT9 interlinearizations, since PT9's Options 1 & 3 gloss against a major-language model text via word alignment.
• Wire the output project (back-translation / adaptation) into export, not creation #149 — output project (back-translation / adaptation). The output (targetProjectId + interlinearMode) becomes an attach-when-you-export concern, chosen at export time rather than locked in as a creation mode.

Together these move us off PT9's 4-way "Create new" fork toward three goals:

1. Simplify project creation — don't force decisions up front that can be made later. Neither the suggestion source (Wire a model-text suggestion source into the suggestion engine #148) nor the output target (Wire the output project (back-translation / adaptation) into export, not creation #149) needs to be declared at creation; a project starts as simply "gloss a source."
2. Generalize the interlinearizer — don't lock a user into a specific source or output. Model text (a sibling analysis or a major-language project) and output target are attached, changed, or dropped at will, so the same analysis can serve gloss-only use, take suggestions from a major-language model (incl. imported PT9 workflows), or export to a back-translation/adaptation project without being pigeonholed at birth.
3. First-contact discoverable — surface each feature intuitively at the moment it's needed (suggestions when glossing, output when exporting) and don't burden the user with it before that point.

Net effect: PT9's Options 1–4 stop being mutually exclusive creation modes and become orthogonal capabilities a single project can pick up or drop as the work demands. The interlinearMode discriminator survives (in #149) only as an output-intent flag, not a creation-time mode selector.

The end-to-end PT9 XML → InterlinearProject import pipeline (the parser exists but is unwired) is broader than either issue above and is tracked in #150 — it consumes both #148 and #149 to link an imported project's model and output. #148/#149 cover only the model-text and output sides respectively.

[imnasnainaec]

@alex-rawlings-yyc The 3 issues created off this (#148, #149, #150) could be reviewed and, if satisfactory, this issue can be closed.

[alex-rawlings-yyc]

@imnasnainaec I think it all looks good to me. I'll defer the actual closing of this issue to you