Позже владелец процесса меняет требование: для определённого типа операции курс нужно фиксировать на другом этапе. Одной правки в спецификации недостаточно. Прежний API-контракт может передавать не тот момент расчёта. Тест продолжит подтверждать старое правило. Интерфейс покажет пользователю обещание, которое система больше не выполняет. Расчёт выплаты и банковская сверка тоже сохранят прежнюю зависимость.

Decision Log помогает собрать набор для повторной приёмки. Команда сохраняет в записи основание нового решения, рассмотренные альтернативы, человека с правом выбора, дату вступления правила в силу и список зависимых материалов. Затем команда проверяет каждый материал: обновлён ли контракт, заменён ли старый тест, совпадает ли текст интерфейса с новым поведением, пересчитаны ли связанные операции. Граница применимости показывает, какие старые результаты сохраняют силу, а какие нужно оценить заново.

Для возвратов можно использовать собственную простую схему связей. Например, команда связывает новую запись с прежней через поле «возврат к решению», а причину отмечает как «ошибка критерия приёмки». В технической модели эти поля можно назвать reopened_from и acceptance_miss. Это вариант организации журнала, предложенный в рабочем обсуждении, а не отраслевой стандарт.

Такая связь отделяет новый запрос от случая, когда команда преждевременно объявила работу завершённой. Она также показывает, какой критерий оказался неверным и какие зависимые материалы прошли повторную проверку.

Журнал не решает за команду. Он сохраняет основание, право решения и карту последствий. Благодаря этому повторная приёмка начинается не с восстановления чужой памяти, а с проверяемого списка изменений.