Демонстрационная логика проверки показывает, как цифровой документ становится не просто файлом, а проверяемым цифровым событием с доказательством, маршрутом, DLT-фиксацией, архивной квитанцией и статусом.

Verification (проверка) — это процесс подтверждения того, что документ или событие действительно существует, не было изменено, имеет корректный хэш, связано с доверенным событием, зафиксировано в DLT и принято в архивный контур.

Страница Verification не является сервисом раскрытия содержания документов. Ее задача — объяснить и продемонстрировать логику проверки доказательств без необходимости передавать полный документ всем участникам сети.

Коротко за 30 секунд

Verification нужна для того, чтобы участник мог проверить не обещание и не скан документа, а доказательную цепочку: документ, хэш, событие, DLT-квитанцию, архивную квитанцию и происхождение данных.

В демонстрационной модели пользователь вводит идентификатор документа, DLT-квитанцию, архивную квитанцию или хэш. Система проверяет, совпадает ли хэш, существует ли Trust Event, подтверждена ли DLT-фиксация, принят ли архивный пакет и не нарушена ли цепочка происхождения.

Итог: документ можно проверить как цифровой факт, не раскрывая лишние персональные, коммерческие или служебные данные.

Что такое Verification

Verification — это проверочный слой архитектуры доверия. Он отвечает на практические вопросы:

существует ли документ или цифровое событие;
совпадает ли хэш проверяемого документа с ранее зафиксированным хэшем;
какое доверенное событие связано с документом;
была ли DLT-квитанция сформирована и подтверждена;
принят ли архивный пакет в Арбитражный Архив;
какой статус имеет документ, событие или квитанция;
можно ли восстановить происхождение данных и маршрут события;
есть ли признаки изменения, подмены или нарушения цепочки доверия.

Что можно проверить

Объект проверки	Что подтверждается
Документ	Хэш, версия, тип документа, связь с событием и статус проверки.
Trust Event	Кто совершил действие, какой объект затронут, когда событие создано, какой trace_id и route_id присвоены.
DLT Receipt	Факт фиксации доказательства в распределенном реестре, временная метка, подтверждения узлов и статус.
Archive Receipt	Факт приема архивного пакета, идентификатор архива, срок хранения и связь с DLT-квитанцией.
Provenance	Происхождение данных: источник, действие, субъект, версия и связь с предыдущими объектами.
Route / Trace	Маршрут цифрового события и путь прохождения через доверенные шлюзы.
Status	Текущий статус: VALID, WARNING, INVALID, EXPIRED, REVOKED, UNKNOWN.

Что Verification не делает

Важно отделять проверку доказательства от раскрытия содержания документа. Verification не должен автоматически раскрывать полный документ, персональные данные, коммерческую тайну, служебные сведения или архивный пакет без правового основания.

Проверочный слой показывает статус и доказательства: хэш, идентификаторы, квитанции, временные метки, статусы и связи. Доступ к содержанию документа должен регулироваться отдельными правилами доступа, полномочиями и правовыми основаниями.

Демонстрационная логика проверки

Демонстрационная проверка может работать по простой цепочке:

Document / Hash → Trust Event → Proof → DLT Receipt → Archive Receipt → Verification Result

Русская формула:

Документ / хэш → доверенное событие → доказательство → DLT-квитанция → архивная квитанция → результат проверки

Пользователь вводит document_id, dlt_receipt_id, archive_receipt_id или hash.
Система находит связанное доверенное цифровое событие (Trust Event).
Проверяется хэш документа или контрольного пакета.
Проверяется криптографическое доказательство: алгоритм, подпись, timestamp и signer_id.
Проверяется DLT-квитанция: event_id, hash, anchored_at, confirmations и статус.
Проверяется архивная квитанция: archive_package_id, hash, received_at, retention_period и статус.
Проверяется provenance: источник, субъект, действие, версия и связь с предыдущими событиями.
Проверяется маршрут: trace_id, route_id, доверенный шлюз и путь прохождения.
Формируется Verification Result с общим статусом и детализацией проверок.

Входные данные демонстрационной проверки

Поле	Назначение
document_id	Идентификатор цифрового документа.
hash	Криптографический отпечаток документа или контрольного пакета.
event_id	Идентификатор доверенного цифрового события.
dlt_receipt_id	Идентификатор DLT-квитанции.
archive_receipt_id	Идентификатор архивной квитанции.
trace_id	Идентификатор сквозного пути события.
route_id	Идентификатор маршрута между системами или шлюзами.

Результаты проверки

