How a script is protected.

Script pages and exported PDFs are stamped with the reader’s name, email address, and a UTC timestamp, rendered on the server at the moment the page is produced. Applied to every role below Producer.

Server-side matters. A watermark drawn in the browser can be deleted from the page with developer tools in about four seconds. The identity in ours comes from the session, so a reader cannot request a copy carrying somebody else’s name.

Stated honestly: the on-screen script overlay is part of the page and a determined reader can remove it from their own view. The stamp baked into an exported PDF cannot be removed that way, and the PDF is the artefact that leaves the building.

Permissions are evaluated on the server for every query, at four levels — project, department, scene, and asset — with the most specific winning and an explicit deny beating an allow above it.

Actors are deny-by-default. An actor sees a scene only where one has been granted to them explicitly or where a character they play appears in it. There is no path that starts from “the whole script” and subtracts.

Search results are filtered before they leave the server. A result a user cannot open is itself a leak, so the filtering happens in the query rather than in the interface.

A call sheet that has not been published does not exist for anyone except the 1st AD and the Producer. That is enforced in the list query and again on a direct lookup by id, so guessing a URL does not reach a draft.

Publishing is deliberate and audited. Before anything is sent, the AD sees exactly who will receive it, by department and headcount, and nothing leaves until they confirm. Publishing and sending are two separate actions — a mis-clicked publish should not email a hundred people.

Scripts and uploaded assets are held in a private bucket and served through short-lived signed URLs, never from a public path. Data is encrypted in transit, and at rest by the database and object store.

The original .fdx of every revision is retained permanently. It is the legal source of truth for what the script said on a given date.

Links generated from an exportable view are tokenised, carry an expiry, can be password-protected, and can be revoked at any time. Revocation takes effect immediately; it does not wait for the token to age out.

Every create, update, and delete on a script, schedule, call sheet, budget, or approval writes a row with the actor, the timestamp, and the change. The log is append-only — there is no update or delete path, and the table carries no soft-delete column, so that is a property of the schema rather than a habit.

Producers and Directors can read it. Nobody can edit it.

Approving an asset locks that version. Changing it afterwards creates a new version and resets approval; it never edits the approved artefact in place. What was signed off stays exactly as it was signed off.

Deleting a project soft-deletes it for 30 days and then purges. Within that window it can be restored; after it, it is gone.