ADI · DDR · Trust Calculus

Хороший следователь не фиксируется на первой версии

Представьте следователя на месте преступления. Плохой следователь фиксируется на первой версии («это сосед, у них был конфликт») и всё оставшееся расследование ищет подтверждения. Хороший следователь работает иначе: сначала выдвигает три-четыре версии, для каждой формулирует «если это правда, то в таком-то месте должны быть такие-то следы», а потом идёт проверять. Если следы не сходятся - версия выбывает. Остаётся та, которая выдержала все проверки.

ADI-цикл - это ровно такой же способ мышления, только про архитектурные решения.

• Abduction · генерация гипотез. Минимум три. Не одну, не две - три. Порог именно такой, потому что две гипотезы почти всегда превращаются в ложную дихотомию («либо Redis, либо Postgres»), а третья гипотеза часто ломает эту дихотомию и оказывается самой интересной («in-process LRU без сети вообще»).
• Deduction · логический вывод. Для каждой гипотезы формулируем «если она верна, то должно наблюдаться вот это». Если ни одно следствие нельзя проверить - это не гипотеза, а красивая фраза.
• Induction · проверка фактами. Бенчмарк, тест, ссылка на документацию, разговор с командой, замер. Каждое evidence подтверждает или опровергает конкретное предсказание из дедукции. Не «вот статья», а «вот статья, и она опровергает гипотезу 2».

Мотивировочная часть для технического решения

Итак, вы прогнали ADI, выбрали решение. Дальше возникает вопрос: что с этим делать, чтобы через три месяца коллега (или вы сами) могли понять, почему было сделано именно так?

Аналогия - судебное решение. Судья не просто говорит «виновен» или «невиновен». Он пишет мотивировочную часть: какие доказательства рассмотрены, какие отвергнуты и почему, на каком основании сделан вывод. Через год, если появятся новые обстоятельства, дело можно пересмотреть - и у следующего судьи есть полная картина, а не «так решили тогда».

DDR (Decision-Driven Record) - это мотивировочная часть к вашему техническому решению. Markdown-файл в репо, в docs/decisions/DDR-NNN-<slug>.md, с шестью обязательными секциями:

Это и называется Evidence Decay: любое evidence устаревает. Бенчмарк 2023 года про Redis 6.x не валиден для Redis 7.4. Цифры для вашего Vault на 50 заметках не валидны на 50 000. Хороший DDR это признаёт заранее.

Каждое утверждение оценивается по трём независимым осям

Теперь у вас есть DDR. Как понять, что evidence в нём достаточно сильное, чтобы на нём основывать решение?

Аналогия - инспекция сборки в строительстве. Инспектор не ставит «хорошо» или «плохо». Он оценивает по конкретным осям: соответствие спецификации, качество материалов, допуски сборки. Каждая ось независима, у каждой свой балл, и общая оценка - это не среднее, а способность отличить объект, который можно сдавать, от объекта, на который нельзя ставить крышу.

Trust Calculus - то же самое для ваших утверждений. Каждое утверждение, на которое опирается решение, оценивается по трём независимым осям, каждая по шкале 0-9:

• F · Formality - насколько строго сформулировано. 0: «мне кажется». 5: явное утверждение с условиями («при нагрузке X метрика Y»). 9: формальная спецификация или доказательство.
• G · Granularity - насколько конкретно. 0: «это медленно». 5: «быстрее на 15%». 9: «p99 = 47 ms на 10k RPS, payload 1 KB, setup описан».
• R · Reliability - откуда источник. 0: анекдот из Slack. 5: несколько независимых источников. 9: peer-reviewed paper или ваш продакшен-бенчмарк.

Оси независимы. Красивый маркетинговый whitepaper от вендора может быть F7 G8 R2 - формально, подробно, но источник продаёт вам свой продукт. Скриншот из Slack от коллеги с reproducible benchmark может быть F2 G8 R7 - без оформления, но цифры реальные и воспроизводимые.

Среднее у обоих одинаковое - 5.7. Но слабая ось разная: у A провалена R (источник продаёт), у B - F (формулировка нестрогая). Trust Calculus показывает не «насколько в среднем хорошо», а какая именно ось проваливается.