It really depends on the decision, what was done, and the overall impact. If the decision is to migrate to microservices, a year in it may be reviewed and decided that the work has been far more than anticipated, and is too much for EVERYTHING to be migrated, and the decision changed.
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.
You can review - but by the time you really know it is too late. If things are going really bad after one year then start over. However often things that will go well long term are having "growing pains" at 1 year and so "staying the course" despite the pain might be the right decision. Until you have a microservices architecture you don't know the pros/cons of it for your system - you can get insight from others, but their system will be different and so will have different problems.
Your org chart should be tweaked every year - as should your architecture. However major changes should not happen often - if at all.
A year is and is not a long time, so it depends on how seasonal the prosu is. New years celebration decorations are at one end of the spectrum, but it turns out a lot of things have a seasonality to them as well.
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.