Сценарий на ноябрь 2026 с source boundary 31.07.2026 начинается не с названия технологии, а с конкретной поломки выбора: команда сравнивает две альтернативы по одному удобному демо, а стоимость внедрения остаётся в сноске. Через месяц всплывают обучение, миграция, поддержка и обратимость. Цена ошибки измеряется не красивой таблицей, а временем людей на разбор неучтённой работы и зависимостей, которые уже успели стать обязательными.
Вторая проблема — матрица, в которой заранее известен победитель. Вес «скорости» получают после просмотра результата, критерий совместимости описывают туманно, а отсутствующие данные заменяют числом. Цена такой точности — ложный мандат на выбор: спор переносится из явных допущений в необратимую реализацию. Это не отчёт, не benchmark и не rollout. Ни один замер или выбор не происходил: ниже только сценарий на 2026-11, а положительный output literal ограничен bounded-review-handoff с effect: no-system-change.
Сначала формулируют решение, которое матрица не может принять
Матрица полезна, когда от неё не требуют магии. Она не выбирает стек и не превращает оценку в доказательство. Её работа уже: удержать на одном листе вопрос, альтернативы, критерии, вес и цену допущения. Для планового примера есть только fixed-runtime-a и fixed-runtime-b. Эти имена нарочно не соответствуют продуктам. Они не обещают, что одна технология реально существует, совместима с вашим кодом или будет использоваться в ноябре.
Хороший вопрос имеет границу. Не «что современнее?», а «какая из двух альтернатив требует меньшей работы адаптации при явно названном способе обучения и миграции?». Не «что быстрее?», а «какой сигнал мог бы в будущем ответить на конкретную операционную гипотезу?». Пока сигнала нет, в клетке не должно быть выдуманного балла. В плановой матрице вес — это публичное предпочтение вопроса, не вероятность и не прогноз результата.
| Критерий | Вес | Что будет уточняться | Что не разрешено утверждать |
|---|---|---|---|
| Пригодность к задаче | 40 | какая граница задачи названа? | что вариант уже решает задачу |
| Cost of adoption | 35 | какие обучение, миграция и поддержка будут считаться? | что переход дешёв или завершён |
| Эксплуатация | 25 | какой будущий операционный вопрос важен? | что наблюдалась надёжность |
| Итого | 100 | почему именно эти приоритеты? | что сумма выбрала победителя |
Cost of adoption — отдельный критерий, а не штраф в комментарии
Стоимость внедрения часто прячут в слове «экосистема». Это плохой контейнер: в нём смешиваются навыки, миграция, документация, инструменты, поддержка и цена ошибки при возврате. В сценарии каждый из этих пунктов остаётся вопросом, пока не назван владелец будущего evidence. Такой подход не раздувает таблицу до финансовой модели. Он не даёт технической демонстрации незаметно отменить работу по переходу.
Для cost of adoption стоит записать не один балл, а состав: чему должна научиться группа; какие границы кода или процессов изменятся; кто будет поддерживать редкий случай; как обнаружить, что обратимость утрачена. Это не означает, что все пункты равны. Вес 35 показывает лишь предварительный приоритет данной synthetic конфигурации. В другой задаче его можно изменить, но тогда изменение надо объяснить до сравнения, а не после удобного вывода.
Вес выражает ценность вопроса, не силу факта
Веса 40, 35 и 25 в примере суммируются до 100, чтобы пропуск был механически заметен. Это не научная шкала и не усреднение мнений. Если критерий не назван или у него нет веса, функция останавливается. Fail-closed статус лучше декоративного нуля: ноль мог бы означать плохой результат, хотя на самом деле неизвестно, что именно хотели оценить. Отдельно важно не делать вес результатом ожидаемого выигрыша: тогда модель уже содержит свой желаемый ответ.
Нужна и короткая запись причины веса. Для пригодности — потому что без неё сравнение не относится к задаче. Для adoption — потому что переход создаёт работу за пределами исходного прототипа. Для эксплуатации — потому что будущему владельцу надо знать, какой вопрос наблюдения вообще имеет смысл. Эти формулировки — собственная модель редакции, не вывод NIST или RFC. Внешние источники здесь помогают отделять требования и оценку риска от риторики, но не подтверждают наш порядок чисел.
Literal validator матрицы
import { createFixedTechnologyEvaluationCase, assessFixedTechnologyEvaluation } from './upgrade-2026-11.mjs';
const plan = createFixedTechnologyEvaluationCase('weighted-plan-v1');
const result = assessFixedTechnologyEvaluation(plan);
console.log({ status: result.status, effect: result.effect, next: result.nextAction });
// { status: 'bounded-review-handoff', effect: 'no-system-change', next: 'give-the-fixed-plan-to-a-future-evidence-owner' }Пример буквально запускается только с экспортами этого модуля и named in-memory literal. JSON clone отделяет вход от внутренней константы, deep freeze блокирует изменение вложенных полей в процессе. Он не читает сеть, браузер, файлы, env, часы, секреты, telemetry или внешние инструменты; он не делает benchmark и не запускает production-код. Его положительный ответ — безопасная передача конфигурации будущему владельцу evidence, а не рекомендация, выбор или разрешение на rollout.
Порядок подготовки ноябрьского сравнения
- Пометить документ как план/сценарий на 2026-11 и рядом записать source boundary 2026-07-31.
- Назвать одну границу решения и две обезличенные альтернативы, не добавляя историю их использования.
- Выписать пригодность, cost of adoption и эксплуатационный вопрос; для каждого дать scale и вес.
- Проверить, что веса дают 100, а у каждого пункта есть причина и будущий владелец evidence.
- Описать synthetic configuration буквально: только fixed literals, без скрытых параметров и запусков.
- Запустить fixture и передать только
bounded-review-handoff; не писать winner, benchmark, rollout или measured.
Матрица не должна стирать разницу между неизвестным и плохим
У оценочной формы есть удобная, но опасная привычка: пустую клетку закрашивают нулём, чтобы таблица «сошлась». Это подменяет два разных состояния. Ноль может означать, что вариант явно не подходит по заранее понятной причине. Пустота означает другое: критерий, способ проверки или данные для него пока не названы. В первом случае можно обсуждать отрицательное свойство альтернативы. Во втором нужно вернуть вопрос владельцу формулировки. Если смешать их, матрица штрафует не технологию, а собственное незнание команды.
Для ноябрьского плана это особенно существенно, потому что никаких фактических scores нет. Не надо назначать фиксированным именам fixed-runtime-a и fixed-runtime-b даже условные победы ради учебного эффекта. Они существуют только как две позиции, для которых будущий evidence contract мог бы задать одинаково понятный вопрос. Такой минимализм не делает статью менее практичной: он сохраняет момент, когда настоящий спор ещё можно вести об условиях, а не о красивой сумме в последней колонке.
Опасные сокращения, которые матрица должна остановить
Первый опасный случай — недатированный plan. Без ноября и cutoff текст легко начинает звучать как уже состоявшееся решение. Второй — отсутствующий критерий или вес. Тогда читатель не отличит сознательное исключение от забытой стоимости. Третий — скрытая конфигурация измерения: фраза «потом прогоняем одинаково» ничего не говорит о входах, повторениях или неопределённости. Четвёртый — положительный результат вида «победитель выбран». Для будущего сценария он запрещён даже тогда, когда таблица выглядит аккуратно.
В validator эти четыре сокращения имеют отдельные stop-коды. Это не policy настоящей команды и не security control. Это учебная граница, которая не позволяет тексту перепрыгнуть от вопросов к факту. Если реальному владельцу понадобится сравнение, он в отдельном процессе должен определить разрешённые данные, среду, метод и полномочия. Ноябрьский пакет ничего из этого не предполагает и не создаёт.
Ограничения и следующий шаг
Взвешенная матрица не оценивает зрелость людей, лицензии, юридические условия, доступность, безопасность или реальные затраты. Она также не показывает, как объединять конфликтующие сигналы и когда один стоп должен отменять весь выбор. NIST SP 800-30 говорит о структуре risk assessment, но не выдаёт веса для конкретной технологии. RFC 2119 объясняет контекст требований, а не делает наш критерий обязательным.
Следующий шаг в будущем сценарии — назначить владельца, который сможет предложить разрешённый evidence contract для одного критерия. До этого надо оставить ячейки без баллов и hand-off без победителя. Если будущий контракт не может назвать входы и границу интерпретации, проблему следует вернуть к формулировке задачи, а не компенсировать уверенностью в презентации.
Проверяемые источники
Проверяемые источники
- NIST SP 800-30 Rev. 1: Guide for Conducting Risk Assessments — версия: Revision 1, September 2012, DOI 10.6028/NIST.SP.800-30r1. Первичный источник использован для различения структуры оценки риска и конкретного проектного решения. Граница: Не задаёт наши веса, альтернативы, результат benchmark или выбор.
- 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. Граница: Не превращает synthetic status в одобрение или факт эксплуатации.