Проблема. Новая возможность внутреннего инструмента может «работать»: заявка подтверждается, итог появляется, ошибки нет. Но путь оставляет человека в очереди между submit и approval, вынуждает искать владельца и создавать ручный обход. Цена ошибки — скрытая: потерянный контекст, повторная работа support и решение о redesign на основании одного яркого сообщения.
Разберём такой случай без притворства, что у нас есть production telemetry или реальные пользователи. Учебный кейс использует только fixed in-memory literals. Его цель — показать форму доказательства: как разделить observation, event, support signal, decision и effect evidence; как записать unknown; и как остановить утверждение, если одно synthetic прохождение не даёт основания говорить «стало удобнее».
Случай: запрос sandbox access
Declared role synthetic-platform-engineer открывает одну fixed задачу. В 09:03 она отправляет request, в 09:04 путь входит в approval wait, в 09:41 получает confirmation и в 09:45 фиксирует synthetic result. Между submit и received задан bucket 30m–1h. Рядом есть UX-observation: роль не понимает, кто отвечает за следующий шаг. Отдельно лежит support signal с категорией routing-unclear.
Важно, что четыре объекта не дублируют друг друга. Event не говорит, что ожидание плохо. Observation не сообщает, что так происходит у всех. Support signal не измеряет число обращений. Candidate change не доказывает эффект. Это намеренное ограничение: одна задача может обнаружить дырку в вопросе, но не может без повторной проверки объявить исправление успешным.
Карта случая: факт, гипотеза и неизвестное
| Артефакт fixed model | Что можно сказать | Чего нельзя сказать | Кто продолжает |
|---|---|---|---|
| stage event approval.wait.started → received | В учебной записи есть этап с bucket 30m–1h. | Почему ждём, насколько это часто и насколько это дорого. | Journey owner проверяет путь. |
| UX-observation owner-unclear | Declared role не видит ответственного после submit. | Что label гарантированно снизит время или frustration. | Research owner уточняет вопрос. |
| support signal routing-unclear | Есть фиксированная формулировка категории обращения. | Что это самый частый запрос или причина задержки. | Support + journey owner выбирают проверку. |
| candidate change owner-before-submit | Есть гипотеза о маршрутизации и один target stage. | Что изменение уже улучшило инструмент. | Journey owner запускает bounded follow-up. |
| claimed effect not-established | Модель честно оставляет вывод открытым. | Что эффект отсутствует в действительности. | Owner сохраняет stop path до нового evidence. |
GOV.UK Service Manual предлагает смотреть на end-to-end journey через задачи, completion и время, периодически сравнивая результаты, а не объявлять качество по одному цифровому сигналу. Для support руководство предлагает использовать feedback в улучшении и различать команды, которые могут действовать. В кейсе эти факты не становятся готовой методикой: они объясняют, почему route, signal и owner должны быть видны отдельно.
Что именно проверяет fixture
Fixture не «прогоняет инструмент». Она делает обратное: атакует учебный договор. Baseline принимается, потому что в нём exact keys, fixed version, declared role, пять ordered events, source для каждого вида evidence, непустые unknowns, owner, bounded follow-up и unresolved claim. Затем fixture подделывает event source, role и result; удаляет fields; создаёт sparse array и cyclic value; нарушает временной порядок. Каждый такой input должен завершиться closed decision.
import { createFixedJourneyInput, evaluateJourney, verifyFixture } from './upgrade-2025-06.mjs';
console.log(verifyFixture());
// PASS fixture: 33/33 assertions
const input = createFixedJourneyInput();
delete input.knownUnknowns;
console.log(evaluateJourney(input).reason);
// invalid-task-contractОтдельный test на forged result особенно важен. Он меняет claimedEffect.status на established и добавляет одну ссылку на несопоставимую запись. Evaluator отвечает effect-claim-not-evidenced. Он не пытается «оценить, похоже ли на правду»: единственный допустимый путь — safe stop, пока не появятся одинаковые task boundary, role, stage order, evidence labels и bounded window.
Почему manual workaround — сигнал, а не готовая причина
В реальном расследовании ручной обход часто выглядит как очевидное доказательство плохого UX. Но он может быть следствием срочности, местной привычки, старой инструкции или ограничения процесса, которого интерфейс честно не может снять. Поэтому в model обход не записан как причинный факт. Вместо этого support signal указывает на routing question, UX-observation формулирует непонимание owner, а candidate change ограничен тем, что может проверить: показать ответственного до submit.
Такая формулировка экономит время. Она не просит сначала переписать весь flow. Она требует выяснить, существует ли сравнимое свидетельство: тот же role проходит тот же task после небольшой change и фиксирует тот же набор полей. Если нет — решение не объявляют неудачным и не объявляют удачным. Его статус остаётся hypothesis-only.
Сравнимость — не декоративное слово. Если после изменения мы поменяли роль, результат задачи, источник события или правило bucket, разница может появиться в данных без изменения самого пути. Поэтому comparisonBoundary перечисляет role, objective, order и evidence labels. Он не делает эксперимент причинным, но не позволяет незаметно сравнить разные процессы. Бounded window тоже не обещает статистический срок: он ограничивает, когда owner обязан вернуться к вопросу или признать evidence недостаточным.
В кейсе safe stop не означает «ничего не делать». Он означает конкретное действие без эффекта claim: исправить broken contract, уточнить source, провести разрешённую проверку или закрыть hypothesis. Такая дисциплина особенно полезна для внутренних инструментов, где один очень громкий отзыв легко перетягивает приоритет, а тихая, но массовая задержка остаётся между системами. Сначала появляется проверяемый путь, потом — обоснование инвестиции.
Петля: от сигнала к повторной проверке
Владелец в кейсе — synthetic-journey-owner. Это не право на production change, а явный адрес ответственности внутри модели. Его decision описывает hypothesis, target stage, expected evidence, bounded window и stop condition. Research owner, support owner и technical owner в реальном мире могут быть разными людьми; модель не заставляет слить их в одну роль. Она только не позволяет оставить вопрос «кто продолжает» без ответа.
- Сохранить исходную формулировку задачи, role и expected result.
- Отметить stages и wait bucket без вывода о причине.
- Приложить UX-observation и support signal как разные источники.
- Назначить owner, одну candidate change и bounded comparison boundary.
- После повторной проверки принять только comparable evidence; иначе оставить claim
not-established.
Откуда берётся скрытая cognitive cost
Cognitive cost часто появляется между видимыми событиями: роль вспоминает, куда писать, сравнивает похожие страницы, ждёт ответа в другом канале или боится повторно отправить запрос. Ни event, ни support category сами по себе не измеряют это состояние. Поэтому полезно записать knownUnknowns заранее: нет population denominator, нет объяснения wait bucket, нет post-change comparison, нет реального support volume. Это превращает «кажется, неудобно» в план исследования, а не в необратимый вывод.
Граница кейса и следующий проверяемый шаг
Граница кейса. Время 09:03–09:45, synthetic role и формулировка support card — декорации одного учебного прохода, а не вырезка из реального workflow. Кейс не образует cohort, не содержит ticket, file или telemetry record и не даёт основания утверждать, что такая же история есть у другой роли. Его единственная проверяемая ценность — показать, где decision обязан остановить неподтверждённый result.
Кейс не содержит реального workflow, документации, заявок, пользователей, telemetry, support tickets или network. Он не устанавливает цену ожидания и не даёт разрешение собирать такие данные. Его положительный decision — лишь согласованность JavaScript literals, а не одобрение изменения в интерфейсе.
Следующий проверяемый шаг. Перед любой реальной работой сформируйте с owner один research question: «видит ли эта role ответственного до submit и остаётся ли вопрос маршрутизации после этого?» Затем согласуйте допустимый источник evidence и условие safe stop. Если источник или comparison boundary не определены, не начинайте с метрики — оставьте claim открытым.
Проверяемые источники
- OpenTelemetry Trace API (v1.31.0, immutable commit 3985e212f0ef5439daf9b10f0ee490e349c69368, 13 March 2024). Версия v1.31.0 описывает span как операцию со start/end timestamps, attributes и timestamped events; event содержит name, timestamp и optional attributes. Граница: Это контракт observability API. Он не определяет UX, не назначает owner и не доказывает, что конкретная команда правильно измеряет путь.
- W3C Performance Timeline (Candidate Recommendation Draft, 21 May 2025). Рекомендация определяет PerformanceEntry и поля name, entryType, startTime и duration для наблюдения временных записей. Граница: Стандарт относится к web performance API; здесь он служит только примером явного имени, типа и времени записи, не рецептом измерения внутреннего сервиса.
- GOV.UK Service Manual: Measuring the success of your service (immutable Internet Archive capture 2024-07-05T18:32:52Z of official GOV.UK guidance; public update 6 August 2018). Закреплённый снимок предлагает сочетать performance metrics с user research, не полагаться только на digital analytics и для пути смотреть completion/time периодически. Граница: Это публичная методическая рекомендация, а не универсальный KPI, договор об измерениях или доказательство эффекта этой учебной модели.
- GOV.UK Service Manual: Set up and manage user support (immutable Internet Archive capture 2023-05-12T13:53:36Z of official GOV.UK guidance; public update 24 November 2016). Закреплённый снимок предлагает использовать feedback user support для улучшения, группировать запросы и связывать их с внутренней командой, способной действовать. Граница: Support signal указывает направление проверки; он не заменяет исследование, не показывает причинность и не является готовым решением.