Character Persistence

The Spouse Had Three Names

Generated names are not identity. They are sticky labels until the harness proves otherwise.

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

The Strange Moment

At some point, John’s wife stopped being a person and became a database problem with nice hair.

That sounds harsher than it is. No real person is involved here. John is generated. His contacts are generated. The house is generated. The emotional texture is generated too, which is important to say before the site accidentally starts sounding like I am documenting a suburban marriage through a broken phone.

The useful observation is narrower: the harness began accumulating spouse-like records that looked related but were not reliably the same identity. Emily Carter. Emily Harper. Emily Miller. Lisa Miller. Sarah Carter. Several records carried the same basic job in the world: wife, household partner, primary household contact, sender of the backyard-photo request, resident with normal access to the house.

That is not a story twist. It is identity drift.

The model knows the role. It knows the domestic grammar. It knows that a person named John in a generated suburban home plausibly has a spouse who texts practical reminders. What it does not know, unless the harness pins it, is that the next spouse-shaped record must be the same spouse-shaped record as the last one.

Generated character reference sheet for fictional contact Emily Miller.
Exploration 07 persistent character reference: `suburban-house-john-001_emily_miller`. Generated image, not a real person.

The Ledger Drift

The evidence is not subtle once you stop reading it like fiction and start reading it like state. Here is the shape of the problem, compressed from the local character manifests:

[
  {
    "id": "emily_miller",
    "name": "Emily Miller",
    "relationship": "John's wife",
    "relationshipStatus": "upset"
  },
  {
    "id": "char_sarah_carter",
    "name": "Sarah Carter",
    "relationship": "Wife and co-resident",
    "relationshipStatus": "happy"
  },
  {
    "id": "char_lisa_miller",
    "name": "Lisa Miller",
    "relationship": "John's wife and household partner",
    "relationshipStatus": "angry"
  }
]

There are more variants, including Emily Carter and Emily Harper. They are not identical records, but they are competing for the same narrative slot. That matters because a generated world cannot be allowed to treat role similarity as identity.

If Emily Miller is upset because a prior message thread drifted, and Sarah Carter is happy because a different run created a cleaner contact, the harness needs to know whether those are separate fictional contacts or a duplicated spouse record. Otherwise relationship state becomes confetti. The model can keep a familiar vibe while the ledger quietly forks the household.

Rule of thumb: a generated name is evidence, not authority. Durable identity needs a stable ID, merge rules, and a refusal to create a new spouse just because the model found a plausible surname.

Generated character reference sheet for fictional contact Sarah Carter.
Exploration 07 persistent character reference: `suburban-house-john-carter-001_char_sarah_carter`. The role overlaps with other spouse/contact records.

What Actually Broke

The break is not that the model made up names. Making up names is the job. The break is that the harness let names become memory.

Names feel stable to humans because in normal life they are backed by a body, a history, a social context, and a lot of external paperwork. In a generated image world, a name can be produced by the same mechanism that produces a countertop or a cloudy afternoon. It is plausible text in a plausible world.

That means the harness has to treat names as soft attributes. The hard object should be the persistent character ID. Everything else attaches to that: aliases, relationship role, appearance capsule, allowed locations, message history, and relationship state.

Without that distinction, the system can produce a sequence that feels continuous while secretly swapping the entity under the role. John gets a reminder from Emily, later sees a wife-like Sarah, then the ledger remembers Lisa as angry about a photo task. The prose can smooth that over. The world state cannot.

Why It Is Useful

This is exactly the kind of failure John’s World is good at exposing. A more spectacular world would hide identity drift behind big scenery. A suburban phone contact list is less forgiving. If the same household role keeps arriving with new names, the ledger has to explain itself.

It also maps cleanly onto agent systems. We see the same class of failure when an agent treats a label as the thing itself: project names, customer names, file names, environment names, model names. Labels are convenient handles, not guarantees of identity.

The next harness should maintain a canonical character registry with alias detection. It should ask, in effect: is Emily Harper a new fictional person, or did the model just rename Emily Carter because it was statistically comfortable? If the answer is uncertain, the system should quarantine the record instead of promoting it into the world.

That is less romantic than saying John’s wife changed names. It is also much closer to the actual problem, which is why it is worth writing down.