My ideal process - authors draft a design document. There is a team review. If there are strong objections (i.e beyond suggestions) a comparative doc is written with a summary from both positions and a commentary from each side on each other's position (~1-2 pages). Then one or more senior technical engineers make a call and document why in the document. After this decision, the discussion is closed for a TTL agreed to in the comparative doc (i.e lets try this for six months and re-evaluate). This is all documented in a project's decision log. This allows decisions to be quickly made with accountability for decision makers while giving anyone on the team an opportunity to propose an alternative approach. Ideally, given a need/objective you are usually considering multiple approaches which is a good opportunity for junior engineers to contribute to processes usually dominated by more senior engineers (i.e even asking a junior engineer to write a document arguing, "we do nothing" as an option is useful). Basically make sure this is encouraged in the organization and so that culturally this is celebrated and is seen as just an important of a contribution as authoring the 'winning' design.
The TTL is based on the cost, time to implement, and time needed to gather enough signal to make a determination. So if you doing normal 'mvp' style of development where you ship intermediaries you should have some signal whether something works in at least six months, ideally sooner. Sometimes this means you might reconsider or even reverse a decision or apply what you learned to a new problem but mostly this just builds confidence and trust in the team that the decision making process is generally 'good enough'.
The TTLs are tracked in the decision log which is reviewed in project retrospectives. You can schedule these in a slot a week you hold open for presentations, document reviews, demos, wheel of misfortunes (debugging simulated production problems if on-call), production reviews, etc.
