Family name planner

Start with people, not a bag of names

A family name is a relationship decision before it is a pleasing sound. A shared surname might indicate an inheritance rule, a chosen household, or a clerk’s assumption. Those meanings are not interchangeable. Draw the people and the relationships first, then decide which links actually transmit a name. In this tool, the parent column is your declared inheritance source. It does not infer gender, biological parentage, nationality or a legal convention. You remain the author of the rule.

Choose inheritance policies deliberately

Parent inheritance follows the declared source through the graph. If Aven has the surname Reed and Sela inherits from Aven, Sela receives Reed. A later change to the unlocked source should affect descendants, not unrelated people. Shared household mode uses the one surname you enter for everyone; it is a fictional policy you have chosen, not a claim that all households work this way. Keep supplied mode evaluates the links but preserves entered surnames. Use it when belonging and surname inheritance need to remain separate.

Distinguish locks from explained exceptions

Put ! in column five of the people table to lock an existing surname; column six is the optional household. A lock protects continuity but cannot resolve contradictory inheritance. If a child is fixed as Morrow while the selected source produces Reed, the solver stops with a conflict. To preserve Morrow deliberately, enter the person ID, surname and reason in the explicit exceptions worksheet under task-specific controls. Alternatively choose keep-supplied policy or unlock the field. These choices imply different stories. Record the reason instead of deleting a warning merely to fill the family tree.

Fictional example: the household census

A workshop census lists Sela Morrow as a visitor because her surname differs from the Reed household. Her cousin Oren corrects the household field: Sela lives there, but has chosen to retain her earlier name. The correction matters because a visiting apprentice would be excluded from the workshop vote. Calling her Sela Reed would make the form easier to process while erasing the very choice the scene is about. The useful design is a separate household relationship, not a universal surname replacement.

What the example teaches

The name works because it creates a specific institutional misunderstanding that the characters can resolve through action. If all three characters used Reed, the census mistake would need another cause. If the narrator treated the difference as proof that Sela was unrelated or unwelcome, it would confuse an official’s assumption with the story’s truth. In your own project, ask who created the record, which relationship it measures, and what practical consequence follows from the label. Then decide whether a shared surname helps or harms the intended inference.

Check rules and events together

The workbench now supports declared-parent, maternal, paternal, dual-component, shared and keep-supplied policies. Generation markers, explained exceptions and dated events are separate choices. These are authored conventions, not an automatic model of real family law. Validate the graph before judging the names, then review scene references. The event comparison keeps residence, inheritance and retained identity distinct.

Review all three pairs in an introduction

Three people in an introduction group produce three pair checks. The matrix keeps short forms, supplied readings and an optional required shared marker separate. Sharing a marker never waives a collision. Removing a required marker changes compliance without changing inheritance source IDs. This is a scoped family workflow: sibling labels and group size do not create another independent tool page.

A complete event-based planning session

Begin with a small family rather than importing the entire dynasty. Enter r | Aven | Reed | | !, s | Sela | Morrow | | and o | Oren | | r |. These are original fictional examples. Aven has an established surname and a lock, Oren inherits through the declared link, and Sela begins with her own supplied surname. Leave the global rule on declared-parent inheritance. The important initial result is not that the words sound related: Aven and Oren resolve to Reed, while Sela remains Morrow because no inheritance link has been specified for her.

Now add the event 3 | s | parent | r | retain | Joins the household while retaining an earlier identity. Set the current chapter to five and the comparison chapter to zero. The relationship changes at chapter three, but the retain policy preserves Sela Morrow. A later event, 4 | s | household | Reed workshop | retain | Accepted as a resident, changes residence. It does not prove biological descent, and it does not authorize replacing Morrow. Inspect the comparison panel: it should show the change in household while preserving her chosen name.

For a controlled alternative, change only the first event’s policy from retain to inherit. Sela now follows the declared source and resolves to Reed. Keep the original scene facts fixed while asking what this alternative would imply. Does the character welcome the public association? Is the change imposed by the household’s record system? Does a later letter need to show the earlier surname? The tool can propagate your rule, but it cannot decide which interpretation your story has earned. Export both versions as separate private projects rather than overwrite the one you have already approved.

If your world uses two inherited components, enter maternal and paternal links in their own table and select dual inheritance. The order selector changes the sequence of the two supplied parental surnames. A founder without both links may retain a supplied surname; an unnamed descendant without sufficient sources produces a conflict. These are authored rules. Do not introduce them as a statement about every real society with multiple surnames.

The workshop vote: an original fictional scene

The clerk laid three brass voting counters beside the register. Then she slid one back into the drawer.

“Two residents,” she said. “One visitor.”

Sela kept her hand on the edge of the table. On the register, the line beneath her name was blank. On the bench behind her stood a survey frame she had spent six weeks repairing.

“I sleep above the west room,” she said.

“I have put the lodging under expenses. The vote belongs to the household.” The clerk tapped the two Reed entries with her pencil. She did not sound hostile. That made the explanation harder to interrupt.

Oren reached for the ledger, but Sela turned it toward herself first. Beside Morrow she wrote the address of the west room. In the empty household column she wrote Reed workshop.

