В планах сравнения технологий часто ломается сам механизм рассуждения: два неполных наблюдения переводят в число с двумя знаками после запятой, а затем число называют выбором. Проблема конкретна — неизвестность входа исчезает из записи. Цена ошибки появляется позже: команда оптимизирует не ту нагрузку, объясняет расхождение «шумом» и уже не может восстановить, какие параметры были приняты молча.
Вторая проблема — смешать измерение и предпочтение. Вес критерия начинают выдавать за факт о мире, а условный measurement — за benchmark, который будто бы уже прошёл. Цена такого смешения — невозможность оспорить решение по частям: несогласный вынужден спорить с авторитетным «итогом», а не с конфигурацией. Материал не описывает внедрение; здесь нет field report, замера, выбора, rollout или результата. source boundary равен 2026-07-31, а единственный положительный выход кода — bounded-review-handoff, effect: no-system-change.
Механизм начинается с разделения четырёх сущностей
В этом сценарии есть четыре независимые сущности: вопрос, наблюдение, неопределённость и предпочтение. Вопрос фиксирует, что хотели бы узнать в будущем. Наблюдение — то, что отдельный разрешённый процесс когда-нибудь мог бы получить. Неопределённость описывает, что мешает переносить сигнал на другую границу. Предпочтение — вес, показывающий, почему вопрос важен для решения. Ни одна сущность не заменяет другую. Особенно опасно подставить weight вместо evidence: это делает решение гладким, но не проверяемым.
Fixed literal намеренно сообщает repetitions: not-executed и uncertainty: not-estimated. Это не пустая деталь. Она запрещает придумать среднее, разброс или победителя там, где не было запуска. Запись «не оценено» полезнее псевдоточности: она оставляет будущему исследованию место назвать вариацию нагрузки, версию окружения, границу времени и способ сравнения. В текущем пакете этих сущностей нет, потому что их нельзя честно взять из памяти без внешнего наблюдения.
| Сущность | Что допускается записать сейчас | Что требует будущего evidence | Ошибочная подмена |
|---|---|---|---|
| Вопрос | граница задачи и named alternative | релевантность к реальной системе | назвать вопрос результатом |
| Конфигурация | fixed literals и запрет запуска | входы, среда, повторения | спрятать параметры в «равных условиях» |
| Неопределённость | not-estimated | разброс и переносимость сигнала | поставить точный балл |
| Вес | явный приоритет 40/35/25 | согласование владельцев решения | выдать приоритет за факт |
Измерение не начинается с числа
До любого числа нужно назвать наблюдаемую величину и её границу. «Производительность» не годится: это контейнер для несовместимых вопросов. Будущая конфигурация могла бы спросить о задержке одного известного действия, объёме памяти при заданной форме данных или стоимости восстановления после ошибки. Но даже так она не становится benchmark, пока не обозначены вход, способ запуска, повторения, правило исключения и трактовка вариации. В ноябрьской модели эти поля сознательно не заполняются внешними значениями.
Нельзя исправить отсутствие конфигурации обещанием честности. Слова «на одинаковой машине» или «в реалистичной нагрузке» скрывают больше, чем сообщают: какая версия, какой вход, какие зависимости, какое ограничение времени, какой порядок прогонов? Для synthetic plan корректнее буквальная строка synthetic-configuration-v1 и явный признак not-executed. Она не похожа на реальную методику, и это достоинство: читатель не примет её за свидетельство проведённого опыта.
Неопределённость — свойство вывода, а не неудобная сноска
Даже будущий повторяемый запуск не отменит неопределённость. Сигнал может зависеть от входа, версии, выбранного измерителя и того, какую цену команда готова считать существенной. Поэтому корректный механизм не строит одну магическую ось «лучше». Он держит frontier: несколько свойств могут улучшаться или ухудшаться одновременно, а выбор требует явно сказать, чем готовы пожертвовать. На диаграмме нет точки-победителя именно потому, что такой точки не создал ни один запуск.
Псевдоточность появляется и в нормализации. Если шкала 0..3 введена ради удобства обсуждения, она не даёт отношение «три в полтора раза лучше двух». Это ordinal ярлык вопроса. Складывать такие оценки можно только как проектное соглашение с ограничением: итог упорядочивает подготовленные гипотезы, но не доказывает реальный эффект. В этом пакете даже такого итога нет. Мы оставляем лишь конструкцию, в которой missing scale, weight или uncertainty mode останавливают передачу.
Weights нужно подвергать отдельному сомнению
Веса в 40, 35 и 25 не претендуют на объективность. Они полезны только потому, что открыты для спора до появления результата. Человек может спросить: почему cost of adoption важнее эксплуатации в этой плановой задаче? Ответ не должен быть «потому что матрица так посчитала». Нужно вернуться к ценности границы: сколько скрытой работы создаёт переход, кому она достанется и почему это свойство сейчас существеннее другого. Если причины нет, у веса нет права маскироваться под метрику.
Полезная проверка — изменить один вес мысленно и посмотреть, меняется ли сам вопрос. Если изменение не влияет на рассуждение, число декоративно. Если оно меняет всё без объяснения, модель слишком хрупка. Но это упражнение не заменяет sensitivity analysis и тем более не доказывает устойчивость выбора. Для проведения такого анализа нужны реальные разрешённые значения и отдельная методика. Ноябрьский literal не получает их, поэтому отдаёт hand-off, а не таблицу побед.
Исполнимый stop для скрытого measurement
import { createFixedTechnologyEvaluationCase, assessFixedTechnologyEvaluation } from './upgrade-2026-11.mjs';
const plan = createFixedTechnologyEvaluationCase('hidden-measurement-v1');
const result = assessFixedTechnologyEvaluation(plan);
console.log({ status: result.status, reason: result.reason, effect: result.effect });
// { status: 'stop-hidden-measurement-configuration', reason: 'configuration-must-be-literal-and-not-executed', effect: 'no-system-change' }Snippet не имитирует запрос, таймер или benchmark harness. Он создаёт JSON-cloned frozen case в памяти и проверяет, что protocol пуст, а hiddenConfiguration включён. Поэтому выдаётся детерминированный stop. Нет чтения файлов, env, сети, browser state, часов, secrets, telemetry или внешних инструментов. Отсутствие результата — не failure выполнения: это намеренное свойство механизма, которое защищает от ложной истории измерения.
Порядок для будущей измерительной конфигурации
- Написать проблему и цену без названия «самой быстрой» альтернативы.
- Отделить наблюдаемую величину от того, почему она важна для решения.
- Назвать inputs, protocol, repetitions и uncertainty rule в отдельном будущем contract; не брать их из неявной среды.
- Сохранить missing information как unknown, а не как нулевой балл.
- Зафиксировать веса как спорные предпочтения и проверить сумму 100.
- Если конфигурация скрыта или вывод обещает winner, вернуть stop и передать только план владельцу evidence.
Где механизм сознательно не помогает
Он не решает, что считать допустимой нагрузкой, кто имеет право запускать код, какие данные можно использовать и как согласовать риск с продуктом. Он не воспроизводит окружение и не учит статистике. Название uncertainty не превращает неопределённость в оценённый интервал; отсутствие скрытой конфигурации не делает конфигурацию хорошей. Эти пределы важны, потому что иначе статья выглядела бы как руководство к benchmark, хотя она описывает только честное состояние до benchmark.
NIST SP 800-30 даёт язык для разговора о риске и источниках неопределённости, но не говорит, какой runtime выбрать. RFC 2119 и RFC 8174 объясняют силу нормативных слов, но не подтверждают, что у этой команды есть одинаковые критерии. Факт источника отделён от собственной модели: frontier, веса, шкала и fail-closed statuses — редакционная конструкция, привязанная к плану 2026-11.
Ограничения и следующий шаг
Следующий шаг — не запуск, а создание отдельного evidence contract: владелец будущего исследования должен записать разрешённые входы, метод, условия остановки, диапазон интерпретации и способ сообщить неопределённость. Если он не может этого сделать, сравнение пока не созрело для измерения. Нельзя заменить этот пробел собственным benchmark: в текущем сценарии такой benchmark не происходил и не может быть назван фактом.
После появления отдельного разрешённого контракта всё равно придётся обсуждать trade-off, а не искать универсального лидера. Только затем кто-то с полномочиями сможет принять решение. Эта статья не предсказывает, каким оно будет, и не говорит, что ноябрьский rollout состоится. Её результат скромнее: она оставляет вопрос измеримым, а неизвестность видимой.
Проверяемые источники
Проверяемые источники
- NIST SP 800-30 Rev. 1: Guide for Conducting Risk Assessments — версия: Revision 1, September 2012, DOI 10.6028/NIST.SP.800-30r1. Первичный источник использован для терминов о неопределённости и оценке риска. Граница: Не подтверждает measurement, benchmark, frontier или выбор технологии.
- RFC 2119: Key words for use in RFCs to Indicate Requirement Levels — версия: BCP 14, March 1997, DOI 10.17487/RFC2119. Первичный RFC использован для границы нормативной формулировки. Граница: Не задаёт метод измерения и не превращает план в факт.
- RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words — версия: BCP 14, May 2017, DOI 10.17487/RFC8174. Первичный RFC использован как уточнение BCP 14. Граница: Не назначает веса и не подтверждает результат будущего сценария.