{
  "index": 77,
  "slug": "editorial-2025-11-mechanism-research-method",
  "title": "Как проверить источник до того, как он повлияет на решение",
  "excerpt": "ETag, дата публикации и цифровая подпись подтверждают разные свойства документа. Разбираем границы этих сигналов и собираем проверку, которая останавливает слишком сильный вывод.",
  "contentHtml": "<p>Команда находит страницу с нужным API, видит свежую дату и сразу переносит совет в интеграцию. Через месяц endpoint ведёт себя иначе. Оказывается, страница описывала другой режим, а заголовок <code>ETag</code> приняли за номер релиза. Ошибка стоит дороже, чем время на чтение: меняется код, растёт число обходов, а причину трудно восстановить после инцидента.</p>\n<p>Тезис статьи прост: источник не равен доказательству решения. Проверка должна разделять публикацию, конкретное представление документа, наблюдаемый факт и действие, которое из него следует. Каждый переход требует своей опоры. Если опоры нет, проверка должна остановиться и показать, чего не хватает.</p>\n<h2>Четыре уровня, которые нельзя смешивать</h2>\n<p>Публикация — RFC, стандарт, релиз или датированная рекомендация. Она задаёт документ и его область. Представление — именно тот HTML, PDF или HTTP-ответ, который прочитал инженер. Оно может зависеть от языка, заголовков запроса, авторизации и времени.</p>\n<p>Наблюдение — короткая фраза, которую можно проверить в представлении: «в разделе указано условие X» или «ответ содержит заголовок ETag». Утверждение — уже интерпретация наблюдения. Решение — изменение кода, конфигурации или процесса. Страница может подтвердить наблюдение, но не обязана подтверждать решение для любого продукта.</p>\n<figure><img src=\"/assets/editorial/2025/research-method-2025-claim-status-matrix.svg\" alt=\"Матрица проверки утверждения: от версии публикации и конкретного представления к наблюдению и решению\" loading=\"lazy\" /><figcaption>Проверка движется от адресуемого представления к наблюдению, затем к ограниченному утверждению и только после этого к решению.</figcaption></figure>\n<p>Удобно хранить эти уровни раздельно. Для публикации нужен идентификатор и дата. Для представления — URL, версия, commit или снимок. Для наблюдения — точный раздел, строка или заголовок ответа. Для решения — условия применимости, риск и способ проверки.</p>\n<h2>Почему ETag не заменяет версию</h2>\n<p>В HTTP заголовок <code>ETag</code> служит validator выбранного представления ресурса. Клиент сравнивает значение при условных запросах. Сервер может вычислить его по содержимому, назначить внутренний идентификатор или учитывать согласование формата. Само значение не обязано раскрывать эту схему.</p>\n<p>Из <code>ETag: \"a81c\"</code> нельзя вывести, что документ относится к релизу 8.1, что он был опубликован в конкретную дату или что смысл каждого абзаца сохранится для другого endpoint. <code>Last-Modified</code> также говорит о времени изменения представления, а не о полном жизненном цикле продукта.</p>\n<p>Для исторической проверки нужен более сильный якорь: датированный RFC, тег релиза, commit, опубликованный PDF или сохранённый снимок. Validator полезно записать дополнительно. Он помогает повторить протокольную проверку, но не превращается в семантическую версию.</p>\n<h2>Что подтверждает цифровая подпись</h2>\n<p>Подпись помогает проверить целостность защищённого объекта и связь с подписантом. Она не превращает каждое утверждение внутри объекта в доказанный факт. Документ может быть подлинным и одновременно описывать ограниченный сценарий, старую конфигурацию или другой объект.</p>\n<p>Поэтому у записи проверки нужны две разные строки: <code>integrity</code> и <code>claimEvidence</code>. Первая отвечает на вопрос «документ не изменили после подписи?». Вторая — «есть ли в нём наблюдение, которое поддерживает именно нашу фразу?». Подмена одной строки другой создаёт ложную уверенность.</p>\n<h2>Учебный пример: остановить слишком сильный вывод</h2>\n<pre><code>const record = {\n  source: {\n    url: 'https://example.test/api-guide',\n    etag: '\"a81c\"',\n    signature: 'valid'\n  },\n  observation: 'Документ описывает режим read-only для версии 2.',\n  claim: 'API безопасен для записи в любой версии.'\n};\n\nconst canRecommend =\n  Boolean(record.source.url) &&\n  Boolean(record.source.etag) &&\n  record.source.signature === 'valid' &&\n  record.claim.includes('версии 2') &&\n  record.observation.includes('версии 2');\n\nconsole.log(canRecommend); // false</code></pre>\n<p>Это учебный пример, а не проверка реальной подписи и не production-код. У записи есть адрес, validator и валидная подпись. Но наблюдение ограничивает вывод версией 2 и режимом read-only, а утверждение расширяет его до записи и любой версии. Проверка возвращает отказ. Правильное действие — сузить утверждение или найти отдельное наблюдение для записи и нужной версии.</p>\n<p>Отрицательный путь важен не меньше успешного. Если система продолжает работу со статусом «достаточно» после отсутствия версии, locator или области применимости, она маскирует неизвестное. Средний балл доверия не исправит отсутствие конкретного факта.</p>\n<h2>Симптом → причина → проверка → действие</h2>\n<div class=\"table-scroll\"><table><caption>Диагностика ошибок при чтении источника</caption><thead><tr><th scope=\"col\">Симптом</th><th scope=\"col\">Причина</th><th scope=\"col\">Проверка</th><th scope=\"col\">Действие</th></tr></thead><tbody><tr><td>ETag выглядит как номер версии</td><td>Протокольный validator смешали с релизом</td><td>Открыть правила версий издателя и сравнить с RFC</td><td>Сохранить ETag отдельно, найти release pin</td></tr><tr><td>Ссылка открывается, но текст уже другой</td><td>Зафиксирован только текущий URL</td><td>Проверить дату, commit, PDF или архивный снимок</td><td>Сузить исторический вывод или сменить источник</td></tr><tr><td>Подписанный документ подтверждает всё сразу</td><td>Целостность приняли за истинность тезиса</td><td>Разделить signature и claim evidence</td><td>Оставить только вывод об авторстве либо добавить факт</td></tr><tr><td>Документ верен, но совет не работает</td><td>Scope документа не совпал с продуктом</td><td>Сопоставить endpoint, версию, права и режим</td><td>Добавить условие применимости и отдельный тест</td></tr><tr><td>В отчёте нет причины остановки</td><td>Отказ заменили общим статусом доверия</td><td>Проверить обязательные поля и отрицательные ветки</td><td>Вернуть статус hold с конкретным недостающим полем</td></tr></tbody></table></div>\n<h2>Порядок проверки</h2>\n<ol><li>Сформулируйте решение одним предложением. Укажите действие, объект, версию и режим.</li><li>Назовите уровень каждого утверждения: публикация, представление, наблюдение или решение.</li><li>Закрепите представление. Используйте release, commit, датированный документ или снимок. Текущий URL оставьте только как навигацию.</li><li>Запишите точный locator: раздел, строку, заголовок ответа или другой повторяемый фрагмент.</li><li>Сверьте scope. Проверьте endpoint, версию, метод, права, язык, формат и условия, при которых сделано наблюдение.</li><li>Сравните силу формулировки с фактом. Уберите слова «всегда», «безопасно», «поддерживает» и «для всех», если источник их не подтверждает.</li><li>Проверьте отрицательный путь: уберите версию, измените режим или подставьте другой объект. Система должна остановиться, а не выдать прежний совет.</li><li>Только после этого выберите действие и добавьте проверяемый критерий результата.</li></ol>\n<h2>Ограничения метода</h2>\n<p>Эта модель не делает веб неизменяемым. Она не устанавливает истинность заявления одной ссылкой и не заменяет предметного эксперта. Официальный стандарт может не описывать operational-ограничение конкретного сервиса. Подпись может быть корректной, но относиться не к тому представлению. Архивный снимок фиксирует текст, но не доказывает, что система в тот день работала по нему.</p>\n<p>Метод также не требует сохранять весь интернет. Для дорогих решений достаточно закрепить минимальный набор: первичный документ, конкретное представление, наблюдение, область применимости и способ проверки. Если какой-то элемент нельзя получить, вывод должен стать уже. Отказ — нормальный результат, когда данных недостаточно.</p>\n<h2>Критерий готовности</h2>\n<p>Проверка готова, когда другой инженер может открыть тот же документ или его закреплённое представление, найти указанный locator, увидеть наблюдение и понять, почему оно поддерживает решение именно в заданном scope. Если он меняет версию, режим или объект, отрицательный путь возвращает остановку с понятной причиной. Ни один из этих результатов не требует доверять интонации автора.</p>\n<h2>Проверяемые источники</h2>\n<ul><li><a href=\"https://www.rfc-editor.org/rfc/rfc9110.html\" target=\"_blank\" rel=\"noopener noreferrer\">RFC 9110: HTTP Semantics</a> — раздел 8.8 описывает <code>ETag</code> и <code>Last-Modified</code> как validator fields для выбранного представления. Документ не назначает ETag номером релиза.</li><li><a href=\"https://www.w3.org/TR/vc-data-model-2.0/\" target=\"_blank\" rel=\"noopener noreferrer\">W3C Verifiable Credentials Data Model v2.0</a> — раздел о verification отделяет проверку credential от оценки истинности закодированных claims. Рекомендация не заменяет независимое доказательство конкретной интеграции.</li><li><a href=\"https://www.w3.org/TR/prov-dm/\" target=\"_blank\" rel=\"noopener noreferrer\">W3C PROV-DM: The PROV Data Model</a> — различает entity и activity, что помогает отдельно хранить документ и действие его проверки. Модель не задаёт автоматическую шкалу доверия.</li></ul>"
}