DEV Community: shizhiliang

Give AI Scene Rewrites a Knowledge Ledger

shizhiliang — Tue, 13 Oct 2026 00:56:56 +0000

Disclosure: I’m building Laper. This article was generated with AI assistance. The example is fictional, and the data structure below is a proposed workflow, not a claim about a feature in Laper.

A rewrite can preserve every character name and still break a mystery. The detective asks about a hidden recording before anybody has told her it exists. The line sounds natural. The scene no longer makes sense.

For an AI-assisted rewriting workflow, “keep the story consistent” is too broad a check. One smaller question is easier to review: what information is available to this character at this point?

The full script is not the character’s context

Imagine a scene where Noor enters a station office to recover her brother’s bag. The audience saw a recorder sewn into its lining. Noor did not. A clerk knows the bag was moved upstairs, but has no reason to know about the recorder.

If a rewriting prompt includes the whole outline, it includes all three perspectives. A fluent output might let Noor say, “Give me the recording,” turning audience knowledge into character knowledge without a discovery.

That is a continuity error unless the writer intends to reveal that she knew all along. The problem is not the wording. It is the missing evidence for her knowledge.

Track fact, belief, and source separately

A small ledger can keep those perspectives apart. Here is an illustrative JSON record for the start of the scene:

{
  "scene": "station_office",
  "story_fact": "recorder_is_in_bag_lining",
  "audience_knows": true,
  "characters": {
    "Noor": {
      "status": "unknown",
      "source_scene": null
    },
    "clerk": {
      "status": "unknown",
      "source_scene": null
    }
  }
}

Use a separate record for the bag’s location. The clerk knows it moved upstairs. Noor believes it is still behind the desk. Her mistaken belief is not a data error to “correct”; it gives her a reason to ask the wrong question.

For each important fact, record only three things: who knows or believes it, what supports that state, and which scene changes it. Avoid cataloguing every incidental detail. Start with information that changes a decision, exposes a lie, or enables a reveal.

Make the review return evidence, not reassurance

Alongside the scene text, give a rewriting system a compact instruction:

Preserve the knowledge states supplied for the start of this scene. Do not let a character act on audience-only information. If a character learns something, identify the observable event that teaches it. After the rewrite, list any knowledge changes with a quote from the scene. Mark uncertain cases for review instead of inventing an earlier discovery.

This is a prompt specification, not a guarantee. A model may still miss a violation or produce an unsupported explanation. Review the cited line yourself.

A useful review output has a character, a fact, the before-and-after state, and the supporting line. “Continuity preserved” provides much less to inspect than “Noor now knows the bag is upstairs because the clerk says, ‘It went up with the other evidence.’”

Check the next scene as well

Suppose Noor opens the lining at the end of this scene. Her knowledge has changed, but finding a recorder does not mean she knows what it recorded. Those should be separate entries.

Now review the following scene. Does she search for a way to play it, or immediately accuse someone using information she has not heard? A local rewrite can create a downstream error even when its own ending works.

An intentional reveal is different. If Noor’s impossible knowledge is a clue, annotate that intention and its later explanation. Do not automatically reject every apparent inconsistency.

Start with one reveal

Pick a reveal in your current script. Work backward to the earliest moment each person could know it, then inspect the intervening dialogue. Keep the ledger beside whichever writing tool you use.

This is part of the broader story-workflow problem that interests me while building Laper: good prose still needs an accountable path from information to action. You can learn about the project at laper.ai, but the exercise needs no particular product.

A character can guess, bluff, or lie. The rewrite should give you enough evidence to tell which one is happening.

Evaluate AI Dialogue Rewrites by Tactic, Not Just Fluency

shizhiliang — Mon, 12 Oct 2026 00:02:29 +0000

A dialogue generator can produce five polished alternatives that all do the same thing: ask again, with different adjectives. If your writing tool labels these “more dramatic,” fluency has become a proxy for a change it never actually measured.

Here is a small, human-reviewed evaluation workflow for separating a wording change from a tactical change. It is a proposed test design, not a benchmark result or a claim about any product's implementation.

