Three-way cast naming reconciliation

Keep the name decision and the merge decision separate

Two writers can make sensible changes to the same character and still produce an unusable combined ledger. One changes a surname to support a scene of independence; another revises the spoken note for a different surname. A simple “take the newest file” operation discards one writer’s decision. A field-by-field merge may preserve both edits while attaching the wrong reading to the resulting name. Neither outcome tells you which story choice the team actually intended.

This workbench compares three explicit naming snapshots: a declared common base, your current draft and an incoming collaborator draft. It separates changes made on one side from changes made on both, exposes deletion-versus-edit conflicts, preserves current locked fields and checks that a reading still belongs to the exact selected name. You resolve the open choices locally. The tool does not send a package to collaborators or apply replacements to manuscript assets.

Shared IDs and a common ancestor are author declarations. The software cannot prove that both writers used an ID for the same person, that a file is the latest authorized revision or that its author accepted your choice. Agree on those facts before merging. A complete data snapshot is useful production evidence, but it is not a signed approval, a pronunciation certificate or proof that every caption and recording has been updated.

Original fictional scene: a courier chooses her own sign

Ivara reached the last roof of the kite-post race with the sponsor’s pennant tangled around her bag. The announcer called her Ivara Tarn, the name the sponsor wanted printed on the winner’s sign. In one comic draft she pulled the pennant free, handed it back and asked to be called Ivara Sel. Soren, the courier who had helped her cross the roofs, repeated Sel before announcing her arrival to the waiting crowd. The change became a small public act of choosing how she would be addressed.

The coauthors had revised different files. The current draft used Sel and expanded Soren’s short label because he now spoke in a crowded scene. The incoming draft kept a separate idea in which Ivara adopted Tarn and removed Soren to shorten the episode. It also supplied a new performance note for Tarn. Neither collaborator had written the version a naïve merge would make: Sel on the sign, a note bound to Tarn in the voice packet, and no Soren in the cast ledger.

The writers did not settle the scene by counting edits. They chose the independence version, retained Soren’s witness role and left the new name’s reading explicitly unsupplied until they could author the appropriate note. The incoming short label Vara could still be useful. Keeping that compatible field did not require adopting the incoming surname or pretending that its reading note applied to Sel.

These people, names, race and naming conventions are invented. The example is not a claim about any real community’s surname practice. The name matters because the public response gives Ivara’s choice an audience. A technically complete merge that removed the witness might still require a new way to stage that response; the software cannot restore the missing scene merely by retaining a cast record.

If Ivara were renamed Ivara Tarn in the chosen scene, the sponsor’s requested form would no longer be the form she rejects. The exchange and its meaning would need revision. If she retained Sel but Soren disappeared, another action would have to make the crowd’s acknowledgment legible. These are story consequences, not a reason to force every old field into the new ledger. The merge should preserve decisions the writers actually make, including an honest gap in a performance note.

Set up three snapshots that can be compared

Each record contains exactly id, name, reading and short. The ID is the stable reference, not a display label. Name is nonblank text. Short is either nonblank text or null. Reading is null or an object containing for and text: the exact written name the note belongs to, and the authored note itself. The tool does not derive a pronunciation from spelling or verify the note against a language source.

All fields are explicit. A null value means that a field is present but unsupplied. A missing record means that the snapshot omits that identity, which the comparison treats as deletion. An omitted field is not accepted as shorthand for unchanged. Extra record fields are rejected rather than silently dropped. If your real cast bible has additional columns, keep the original and prepare this limited naming projection deliberately.

The three snapshots together accept 1–40 distinct IDs. IDs start with an ASCII letter and use at most 40 letters, digits, underscores or hyphens, with reserved prototype-related IDs rejected. Visible names and authored reading notes can use other writing systems. Strings are compared exactly: the engine does not normalize different Unicode forms into one hidden identity.

Before pasting an incoming draft, check its scope. If someone sent only a few changed records, it is not automatically a full snapshot. Treating that excerpt as complete could propose removal of every omitted person. Reconstruct a complete comparable snapshot from reliable project records, or stop and obtain the missing context. The program cannot infer whether a missing row was intentional.

Read the three-way decision, not a majority vote

When an identity exists in all three drafts, the comparison operates on its fields. If current and incoming agree, their value is retained. If current equals base, the incoming change can be retained. If incoming equals base, the current change can be retained. When both differ from the base and from each other, the field remains a conflict. Two matching values are evidence about these versions, not a popularity judgment about the best name.

The initial courier name is a conflict between Ivara Sel and Ivara Tarn. The incoming short label Vara changes a different field, so it can be preserved without deciding the surname. The reading can also be a one-sided edit and still fail its later binding check. “Only one writer changed this field” is enough for the structural comparison, but not enough to establish that its meaning fits every other merged field.

Deletions and independent additions need a different unit. If one side removes a base record while the other changes it, choose the whole record rather than assembling fragments around an absent person. If both sides independently add different records under the same new ID, the tool also requires a whole-record choice. It does not assume that two independently created characters are one merely because their IDs collide.

An unchanged opposite side permits a deletion, and identical additions can agree. Different IDs are never consolidated by a matching name. A same-display diagnostic preserves both records and asks you to review the creative use. It is not a global name-availability check or evidence that the team has accidentally duplicated a person.

