This seems to be very much in line with one of the things to do when writing software: Whatever you're building, think about what would disrupt/break it and deal with it somehow.
Right. Or when you're introducing code to work around a known problem. Add a comment stating that it is a workaround, what problem it works around, when the problem is expected to be fixed, and, critically, how the reader can verify whether the problem exists anymore or not.
Make it easy to find out when it can be removed, in other words.
On one long-term project we even had special comments with an expiry date attached. Every time the build was running a script would scan all comments and print to output those comments that were expired to make sure someone revists them. And you could either remove, keep and extend expiry or modify that code, depending on context.
I guess it never crossed my mind I could do the same when creating company policies and processes.
I've even written a unit test that fails after a certain date with a descriptive message for this purpose. It's maybe more familiar to developers and already has tooling around it.
Or just thinking about what the burdens of success are. Especially when you know early success is not actually going to bring in the funds to pay for them.
Make it easy to find out when it can be removed, in other words.