One Change, Everything Moves
Most production software stores documents. The interesting version stores decisions — and lets them propagate. Notes on the rail beneath LightsKiddo.
By Matt
Here is the quiet disaster at the centre of almost every film production. A decision gets made — the scene moves to the coast, the actor's dates shift, the hero prop is cut — and then a human being has to walk that single fact into six different documents by hand. The breakdown. The shot list. The schedule. The budget. The call sheet. The edit's assumptions. Each lives in its own app, owned by its own department, and none of them knows the others exist. The decision was made once. It has to be re-entered six times, and it will be entered wrong at least once, and no one will find out until the day.
We started LightsKiddo from the belief that this is a data-modelling problem wearing a logistics costume. The industry stores documents. It should store decisions, and let the documents fall out of them.
The unit of truth is the decision
If you model a production as a pile of files, every file is a source of truth, which is another way of saying none of them is. The alternative is to make the decision itself the primary object, and to treat every artifact as a view of the decisions that produced it.
// A decision is the unit of truth. Everything else is a view of it.
type Decision = {
id: string;
subject: "scene" | "cast" | "location" | "asset";
change: Change; // what actually moved
at: string; // when it was made
by: string; // who stood behind it
};
// Downstream artifacts subscribe. They never keep their own copy.
schedule.dependsOn(decision); // re-sorts the strip
budget.dependsOn(decision); // re-prices the day
shotlist.dependsOn(decision); // re-plans coverage
Once the decision is the object, the six-documents problem inverts. You do not push a change outward into six places. You change one thing, and six views recompute, because they were never anything more than functions of the decision in the first place.
Propagation, not synchronisation
The word "sync" is a symptom. You only need to synchronise things that are allowed to disagree, and the whole trouble starts the moment two documents are allowed to hold different versions of the same fact. So we do not sync. We propagate.
Move scene fourteen to the coastal house, and the strip re-sorts, Thursday's daylight goes tight, the location fees swap, and the overtime risk re-prices — before you have finished reading this sentence.
That is not a feature. It is what falls out for free once the model is right. The engineering work is almost entirely in the discipline of refusing to let any downstream view store its own authoritative copy of an upstream fact — because the instant it does, you are back to synchronising, and back to the day-of surprise.
What we refuse to propagate
There is one thing the rail deliberately will not do, and it is the most important line in the system: it will not make the decision for you. It will re-sort the schedule the moment you move the scene, but it will never move the scene. Propagation is mechanical and total; the decision is human and singular. The machine's job is to make the consequences of a choice instant and honest, so that the person making it can see the full cost of the change and then make it anyway, or not.
One change, everything moves. The change is still yours to make.