Давайте на примере:

Вот есть условная задача "сделать так, чтобы база данных могла обрабатывать бОльшее количество запросов без возможности вертикально масштабировать БД".

Поставь эту задачу группе технически подкованных людей - и они через 15 минут прибегут к тебе с вариантами решений: "шардировать БД, нет, перевести всё на микросервисы, нет, заменить РСУБД на NoSQL, нет, выкинуть БД и перенести всё в облако...". Затем на каждый такой вариант они начнут сами себе задавать вопросы, погружаясь в пучину разветвленного дерева решений - если заменить всё на микросервисы, то какие это будут микросервисы? Может тогда часть БД всё-таки заменить на NoSQL? А если нет, то может это можно шардировать? Но по какому ключу? А что если мы наймем еще 30 новых разработчиков? Обязательно кто-то задаст вопрос "а сколько у нас вообще CPU и RPS?", и скажет, что без этого решить ничего абсолютно невозможно.

Проблема всего этого процесса в том, что на самом деле в нем принимается не одно решение. Это цепочка решений, где каждое принятое решение влияет на пространство вариантов для последующих (вполне нормальная ситуация, именно поэтому эти решения и архитектурно-значимые - потому что влияют на много и лежат в базе многих других решений). И ключевое умение тут - ограничить скоуп каждого принимаемого решения и принимать только его.

Скажем, в нашем примере первое решение - выбор стратегии или подхода - или как хотите назовите - по решению задачи "сделать так, чтобы база могла обрабатывать больше запросов без вертикального масштабирования". Все остальные детали - ключ шардирования или количество микросервисов - будут уже потом, сперва надо решить главное (на сейчас).

Или, например, задача "импортозамещения БД", которая часто воспринимается как задача "замена импортной БД на другую", на самом деле чаще звучит как "избавиться от импортной БД" со всем остальным контекстом.

От умения ограничить задачу (problem в структуре любого ADR) и границы (scope/ context) зависит, удастся ли выстроить процесс принятия архитектурно-значимых решений. Это же позволит многие "важные" решения (которые на самом деле - составляющие части других, более поздних решений) отложить на потом, писал об этом тут.

Да, это порой звучит как философия, особенно для специалистов в командах "на земле" (аналитиков, разработчиков) - мол, зачем мне твоя абстракция "как решать задачу" и "решение, которое драйвит следующее решение", ты мне дай постановку. Это вполне очевидное следствие процесса "некогда топор точить, нам надо деревья рубить". Но если вам удалось а) как минимум, повернуть своё мышление таким образом и б) как максимум - помочь с этим коллегам - значит есть шанс.