How to Build a Shot Level Provenance Record for AI Vertical Drama

Episode forty one, shot twelve. A note comes back asking why the kitchen reads warmer here than it does in episode thirty nine. The shot was generated six weeks ago by an operator who has since rotated onto a different block. The file sits in the delivery folder where it belongs. The prompt that produced it is somewhere in a session history, a shared document, or nowhere at all. Answering the note means reconstructing a decision from its output instead of reading the decision that was made. That reconstruction takes an afternoon when it should take ninety seconds, and on a seventy episode pipeline it recurs often enough to become one of the largest uncosted line items in the schedule.

The fix is not better memory or tidier folders. It is a record written at the moment of generation that makes the question answerable by lookup. This is the structure of that record, where it gets written, how it is queried, and how to introduce it into a series that is already underway.

1. What a Provenance Record Is and What It Is Not

A shot level provenance record is one row per accepted asset stating which prompt, which reference inputs, which model and which settings produced the file now sitting in delivery. It answers a single question in one direction: this frame exists, what made it. The term carries over cleanly from records management, where provenance describes the chronology of custody of an object rather than any judgement about the object itself. The record holds fact, not intent, and that distinction is what keeps it small enough to be maintained by the people generating the work.

It is not a continuity bible, which holds what the series is supposed to look like. It is not a retake log, which holds what failed and why. It is not a style guide or a shot plan, both of which exist before generation and describe what should happen. Provenance exists after generation and describes what did. Teams that try to merge these four documents end up with one document that nobody updates, because each has a different author, a different update rhythm and a different reader. Keep them separate and each one stays current.

2. The Eight Fields That Make a Frame Traceable

Eight fields are enough. Series code, episode number, scene number, shot number and version give the asset its address and match the naming convention already in use on the files themselves. Prompt identifier, reference set identifier and model identifier give the asset its lineage. A date stamp and an operator initial round it out, though those two are diagnostic rather than reproductive. Anything beyond this starts to duplicate the shot plan, and duplication is what causes the record to drift out of agreement with the files it describes.

Resist the urge to add free text. A notes column fills with the reasoning an operator had at the time, which feels valuable and is almost never read, while the structured fields that would actually answer a question go half completed because the notes column absorbed the attention. If reasoning needs to be preserved, it belongs in the retake log where failure analysis lives. The provenance row should be fillable in under fifteen seconds from information the operator already has on screen, or it will not be filled at all.

3. Where the Record Gets Written

The row gets written in the same action that names the output file. Not at the end of the day, not at the end of the block, not during a review pass. The information needed to complete a provenance row is fully available for about ninety seconds after a generation returns and begins degrading immediately afterwards, because the operator moves to the next queue item and the session scrolls. A record written at the point of naming costs almost nothing. A record written at the end of a block is partly reconstructed, and a reconstructed record is worse than no record because it carries the authority of documentation without the accuracy.

One append only sheet per series works better than one sheet per episode or one per operator. Per episode fragments the lookup exactly when a question spans episodes, which is when most questions arrive. Per operator fragments it along the axis that matters least to the reader. A single sheet with a few thousand rows is trivially filterable and gives every operator the same destination, which removes the question of where a row belongs. Write access is shared. Edit access to existing rows is not, for reasons covered in section eight.

4. How to Capture the Prompt Without Storing Nine Hundred Text Files

Prompts are long and most of their length is shared. Storing the full text alongside every row produces a sheet that is unreadable and a maintenance burden that grows with the episode count. Store each distinct prompt once in the prompt library and reference it from the provenance row by a short stable identifier. The library entry holds the text. The provenance row holds the pointer. A series running seventy episodes typically resolves to a few hundred distinct prompt bodies rather than nine hundred, because coverage repeats and only the variable layers change between shots.

The pointer has to be immutable. If an operator improves a prompt body in the library, that is a new identifier, not an edit to the old one. This is the single rule that makes the whole record trustworthy, and it is the rule most often broken, because improving a prompt in place feels like tidying rather than like destroying evidence. Where a prompt is assembled from layers, record the identifier of the assembled result rather than the components, and let the library entry record which components it was built from. One pointer per row keeps the lookup single step.

5. How to Record Reference Inputs and Model State

A prompt alone does not determine an output. The same prompt text against a different character reference, a different location plate or a different first frame produces a materially different shot, so the reference set carries equal weight and needs its own identifier with its own version. Reference sets change more often than prompt bodies do, usually quietly, when someone swaps in a cleaner face plate or a corrected wardrobe still. Versioning the set rather than the individual files means the row stays one field wide while remaining precise about which combination was in play.

Model state is the third leg and the one teams skip. Record the model name and the version or release date in force at generation time. Generation models move, and a reference set that produced reliable output against one release can drift against the next one without any change to the prompt or the references. When a block generated in one month and a block generated three months later disagree visually, model state is the field that explains it, and it is unrecoverable after the fact. Two tokens per row buy an explanation that would otherwise require guesswork.

6. What to Do When a Shot Is Reworked in Edit

Most delivered frames are not raw generation output. They have been graded, stabilised, retimed, cropped or composited, and each of those operations breaks the direct line between the delivery file and the prompt. The answer is not to record edit operations inside the generation row, which mixes two different authorities into one line. The answer is a derived row that points at its parent. The parent row says what was generated. The child row says what was done to it and by whom, and carries the parent identifier as its lineage field.

