После рабочей пробы заметка reviewer-а (того, кто читает и сверяет запись) нередко выглядит так: «понимает кеширование, можно продолжать». В ней исчезают исходный symptom, услышанный факт и неизвестное; следующий читатель не отличит наблюдение от мнения. Цена ошибки — команда калибрует не критерии, а память о разговоре, и одинаковая работа получает разные трактовки у разных reviewer-ов.
Причина — три разных операции пишут в одно поле. Observation отвечает «что было в fixed входе», interpretation — «какой узкий вывод разрешён», review decision — «какое действие допустимо дальше». Проверка: у каждого interpretation есть ссылки на observations и фраза об unknown; у decision есть ссылка на interpretation и запрет на personal outcome. Действие — сделать эти записи отдельными объектами и принимать только synthetic hand-off — учебный запрос недостающего факта.
Три слоя работают как границы модуля
Можно представить заметку как маленькую систему с типами. Observation не объясняет, почему stale ответ появился: она сохраняет, что в header задан max-age=0. Interpretation вправе сказать лишь «нужен origin rule», потому что это следует из наблюдения. Review decision не создаёт изменение в сервисе: он просит недостающий rule. Как только слой перепрыгивает границу, цепочка становится непроверяемой. Фраза «не стал бы рисковать» может быть полезной для беседы, но без наблюдаемого условия она не является evidence.
| Слой | Допустимое содержимое | Обязательная связь | Стоп-сигнал |
|---|---|---|---|
| Observation | Факт fixed literal и unknown | sample id, evidence ref | появились реальный доступ или личные сведения |
| Interpretation | Узкий claim о следующем факте | список observation id | claim объясняет причину без evidence |
| Review decision | request или stop | список interpretation id | решение о человеке, change или score |
| Calibration note | расхождение по criterion | одна и та же цепочка id | переписывание исходного observation |
Наблюдение должно пережить несогласие
Хорошее observation можно перечитать, даже если reviewer не согласен с выводом. «Route задан как /v1/report; owner не указан» переживает спор. «Не разобрался с ownership» уже содержит трактовку и предполагает, что другой стороне был доступен способ разобраться. Поэтому у observation есть поле unknown. Оно не делает заметку слабой; оно фиксирует стоимость следующего шага. До тех пор пока origin rule отсутствует, объяснение stale ответа должно оставаться за границей записи.
Эта дисциплина особенно важна там, где технический язык маскирует догадку. Слова «architecture smell», «сложный edge case» или «не хватает системного мышления» могут звучать точно, но без симптома и свидетельства они ничего не передают следующему reviewer-у. Лучше сохранить один header literal, чем абзац профессиональных эпитетов. Поздний автор не делает вид, что видит больше данных: он называет, какие данные нужны, и оставляет простой путь проверки.
Кодовая проверка traceability
import {
createFixedInterviewInput,
inspectEngineeringInterview,
} from './upgrade-2025-09.mjs';
const broken = createFixedInterviewInput('fixed-unsupported-interpretation-v1');
const report = inspectEngineeringInterview(broken);
console.log(report.accepted); // false
console.log(report.reasons); // ['interpretation-not-traceable']
// The module stops before a hand-off; it never contacts a service or rates a person.Negative path здесь важнее happy path. Он показывает, что interpretation без существующего observation id не получает право перейти в review. Технически это похоже на ссылочную целостность: объект может быть оформлен красиво, но ссылка на отсутствующий источник делает его недействительным. В настоящем процессе эту проверку можно делать вручную по таблице. Скрипт нужен только для того, чтобы фиксированные правила упражнения можно было повторить без сети, файлов и скрытого состояния.
Что не следует нормализовать в записи
Удобная, но опасная привычка — переписать observation так, чтобы reviewer-ы быстрее согласились. Например, один записал «в header есть max-age=0», другой — «ответ явно stale из-за cache». После нормализации может остаться только вторая формулировка, и обсуждение станет гладким, но неверным: причина вошла в журнал без источника. Поэтому у слоёв разный статус. Fact можно уточнить только ссылкой на тот же literal; interpretation можно заменить, оставив старую как расхождение; hand-off можно сузить до stop. Нельзя редактировать ранний слой ради согласованного позднего вывода.
Такая строгость помогает и при изменении rubric. Если команда решила добавить criterion «владелец следующего шага», она не должна задним числом искать owner в старом sample. Правильный вариант — выпустить новую fixed карточку с явным owner literal либо признать, что старый sample этот criterion не проверяет. Версионирование здесь не бюрократия: оно не даёт сравнению разных заданий выглядеть как несогласие reviewer-ов. В этом пакете модель имеет version id именно для такого разделения, хотя сама не хранит историю и не читает внешнее состояние.
Калибровка начинается до обсуждения
Калибровка не означает, что два reviewer-а обязаны одинаково думать. Она отвечает на более узкий вопрос: одинаково ли они видят criterion и его evidence boundary. До совместного обсуждения каждый читает один fixed sample, выписывает observations и привязывает interpretation к id. Затем сравнивают не итоговую фразу, а первую расходящуюся строку. Если один считает header достаточной причиной, а другой — только симптомом, предмет разговора уже найден: missing origin rule, а не «кто строже».
- Заморозить sample. Оба reviewer-а используют одни literals и один stop condition.
- Писать observation отдельно. Не обсуждать результат, пока не заполнены факт, evidence ref и unknown.
- Привязать interpretation. Для каждой трактовки показать observation id и criterion id.
- Сравнить первую развилку. Найти строку, где выводы расходятся, а не усреднять впечатления.
- Проверить boundary. Удалить всё, что требует личности, реальных данных или незаданного доступа.
- Сформировать hand-off. Оставить request missing evidence либо stop-and-repair-boundary.
Почему общая шкала без evidence не спасает
Общая шкала полезна, когда её якоря описывают наблюдаемую работу. Но сама цифра не объясняет, какие слова, действия или ограничения увидел reviewer. В учебной модели мы вообще не используем numeric score: это уменьшает соблазн превратить упражнение в ранжирование. Вместо него есть criterion id и decision, который нельзя читать как рекомендацию. Такой выбор не доказывает, что числа всегда вредны; он подходит именно для цели пакета — проверить разделение слоёв на synthetic данных.
OPM guide 2008 описывает common rating scale и индивидуальные оценки до обсуждения расхождений. Из этого не следует, что любой технический процесс обязан воспроизводить федеральную процедуру. Здесь взят только переносимый механизм: договориться о критерии до review и сохранять основание для разногласия. Наши поля observation/interpretation/decision — авторская инженерная схема, не цитата и не нормативная модель. Она должна быть проверена на собственных ограниченных примерах, прежде чем использоваться где-либо ещё.
Ограничение механизма
Механизм ограничен fixed synthetic records: все ids, facts, claims и decisions заранее заданы в модуле и не переживают процесс выполнения. У него нет сетевого транспорта, файлового ввода, clock, telemetry, Git, CI или production side effect. В нём отсутствуют реальные собеседования, люди и их данные. Поэтому accepted report означает только целостность ссылок между учебными объектами, а не достоверность характеристики кого-либо.
Разделение записей не устраняет ошибку формулировки role rubric и не даёт полного контекста реальной инженерной работы. Оно также не измеряет скорость, продуктивность, знания или свойства личности. Зато его легко проверить: откройте любую interpretation, удалите мысленно её ссылки на observation и спросите, остаётся ли она доказуемой. Если да, в цепочке, вероятно, спрятан общий ярлык. Следующий шаг — переписать его как request к отсутствующему факту или как явное unknown.
Историческая граница сентября 2025
Источники в разделе ниже публичны и относятся к периоду до 30 сентября 2025; датированный guide OPM выпущен в 2008 году. Они дают контекст для стандартизированных критериев и примеров ответов. Они не подтверждают качество этой модели, не распространяются автоматически на другую организацию и не легитимируют решение о реальном человеке.
Проверяемые источники
- U.S. Office of Personnel Management: Structured Interviews — A Practical Guide — версия: immutable Internet Archive PDF capture 2013-06-25T14:25:25Z; document dated September 2008. Руководство описывает связку анализа работы, компетенций, вопросов, общих шкал, индивидуальных оценок и обсуждения расхождений. Граница: Это историческое руководство федерального ведомства США. Оно не подтверждает пригодность конкретной роли, не задаёт policy другой организации и не доказывает исход реального отбора.
- U.S. Office of Personnel Management: Structured Interview Example — версия: immutable Internet Archive PDF capture 2013-02-27T00:54:26Z of official OPM example. Пример показывает, что вопрос и признаки ответа можно хранить рядом, а не заменять их общим впечатлением reviewer-а. Граница: Короткий пример не является готовой рубрикой для инженерной работы и не обосновывает автоматическую либо персональную оценку.
- U.S. Office of Personnel Management: Writing Samples Summary — версия: immutable Internet Archive PDF capture 2014-03-27T03:42:49Z of official OPM summary. Сводка различает портфолио и заданную работу, отмечая типичность задачи и одинаковые условия review как свойства рабочей пробы. Граница: Источник относится к письменным образцам и не переносит выводы на инженерное интервью, конкретных людей или любой процесс другой команды.