Problems Fixed

Names Became Records

The spouse-name problem did not need better character vibes. It needed IDs, manifests, and rules about who belongs in a frame.

Every person, portrait, message, relationship, and name discussed here is generated. These are fictional harness artifacts, not real people or real relationships.

The Pain Point

John’s wife kept changing names. Emily Carter, Emily Harper, Emily Miller, Lisa Miller, Sarah Carter: the exact list mattered less than the pattern. The model could preserve the role while drifting the identity. Wife, household partner, sender of a practical text, person with access to the house. Same narrative slot, too many labels.

That is funny once. After that it breaks the experiment. If a generated world cannot tell whether a recurring person is the same person, then messages, relationships, visit permissions, appearance, and emotional state all become decorative.

The everyday version is your phone contacts going slightly haunted. Imagine John gets a message from “Emily,” replies to “Lisa,” mentions “Sarah” in the next note, and the system treats all three as maybe his spouse because they fit the same role. A human would stop and ask whether these are three people, one person with inconsistent labels, or a contact list that needs cleaning.

The model was doing what language models do well: filling in a socially plausible person for the scene. The harness needed something stricter. It needed to know that the next spouse-shaped contact was not automatically a new spouse-shaped person.

Generated character reference sheet for fictional contact Emily Miller.
Reference portraits helped with appearance, but the fix had to treat characters as records, not just images.

Why It Was Hard

Names are cheap. Roles are cheap. A model can produce a believable spouse-shaped person because the domestic grammar is familiar. But continuity requires more than plausibility. It requires a stable character ID, a manifest, allowed locations, relationship state, and a reason for that person to appear now.

Reference images alone do not solve that. A portrait can anchor appearance while the world still invents a second spouse, a duplicate neighbor, or a new sender for an old conversation. Visual consistency and identity consistency overlap, but they are not the same system.

People already understand this in normal life. A name in your contacts, a face in a photo, and a relationship in your head are three related records. If one changes, you do not automatically rewrite the others. The early world kept letting a plausible name tug the whole identity around.

Commit-backed fix: the newer character and social-state work adds persistent character profiles, reference manifests, relationship dynamics, social presence planning, and tests that separate generated story texture from canonical identity.

Infographic showing name drift repaired by a stable character record, manifest, relationship state, and presence rules.
Names become durable only when they are attached to records: IDs, manifests, relationship state, references, and presence rules.

What Changed

Characters became structured records. A person can have an ID, name, relationship, relationship status, reference paths, notes, and world membership. Social presence planning decides whether a character should be present, where they are allowed to appear, and what kind of interaction fits the current state.

Relationship dynamics also moved out of pure prose. The system can track whether a relationship is neutral, tense, happy, upset, or otherwise constrained by prior events. That does not make the emotion real. It makes the harness honest about which fictional state it is carrying forward.

The admin console work matters here too. Character records, manifests, vehicles, phase rules, and raw world data are visible and editable through a local interface with schema validation and audit records. Continuity stops being an implied prompt behavior and becomes inspectable state.

The fix is not to make John’s fictional family feel more real. The fix is to make the fiction less sloppy. If a contact sends a message, the message belongs to a record. If a character appears in the house, their presence has to be allowed by the world state. If a relationship is tense, the next interaction can carry that tone without inventing a different person.

That is also why the disclosure matters. These records are generated artifacts. The value is in the accounting pattern, not in pretending the relationship is real. A stable ID lets the harness study continuity without accidentally turning name drift into soap opera lore.

What This Unlocks

The world can now ask better questions. Is this the same character? Should this person be in this location? Does this message belong to this relationship? Is the portrait being used as evidence of identity, or only as an appearance reference?

That turns spouse-name drift from a recurring joke into a testable class of failure. John’s household can remain fictional and generated while still having enough bookkeeping to stop inventing a new spouse every time the story needs a text message.

The broader lesson is portable. Any generated world with recurring people needs a character ledger before it needs richer dialogue. Otherwise every neighbor, coworker, spouse, clerk, and text sender is just a convincing mask that may or may not be the same mask tomorrow. Records are what let the story stay ordinary long enough to test the interesting parts.