Script Revisions & Note Reconciliation

Why this exists

Scripts change constantly during prep. Scenes get renumbered, rewritten, inserted, and cut. Older systems keyed a scene’s identity on its number or its name, which caused two painful bugs: genuinely different scenes at the same location were flagged as duplicates, and a simple renumber orphaned a scene along with all its notes, shots, and comments.

The fix is a single idea: a scene’s identity comes from its content, not its number.

The spine — a deterministic scene count

When a script is analyzed, a deterministic parser (the “spine”) reads the PDF text and establishes the ground truth: how many scenes there are, where each begins, and a stable content fingerprint for each. The AI then annotates this fixed list (names, descriptions, elements) — it never invents or merges scenes. Scene count and boundaries can never disagree with what’s on the page.

• Scenes split across a page break are merged back into one scene.
• Inserted A scenes (e.g. 4A) keep their literal number.
• Each scene gets a content hash and a set of text shingles used for matching.

Cross-draft scene matching

When you import a new draft, each new scene is matched against your existing scene rows using a best-first ladder. Whatever matches keeps its database row — and therefore its shots, palette, mood board, department notes, and comments.

• Unchanged — identical content hash. Same scene, no text change.
• Revised — high text similarity. Same scene, lightly edited.
• Rewritten — same location and roughly the same position, moderate similarity.
• Renumbered — matched, but the scene number differs; the old number is stored in the scene’s history and shown as a 4A → 5 notice.
• Added — a new scene with no counterpart in your project.
• Removed — an existing scene absent from the new draft (a genuine cut).

The review screen’s Scene Changes summary groups every scene by these kinds with a text-diff preview, so the team can agree on what changed before confirming the import.

Versioned scene text

A scene’s script text is never overwritten in place. Each meaningful change appends a numbered revision, so the full history is preserved.

• The Script tab shows a Script updated to v4 banner once a scene has more than one revision.
• Toggle Show changes for an added/removed diff against the previous revision.
• The current text is a fast read cache; the authoritative history lives in the revision log.

Comment anchor states

Script comments are anchored to a character range in a specific revision. When the text changes, every anchor is recomputed against the new text and lands in one of three states:

• ok — the anchored passage is unchanged; the highlight tracks it exactly.
• shifted — the passage moved (text was inserted or removed around it); the highlight follows it, disambiguated by the stored context on either side.
• orphaned — the passage can no longer be placed confidently. The comment is not deleted; it moves to the Unanchored comments list with its quoted text intact.

Department note staleness

Camera and Art notes are prose written by a human, so they are never auto-edited. Instead, each note remembers the script revision it was last reviewed against. When the scene’s script advances past that revision, the notes tab shows a Script changed since these notes chip.

• What changed opens a diff of the script since your last review.
• Acknowledge marks the notes as reviewed against the current revision and clears the chip.
• Saving a note automatically acknowledges the current revision — freshly written notes are never marked stale.

Existing projects

Projects created before this system are handled gracefully. On the next import, spine-style content hashes are computed on demand from each scene’s stored text, so already-imported scenes match correctly instead of producing a round of false “removed” scenes. Rows that predate content hashing fall back to a scene-number + slug match.

Permissions