Telling the people downstream about a change
Whoever reviews the work will notice a change in look and read it as an error. One dated sentence saying the model changed, and that earlier material was produced under the previous one, prevents a round of corrections that cannot be made. It also sets expectations for the next delivery. As of 2026-09-12.
| Who | What they need |
|---|---|
| An editor | Which episodes came from which engine, by date |
| A reviewer or client | That the change was external, and when |
| A colleague picking up the work | Which settings produced the current look |
| Yourself, in six months | A dated note rather than a memory |
Inclusion rule. Audiences a serial production has to inform when the engine underneath changes. Order. From the audience closest to the work outward.
1Silence gets read as carelessness
A reviewer comparing episode four with episode nine has no way to know a vendor changed something. The natural conclusion is that the work got worse or the team got sloppy, and the corrections requested will be impossible to deliver.
Saying it first costs a sentence. It also moves the conversation from quality to scheduling, which is where it belongs.
2Give the date, not the explanation
Nobody downstream needs a description of model lifecycles. They need to know that the engine changed, roughly when, and which deliveries sit on each side of it.
That is exactly the information a per-file record already contains, which is one more reason to keep one. Without it the note has to be vague, and a vague note invites questions.
3Set expectations for the first deliveries after
The episodes immediately following a change are the ones most likely to need another pass, because the look is being re-established. Saying so in advance turns a surprise into a planned iteration.
It also protects the estimate. A production that warned about two extra passes is in a different position from one that delivered them unannounced.
4Write it down where the project lives
A message in a chat thread is lost in a week. A dated line in the project notes survives the handover and answers the same question the next time somebody compares two episodes.
This is the same discipline the register applies to itself: a claim with a date can be checked, and one without has to be believed.
5Where each vendor's own wording lives
None of the above is a date. Announced end dates, and the apps still carrying the models they apply to, are kept on the calendar with the announcement each one came from.
- Recording per file — where the dates in that note come from
- The change calendar — for the cases where a vendor did publish a date
Guidance rather than a dated entry. No line here is a vendor statement, and none should be read as an announcement. The sourced material is on the calendar. Related: Budgeting a migration, Watching a page.