“The address was already there,” the clerk said.

“In a different account.”

Aven watched from the door. Everyone expected him to settle it, and for a moment Sela wished he would. He could have said that she was one of them. He could also have said that the simplest solution was to put Reed after her given name. Either sentence would make the decision his.

Instead, he asked the clerk to read the voting rule. It named people who lived and worked at the workshop. It said nothing about shared surnames.

The clerk read it twice. She opened the drawer and put the third counter on the table.

At the vote, Sela opposed Aven’s proposal to sell the damaged survey frame. Oren laughed before he could stop himself. Aven looked at the frame, then at the third counter, and accepted the count.

Later, the clerk asked whether Morrow should still appear on next month’s register.

“Yes,” Sela said. “And this column should stay filled.”

This scene is a creative example, not a claim about a real adoption, citizenship or voting system. Its institutional rules exist only in the fictional workshop. That restriction matters: the narrative effect comes from a specific clerical shortcut contradicting a disclosed local rule, not from asserting that a surname universally determines belonging.

Why the name decision changes the scene

Morrow gives the clerk a plausible but mistaken shortcut. The separate household field lets Sela correct the assumption without erasing an earlier identity. The practical consequence is a vote she uses independently. If she merely accepted a new surname and then supported Aven, the scene might suggest that inclusion required both nominal conformity and obedience. The recorded choice instead distinguishes recognition from ownership. Neither the tool nor the name alone establishes that interpretation; the final vote makes it observable.

Consider three revisions. In the first, Sela already uses Reed. The surname mistake disappears, so the author must find another reason for the missing counter. In the second, the rules explicitly restrict voting to hereditary members. Correcting a household column would not resolve the dispute; the characters would need to challenge the rule itself. In the third, Sela wants to adopt Reed but is prevented from doing so. Retaining Morrow would no longer express the same agency. Use the event policy that matches the character’s actual choice, not whichever version sounds more emotionally satisfying in an isolated paragraph.

The story also needs a record of who knows the earlier name. A later visitor may recognize Morrow from a map caption. That does not require every workshop resident to know the same history. Keep prior forms in the private family bible, then decide which belongs in each scene. Use the address tool when the question is who may say a form; use the identity tool when the question is who knows a hidden connection. A family inheritance graph should not silently become a universal knowledge database.

Diagnose the failure instead of adding names

A cycle such as Sela inheriting from Oren while Oren inherits from Sela is not a sophisticated family history. The solver cannot establish a source order. Correct the directed links or represent the relationship outside the inheritance field. Similarly, a missing parent ID means the referenced source is absent; inventing a new person to satisfy it would falsify the author’s input. Unknown parentage should remain unknown.

A lock conflict needs a real decision. If an accepted surname must remain Morrow while the new policy produces Reed, preserve the identity with an explicit exception and its reason, revise the event’s retain policy, or deliberately unlock it. Do not edit the underlying rule solely to make the warning disappear. For a large saga, check a small subtree after every change, then compare the full set of descendants. Unrelated people should remain unchanged.

Generation markers are supplied fictional components, not deductions from ages or kanji. A shared marker can communicate affiliation while making siblings harder to distinguish. Add the forms they actually use in dialogue and the scene groups where they meet. An exact shared reading or short form deserves a scene review even when the inheritance is internally consistent. Keeping the surname fixed and changing a permitted short reference often preserves more work than renaming an entire branch.

Before handing the family bible to an artist or translator, verify that each person has a stable ID, each exception has an explanation, and the selected chapter is visible in the export. A private event history may contain unrevealed relationships. It is production material, not automatically a reader-safe family tree. The last check is always a scene: can a collaborator tell who is related, who lives together, and which facts are still intentionally uncertain?

Why does changing a household not change the surname?

Residence is a different relationship from inheritance. The event has deliberately separate fields so moving into a home does not erase an earlier identity. Use a parent-link event with inherit when you intend a name transition, or retain when you intend continuity. If your institution forces a surname change, record that as an explicit fictional rule and show its consequences; do not make it an accidental side effect of the address field.

Can a generation marker prove a secret relationship?

No. The marker is an authored component applied to a declared generation key. It can give a character a reason to ask a question, but it cannot establish parentage by itself. Decide who knows the convention and whether unrelated people can share it. A fair reveal needs additional evidence. Keep an intentional clue separate from the graph’s author-known relationship, otherwise a public export may disclose more than the scene should contain.

What happens when two inherited surnames keep growing?

Dual mode joins the two resolved parental components in the selected order. It does not silently invent a truncation law for later generations. If your setting retains only designated components, define those as supplied names or explained exceptions until that richer policy is explicitly modeled. Inspect the family bible before reuse; a long technically derived form may still be unsuitable for ordinary dialogue.

Should I repair a family rule or rename a confusing cousin?

Determine which problem is real. An inheritance conflict needs a rule or exception decision. A shared dialogue nickname needs a reference decision, which may leave the family rule intact. Lock published identities, compare the relevant scene group, and try the smallest justified change. Save the old and new versions with the affected people rather than treating a shorter name as evidence of a better family system.