Define a character once, cite it forever: what should I watch out for?

Editing a locked character forks it into a new ID. Existing shots keep pointing at the old one by design.

Uploading a real person's photo is a consent question. Workspace policy can require an attestation before lock.

CONTINUITY

Define a character once, cite it forever

A character is an entity with reference plates, wardrobe notes and a locked identity — not a paragraph you retype into every prompt.

01CreateName and describe. Returns an ID like char_maya.

02PlateGenerate a turnaround — six views, consistent identity.

03LockFreeze the plates. Later shots resolve against them.

04CiteShots name the ID; the resolver supplies the images.

Locations and props follow the same lifecycle. Anything that must stay consistent across shots belongs here.

cast.create(desc): Create a character entity from a description or an uploaded photo.
cast.plate(id, views): Generate a reference sheet of N consistent views.
cast.lock(id): Freeze the identity. Required before a character can be cited.
location.create(desc): Same lifecycle for a place, with an establishing plate.

RequestPOST /v1/cast

{
  "name": "maya",
  "desc": "late 20s barista, curly hair",
  "plates": 6
}

Response200 OK

{
  "id": "char_maya",
  "plates": 6,
  "locked": true,
  "embedding": "emb_77c1"
}

From the CLI

$ picx cast create maya --desc "late 20s barista, curly hair"
$ picx cast plate maya --views 6
$ picx cast lock maya

✓ char_maya locked · 6 plates

Lock your cast before you shoot. Ten minutes here saves an afternoon of characters who change face between shots.

Each plate carries a face embedding. Continuity scoring compares a take's embedding against the locked mean — that is the signal behind auto-retake.

Editing a locked character forks it into a new ID. Existing shots keep pointing at the old one by design.
Uploading a real person's photo is a consent question. Workspace policy can require an attestation before lock.