Start with an observable distinction

Use an invented scene. Mara needs her coworker Eli to sign a transfer request before the office closes. Eli wants to know who will take over his unfinished work.

Original line: “Please sign it before five.”

Candidate A: “I really need your signature before five.”

Candidate B: “If I take the Friday handover, will you sign it now?”

Candidate C: “The director already approved it. You are only holding everyone up.”

A intensifies the request. B offers a trade. C invokes authority and applies pressure—but invents an approval unless that fact already exists in the scene. A tactical change is not automatically an acceptable rewrite.

1. Make the fixture small enough to inspect

Keep the source exchange, known facts, and requested change together. For example:

{
  "goal": "Mara wants Eli to sign before five",
  "known_facts": [
    "Eli is worried about his unfinished work",
    "Mara can offer to handle Friday's handover"
  ],
  "unknown_facts": ["Whether the director approved the transfer"],
  "source_tactic": "direct request",
  "requested_tactic": "offer a concrete trade",
  "must_preserve": ["Eli has not agreed yet"]
}

Do not turn missing information into false certainty. “Unknown” means the evaluator should not accept a new claim as established fact; it does not mean the claim is necessarily false.

2. Ask for evidence, not a quality score

A useful review record has four fields:

Observed tactic: What is the speaker trying to get the other person to do, and how?
Evidence: Quote the exact words that support that interpretation.
New commitments or facts: What did the rewrite add?
Decision: Accept, revise, or uncertain—with one reason.

For B, the evidence is “If I take the Friday handover.” The added commitment is explicit and supported by the fixture. It is a reasonable candidate to keep, not proof of a good scene. Eli's response still has to make dramatic sense.

For C, the authority tactic is visible, but the approval is unsupported. Flag that separately rather than rewarding the stronger tone.

3. Test the evaluator with contrast pairs

Before relying on a reviewer model, include pairs where a fluent answer should not win:

Same request, more emotional wording.
A genuine trade versus an unrelated new offer.
A change of tactic that preserves facts versus one that invents leverage.
An indirect line with two plausible readings, where “uncertain” is appropriate.

Have a person label the pairs first. Compare the model's evidence and decisions against those judgments. If people disagree, keep the disagreement visible; do not hide it behind a single reference label.

This is a qualitative test set. With only a few examples, a pass percentage can create more confidence than the evidence deserves. Log concrete failure modes instead: unsupported leverage, paraphrase mistaken for strategy, or ambiguous subtext treated as certain.

Where automation should stop

Simple code can check whether required fields are present. It cannot establish that a character's offer feels honest, surprising, or dramatically appropriate. A second model can suggest a reading, but it is not independent proof that the first model improved the scene.

The final review question belongs to the writer: does the other character now have a different reason to answer?

Disclosure: I work on Laper. This article was generated with AI for our editorial account. The fixture and evaluation workflow above are illustrative, not a description of a shipped Laper feature or measured results.

Try the test on one exchange before expanding it into a pipeline. If every alternative gives the listener the same choice, you may have generated variety in wording—not variety in action.

Treat AI Scene Rewrites as Constrained State Changes

shizhiliang — Sun, 11 Oct 2026 03:34:12 +0000

Disclosure: I’m building Laper. This article was generated with AI assistance. The workflow below is a standalone design example, not a description of shipped product behavior or measured results.

An AI rewrite can improve every sentence and still break the next scene. For developers building writing tools, that is an evaluation problem: fluency is not the same as preserving the writer’s intent.

Consider an invented screenplay scene. Two sisters are clearing their late father’s apartment. The older sister has booked a viewing for tomorrow without permission. The younger sister does not yet know that. By the end, she agrees to the viewing but keeps the spare key.

A polished rewrite in which she hands over the key has changed more than dialogue. Any later scene built around her control of the apartment now needs another pass.

Why one “quality” score misses the failure

A reviewer might prefer the more conciliatory version in isolation. That does not make it the right replacement in this screenplay. Separate at least two questions: does the scene read well, and does it satisfy the current revision brief?