Статус	Что означает
VALID	Цепочка проверки корректна: хэш совпадает, DLT-квитанция подтверждена, архивная квитанция действительна.
WARNING	Критической ошибки нет, но есть ограничение: например, отсутствует часть provenance, задержка архивирования или неполный набор подтверждений.
INVALID	Нарушена проверка: хэш не совпадает, квитанция не найдена, подпись недействительна или статус отклонен.
EXPIRED	Срок действия проверяемого статуса, полномочия или credential истек.
REVOKED	Полномочие, credential или статус были отозваны.
UNKNOWN	Проверяемый объект не найден или недостаточно данных для вывода.

Пример Verification Result

{
  "verification_id": "VER-2026-000001",
  "checked_at": "2026-01-10T10:05:00+06:00",
  "status": "VALID",
  "document_id": "DOC-2026-000001",
  "event_id": "EVT-2026-000001",
  "dlt_receipt_id": "DLT-2026-000001",
  "archive_receipt_id": "ARCH-2026-000001",
  "checks": {
    "document_hash": "MATCH",
    "proof": "VALID",
    "dlt_receipt": "CONFIRMED",
    "archive_receipt": "ACCEPTED",
    "provenance": "CONSISTENT",
    "route": "TRACEABLE"
  },
  "warnings": [],
  "errors": []
}

Verification API: демонстрационный контур

В будущем демонстрационная логика может быть оформлена как публичный или ограниченный Verification API. API не обязан раскрывать содержание документа. Его задача — принимать идентификатор или квитанцию и возвращать проверяемый статус.

Метод	Endpoint	Назначение
POST	/verify/document	Проверка документа или его хэша.
POST	/verify/dlt-receipt	Проверка DLT-квитанции.
POST	/verify/archive-receipt	Проверка архивной квитанции.
POST	/verify/chain	Проверка полной цепочки document → DLT → Archive.
GET	/verify/status/{receipt_id}	Получение статуса по идентификатору квитанции.
GET	/schemas	Получение опубликованных схем данных.

Почему проверка не требует раскрытия документа

Один из ключевых принципов архитектуры доверия — разделение содержания документа и доказательства его существования. Полный документ может храниться в системе-источнике или в архивном контуре с контролем доступа. Для проверки может быть достаточно хэша, квитанции, статуса, временной метки и цепочки provenance.

Это позволяет подтвердить факт существования, неизменность и статус цифрового события без передачи всего содержания документа каждому проверяющему участнику.

Связь Verification с DLT

DLT фиксирует доказательство события: хэш, временную метку, идентификатор события, статус и подтверждения узлов. Verification использует DLT-квитанцию как один из элементов проверки. Если DLT-квитанция подтверждена, это означает, что доказательство события было зафиксировано в распределенном реестре и не должно быть незаметно изменено одним участником.

Связь Verification с Арбитражным Архивом

Арбитражный Архив отвечает за правовую и долговременную сохранность доказательного пакета. Verification проверяет архивную квитанцию, чтобы подтвердить, что пакет был принят, имеет идентификатор хранения, связан с DLT-квитанцией и находится в корректном статусе.

Связь Verification с W3C-профилем

W3C-профиль помогает сделать проверку понятной для внешних систем. DID может использоваться для идентификации субъекта или сервиса, Verifiable Credentials — для проверки полномочий, JSON-LD — для структурированного описания данных, PROV — для происхождения события, Data Integrity — для криптографической целостности.

Связь Verification с sovereign infrastructure

Проверка должна быть не только логически корректной, но и доступной. Поэтому verification-сервисы зависят от суверенной инфраструктуры: ЦОДов, trust nodes, шлюзов, маршрутов, мониторинга, доступности и безопасности. Сайт sovereign.satcom.kg объясняет инфраструктурную сторону этой модели.

Что видит пользователь в демонстрационном интерфейсе

Блок интерфейса	Содержание
Поле ввода	document_id, hash, dlt_receipt_id или archive_receipt_id.
Общий статус	VALID, WARNING, INVALID, EXPIRED, REVOKED или UNKNOWN.
Проверка хэша	Совпадает ли текущий хэш с зафиксированным.
DLT-блок	Событие, временная метка, подтверждения узлов и статус.
Архивный блок	Архивная квитанция, статус хранения, срок и связь с DLT.
Provenance-блок	Источник, действие, субъект, версия и цепочка происхождения.
Маршрут	trace_id, route_id и доверенные шлюзы.
Ограничения доступа	Какие сведения скрыты или требуют правового основания.

Пример объяснения результата для пользователя

Документ проверен.
Статус: VALID.
Хэш документа совпадает с ранее зафиксированным хэшем.
DLT-квитанция подтверждена.
Архивная квитанция действительна.
Происхождение данных не нарушено.
Маршрут события восстановлен по trace_id.
Содержание документа не раскрыто в рамках публичной проверки.

Verification: проверка цифровых документов и квитанций