У будущего сравнения технологий есть типичный организационный сбой: человек передаёт следующему владельцу фразу «вариант B доказал преимущество», хотя у него есть лишь незакрытые вопросы. Конкретная проблема — hand-off переносит уверенный вывод вместо границы evidence. Цена ошибки высока: получатель тратит время на защиту несуществующего benchmark, а решение получает историю, которую невозможно проверить или отменить без потери лица.
Вторая проблема — назвать synthetic пример field report. Тогда фиксированные строки, придуманные для разговора, выглядят как данные среды, а stop воспринимается как мелкая формальность. Цена — ложная операционная память: кто-то позже решит, что выбор, rollout или замер уже случились. Ничего такого не происходило. Ноябрь 2026 ещё впереди, source boundary — 2026-07-31; это план/сценарий, не кейс о внедрении. Положительная ветка кода возвращает только bounded-review-handoff и всегда содержит effect: no-system-change.
Field здесь означает форму передачи, а не наблюдение поля
Слово field обычно обещает опыт: контекст, временную линию, наблюдение и последствия. В этом пакете оно употребляется уже. Мы рассматриваем, как подготовить карточку для будущего владельца evidence, не выдумав ни одной строки истории. Карточка хранит дату плана, cutoff источников, alternatives, criteria, visible measurement configuration, статус и следующий вопрос. Она не хранит ID проекта, клиентов, инфраструктуру, реальные метрики, ссылки на dashboard или утверждение о совместимости.
Такой hand-off полезен именно своей неполнотой. Получатель сразу видит, чего нет: результата запуска, оценки uncertainty, полномочий на выбор и доказательства cost of adoption. Он не обязан раскапывать прозаический рассказ, чтобы обнаружить пробел. Взамен карточка даёт точный адрес следующего действия: владелец будущего evidence должен сформировать отдельный разрешённый contract. Это больше похоже на передачу вопроса, чем на передачу решения, и этим снижает цену неверной эскалации.
| Поле | Что в нём допустимо | Чего в нём нет | Кому адресован следующий шаг |
|---|---|---|---|
| Временная граница | 2026-11 и cutoff 2026-07-31 | прошедшая дата внедрения | редактору планового сценария |
| Criteria | named question, scale, weight | заполненный score или лидер | владельцу decision framing |
| Measurement | fixed literal, not-executed, not-estimated | trace, timing, telemetry | владельцу будущего evidence |
| Output | bounded-review-handoff либо stop | approve, select, deploy, measured | следующему reviewer |
Передача начинается с provenance, а не с вывода
Provenance в этом сценарии не означает журнал событий. Это короткая подпись происхождения: fixed in-memory literal, JSON clone, deep freeze, дата плана и cutoff. Её задача — дать читателю повод не доверять карточке как отчёту. Если рядом нет этой подписи, fixed-runtime-a можно принять за настоящий сервис, а not-executed — за плохо записанный результат. Явная искусственность не украшение: она удерживает границу между моделью и миром.
Особенно важно сохранять source boundary. Источник, опубликованный до 31.07.2026, может объяснить термин или ограничение документа; он не сообщает, что сделает команда в ноябре. Собственная модель добавляет веса, структуру hand-off и код статусов. Эти слои нужно называть разными словами. Нельзя взять авторитет первичного RFC и на его основании сказать, что synthetic конфигурация уже прошла review. Источник даёт факт о тексте источника, модель — только правило этого учебного пакета.
Fail-closed status делает пробел передаваемым
Четыре остановки несут разный смысл. stop-undated-plan-or-cutoff сообщает, что нельзя понять, относится ли карточка к будущему. stop-missing-criterion-or-weight показывает, что выборочное внимание скрыто. stop-hidden-measurement-configuration не разрешает назвать словом benchmark неописанный запуск. stop-disallowed-positive-result останавливает попытку передать winner или rollout как будто они следуют из preparation. Каждый статус возвращает nextAction, а не диагноз личности автора.
Fail-closed важен в hand-off потому, что получатель не должен угадывать, что исправить. Общая фраза «не хватает данных» расширяет scope до всего мира. Точный stop говорит, какое поле недопустимо и какую границу надо сделать видимой. При этом он не заменяет будущую проверку: добавленный weight ещё не делает оценку верной, а раскрытый protocol ещё не производит измерение. Карточка лишь становится честной для передачи дальше.
Runnable example передаёт план, не действие
import { createFixedTechnologyEvaluationCase, assessFixedTechnologyEvaluation } from './upgrade-2026-11.mjs';
const refusedPlan = createFixedTechnologyEvaluationCase('claimed-benchmark-win-v1');
const gate = assessFixedTechnologyEvaluation(refusedPlan);
console.log(JSON.stringify([['review-status', gate.status], ['result-limit', gate.effect], ['repair', gate.nextAction]]));
// [["review-status","stop-disallowed-positive-result"],["result-limit","no-system-change"],["repair","use-bounded-review-handoff"]]Этот пример намеренно содержит запрещённый вывод benchmark-winner-selected. Он не ищет benchmark output и не отменяет чей-либо выбор. Все значения зашиты как literals, clone создаётся только в памяти, freeze не позволяет подменить вложенный conclusion после factory. В процессе не открываются browser, сеть, file system, environment, clock, secrets, telemetry или внешние инструменты. Возвращённый stop доказывает только одно свойство кода: этот сценарий не пропустит позитивный результат, который не имеет права существовать.
Как выглядит безопасный synthetic evidence hand-off
Получателю не надо писать «технология перспективна». Достаточно передать: рассматривается план 2026-11; источники не позднее cutoff; есть три named criteria с weights; measurement configuration literal и not-executed; решение отсутствует; нужен владелец evidence. Такая запись не впечатляет лозунгом, зато сохраняет объект спора. Если владелец возражает, он может изменить ровно один слой: границу вопроса, набор criteria, будущий protocol или порядок ответственности.
Нельзя подменять hand-off очередью работ. Карточка не ставит задач, не вызывает сервис, не отправляет уведомление и не меняет registry. Она может сказать, что следующий владелец должен быть назван, но не может назначить человека и срок. Иначе synthetic exercise незаметно станет внешним действием. Для плановой публикации безопаснее оставить ownership как открытый вопрос, чем изобразить выполненную координацию.
Порядок передачи для сценария ноября
- Проверить, что карточка прямо называет 2026-11 и source boundary 2026-07-31.
- Показать provenance: fixed literals, JSON clone и deep freeze; не добавлять правдоподобных данных.
- Проверить каждый criterion на id, scale, question и weight, а сумму weights — на 100.
- Открыто записать protocol и отметки not-executed/not-estimated; скрытую конфигурацию вернуть с stop.
- Запретить слова winner, selected, benchmark complete, rollout, deploy и measured в positive branch.
- Передать status, boundary и nextAction владельцу будущего evidence без утверждения, что работа уже началась.
Чего field-ярлык не разрешает
Он не разрешает говорить о пользователях, времени ответа, экономии, проценте ошибок или зрелости инструмента. Он не делает источники после cutoff допустимыми и не превращает первичные документы в данные конкретной среды. Он не заменяет legal, security, accessibility или operational review. Отдельно опасно сказать «мы проведём собственный benchmark» так, будто его итог уже известен. В будущем сценарии корректная замена — synthetic configuration, которая описывает только форму ещё не созданного evidence contract.
Нельзя также считать freeze защитой от внешнего вмешательства. Это локальное свойство fixture, не безопасность production. JSON clone полезен потому, что делает пример независимым от shared reference, а не потому, что способен защитить реальную систему. Такие разграничения кажутся педантичными, пока карточка не начинает жить дольше автора. Потом именно они определяют, сможет ли новый читатель отличить ограничение кода от факта эксплуатации.
Ограничения и следующий шаг
NIST SP 800-30 может подсказать аккуратность в разговоре о риске; RFC 2119 и RFC 8174 — дисциплину нормативных слов. Ни один из них не подтверждает выбранную matrix, существование альтернатив или будущий outcome. Редакционная модель намеренно не пытается заменить эти пробелы. Её максимальная польза — сделать недостающее evidence объектом передачи, а не скрытой причиной поспешного решения.
Следующий шаг — будущему владельцу evidence contract решить, допустимы ли реальные inputs и какой результат он вообще сможет интерпретировать. Пока такого контракта нет, честный status остаётся hand-off или stop. Не следует превращать этот draft в report задним числом: ни benchmark, ни внедрение, ни выбор в нём не произошли и не заявляются.
Проверяемые источники
Проверяемые источники
- NIST SP 800-30 Rev. 1: Guide for Conducting Risk Assessments — версия: Revision 1, September 2012, DOI 10.6028/NIST.SP.800-30r1. Первичный источник использован только для различения risk vocabulary и собственного решения. Граница: Не является field evidence, подтверждением benchmark или разрешением rollout.
- RFC 2119: Key words for use in RFCs to Indicate Requirement Levels — версия: BCP 14, March 1997, DOI 10.17487/RFC2119. Первичный RFC использован для аккуратной силы слов требования. Граница: Не подтверждает status карточки и не создаёт workflow команды.
- RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words — версия: BCP 14, May 2017, DOI 10.17487/RFC8174. Первичный RFC уточняет использование BCP 14. Граница: Не разрешает называть synthetic hand-off фактом выбора.