The brief is not an objective definition of good storytelling. A writer can change it. The important part is making that decision explicit instead of silently treating a different outcome as a style improvement.

1. Store the revision contract separately from the prose

A small, writer-approved record is enough to start. Here is illustrative JSON, not a production schema:

{
  "sceneId": "apartment-07",
  "revisionGoal": "Make the older sister's request less direct",
  "initialFacts": [
    "The older sister knows the viewing is tomorrow",
    "The younger sister does not know about the booking"
  ],
  "requiredEndState": [
    "The younger sister agrees to the viewing",
    "The younger sister keeps the spare key"
  ],
  "forbiddenChanges": [
    "Add a new family secret",
    "Resolve the disagreement about selling"
  ]
}

Keep the source scene, contract version, and candidate rewrite together. If someone later edits the contract, an earlier review should not appear to validate the new requirements.

This is deliberately smaller than a complete character database. It records the facts needed for this revision, not every fact in the fictional world.

2. Ask for evidence, not a self-awarded pass

A separate review step can compare the candidate against each requirement. Ask it to quote the relevant lines and return one of three statuses: supported, contradicted, or unclear.

For example, “She drops the key into her sister’s palm” contradicts the required end state. “They look at the door” does not establish who keeps the key; mark it unclear rather than inventing evidence.

These labels are proposed review outcomes, not benchmark results. A model-generated check can miss implication, sarcasm, or an unreliable speaker. Treat it as a queue of claims for the writer to inspect, not an automatic approval gate. If the reviewer cannot point to evidence, show that uncertainty.

3. Review the boundary before accepting the patch

Show the original scene and proposed replacement side by side, followed by the beginning of the next scene. The writer should be able to accept, reject, or revise the candidate without overwriting the original first.

For the apartment example, check whether the next scene assumes the younger sister still has the key. Also check when she learns about the viewing: a line mentioning tomorrow before the reveal may be a knowledge leak, unless the writer deliberately establishes another source.

Keep structural checks separate from semantic ones. Software can check that an output includes required fields or a valid status value. That does not prove its interpretation of the screenplay is correct.

Try a tiny evaluation set

Before adding automation, assemble three hand-written candidates for the same scene: one that preserves the brief, one that hands over the key, and one that leaves the key’s location ambiguous. Have a human label the relevant passages, then compare the reviewer’s output against those labels.

This small set can expose obvious weaknesses in your review design. It cannot establish general reliability. Add different scenes and failure types before making broader claims, and keep human review in the acceptance path.

The useful question is not only “Is this rewrite better?” It is “What changed, what evidence supports that reading, and did the writer intend it?” A writing tool that exposes those questions gives its user something more useful than a confident score.

Why AI Script Writers Lose Track of Characters

shizhiliang — Sat, 10 Oct 2026 03:18:41 +0000

An AI writer can produce a convincing confrontation and still lose the character one scene later. A cautious investigator suddenly confesses without leverage. A son who learned about his father's debt asks about it as if it were new. Two rivals speak with the warmth of old friends because the prompt requested an "emotional conversation."

The sentences may be polished. The character logic is not.

An AI Script Writer is more useful when it treats the screenplay as an evolving source of story facts rather than a collection of isolated prompts. Laper keeps screenplay scenes inside a structured project and connects planning material to the work that requested it. That structure can make continuity easier to inspect, but it cannot decide what a character should feel. The writer still owns the change.

Compare Prompt Memory With Story State

Giving a model more previous text can help, but text volume is not the same as dramatic memory. A screenplay carries facts that change at different speeds.

Memory layer	What it records	Typical failure
Identity	Values, habits, voice and long-term fear	The character behaves like a different person
Knowledge	What the character has learned or misunderstood	A reveal is repeated or anticipated too early
Objective	What the character needs in the current scene	Dialogue sounds good but does not pursue anything
Relationship	Trust, debt, power and concealed conflict	Enemies speak like friends without a dramatic cause
Performance	What the character shows versus what they feel	Subtext disappears into direct explanation

