If Almost Nothing Is Kept, What Is?
The material lives in the system that owns it, the tool lives in version control, and every per-run artifact is disposable. So the series needs exactly one thing it does not have yet: a way to know what has actually shipped. That is a single index file living beside the pipeline, with one line per episode.
Each line carries what you need to find your way back — the date, the pointer that produced it, the title, where the render lives, and links to where it was published. Nothing more. It sits with the pipeline rather than with any episode because it belongs to the tool, not to any single run.
The Discipline Is in What It Omits
The temptation with an index like this is to make it useful in more ways. Add the runtime. Add loudness. Add the rejection count. Add a summary. Add tags so you can find episodes about a topic. Each addition is individually reasonable, and together they turn a one-line-per-episode record into a small database that must be kept accurate — at which point maintaining the index becomes its own job, and an index nobody maintains is worse than none because it lies.
So the line is drawn at enough to know what shipped and where to find it. Anything derivable from following one of those links does not belong on the line. If you want the rejection count, the run's own log has it. If you want the runtime, the render has it. The index's job is to be the map, not the territory.
Records Around the Record
Notice that the index is not the only permanent trace — it is the only one that had to be designed. The request thread already holds the discussion and the verdicts, permanently, because that system keeps its history anyway. The published work is public and permanent on its own. The commit history records when the tool changed. All of that was already there, and the index exists precisely to fill the one gap none of them covered: a single place where the series can be seen as a series.