This matters most on the questions that look simplest. A note about warmth in a kitchen may resolve to a prompt difference, a reference difference, a model difference or a grade applied in post to one episode and not another. Without a derived row, the generation record gets blamed for a decision made two steps downstream, and an operator spends a day regenerating a shot that was correct when it left the pipeline. The derived row makes the boundary between generation and edit visible, which is where most cross stage confusion on a long series actually originates.

7. How to Query the Record When a Question Arrives

Three question shapes account for nearly all real use. The first is diagnostic: this shot is wrong, what produced it. That is a single row lookup by file name and it is the use everyone anticipates. The second is reproductive: the platform wants three more shots that match this one, what do we feed the generator. That is also a single row lookup, read in the other direction. Both are satisfied by any record that exists at all, which is why teams underbuild and then find the record thin when the third question arrives.

The third shape is the one that justifies the structure: this input is bad, what else used it. A character reference that turns out to have a wardrobe error, a prompt body with a geography flaw, a model release that introduced a drift, each implies a set of affected shots that may span twenty episodes and three operators. Filtering by reference set identifier or model identifier returns that set in seconds. Without the record, the same question becomes a visual review of the entire delivered series. This is the query that converts provenance from administrative overhead into schedule protection.

8. The Failure Modes That Break Traceability

Three failures account for most broken records. Rows written after the fact, which have already been covered and which produce confident inaccuracy. Silent edits to prompt bodies or reference sets without a new identifier, which make every historical row that points at them subtly false. And overwritten versions, where version four replaces version three under the same file name and the row that described version three now describes something else. All three share a cause, which is that the record was treated as a working document rather than as an audit trail.

The structural defence is append only discipline. Rows are added, never edited. A correction is a new row that supersedes an earlier one and says so. Versions get distinct names and distinct rows even when the earlier version is immediately discarded. This feels wasteful for about a week and then starts paying, because the first time a question arrives about a shot that went through four versions, the record shows the sequence rather than only the survivor. Lock edit access on existing rows and the discipline enforces itself without anyone having to remember it.

9. How to Retrofit a Production That Is Already Halfway Through

Do not backfill. A team that decides to document forty episodes retroactively will spend three weeks producing a record whose accuracy nobody can vouch for, and the exercise competes directly with the generation schedule it was meant to protect. Start the record forward from today, with a clear boundary note stating which episode is the first one covered. A record that is honest about its start date is more useful than one that pretends to completeness, because a reader knows which questions it can answer and which it cannot.

Then backfill selectively, by value rather than by sequence. Hero shots that will be reused in marketing, recurring interiors that will appear again in later blocks, and any character reference still in active use are worth reconstructing because they will be queried again. One pass over the prompt library to assign stable identifiers to the bodies already in it, and one pass to version the reference sets currently live, gets most of the forward value without touching the historical rows at all. Treat the gap as a known condition rather than a debt to be cleared, and the record stays trustworthy from the moment it starts.

Axis AI Studios Perspective

Axis AI Studios runs native vertical production from a standing records layer rather than assembling one when a question arrives. Shot naming, prompt library identifiers, reference set versions and model state are captured at generation time on every series, because a seventy episode production generates questions for months after delivery and the answers have to survive operator rotation. That practice sits entirely on the production side, which is the side Axis controls, and it is applied on live work for production clients including Den Tolmor and Good Fight Production LLC, and HolyWater.

The reason it holds is that the record is written by the people generating the work rather than by anyone reviewing it afterwards. Provenance maintained as a reporting obligation decays, because the person filling it is not the person who needs it. Provenance maintained as part of the naming step survives, because the operator who writes the row is the one who will be asked about the shot three weeks later. Keeping the record narrow is what makes that sustainable. Eight fields, append only, one sheet per series, and nothing in it that the shot plan already says.

What this buys a commissioning platform is specific rather than general. A note about a single frame resolves to a lookup. A bad input resolves to a filtered list rather than a visual review of the delivered series. A sequel eighteen months later resolves to a reproducible set of inputs rather than a reverse engineering exercise. For production enquiries, including provenance structure on a series already in progress, write to business@axisaistudios.com.

FAQ

How many fields should a provenance record actually have?

Eight is the working number. Series code, episode, scene, shot and version give the address. Prompt identifier, reference set identifier and model identifier give the lineage. A date stamp and operator initial are useful additions and still leave the row fillable in under fifteen seconds. Beyond ten fields the record starts duplicating the shot plan and completion rates fall, which costs more than the extra detail returns.

Does a provenance record replace a retake log?

No. They answer different questions and have different authors. A retake log records what failed, how many attempts it took and what the diagnosis was, and it is read when deciding whether a prompt needs rewriting. A provenance record states what produced the accepted output, and it is read when a delivered frame comes into question. Merging them produces one document with two update rhythms, and the slower rhythm wins.

What happens when the generation model updates mid production?

The model identifier field is what makes that recoverable. Record the model name and release in force at generation time on every row, and a visual disagreement between an early block and a later one resolves by filter rather than by investigation. Without the field, the same disagreement looks like an operator error or a reference problem, and the time spent ruling those out is time the field would have saved.

Further Reading

For the naming structure that the first five provenance fields should mirror exactly, the shot naming conventions guide covers the field order, versioning practice and mid production rollout that make the address portion of a provenance row match the files on disk.

For the reference set versioning that section five depends on, the character reference version control guide covers how reference sets are versioned across a long pipeline and how to avoid the silent swaps that invalidate historical rows.

For what a provenance record is ultimately for, the production archive guide covers what to save, how to store it and what a sequel production will need from the record eighteen months after delivery.