Locks preserve a current decision without hiding a conflict

Locks name a current-side person and a field: name, reading or short. The protected value is the exact value in left. A proposed change to it is withheld, and removing the record is blocked when any current field is locked. Locks do not silently convert an incoming change into permission to overwrite a current identity.

This supports the related import task. When base and current represent the same starting ledger, an incoming rename might otherwise be a straightforward one-sided change. A current lock still stops it. You can explicitly keep the current value or revise the lock input after reviewing the decision. The workbench does not treat an import as a higher authority than the local constraint.

A lock is a production control, not a contributor’s consent or an unchangeable artistic truth. If current name and current reading are inconsistent and both are locked, preserving both does not make the inconsistency valid. The complete export remains unavailable until the team explicitly corrects the source or revises the relevant lock and decision. No rule is relaxed to manufacture a clean result.

Work through the initial conflicts

Compare the default drafts, then use the choice controls for courier / name. Keeping current retains Ivara Sel and satisfies its lock. Trying to use incoming is blocked with an explanation and does not record a successful decision. These controls update the resolution ledger only. They do not rewrite the base, current or incoming source textarea.

Next inspect courier / reading. Its incoming note belongs to Ivara Tarn, not the selected Sel. Choose an explicit custom value of null to leave the reading unsupplied, or enter an authored object whose for value exactly matches Ivara Sel. Null is a deliberate declaration of missing information, not a guessed way to pronounce the name. The default completion example uses null.

For witness / record, keep current to retain Soren Dask and the current short label Soren. The incoming deletion conflicts with a current edit and would also remove a locked short field. Once these choices are resolved, the complete naming snapshot contains the selected Ivara record and the retained Soren record. It preserves Vara from the compatible incoming field and lists both remaining null readings as unsupplied.

The source ledger and the scene still need separate production review. Retaining Soren in data does not add his dialogue back to a script. Removing his record does not erase a drawn figure. Export the naming decision, then check the real panels, dialogue fixtures and voice notes against the adopted story version.

For a short-label conflict, custom text is literal, including the four letters null. Use the separate unsupplied option to record an actual null value. This keeps a written label distinct from missing information rather than interpreting an unusual creative choice as a deletion.

A decision can become old while its wording still looks reasonable

Captured decisions retain the exact source values and lock context they resolve. A reading decision also retains the selected name context. If a relevant source changes, the stored decision becomes stale instead of being reapplied to a different conflict. Choosing Sel once is not permanent authorization to choose a new, unseen current spelling later.

Resolve the name before its reading. A reading choice recorded while the name is unresolved can become stale when the name is subsequently selected, even if the note’s text has not changed. Revisit the actual row and capture a decision against its current context. This is more useful than treating a historical checkbox as approval for every downstream form.

The buttons also check the current form values before recording a choice. If you manually edit relevant source text without recomparing, an old visible control cannot overwrite a newer context. Compare the drafts again. Removing a saved decision is explicit and checks that the displayed decision is still the one present in the ledger.

After a structural change, a previously decided field may no longer be part of the current comparison. The unmatched decision remains visible and blocks complete export until explicitly removed or replaced through a relevant comparison. It is not silently discarded. Preserve the private audit if you need the reasoning behind a decision that no longer applies.

Export a resolution, then verify the production

The private audit is available with unresolved issues. It contains all three snapshots, decisions, provisional outcomes and diagnostics; it is not spoiler-redacted. A dedicated resolved-snapshot download appears only when conflicts, stale or unmatched decisions, lock violations and name/reading mismatches are resolved. It can contain null readings, and a deliberate deletion of every record can yield an explicitly empty snapshot.

Main copying, favorites, comparison, ordinary result downloads and saved projects also contain private editorial context. They do not constitute public cast pages or contributor approvals. Keep source backups and inspect files before sharing. This tool has no collaboration account, remote comment system or automatic publication step.

For the next production pass, agree on which snapshot is authoritative, preserve the IDs and record open questions outside the naming fields where necessary. Use a replacement audit to find actual manuscript occurrences, a localization map for edition-specific forms, or dialogue checks for required labels. Those are different tasks. A good reconciliation makes the adopted naming decision traceable while leaving the remaining creative work visible.

Is a shared ID proof of one character or a common version history?

No. Stable IDs and base ancestry are author declarations. Check the source scope before comparing. Identical display names under different IDs stay separate, while independently added same-ID records require an atomic choice when they differ.

Why does a reading conflict remain after choosing a name?

The note is bound to its exact for value. A compatible one-sided edit can belong to a different written name. Supply an appropriate authored note or explicitly choose null; the tool never guesses a replacement pronunciation.

Can incoming data override a current lock?

No. A changed locked value or a deletion removing a locked field is withheld. Keep the current source or explicitly revise the lock after review. Importing a file is not automatic authority to discard that constraint.

Does a complete export update every manuscript occurrence?

No. It is a resolved naming data snapshot, not a text replacement, contributor approval or production release. Inspect scripts, captions, artwork and recordings with the relevant workflows. The private audit and ordinary exports can reveal all drafts.