Every pipeline works in January. Requirements are clear, the team is rested, and the conventions are fresh enough that people still remember why they exist. The interesting question is what the pipeline does in the last two weeks.
Deadlines find the manual steps
Under pressure, any step that depends on a person remembering will eventually be skipped. Not through carelessness — through triage. Someone decides that this once, the export can go straight to the edit without the naming pass, because the alternative is missing the screening.
A pipeline that assumes those steps happen is not a pipeline. It is a description of good intentions, and it fails precisely when it matters.
Make the correct path the easy one
If doing it properly takes longer than doing it wrong, the wrong way is what your pipeline actually is.
The most reliable pipelines we have seen are not the strictest. They are the ones where the shortest path is also the correct one — where publishing properly is fewer clicks than working around it.
Fail loudly or not at all
The second property is noise discipline. A pipeline that warns about everything trains people to ignore warnings, which is worse than not warning at all. Reserve the interruption for the cases where continuing produces work that will have to be redone.
Everything else can be a report nobody has to read.
Versioning is a pipeline problem, not a storage problem
Teams tend to treat versioning as something the storage layer provides. It gives you the ability to recover an old file, which is necessary and nowhere near sufficient. What a production needs is the ability to answer which version is current, which was approved, and what changed between them — and none of those are questions a filesystem can answer.
The practical consequence is that the pipeline has to own the version state, and it has to own it at the point where work is published rather than at the point where a file is saved. Those are different moments, and conflating them is why so many pipelines have a folder called WIP that is load-bearing.
Testing a pipeline you cannot run twice
The hard part of pipeline work is that the interesting failures only appear under conditions you cannot reproduce on demand: forty artists, a full render farm, and a deadline. Unit tests will not find them.
What helps is making the pipeline observable rather than trying to make it provably correct. Log the decisions it makes, not just the errors. When something goes wrong at 2 AM in week eleven, the question is never “did it throw” — it is “why did it choose that”, and only one of those is usually recorded.
A pipeline you cannot explain after the fact is one you will rewrite rather than fix.
The last two weeks, again
Everything above is really about the same thing: the pipeline you have is the one that works when nobody has slack. Design for that week and January takes care of itself. Design for January and you will spend the last two weeks discovering which of your assumptions were actually requests.
