Writing a decision down doesn't mean you have to stick to it forever.
I'd expect you to change your mind when testing reveals something you missed or the product changes enough that the original approach no longer fits. That's all fine.
But you need to leave a trail.
If the decision needs a clarification, amend the record. At the very least, you should update its "Updated at" date. Write down what changed and why, so someone returning to it can tell they're reading a revised decision. On the other hand, when new evidence should completely overturn your approach, you should probably create a new record.
You'll be tempted to replace the old one or delete it. Don't! Instead, mark it as deprecated and link to the decision that now takes precedence. Link back from the new record to the old one too. This history will matter quite a lot after you make more than a handful of decision records. Without these inner links, someone can look at the new approach, decide it's not good any more and somehow (yes, it happens more often than you think) repeat the old approach. You're again repeating your mistakes. Instead, they should see what made them reconsider it.
And then look beyond the records.
Which components or features use the old approach? Which teams need to know? Does existing work need fixing or does the change only affect a particular situation?
Updating the record won't update those implementations, so someone still needs to plan the work and then do it.
All this makes changing direction easier to understand. You can point to the evidence, identify the work and decide what happens next.
You want a history of what you understood, what you learned and how your choices changed, not a library of decisions that nobody dares to question.