Methodology

Жизненный цикл доверенного цифрового события

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

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

Объяснение за 30 секунд

Методология trust.asiainfo.kg описывает, как обычный цифровой документ или действие превращается в проверяемое доказательство.

Сначала система устанавливает субъект: человек, организация, государственный орган, сервис или устройство. Затем проверяются его полномочия. После этого создается документ или цифровое событие. Система формирует хэш, временную метку и доказательство действия. Далее доказательство фиксируется в DLT-сети (Distributed Ledger Technology — технология распределенного реестра), а архивный пакет передается в Арбитражный Архив.

В результате появляется проверяемая цепочка: субъект — полномочие — документ — доказательство — DLT-запись — архивная квитанция — проверка.

Что такое доверенное цифровое событие

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

Примеры таких событий:

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

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

Базовая формула методологии

Субъект → идентификация → полномочия → документ → метаданные → хэш → доказательство → provenance → DLT → Архив → проверка

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

Жизненный цикл доверенного цифрового события

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

Шаг	Этап	Что происходит
1	Идентификация субъекта	Система определяет, кто действует: пользователь, организация, ИП, государственный орган, сервис, устройство или узел сети.
2	Проверка полномочий	Проверяется право действовать: должность, роль, доверенность, статус, лицензия, право подписи или право доступа.
3	Создание документа или события	Создается цифровой документ или фиксируется действие: договор, акт, счет, запись, запрос, решение, уведомление.
4	Структурирование данных	Документ получает реквизиты, метаданные, идентификаторы, связи с субъектами, маршрут и контекст действия.
5	Криптографическое доказательство	Формируются хэш, подпись, временная метка и доказательство целостности.
6	Provenance — происхождение	Фиксируется история происхождения: кто создал, какая система участвовала, на каком основании, от какой версии произошло событие.
7	Передача через Trust Gateway	Событие проходит доверенный шлюз: форматную проверку, проверку полномочий, маршрута и готовности к фиксации.
8	Фиксация в DLT	В DLT передается не сам документ, а доказательство события: хэш, время, тип действия, идентификаторы и подтверждение узлов.
9	Архивирование	Архивный пакет или контрольные данные передаются в Арбитражный Архив для правовой сохранности.
10	Формирование квитанций	Система формирует DLT-квитанцию и архивную квитанцию, которые связывают документ, событие и доказательство.
11	Проверка	Уполномоченная сторона может проверить документ, хэш, статус, маршрут, DLT-запись и архивную квитанцию.
12	Аналитика и наблюдаемость	Агрегированные события могут использоваться для мониторинга, аудита, отчетности, управления рисками и аналитики T+1.

Методология по слоям доверия

Identity Layer — слой идентичности

На этом уровне определяется субъект действия. Идентичность может включать доменное имя, учетную запись, DID (Decentralized Identifier — децентрализованный идентификатор), цифровой паспорт, Face ID, MFA (Multi-Factor Authentication — многофакторная аутентификация) или WebAuthn / passkey.

Authority Layer — слой полномочий

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

Document Layer — слой документа

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

Proof Layer — слой доказательства

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

Provenance Layer — слой происхождения

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

DLT / Trust Layer — слой распределенного доверия

DLT-сеть фиксирует доказательство события в неизменяемом виде. В DLT не передается сам документ; в сеть передаются только доказательства: хэш, timestamp, event_id, trace_id, тип события и подтверждение узлов.

Legal / Archive Layer — правовой архивный слой

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

Verification Layer — слой проверки

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

Что хранится и что не хранится

Компонент	Что хранит	Что не должен хранить
Система-источник	Рабочий документ, процесс, статусы, версии, бизнес-логику.	Не должна быть единственным источником доказательности.
Crypto / Proof Layer	Хэш, подпись, timestamp, proof envelope, контроль целостности.	Не хранит полный бизнес-процесс вместо системы-источника.
DLT-сеть	Хэш, идентификатор события, временную метку, тип события, trace_id, подтверждение узлов.	Не хранит документы, персональные данные, коммерческую или государственную тайну.
Арбитражный Архив	Архивные пакеты, квитанции, метаданные, контрольные данные, правовую историю хранения.	Не заменяет рабочие системы документооборота.
Verification API	Проверочный ответ: статус, совпадение хэша, наличие DLT- и архивной квитанции.	Не раскрывает содержание документа без правового основания.

Примеры применения методологии

• Бизнес-документ: Компания создает договор или акт. Система проверяет полномочия подписанта, формирует хэш, фиксирует доказательство в DLT, передает архивный пакет и выдает квитанции.
• Государственный документ: Государственный орган формирует решение, уведомление или акт. Событие получает маршрут, trace_id, доказательство, DLT-запись и архивную квитанцию.
• Проверяемое полномочие: Организация или должностное лицо получает цифровое полномочие в формате Verifiable Credential. Проверяющая сторона может подтвердить статус без ручного запроса.
• Судебное или арбитражное доказательство: Сторона предоставляет не просто файл, а цепочку доказательств: хэш, provenance, DLT-квитанцию, архивную квитанцию и историю проверки.
• Аналитическое событие: Агрегированные и обезличенные события могут использоваться для мониторинга процессов, рисков и цифровой аналитики без раскрытия содержания документов.

Карточки для страницы

Identity Сначала определяется субъект: человек, организация, орган, сервис или узел сети.	Authority Затем проверяются полномочия: кто и на каком основании имеет право действовать.
Proof Документ получает криптографическое доказательство: хэш, подпись, timestamp и контекст.	Provenance Система фиксирует происхождение события: кто, что, когда, где и на основании чего создал.
DLT В распределенный реестр передается доказательство факта, а не содержание документа.	Archive Арбитражный Архив обеспечивает правовую сохранность и проверку через время.
Verification Любая уполномоченная сторона может проверить статус, хэш, маршрут и квитанции.