For example with Architecture Decision Records, put a 6 or 12 month expiry on them and evaluate to see if they can be renewed, should be changed or replaced with something that covers new insights.
Unfortunately that seems a very unpopular thing to do so I’ve never seen it work and companies end up with “we have always done it like this” type practices
Architecture should not be "we have always done it like this". If you don't write down why though it will become that. Often there are good reasons that things have always been done like that - those reasons may or may not still be valid but if you don't know what they are it is hard to evaluation. More than once I've seen someone rethink a "we have always done it like that" and discover the hard way why they always did it that way.
I've never seen a company with a good way to write down why they do things though. When someone even tries nobody reads those documents.
Or it might be an architectural decision to change the hierarchy of some organisational structure. Again, it could be the correct call for the time, but as things evolve over a year, it may not be sufficiant a year later.
A year isn't a bad time to review, and if the decision is just a "yeah, duh, of course we'll continue", then it's a really quick conversation, but at least you're thinking about things.
Your org chart should be tweaked every year - as should your architecture. However major changes should not happen often - if at all.
Keeps from changing up too often but also gives a conscious evaluation.
Then when new knowledge/technology/idle cycles come along they can take advantage to update/refine it in sensible ways.
Often the sensible way is "leave it, it works fine". But there's a big difference between arriving at that outcome via ignorance vs. deliberation. Too often management doesn't recognize the difference, but the former as your state of affairs will eventually lead your stuff to rot.