Joint cast name allocation

Allocate a cast instead of drawing one name at a time

A supplied name can be suitable for two roles and be the only eligible choice for a third. If you assign it to the first person you consider, the remaining cast may become impossible even though a complete allocation existed. This workbench treats the choices together. It searches for a joint assignment under explicit role eligibility, fixed decisions and shared-scene restrictions rather than picking independently and repairing duplicates afterward.

Come here with roles and an author-approved candidate pool. The tool does not source names for you, infer a character's background, decide who deserves the strongest name or measure whether a supporting character overshadows the lead. Its question is narrower: can the supplied candidates occupy the supplied roles without violating the declared rules? A feasible result is a starting point for reading the cast, not a substitute for that creative review.

The cast distinction studio serves another stage. It compares names already attached to characters and helps you inspect collisions. This allocator makes and revisits the attachment itself. A choice consumes a candidate for the rest of the search. Changing one lock can therefore change several assignments, even when the other roles and candidate spellings remain untouched.

Keep roles separate from candidate identities

Each role row has a stable role ID, a label, a numeric priority and an optional locked candidate ID. The role ID belongs to the story position you are filling. The candidate ID belongs to a supplied naming proposal. Do not use the current display name as the role key: changing the assignment should not create another character or break every reference to that role.

Priority is a deterministic tie-break after the solver chooses the most constrained unassigned role. A smaller number goes first among equally constrained roles. It is not an artistic ranking, an exposure measurement or a promise that the protagonist receives the most memorable spelling. If a role genuinely requires one candidate, use a lock or explicit eligibility; a low priority number does not turn a preference into a hard rule.

Each candidate row contains its ID, exact full display, optional dialogue short form and optional approved reading. The display is preserved in the output. Reading is supplied evidence for this comparison, not something guessed from spelling. The solver accepts one to sixteen roles and one to sixty candidates, with table and input limits. Those bounds keep the search understandable and limit the amount of work a browser is asked to do.

State eligibility before searching

Eligibility rows identify a role, a candidate and allow or block. If a role has any allow rows, only those candidates enter its domain. Otherwise its initial domain is the whole supplied pool. Block removes a pair from that domain. A pair can be declared only once; contradictory allow and block rows do not silently compete according to file order.

A lock narrows the role to its locked candidate after those rules. If the lock refers to an unknown candidate or one excluded by eligibility, the tool stops with an explicit conflict. If a role has no eligible candidates before joint constraints are considered, the tool also stops. Randomly choosing from the original pool would hide the exact condition you need to repair.

Write eligibility because of an authored requirement you can explain. For example, a candidate may already appear on commissioned artwork for a particular identity, or a short form may be established in a published passage. The software does not derive eligibility from gender, ethnicity, social status or the apparent cultural associations of a spelling. Those are not hidden attributes in the candidate table.

Shared scenes constrain pairs

Scene rows identify two distinct role IDs and short, reading or both. The selected channels cannot match exactly after the disclosed comparison normalization when those two roles receive their candidates. The restriction applies to that pair, not automatically to every character in the book. A deliberately shared nickname can remain possible for characters who do not participate in a restricted pair.

Comparison uses NFKC, English-locale lowercasing and collapsed whitespace on the supplied strings. Full display collisions are blocked globally, as is reusing a candidate ID. This policy makes equivalent comparison strings compete even if the original displays differ. It does not claim that all visually similar names are equivalent or that different approved readings will be easy to hear in a performance.

An absent short form or reading cannot establish a collision, but it also cannot establish safety. When an allocated restricted pair lacks a selected comparison form, the result includes a missing-data warning. The allocation may be complete while the review state remains partial. Supply an approved form or review the actual scene rather than interpreting an untested channel as a pass.

Run the default allocation

The lead courier can use n1 or n2. The guest witness can use only n1. The registry clerk can use n3 or n4. Candidate n1 is Aven Reed with the short form Ave; n2 is Sela Morrow with Sela; n3 is Orin Vale with Ori; n4 is Arden Rowe with Ave. These are supplied fictional casting choices, not historical facts about their forms.

A greedy choice of n1 for the lead would leave no candidate for the guest. The joint solver sees the guest's smaller domain and reserves n1 there. It can assign n2 to the lead and n3 to the clerk. It also respects the short-form restriction between guest and clerk: n4 would produce Ave alongside Ave, so that pair is not accepted under the supplied scene rule.

Now lock the lead to n1. The guest's individual domain still contains n1, but reuse is forbidden, so there is no complete joint allocation. The result may preserve a compatible partial assignment, clearly marked incomplete. It does not invent another candidate, duplicate n1, drop the guest or remove the scene restriction to reach the requested role count.

Original fictional scene: the last credit on the rehearsal sheet

The rehearsal sheet had three empty role boxes and three approved naming cards. Each card had already passed through a different production decision. One matched an illustration, another had a short form used in a preview chapter, and the third had no fixed place yet.

The assistant put the most flexible card beside the courier. It looked good there. The writer agreed, and they moved on to the guest.

The guest could use only that same card. Its signature appeared on the preview chapter's witness statement, and the statement could not be changed before the scheduled reading. The assistant offered to reuse the card for both people and distinguish them with speaker labels.

