Character rename migration

Start with the identity that must survive the edit

An established character already has a network of references. A name may appear in dialogue, a family register, an illustrated suitcase, a witness statement and the answer to a puzzle. Choosing a better surname does not update those relationships automatically. This workbench makes the rename an occurrence-level editorial migration: identify which person owns each reference, propose exact changes, and inspect the creative consequences before touching a manuscript.

The task differs from generating a fresh name. You arrive with an old form, a proposed replacement and some confirmed uses. The tool helps determine whether that replacement can enter the existing story safely. It does not choose the most beautiful candidate, discover every reference in a novel, or decide whether two similar strings describe the same person. Those boundaries matter because a confident global replacement can produce a coherent-looking file that tells a different story.

Use stable person IDs even when two people deliberately share a display name. The default ledger contains two identities called Aven Reed. Only the occurrences assigned to identity a enter its rename. Identity b keeps the same spelling. Their textual equality is part of the fixture, not a reason to collapse them. An author-confirmed identity link is the authority within this workflow; an accidental string match is not.

Build a ledger narrow enough to inspect

Each occurrence has six fields: occurrence ID, person ID, form key, current text, replacement permission and asset. The occurrence ID identifies one place where a decision can change. The person ID establishes whose name it is. The form key distinguishes a full name from a nickname, signature or another authored reference. The text is the complete field that could be replaced, not a paragraph containing an unknown number of matches.

The permission is either replace or lock. A locked quotation remains as supplied even when its form key has a replacement mapping. Give the asset a useful location such as chapter two dialogue, suitcase lettering or archived invitation. This label is part of the undo guard. If a later editor repurposes the occurrence for another asset, the old patch should not silently rewrite it.

This is a manually confirmed occurrence map. A blank ledger cannot mean that no dependencies exist, and a short ledger cannot certify coverage of the whole project. For a large manuscript, build scoped manifests with your editor or production system, then review them in groups of at most two hundred rows per table. The browser input limit is also bounded. Keep an explicit list of materials still outside the review, especially images and older editions.

Exact mappings prevent convenient guesses

The replacement table gives a form key, the exact old text and the proposed new text. A full-name mapping from Aven Reed to Aven Vale does not infer a new nickname, translate a signature, or change a family member's surname. Add separate keys when those decisions belong in the same migration. Each key appears once so the workbench never has to choose between competing instructions.

An occurrence enters the proposed patch only when its selected person ID, form key and old text agree with the mapping and the occurrence is replaceable. If the current value differs, the result identifies a drift instead of using substring matching or an approximate search. If there is no mapping for its form key, it remains unresolved. These are opportunities to inspect the source, not errors to hide by broadening the match.

Names retain their original spelling in the ledger. The tool does not normalize display forms into another writing system. Its dependency helpers have narrow comparison rules, but those do not authorize changes to the actual name. A form that looks equivalent to you may have a distinct story role. Record that decision explicitly rather than relying on a renderer, a font or a language assumption to merge it.

What the default case actually changes

Run the default example for person a. The dialogue occurrence and the suitcase reference change from Aven Reed to Aven Vale. The other person's identical name stays Aven Reed. The old quoted document also stays Aven Reed because its occurrence is locked. The displayed result is a proposed ledger; no source file, image or document on your computer has been opened or overwritten.

The dependency row attaches the recorded monogram requirement AR to the suitcase occurrence. Under the tool's disclosed initials helper, Aven Reed gives AR and Aven Vale gives AV. That difference sends the dependency to review. The supplied repair note asks for a redesign of the monogram, but it does not mark the redesign as finished. A plausible plan and an approved piece of artwork are different states.

Download the reversible occurrence patch and the proposed occurrence table separately. The first records only actual before-and-after edits and their identity, key and asset guards. The second includes the complete reviewed table and a worksheet string that can be copied back into the form. Keeping both lets you distinguish a decision log from the current editorial snapshot. Neither file claims that your manuscript was automatically migrated.

Original fictional scene: the suitcase that accused the wrong person

The illustrator put the suitcase on the table between two cups of cold tea. Its brass corners had taken an afternoon to shade. On the lid, two letters caught the station light: AR.

In the revised script, the passenger who owned it was Aven Vale. The editor had approved that surname because another major character already used Reed. The new name was easier to distinguish in dialogue. Every speaking balloon in the working chapter had been changed.

The detective still pointed at the suitcase on the last page. “Those are your initials,” she said.

“They were,” the writer answered, reading the old draft beside the new one.

The suitcase was not a decoration. A reader had seen it carried onto the platform before seeing the passenger's face. AR was meant to connect the object with two possible owners, keeping the first accusation uncertain. Changing one owner to AV left only the other person in the candidate set. The rename had moved the apparent solution four pages earlier without altering a line of deduction.

The team considered repainting the letters. That would reconnect the suitcase with Aven Vale, but it would also remove the intended ambiguity. They could add another AV character, yet that would create a person solely to repair an editorial accident. They could rewrite the detective's claim, but then the earlier framing of the suitcase needed another purpose.