The useful unit is not "everything written about this person." It is the state that matters now.

Test One Character Across One Dramatic Turn

Do not begin by asking the system to remember an entire feature. Choose one character and one irreversible change.

Imagine Maya, an observant investigator who trusts her business partner, Daniel. Halfway through the story, she finds evidence that Daniel hid a payment. She needs access to his office, so she continues performing trust while privately testing him.

The next scene should preserve five facts:

Maya is controlled and reluctant to accuse without proof.
She knows Daniel lied about the payment.
Daniel does not know what she found.
Maya needs him to leave the office unlocked.
The audience should notice that her friendliness has become strategic.

Now request the scene twice. In the first version, provide only Maya's biography and the latest prompt. In the second, provide the five current facts. Compare what changes.

The test is not whether the second version uses more detail. It is whether every line serves the same concealed objective.

Separate Stable Traits From Changing Facts

A character profile often mixes permanent description with temporary state. "Reserved, loyal, angry with Daniel, carrying a recorder" looks compact, but the four facts have different lifetimes.

Keep them separate:

Stable trait: Maya avoids accusations she cannot prove.
Current belief: Daniel concealed the payment.
Scene objective: Get access to the office.
Visible behaviour: Remain calm and cooperative.
Hidden pressure: She may lose the evidence if Daniel becomes suspicious.

This separation prevents one dramatic beat from rewriting the whole character. Anger in one scene should not become a permanent voice setting. A prop used once should not follow the character forever. A mistaken belief should be able to expire when the truth arrives.

Make Knowledge Unequal

Characters rarely share the same version of the story. Suspense often depends on that inequality.

For every important fact, record three positions:

Who knows it?
Who only suspects it?
Who believes the opposite?

In Maya's scene, the audience and Maya know about the hidden payment. Daniel may suspect that she is investigating, but he does not know what she found. A colleague still believes the partnership is healthy.

If the generated dialogue gives all three people the same knowledge, the scene loses its pressure even when every sentence is individually plausible.

An AI screenplay software workflow should therefore expose the context used for a scene instead of hiding it behind a general promise of memory. Writers need to see which facts entered the request, reject the wrong assumptions, and keep approved changes attached to the authoritative draft.

Track The Cause Of Every Character Change

A character can contradict an earlier version of themselves. That is often the point of drama. The continuity test is not "Did this person remain the same?" It is "Did the story earn the difference?"

Write a cause beside each meaningful change:

Trust becomes suspicion after Maya finds the payment record.
Restraint becomes confrontation after Daniel destroys the evidence.
Isolation becomes cooperation after Maya admits what she concealed.

Without the cause, development becomes random variation. With it, a surprising action can still feel inevitable in retrospect.

Use A Five-Part Character Consistency Check

Review the generated scene without asking whether the prose sounds impressive.

Knowledge: Does the character know only what the story has revealed to them?
Objective: Does each choice pursue the current scene goal?
Relationship: Does the behaviour reflect the latest balance of trust and power?
Performance: Is the difference between feeling and display still visible?
Causality: Can every meaningful change be traced to an event in the screenplay?

A scene can fail one category and still contain useful material. A blunt accusation may be out of character but reveal the conflict the scene needs. Keep the conflict, reject the behaviour, and rewrite the route.

Approve A Character Rule, Not A Favorite Line

The most valuable result from a continuity test is not one clever exchange. It is a rule the next scene can obey.

For Maya, the rule might be: Until Daniel knows she found the payment, Maya turns suspicion into practical questions and never names the accusation directly.

That sentence can guide dialogue, blocking and performance. It can also be revised when the story crosses the next threshold.

AI should reduce the work of carrying decisions across a long project. It should not hide those decisions or make them on the writer's behalf. When identity, knowledge, objectives and relationships remain visible, generated scenes become easier to judge and easier to reject.

The final test is simple: a reader should recognize the same character while feeling that the story has changed them.

To explore a structured AI-assisted screenwriting workflow, visit laper.ai.