The director read the exchange without the labels. Both characters answered to the same short form in the same scene. A narrator could explain the difference, but the planned performance had no narrator at that moment. The apparent shortcut would add another production obligation rather than preserve the existing plan.

They looked for a fourth naming card. The writer stopped them. “We have not proved we need another one.”

The unused flexible card could fit the courier. The guest could keep the form on the statement. The clerk could take the remaining eligible card. The first decision had been locally attractive and globally unhelpful; it had consumed the only option another role had.

They moved the first two cards and read the scene again. Nobody had to redraw the witness statement or add an explanatory narrator. The courier's new assignment was not declared artistically superior. It simply respected the production conditions that had made the original greedy choice fail.

Later, an actor suggested another short form for the clerk. The team entered it as a revised candidate and reran the scene restrictions. They kept the old allocation sheet with the preview version rather than pretending the revised pool had always existed. This is an original fictional rehearsal scene, not a report from a real production, a reader experiment or a working integration with casting software.

Why the swap matters more than another generated name

The conflict in the rehearsal scene is about scarcity within a supplied pool. Giving the courier the guest's only choice blocks the joint plan. A new randomly generated spelling might avoid that problem, but it would create another approval task and might not satisfy the preview or artwork constraints. The swap preserves the conditions already paid for by the production.

If the guest's statement were still editable, the domain could change. That would be another valid plan, but it should be recorded as a changed requirement. If the short-form collision were intentional and the performance included a clear linking exchange, the pair restriction could also be revised. The solver cannot decide those creative tradeoffs; it can show what follows from each explicit version.

Use this counterfactual with your own cast. Ask which choices are genuinely fixed and which are merely familiar. A lock on a tentative preference can make the whole problem appear impossible. Conversely, removing a lock to produce a complete table can erase a published fact. The useful process identifies the authority behind a condition before changing it.

Understand the bounded search

The solver keeps the current partial assignment, chooses an unfilled role with the fewest currently compatible candidates and tries candidates deterministically. It checks uniqueness and applicable scene rules before extending the assignment. If a choice creates a dead end, it backtracks. Priority and role ID provide stable tie-breaks; candidate order comes from your supplied pool.

The candidate-attempt limit is explicit. When all branches allowed by the finite model have been explored without success, the output says no complete allocation was found under those rules. When the attempt limit is reached first, the output says the search is bounded and has not proved impossibility. Increasing the limit can help in the latter case, but it cannot repair contradictory locks or an empty initial domain.

The browser runs the search in a background worker so the form remains usable. A newer generation request replaces the older worker rather than letting an old result overwrite current parameters. If the browser cannot run the worker, the tool reports the failure and preserves input. The server-rendered example remains readable without JavaScript; interaction and background computation need JavaScript.

Inspect a partial result rather than filling the blanks

A partial allocation contains only roles that received candidates in a compatible explored state. Unfilled roles are listed separately with their initial eligible domains. They are not converted into fictional names such as Unknown or Pending and passed to the copy button as though the cast were finished. The role count and allocation completeness remain visible in the report and export.

A complete allocation with missing comparison data is also partial in review terms. Its complete flag describes assignment coverage; missing-data notes describe checks the supplied inputs could not support. These are different dimensions. A cast with every slot filled can still require confirmed readings or a rehearsal, while an incomplete allocation can contain several perfectly usable fixed decisions.

Before changing a constraint, consider the smallest meaningful repair. Add an eligible candidate, unlock a genuinely provisional choice, revise a scene pair or supply a missing comparison form. Change one condition and rerun. Do not interpret an attractive complete table as evidence that those changes were narratively justified.

Keep the allocation with its scope

The downloadable joint allocation records role and candidate IDs, original forms, locks, eligible domains, shared-scene restrictions, attempt count, search status and unfilled role IDs. It does not scan your manuscript, update game resources or certify worldwide uniqueness. The comparison applies only to the supplied pool and rules.

After choosing an allocation, read the actual scene and use the cast distinction tool for broader editorial comparisons. The allocator intentionally checks only its hard exact-match channels; it does not rank subtle sound or visual resemblance. Keep the accepted assignment as story state, not a seed you expect to recreate after silently changing the pool. The final goal is a cast whose names serve the work, with a clear record of which constraints made the joint plan possible.

Does priority give the protagonist the best name?

No. It breaks ties in a deterministic search after domain size. The solver checks feasibility, not artistic quality or reader attention. Use a lock for a truly fixed candidate and review the resulting cast in its actual scenes.

Why did changing one lock move several names?

Candidates are shared resources and cannot be reused. A fixed choice narrows other roles through eligibility and scene rules. A joint solution can therefore change more than one assignment even when only one input decision changes.

Does a search limit mean there is no solution?

No. Limit reached means the bounded search stopped before proving exhaustion. The export distinguishes this state from an exhausted finite search with no complete allocation. Revise constraints or increase the permitted bound consciously.

Why is a complete allocation still marked partial?

Selected scene comparisons may lack a supplied short form or approved reading. Every role can have a candidate while some distinction checks remain unsupported. The complete flag describes coverage; the warnings describe remaining review work.