The editor opened a ledger instead of a search box. She marked the suitcase occurrence as a clue dependency and separated it from the ordinary dialogue references. A quoted luggage receipt remained locked because its incorrect spelling was intentional evidence. A second Aven Reed, named in an unrelated newspaper cutting, belonged to another person ID and stayed outside this migration.

They finally kept the new surname for the passenger and redesigned the clue around a repair mark on the suitcase handle. The earlier pages already showed who had access to the repair shop. The monogram became inconclusive background detail, and the detective's accusation changed into a question about the repair. The artist revised the relevant panel rather than every old object carrying AR.

Before closing the file, the writer reread the platform sequence without the ending. The new evidence still allowed two explanations at the right moment. The name had improved the dialogue, but the scene worked only after the consequences were repaired. This is an original fictional production scene, not a report from an actual customer or a tested connection to an illustration application.

Why this rename needs more than replacement text

In the scene, a different surname changes a reader's inference. AR originally admitted two candidates; AV changes that relationship. Merely replacing the letters on the prop does not restore the old ambiguity. A rename therefore needs two decisions: whether the new name serves the cast, and whether the surrounding evidence still does its intended work. The tool can expose a dependency; the writer must redesign its dramatic function.

The counterfactual is useful. If Aven Reed became Aven Rowe instead, the initials helper would still return AR. The dependency would report an unchanged token, yet the entire scene would not be approved. An anagram, family link or handwriting remark might still depend on Reed. An unchanged initial pair is evidence about that one rule, not proof that every consequence survived.

Apply this method by naming what each reference does. A shouted surname may establish distance; a formal signature may disclose affiliation; an inscription may reveal access to a room. Give those functions dependency rows when appropriate. If a consequence cannot be expressed as a simple comparison, choose manual and write the recorded requirement. Changed manual dependencies always require review rather than receiving a fabricated pass.

Four dependency helpers, four limited claims

The initials helper splits on whitespace and hyphens, takes the first Unicode code point of each part and uppercases the result using the engine's declared locale behavior. This is a reproducible editorial convention, not a universal account of initials. Names without those boundaries and names with combining marks can need a manually supplied check. The tool does not infer family-name order or culturally correct monograms.

The anagram helper applies NFC, lowercases, retains Unicode letters and numbers, and sorts those code points. It ignores punctuation and spacing for this specific comparison. It does not equate different scripts, transliterations, accents or culturally related forms. A changed sequence flags review. An unchanged sequence says only that this helper preserved the same inventory; it does not establish that a puzzle is solvable or fair.

The text helper compares the supplied forms directly. Manual records an obligation that the software cannot evaluate. Each affected row shows before and after values, the author's recorded requirement, and any repair note. The requirement is context, not an automatically inferred test oracle. A note such as repaint the seal records planned work. It cannot substitute for seeing the revised seal and rereading the scene.

Undo must respect later editorial work

To preview a reversal, choose guarded undo, supply the current occurrence ledger and paste the reversible patch JSON. The patch must use this tool's supported schema and selected identity. Each edit must have a unique occurrence ID and valid before-and-after values. The workbench checks person ID, form key, asset, current text and lock status before proposing a restoration.

If the current text still equals the patch's after value, the original before value can be proposed. If someone has changed that occurrence again, renamed its asset or locked it, undo preserves the current row and explains why it was blocked. Other occurrences can still be restored, with a partial result clearly identified. There is no promise of an atomic manuscript transaction because this page does not control the manuscript.

The generated undo patch is itself reversible. It records what this preview actually proposes, not what the earlier patch originally intended. A repeated undo cannot keep erasing new edits: after the first proposed restoration is adopted, its former after value no longer matches. This guard is a text-and-identity check rather than cryptographic authentication. Inspect imported patches and maintain a separate backup of your project.

Finish with a reader-facing decision

Before adopting the patch, compare the changed name in its actual dialogue, art and document contexts. Review every unresolved form, every locked exception and every affected dependency. A deliberate old spelling may need an explanation in the story. A clue repair may require changing an earlier panel, not just the moment of revelation. Exporting a plan does not finish those creative tasks.

Keep the old patch with the accepted occurrence table and your revised assets. Record which edition the decision belongs to and which materials remain outside its scope. Then use the cast comparison or mystery tool for the next appropriate question. This page answers which confirmed references can move together and what they disturb. It does not certify a complete manuscript, a legal name, an external right or a reader's understanding.

Will this find every name in my manuscript?

No. You supply confirmed occurrence IDs and person links. The workbench evaluates that ledger, not unseen paragraphs, images or external documents. Keep an explicit coverage note and inspect other editions separately. A successful patch is bounded by supplied occurrences.

Can two people with the same name stay separate?

Yes. The selected person ID controls the migration. Another identity with identical text is unchanged. Confirm the links before generating the patch; the tool cannot know whether an author-assigned identity is correct.

Does an unchanged monogram approve my mystery?

No. The initials helper preserves only its declared token. Plot access, family associations, language conventions and alternative explanations can still change. Review the scene and record noncomputable obligations as manual dependencies.

What happens if I undo after another editor changes a line?

The changed occurrence is preserved and reported as blocked. Undo requires the recorded after text, identity, key and asset to match, and the occurrence must not be locked. Other matching rows can produce a partial reversal preview.