A character should not become five disconnected records
A screenplay introduces a character in the page, but development quickly creates more material: a profile, a relationship map, casting thoughts, visual references, scene statistics, and revision notes. If every view owns a separate record, names and intentions drift.
Laper begins with the screenplay cue. Character elements feed a shared character entity layer in the project. The writer can enrich those entities, and several views can project the same underlying data without copying it.
The page remains authoritative about who speaks. The character system adds information the screenplay format is not designed to hold.
Three views, one character model
The Characters module provides three different lenses:
| View | Question it helps answer |
|---|---|
| Character board | Who are the characters, what is known about them, and how should they be organized spatially? |
| Relationship network | Which emotional, familial, professional, or adversarial links shape the ensemble? |
| Casting view | What casting and performance information belongs to each role? |
These are not separate applications. The board, graph, and casting table subscribe to the same CRDT-backed characters and relationships. A profile change should not require three manual updates.
Relationship data is explicit. Laper does not infer every bond from co-occurrence and present it as fact. Writers can create and edit relationships, choose the meaningful labels, and decide which connections belong in the story model.
Derivation keeps the cast accountable to the draft
Character cues are machine-readable because screenplay format is structured. As the editor encounters those cues, it can establish the project entities used by the character views. Dialogue and scene scans can then provide useful statistics without changing the words.
This creates a two-way accountability:
- the screenplay tells the character layer who actually appears;
- the character layer gives the team a place for profiles, relationships, casting, and visual references;
- AI tools can read the relevant entity and scenes when a requested task needs both;
- collaborators see the same character state through Loro synchronization.
The system avoids claiming that a generated bio is automatically canon. AI can propose or populate fields through explicit actions, but the user remains able to review and edit them.
Visual development attaches to a real subject
Character portraits and casting references are handled as AI generation tasks and durable assets. The character entity provides the subject context; the generation backend owns task status and credit handling; successful outputs enter the project asset library. A selected result can be associated back with the character through the normal entity write path.
That separation prevents the image generator from becoming a shadow character database. Read AI production assets for the task and asset lifecycle.
Relationship maps are analytical, not decorative
A network view becomes useful when it helps test the story:
- Does the protagonist have a meaningful relationship outside the central conflict?
- Which character connects otherwise isolated plot lines?
- Is an ensemble built around one hub, or are there competing centers of gravity?
- Does the apparent antagonist have the relationship pressure needed to attack the protagonist's weakness?
The answer still comes from the writer. The graph makes the current model visible. It does not declare that visual density equals dramatic depth.
For structural diagnosis across scenes and arcs, the writer can bring those entities into the AI Script Doctor workflow. The doctor can read the outline and targeted scenes rather than operating on a graph alone.
Casting belongs beside character development
Casting is not just a headshot. It is an interpretation of role, age range, performance quality, and production intent. Keeping a casting view beside the character profile reduces the handoff gap between writer, director, and producer while preserving the screenplay as the source of performed behavior.
Laper's wider model connects that work to script structure visualization and real-time collaboration. The goal is not to replace casting judgment. It is to stop the data around that judgment from fragmenting.