Проблема механики источников появляется, когда один признак пытаются использовать как ответ на все вопросы. У страницы есть дата — значит, она верна; у файла есть подпись — значит, верно каждое предложение; есть ETag — значит, найдена нужная версия. Цена подмены — архитектурное решение с неявной предпосылкой, которое невозможно объяснить после смены документа или инцидента.
Надёжнее разложить проверку на четыре уровня: публикация, её конкретное представление, наблюдаемое утверждение и решение, которое из него следует. Между уровнями нет автоматического перехода. Проверка — для каждого слова в выводе спросить, кто его несёт: pin, artifact, первичный текст или отдельный эксперимент. Действие — выдавать status только на тот уровень, который действительно наблюдался.
Четыре объекта вместо одного слова «источник»
Публикация — например, RFC или датированная рекомендация. Представление — конкретная HTML-страница, PDF или response, которые читатель может открыть. Утверждение — короткая фраза о поведении или факте. Решение — действие команды: изменить интеграцию, добавить проверку, запретить перенос. Все четыре объекта могут иметь похожие имена, но отвечают на разные вопросы. Смешение начинается, когда URL начинают называть доказательством решения.
W3C PROV-DM полезен не как готовый workflow, а как минимальный язык связей. Он определяет entity как вещь с фиксированными аспектами, а activity как действие, которое использует или создаёт entities. В журнале pinned document — entity, чтение section — activity, а statement — отдельный артефакт с scope. Этого уже достаточно, чтобы не выдавать акт чтения за свойство самой системы, о которой читали.
| Сигнал | Что можно сказать | Что не следует заключать | Нужный дополнительный факт |
|---|---|---|---|
| датированный release | известна временная граница публикации | все её тезисы применимы к продукту | точный section и scope |
| ETag или Last-Modified | сервер различает representation для protocol validation | это номер продуктовой версии | версионная политика издателя |
| валидная подпись | проверена authorship/целостность защищённого объекта | семантический claim истинный | прямой первичный факт |
| landing headline | так сформулировано обещание | результат воспроизводим | метод и наблюдение |
Почему validator — это не смысловая версия
RFC 9110 называет ETag непрозрачным validator выбранного representation. Его значение специально не обязано раскрывать внутреннее устройство документа; клиенту достаточно сравнить строки в нужном протокольном контексте. Это хорошо для conditional request и cache validation. Но из opaque tag нельзя вывести, что он соответствует release number, change log или смыслу отдельного абзаца. У одного сервера tag может быть hash содержимого, у другого — внутренний счётчик, у третьего — комбинация вариантов представления.
Last-Modified тоже не следует превращать в доказательство исторической версии. RFC описывает его как время изменения представления, обычно зависящее от многих частей за интерфейсом ресурса, и отдельно допускает слабое сравнение. Даже идеальное время ответа отвечает лишь на вопрос о том, что прислал server. Для исторической статьи нужен более сильный anchor: опубликованный PDF, tagged release, commit или archive capture до даты публикации. Validator можно сохранить как дополнительное наблюдение, но не как замену pin.
Подпись подтверждает автора, а не тезис
У криптографической проверки есть чёткая полезная граница. W3C VC Data Model определяет verification как проверку того, что credential является authentic and current statement issuer или presenter, и прямо говорит: verification credential не означает evaluation truth of encoded claims. Это редкая формулировка, которую стоит переносить почти дословно в инженерную дисциплину: целостность и авторство representation важны, но не закрывают вопрос, верна ли его интерпретация в другой системе.
Практический риск здесь не теоретический. Подписанный документ может честно описывать ограниченную конфигурацию, а автор статьи незаметно выберет другое условие. Подпись не проверит, тот ли endpoint, лимит, дата или право доступа использованы в выводе. Поэтому в механической модели source integrity и claim evidence — разные колонки. Первая защищает цепочку передачи документа; вторая требует прямой связи между locator, наблюдением и фразой в тексте.
Исполняемый отрицательный пример
import { createFixedResearchRecord, assessFixedResearchRecord } from './upgrade-2025-11.mjs';
const signedClaim = createFixedResearchRecord('signature-overreach-v1');
const report = assessFixedResearchRecord(signedClaim);
console.log({ status: report.status, reasons: report.reasons });
// { status: 'hold-claim', reasons: ['integrity-does-not-establish-semantic-truth'] }Функция не проверяет настоящую подпись. Она сравнивает fixed literal с правилом fixture: в карточке наблюдается только signature: valid, а statement делает более сильный семантический вывод. Поэтому status остаётся hold. Такой пример полезнее правдоподобной криптографии в учебном коде: нет ложного впечатления, что библиотека или ключ уже решили исследовательскую часть задачи.
Механика статуса: не рейтинг, а управление неизвестным
Статус не должен отражать настроение автора словами «надёжный» или «сомнительный». Он выбирает следующий разрешённый переход. evidence-ready-for-synthetic-hand-off появляется только у record с известным pin, scope и воспроизводимым artifact. repair-source-pin говорит, что фраза может быть разумной, но её источник нельзя зафиксировать исторически. hold-claim оставляет работу незавершённой, потому что наблюдение не несёт заявленного вывода.
Это различие уменьшает стоимость ревью. Вместо спора «достаточно ли верить странице» reviewer видит конкретную недостающую связь. Для versionless card нужно найти versioned primary source. Для marketing copy — заменить promise наблюдаемой формулировкой или получить измерение. Для signature overreach — сузить statement до authorship либо добавить независимый evidence факта. Ни один status не является наказанием; это маршрут, который экономит следующий поиск.
| Откуда | Куда | Проверка перехода | Стоп-сигнал |
|---|---|---|---|
| publication | representation | есть immutable pin или дата capture | только current URL |
| representation | observation | есть locator и точный artifact | пересказ без фрагмента |
| observation | claim | scope не шире факта | обещание результата |
| claim | decision | добавлены условия применения | перенос на неизвестный контекст |
Проверка сравнения до того, как появляются метрики
Сравнение двух источников начинается не с подсчёта ссылок, а с совместимости объектов. Сначала спросите: это две версии одного вида документа или разные классы evidence? Совпадают ли scope, термин и наблюдаемый объект? Сравнение response header с рекламным обещанием может быть полезно как контраст, но не как подтверждение. Если хотя бы одна карточка не прошла status, агрегирование результатов лишь делает неопределённость более аккуратно оформленной.
import { compareFixedResearchRecords } from './upgrade-2025-11.mjs';
const result = compareFixedResearchRecords(
'pinned-representation-v1',
'versionless-compatibility-v1',
);
console.log(result.decision);
// 'stop-before-comparison' — second record has no source pinЗдесь нет числа «качества источника». Сравнение останавливается потому, что один record нельзя повторно адресовать к версии. Это правильный отказ: он сохраняет источник неопределённости, а не маскирует его средним баллом. Если требуется оценка вариантов, после pin и observation нужно отдельно описать критерий решения. В текущем fixture такого критерия нет, значит никакая рекомендация продукта не выдаётся.
Пять диагностических вопросов к сильному выводу
- Назвать уровень. Это publication, representation, observation, claim или уже decision?
- Проверить адресуемость. Можно ли открыть именно тот release, PDF, commit или capture, который использован?
- Проверить literal. Есть ли locator и artifact, а не только удобный пересказ section?
- Сравнить силу. Не добавляет ли statement слово, которого нет в наблюдении: «всегда», «безопасно», «поддерживает»?
- Выбрать stop. Если связь не доказана, вернуть hold или repair вместо технической рекомендации.
Граница механизма и следующий шаг
Модель не делает веб неизменяемым и не обнаруживает ложь автоматически. Она также не заменяет эксперта предметной области: primary source может корректно описывать протокол, но не содержать нужный operational факт. Её сила в дисциплине разделения. Каждый раз, когда вывод звучит сильнее, чем наблюдение, status даёт место для явного stop. В условиях технического блога это честнее и быстрее, чем заполнять пробел авторитетной интонацией.
Возьмите одну ссылку из текущего черновика и подпишите четыре объекта: publication, representation, claim, decision. Затем удалите любой один из них и посмотрите, что перестанет быть проверяемым. Часто исчезает не URL, а связь между строкой источника и практическим советом. Её и нужно восстановить через source pin, locator, scope или отдельный эксперимент. После этого текст может стать короче, но у него появится механизм, который читатель способен воспроизвести.
Проверяемые источники
- RFC 9110: HTTP Semantics, §8.8 validator fields — версия: RFC 9110, June 2022, immutable RFC publication. RFC 9110 определяет ETag и Last-Modified как validator fields для selected representation и описывает их сильные и слабые свойства. Граница: Документ не назначает ETag релизной версией и не интерпретирует смысл содержимого за автора статьи.
- W3C Verifiable Credentials Data Model v2.0 — версия: W3C Recommendation, 15 May 2025, dated immutable publication. VC Data Model фиксирует границу: криптографическая verification не оценивает truth encoded claims. Граница: Recommendation не доказывает правильность конкретной интеграции и не заменяет independent evidence.
- W3C PROV-DM: The PROV Data Model — версия: W3C Recommendation, 30 April 2013, dated immutable publication. PROV-DM различает entity и activity; это основание для раздельных полей publication, representation и reading activity. Граница: Стандарт не задаёт шкалу доверия или автоматический verdict исследовательскому выводу.