The decision record
Every decision on an episode (pushes, submissions, approvals, rejections, client verdicts, comments, shot notes) written once, in order, into a record neither side can quietly rewrite.
Why a studio needs one
Client work runs on memory until the day it doesn't. Then it's March, the customer says the cut they signed off had the old tagline, your editor is certain it didn't, and the only evidence anybody has is a thread where the relevant message is an attachment nobody can open. Whoever is more insistent wins. That's not a record. That's a negotiation about the past.
So every episode carries a ledger, and it has two properties that a message thread does not: entries are only ever appended, never edited or deleted, and each entry's hash covers the one before it. Change any entry after the fact and every entry after it stops matching. The history is checkable rather than merely stored.
What the chain looks like
What gets recorded
Every event that changes what somebody knows or what somebody owes:
- Pushes. An episode's script, decisions and state synced up from an operator's machine, and media pushed alongside it.
- Submissions. A cut put forward for client review, and the note that came with it.
- Approvals and rejections: the owner's decision at the publish gate, with the internal note on a rejection.
- Client verdicts. Approvals and change requests from the customer's seat, and how each one arrived: from the portal, or from the review link you sent.
- Comments: free text from either side, in order, in place.
- Shot requests and their resolutions. What was asked on which shot, of which kind, and how it was answered.
- Screenplays and assets handed over: what the customer sent you and when.
Read as a list, it's the production's history. Read as a chain, it's the production's proof.
Approvals name the exact cut
The single most useful property of the record is that a sign-off is attached to content, not to a filename. When a customer approves, the entry carries the content hash of the video they were shown, the same hash their signed link was pinned to.
That closes the gap where these disputes live. "The client approved the delivery" is a claim about a file path, and file paths get overwritten. "The client approved the video whose content hashes to e930…" is a claim about a piece of footage, and it stays true no matter what happens to the folder it was in.
How the answer reached you is recorded beside it, and changes nothing about it. An approval that came from a tapped link is the same seat, the same hash, the same entry in the same chain as one made after signing in. The extra field exists so a studio can audit how its deliveries actually travel, not so that one kind of yes counts for less. Your customer's own copy of the history leaves that column out; it answers a question about their front door, which is not a question they asked.
Verifying it
Both sides can check the chain from their own side of the system, without asking the other for anything: recompute each entry's hash from its contents and the entry before it, and confirm the sequence holds end to end. A studio can prove its record is intact; a customer can confirm the history they're reading is the history that was written.
Append-only, including your mistakes
Worth being straight about the cost of this design. Nothing can be deleted, so a comment sent to the wrong episode stays there, and so does a rejection you'd rather have phrased better. The correction is a new entry, not an erasure, and the record shows both what you said and what you said afterwards.
That is the trade, and it's deliberate: a record your customer can trust is one that you also cannot tidy. The version of this feature where the owner can delete entries is the version where an approval proves nothing.
Next: hub, portal & the terminal, the three places you'll actually be working.