Scenes, Beats, Props, and Locations in One Project

The screenplay is a document; production work is a graph

A screenplay reads from top to bottom. Development and pre-production ask cross-cutting questions: which scenes share a location, which beat lacks a scene, which prop recurs, and which scenes are ready for a still or storyboard.

Laper keeps those views in one project while preserving a clear authority boundary. The screenplay determines narrative facts that can be read directly from its typed nodes. Planning and production entities add information the page should not carry.

Scenes: derived and ordered by the page

Every real scene begins with a scene_heading node. Laper derives scene entities from those nodes and scans their order from the screenplay. That scan is load-bearing because the CRDT scene map itself is unordered.

As a result:

• scene numbers follow the current page order;
• scene navigation points back to the real heading;
• scene tables and canvases can refer to the same entity;
• storyboard lists can use screenplay order;
• moving a scene in the draft can update the authoritative sequence.

If scene metrics are temporarily unavailable, some views can fall back to map order, but that is a degraded display—not a new source of narrative truth.

Locations: derived, then enriched

The location portion of a scene heading provides a deterministic starting point for location entities. The Locations module can then present those entities as a canvas, network, or scouting sheet and group related locations.

This separates two kinds of truth:

• INT. DINER - NIGHT establishes that the script uses a diner location;
• scouting notes, reference images, groupings, and production choices enrich that location for the team.

Changing scouting data should not rewrite the slugline without an explicit screenplay edit. Changing the slugline should remain visible to the location projection.

Beats: authored dramatic structure

Beats live as first-class CRDT data and can appear in beat, outline, and inspiration views. They help writers map story movement, but they are not presented as an infallible automatic extraction.

A writer may create beats manually, ask an explicit AI tool to propose or edit them, or use a framework such as the Save the Cat beat sheet. The dramatic interpretation stays reviewable. Software can show that a beat is placed near a scene; only the writer can decide whether the scene earns it.

Props: persistent project entities

Props need identity beyond a mention. A recurring object can carry description, visual reference, ownership, and layout information across scenes. Laper stores props as first-class project entities with canvas and list views rather than burying every decision inside action text.

The screenplay still describes what the audience sees. The prop layer gives development and art-direction work a stable subject. Explicit AI or user actions can create and enrich that subject, and generated references follow the durable task and asset pipeline.

Views can differ without data splitting

Each entity type supports the views appropriate to its work:

These views subscribe selectively to the Loro-backed project model. They do not need Supabase Realtime to shuttle screenplay state between screens. Real-time screenplay collaboration explains that separation in detail.

One model reduces reconciliation work

The value is not that every department gets more fields. It is that every field has an accountable home. Scene order belongs to the screenplay. Scouting belongs to the location. Camera choices belong to the shot. Generated media belongs to the task and asset system. Synchronization belongs to Loro.

That is the project model behind Laper's script structure visualization and the broader AI screenwriting software overview.