ЖУРНАЛ РЕШЕНИЙ · ДОКАЗАТЕЛЬСТВА

Evidence и Decay: почему доказательства имеют срок годности

Бенчмарк, сделанный год назад на устаревшей версии библиотеки, уже не валиден - даже если он лежит в записи решения и выглядит убедительно. Доказательства (evidence) - не вечные объекты. У каждого есть срок годности, и система должна об этом знать.

Что считается доказательством

Доказательство - это конкретный источник, на который опирается решение. Не «по нашему опыту», а «вот что именно мы измерили, прочитали или услышали». Четыре типа с разным весом:

01 · ЗАМЕР НА СВОИХ ДАННЫХ

Сильнейший тип

Бенчмарк на реальной нагрузке, нагрузочный тест в продакшене, профилировочный прогон на нашем железе. Привязан к нашим условиям напрямую. Устаревает при смене нагрузки или инфраструктуры.
02 · БЕНЧМАРК КОЛЛЕГИ

Средний вес

Замер другой команды с похожим стеком и похожей нагрузкой. Применим, если контекст совпадает. Теряет вес при расхождении масштаба, версий или архитектуры.
03 · ДОКУМЕНТАЦИЯ ПОСТАВЩИКА

Зависит от актуальности

Официальная документация, changelog, release notes. Надёжна, пока версия совпадает с той, что используется в проекте. После мажорного обновления нужно перепроверить.
04 · ОПЫТ ЧУЖОЙ КОМАНДЫ

Слабый, но полезный

Case study, статья, разговор на конференции. Применим как аргумент «направления», а не как точный прогноз. Должен идти в паре с более строгим источником.

Принципиальный момент: в записи решения каждое доказательство должно быть привязано к типу. Если написано только «мы провели тесты» - непонятно, что именно, на чём и когда. Если написано «бенчмарк 14.11.2025, PostgreSQL 16.2, наш staging, 1 000 RPS - p95 4 мс» - это доказательство, у которого можно оценить применимость через год.

Каждое доказательство имеет три измерения

Чтобы оценить, насколько доказательство применимо к вашей ситуации, используются три независимых оси. Вместе они дают ответ на вопрос: «насколько этому стоит доверять».

Строгость (Formality)

Насколько методологически корректно получено доказательство. Контролируемый эксперимент с изоляцией переменных - высокая строгость. Субъективное впечатление из разговора - низкая.

F0 (впечатление) → F3 (контролируемый эксперимент)

Детальность (Granularity)

Насколько конкретен источник относительно вашей задачи. Замер именно вашей операции на вашем железе - высокая детальность. Общий обзор технологии без цифр - низкая.

G0 (обзор) → G3 (точный замер под контекст)

Надёжность (Reliability)

Насколько источник заслуживает доверия. Рецензируемое исследование, официальная документация - высокая надёжность. Анонимный комментарий в блоге - низкая.

R0 (аноним) → R3 (верифицированный источник)

Эти три оси образуют то, что принято называть доверительным калькулятором (trust calculus). Результирующий балл - не среднее F, G и R, а произведение худшего из трёх. Одно слабое измерение тянет весь результат вниз. Если доказательство строгое и детальное, но взято из ненадёжного источника - его итоговый вес низкий. Подробный интерактивный разбор и пространственная модель - в trust-calculus.

Срок годности - что происходит с доказательством со временем

Каждое доказательство при создании получает поле valid_until - дату, после которой оно считается устаревшим. Не «нужно перепроверить когда-нибудь», а конкретная дата. После неё доверительный вес доказательства автоматически падает до минимума.

Логика простая: если нагрузочный тест проводился год назад, а за это время библиотека выпустила три мажорных версии - тест мог стать нерелевантным. Система не знает, изменилось ли что-то. Но она знает, что дата истекла, и помечает доказательство как требующее проверки.

Как меняется доверие к решению с течением времени:

ЖИЗНЕННЫЙ ЦИКЛ ДОКАЗАТЕЛЬСТВА · ПРИМЕР

День создания - доказательство свежее

Бенчмарк только что проведён на актуальной версии. Все три оси F/G/R в норме. Вес максимальный.

вес 1.0

Через 6 месяцев - приближается к сроку

Библиотека выпустила минорное обновление. Документация поставщика обновлялась дважды. Доказательство формально ещё валидно, но требует внимания.

вес 0.6

После истечения valid_until - устаревшее

Система автоматически помечает доказательство как expired. Вес падает до минимума. Решение, опирающееся только на это доказательство, получает низкий итоговый балл.

вес 0.1

После обновления - доказательство продлено

Провели повторный замер или нашли актуальный источник. Вес восстанавливается. Условие пересмотра в записи решения закрыто, новое выставлено.

вес 1.0

Ключевое следствие: итоговый балл доверия к решению - это минимум среди всех доказательств, на которых оно стоит. Если одно доказательство устарело - весь балл решения падает, даже если остальные свежие. Именно поэтому обновлять устаревшие доказательства выгоднее, чем накапливать их.

Триггеры пересмотра по истечению срока

Истечение срока годности доказательства - один из трёх стандартных триггеров, которые сигнализируют о необходимости пересмотра. Все три стоит прописывать явно при создании записи решения.

Тип триггера	Что происходит	Рекомендуемое действие
DATE Дата истечения срока	Поле `valid_until` у доказательства истекает. Система помечает запись как требующую внимания.	Перепровести замер или найти актуальный источник. Если всё ещё валидно - продлить дату. Если устарело - пересмотреть решение.
EVENT Событие в проекте	Мажорное обновление зависимости, смена архитектуры, рост нагрузки в 10 раз. Прописывается явно в поле «Условия пересмотра».	Открыть запись и проверить, не изменился ли контекст настолько, что решение нужно переосмыслить.
METRIC Пороговое значение метрики	DAU превысил 10 000, latency выросла выше 200 мс, стоимость инфраструктуры удвоилась. Проверяется внешним мониторингом.	Пересмотр решения как часть разбора инцидента или планового аудита метрики. Триггер фиксируется как условие заранее.

Настройка автоматического уведомления зависит от вашего рабочего окружения. Простейший способ: добавить в календарь повторяющееся событие с ссылкой на запись решения. Если ваш журнал живёт рядом с кодом - можно поставить CI-скрипт, который проверяет поля valid_until и выдаёт предупреждение при сборке. Важна не конкретная реализация, а то, что уведомление существует и срабатывает само - без подвига памяти кого-то из команды.

Типичная ошибка: прописать условие пересмотра «если ситуация изменится». Это не условие - это намерение. Условие - это «если p95 latency вырастет выше 200 мс» или «если выйдет major-версия библиотеки». Только конкретные триггеры срабатывают сами. Абстрактные - не срабатывают никогда.

Глубже

Два раздела, которые показывают эти концепции с разных углов: формальная трёхмерная модель оценки доказательств и жизненный цикл записи от активации до устаревания.

3D ИНТЕРАКТИВ

Trust Calculus: пространственная модель F/G/R с калькулятором →

ЖИЗНЕННЫЙ ЦИКЛ

State machine: active → stale → renew → supersede →

Главное: доказательство без срока годности - это не доказательство, а утверждение. Дата valid_until превращает источник из статичной ссылки в живой контракт. Когда срок истекает, система это знает и сигнализирует. Без этого механизма записи решений через два года превращаются в музей: всё записано, всё неактуально, никто не знает, что именно.