Самая дорогая ошибка годового разбора выглядит безобидно: рядом стоят решение и удобное наблюдение, поэтому текст объявляет одно причиной другого. Проблема не в наличии метрики или timeline, а в пропущенных звеньях между ними. Цена ложного эффекта — команда продолжает финансировать выбранный путь, хотя изменение могло совпасть с другим фактором, окном измерения или особенностью выборки.
Механизм защиты начинается с разъединения трёх объектов: decision фиксирует намерение, cost фиксирует принятый trade-off, observation фиксирует увиденный факт. Ни один из них по отдельности не создаёт causal claim. Проверка должна искать unknown и comparison boundary: какой контрфакт отсутствует, что именно сопоставлено, какие условия остались за рамкой. Если ответы пусты, действие одно — остановить вывод, а не подобрать более убедительный график.
Три слоя, которые часто склеивают
Decision — это запись выбранного пути в конкретный момент. Она говорит, что автор хотел изменить и какой вариант отверг. Cost — это цена выбора: дополнительные шаги, сложность сопровождения, неполное покрытие или иной заранее принятый расход. Observation — это факт, который появился после решения: значение в fixed literal, порядок событий, наличие статуса, результат заранее заданной проверки.
Склейка начинается со слова «после». Оно верно описывает время, но не объясняет причину. В нашем synthetic наборе решение находится раньше observation, однако между ними нет реальной среды, независимого сравнения, случайного распределения, control group или доступа к production telemetry. Поэтому единственная честная интерпретация: запись полнее или неполнее, а не «изменение сработало».
| Есть в карточке | Допустимый текст | Запрещённый скачок | Ремонт |
|---|---|---|---|
| decision и alternatives | выбран путь A вместо B и C | A был лучшим вариантом вообще | назвать требования и последующую проверку |
| cost | выбор добавил отдельный fixed шаг | цена окупилась | указать, что измерялось и по какой границе |
| observation | после decision есть такой факт | decision вызвал этот факт | добавить контрфакт и внешний контекст |
| unknown | ответ о внешнем факторе отсутствует | причина известна | оставить статус open |
| comparison boundary | сопоставлены два literal | сравнены реальные периоды | сузить формулировку до факта |
Fail-closed модель не пропускает корреляцию
import {
createFixedYearSynthesisInput,
inspectYearSynthesis,
} from './upgrade-2025-12.mjs';
const report = inspectYearSynthesis(
createFixedYearSynthesisInput('correlation-only-v1'),
);
console.log(report.reasons);
// ['missing-cost', 'missing-unknown',
// 'missing-comparison-boundary', 'effect-claim-not-allowed']Этот literal специально соблазнителен: в нём есть decision, варианты и observation после него. Но стоимость написана как «не указан», unknown и comparison boundary пусты, а claim прямо объявляет эффект установленным. Проверка не пытается угадать недостающую историю. Она возвращает точные причины остановки. Так автор видит, что проблема не в недостаточно сильной формулировке, а в том, что модель не содержит нужных оснований для вывода.
Контрфакт — не декоративный вопрос
Контрфакт формулирует, что могло бы быть при другом пути или без изменения. Он не обязан быть сложной статистической моделью, чтобы быть полезным. В годовой записи достаточно сначала признать его отсутствие: «мы не знаем, каким был бы наблюдаемый факт при другом порядке». Эта фраза не обесценивает работу. Она запрещает выдать единственный увиденный след за доказательство причины.
Comparison boundary делает отсутствие контрфакта проверяемым. Для fixed примера это фраза о том, что сопоставлены только заданные before/after literals. Для реального исследования boundary должна назвать популяцию, окно, способ сбора, исключения и правила сравнения. Пока этих деталей нет, читать можно только observation. Причинный глагол нужно отложить.
Как строится корректная цепочка рассуждения
- Назовите question. Что именно пытаемся понять: порядок событий, наличие дефекта, стоимость процесса или влияние изменения?
- Разложите запись. Отдельно выпишите decision, alternatives, cost и observation; не объединяйте их одним выводом.
- Спросите про контрфакт. Что могло бы измениться без выбранного пути или при другой альтернативе?
- Сформулируйте unknown. Укажите первый фактор, который текущая запись не наблюдает.
- Определите comparison boundary. Проверьте, есть ли общие условия и метод сопоставления, а не только порядок дат.
- Выберите исход. Либо узкий факт, либо stop-and-repair-boundary; synthetic hand-off не становится production decision.
Почему стоимость относится к механизму, а не к украшению
Без cost решение легко выглядит как техническая победа. На деле дополнительная валидация может увеличить путь, отдельный статус unknown — нагрузить review, сохранение альтернатив — сделать карточку длиннее. Это не аргументы против дисциплины записи. Это условия выбора. Если в декабрьском тексте нет стоимости, читатель не может повторить компромисс в другой границе: он видит только пользу, которую автор уже отобрал задним числом.
RFC 7282 не предлагает считать инженерный выбор голосованием. В нём важно, что техническое возражение может быть реальным, даже если его не берут в выбранную конструкцию. Для нашего механизма это означает простое правило: alternative и cost должны остаться видимыми рядом с decision. Они не превращают model в доказательство, но убирают ложную неизбежность.
Lessons learned не равны набору красивых фактов
NIST SP 800-61r3 описывает цикл, где lessons learned анализируют, приоритизируют и возвращают в improvement. Мы используем это только как узкий пример направления записи: наблюдение должно вести к проверяемому следующему вопросу, а не к немедленному заявлению об успехе. Документ относится к cybersecurity incident response, поэтому из него нельзя выводить формат нашей таблицы или переносить security-рекомендации в synthetic годовой текст.
В практической карточке следующий вопрос может быть совсем небольшим: «какой внешний фактор не виден», «какой вариант не сопоставлен», «какой расход не записан». Такой вопрос полезнее громкой формулы «извлечены уроки», потому что по нему можно вернуть запись на ремонт. Нельзя исправить причинность дополнительным эпитетом; её можно только сузить или собрать новый метод сравнения.
Три ложных механизма, которые стоит остановить
Первый ложный механизм: «было решение, потом уменьшилось значение, значит решение уменьшило значение». В нём пропущен контрфакт. Второй: «альтернатива была дороже, значит выбранный путь окупился». Здесь cost заменяют наблюдением пользы, которого запись не содержит. Третий: «несколько похожих историй подтверждают эффект». Похожесть без общей границы сравнения только увеличивает число совпадений, но не делает их причиной.
Во всех трёх случаях ремонт начинается не с вычисления. Сначала надо назвать фактическое утверждение, которое уже разрешено: выбор сделан, расход записан, определённый факт замечен. Затем определить, какого условия недостаёт для следующего уровня вывода. Иногда ответом будет новый сбор данных; иногда — отказ от эффекта как цели годовой заметки. Механизм становится честным именно в тот момент, когда уровень утверждения совпадает с содержимым карточки.
Когда метрическое чтение превращается в метод
Число в отчёте ещё не является measurement method. Для метода нужны единица, источник, правила расчёта, временное окно, исключения и заранее определённый способ сравнения. Без этого число остаётся observation: оно может быть полезным симптомом или поводом проверить гипотезу, но не доказательством того, что решение изменило систему. В synthetic literal вместо реального числа мы намеренно оставили текст о заданном факте, чтобы не симулировать такую методику.
Это различие помогает планировать работу. Если целью является causal question, надо явно открыть отдельный трек: определить сравниваемые условия, доступы, владельца данных и риск неправильной интерпретации. Если такой трек не нужен, годовой текст должен остаться на уровне traceability и cost. Оба исхода нормальны; ошибка появляется, когда второй маскируют под первый.
Граница технического примера
Фабрика принимает только известные frozen inputs. Произвольный объект, даже похожий по полям, получает unknown-fixed-input и не проходит дальше. Это сделано не ради криптографической защиты, а чтобы пример не имитировал проверку реальных данных. В нём нет идентификаторов, организаций, людей, интеграций, сетевых вызовов, файлов, timestamps исполнения, incident records или метрик из внешнего мира.
Временные строки внутри literal соответствуют ограниченному формату UTC RFC 3339. Они нужны для проверки порядка карточек, но не для измерения длительности или доказательства влияния. Положительный результат функции содержит только bounded-review-handoff-only и effect: no-system-change. Если требуется реальное решение, нужен другой процесс с владельцем, законным доступом и заранее определённой методикой.
Следующий проверяемый шаг
Возьмите одну фразу из годового отчёта, где рядом стоят изменение и результат. Разрежьте её на четыре поля: decision, cost, observation, unknown. Затем напишите comparison boundary одной строкой. Если любой из двух последних элементов получается вымышленным, не делайте causal claim. Верните формулировку к наблюдаемому факту и поставьте конкретный вопрос для следующего review.
Проверяемые источники
- RFC 3339, Date and Time on the Internet: Timestamps — версия: RFC 3339, July 2002, immutable RFC text. Раздел 5.6 задаёт форму date-time как full-date, букву T и full-time с часовым offset. В fixed модели это даёт проверяемый синтаксис временной отметки записи. Граница: RFC описывает формат времени, а не причинность решения, смысл метрики или правила годового review.
- RFC 7282, On Consensus — версия: RFC 7282, June 2014, immutable RFC text. Документ называет trade-off неустранимой частью инженерного выбора и отделяет техническое рассмотрение возражения от простого подсчёта голосов. Граница: Это контекст инженерного компромисса в IETF, не готовая процедура для другой организации и не доказательство результата synthetic модели.
- NIST SP 800-61r3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management — версия: NIST SP 800-61r3, April 2025, immutable published PDF. В модели документа lessons learned анализируются, приоритизируются и возвращаются в Improvement. Это узкий пример цикла наблюдение → разбор → изменение процесса. Граница: Публикация посвящена cybersecurity incident response; она не предписывает наш формат ADR, не валидирует causal claim и не делает годовой текст доказательством эффекта.