Keeping courses current when the source changes
Training does not go wrong all at once. It goes wrong one unnoticed update at a time.
Part of a single argument: the engagement gap is a workload problem.
The most damaging state for a course is not being bad. It is being subtly out of date, because a wrong course is trusted in exactly the way a missing one is not.
Nobody discovers this on a schedule. It is discovered by a learner who follows the training and gets a different result from the one it promised, and then tells their colleagues that the training is unreliable.
Why staleness is invisible
The course does not change. That is the whole problem: it looks exactly as correct on the day it becomes wrong as it did the day before.
The change happened somewhere else, in a policy, a product, a process, and the person who made that change had no reason to know a course had been built on it. There is no notification, because there is no link.
So the decay is silent, and it accumulates fastest in exactly the material that matters most, because important things get updated more often.
Separate the durable from the volatile
Not all content decays at the same rate, and treating it as though it does is what makes maintenance feel impossible.
The concept of a permission model is durable. The exact position of a toggle in the interface is volatile. Keep them in separate lessons and a change invalidates a small, identifiable piece rather than casting doubt over a whole course.
Teams that do this find that the volatile fraction is usually small, maybe a fifth of the material, and that maintaining a fifth of a course quarterly is a completely different proposition from reviewing all of it annually and never quite getting to it.
Record what each lesson was built from
This is the highest-leverage habit available here and it is nearly free at authoring time.
If every lesson records its source, then when a source changes you get a list of what needs looking at. Without it, you have a vague obligation to review the training at some point, which is not actionable and therefore does not happen.
The difference between a list and an obligation is most of the difference between maintenance happening and not happening.
Publish the verification date
Show learners when each lesson was last checked against reality. It costs nothing and it preserves trust in a specific way.
A lesson marked as verified three weeks ago is treated appropriately by a reader. An unmarked lesson that turns out to be wrong damages confidence in everything around it, because there is no way to tell which parts are current.
Teams resist this because it makes staleness visible. Making staleness visible is the entire point, and the discomfort is a reasonable proxy for how much of a problem you currently have.
The review that actually happens
Annual review of the whole catalogue is the standard plan and it is almost universally not done.
What works instead is review triggered by change: the source moved, so the three lessons built on it get looked at this week. It is smaller, it is prompted rather than remembered, and it happens close to the change while somebody still understands what changed and why.