The production bible#

A twenty-minute film is hundreds of shots, and what makes them feel like one film is that the same character has the same face in every one of them. The production bible is where you record what "the same" means: one entry for each recurring character, environment, prop or style, with the reference images that define it.

Those references are then supplied to every generation that involves that entry. The bible is not documentation about your production — it is the input your production runs on.

ZymCOS is in active development. The bible works through the API today. Its screens in the Production Book are still being built, so what you read here describes behaviour you can drive, not a page you can open yet.

Entities#

Each entry in the bible is an entity, and every entity has a kind and a name.

A name is unique per kind within a project, so "which Maya?" is never a per-shot guess. An entity you have never snapshotted can be deleted; once it has locked versions it cannot, because those versions are the record of what your finished shots were actually made from.

Reference packs, and why they matter#

An entity's reference pack is the list of images that define it, chosen from assets already in the same project. Nothing else in the bible does as much work.

Today's generation models hold identity from references rather than from a description. Give them the same three photographs of a character in shot after shot and the character stays recognisable; describe her in words instead and she drifts. Everything else here — versions, locking, the continuity check — exists to make sure the right references reach the right shot.

Practical guidance:

• Several references beat one. The identity fingerprint is built from the whole pack, not from whichever image happens to be first, so a varied pack is more robust than a single hero image.
• Duplicates are dropped, order is kept. Sending the same image twice does not weight it twice.
• Show the thing you want measured. A character whose pack is only back-of-head shots has no face to compare against, and her identity simply cannot be checked. That is reported honestly rather than passed silently, but it is easier to fix in the pack than in a shot.
• A reference must belong to the same project. An image id from anywhere else is rejected.

Recording a rights basis#

An entity can also carry a rights basis — where your permission to use this likeness, place or object comes from — together with a consent record and a note on its scope.

There are four bases: the material is original to you, licensed from someone, used with documented consent, or wholly synthetic.

This is not paperwork for its own sake. A person's voice and likeness are property, and the first question a studio's counsel asks about an AI-assisted production is whether every character in it has a documented basis. Recording it here turns that from an email thread into a mechanical answer.

Two things to know about how it behaves:

• ZymCOS records your basis; it does not judge whether it is sufficient. What it does enforce is that a reference with no basis at all, or one whose rights have been withdrawn, never reaches a shot — so nothing you pay to generate is conditioned on an undocumented likeness.
• Re-curating a pack clears the rights. Consent names specific images, so changing which images an entity uses invalidates the permission that described the old ones. If the new pack is covered by the same basis, state the basis again in the same request.

Locking: a snapshot, not a state#

Locking the bible takes a numbered snapshot of the whole registry. Every entity in the project gets a fresh, immutable version carrying the pack and the rights it had at that moment, and the snapshot itself is recorded as revision 1, 2, 3 and so on.

The word "lock" is film vocabulary, and it can mislead here, so it is worth being precise:

• Nothing is frozen. Your entities stay editable after a lock. That is deliberate — a production keeps developing, and only the version a finished shot was made from must not move.
• There is no unlock, because there is no state to leave. Correcting a mistake means editing the entities and locking again. Revisions accumulate, which is intended and costs nothing.
• A version, once minted, never changes. That is what makes a retake reproducible: a shot redone six weeks later uses exactly the references it used the first time, even if the entity has moved on since. It is also what makes drift attributable — you can point at a specific locked reference rather than at a moving target.

When a lock is refused#

A snapshot covers the whole registry, so it refuses rather than quietly skipping:

• An entity with an empty reference pack. The refusal names the unfinished entities. An entity with no references cannot condition a generation and cannot be checked for continuity; the lock is the cheapest moment to notice that.
• A project with no entities at all. There is nothing to snapshot.
• A revision someone else just took. Two people locking at the same moment is resolved by refusing the second rather than silently creating two near-identical snapshots. Read the history and lock again.

What a lock reports rather than refuses#

A lock tells you how many entities it snapshotted and how many of them have no rights basis yet — "revision 3, 41 entities, 2 pending rights". It is a report, not a blocker. Drafts legitimately exist before the paperwork does, and a bible you cannot snapshot until every release form is signed would stop all creative work on a legal dependency.

The refusal that protects you arrives later and more precisely: a shot cannot commit to a version with no basis, so nothing is generated from it.

Withdrawing rights#

If a permission is withdrawn, the affected version is marked as revoked. This is the one change that is ever made to a locked version, and it is not retroactive:

• shots that already committed to it stand — they are the record of what happened, and rewriting history would destroy the provenance the record exists to give you;
• new commitments to that version are refused from that moment on.

What happens after a lock#

Locking is also what makes continuity measurable. A separate pass reduces each version's reference pack to a compact fingerprint — one for a character's face, one for a figure or prop, one for a set — and the continuity check compares generated frames against those. A pack that yields nothing usable leaves that fingerprint absent, and the check says so rather than inventing a result.

That side of the system is described in The continuity gate.