Цифровой реестр и регистрационные дела

Статья 14. Сведения о рекордсмене

Регистрационная запись может содержать: имя; фамилию; иные идентифицирующие сведения; страну; регион; организацию — если применимо; Holder ID.

Статья 15. Holder ID

Для цифровой идентификации рекордсмена может использоваться Holder ID. Он позволяет связывать несколько зарегистрированных достижений с одним субъектом без необходимости дублировать все сведения в каждой записи.

Статья 16. Категория достижения

Каждая запись должна иметь классификационную категорию. Категория должна позволять: поиск; фильтрацию; статистический анализ; применение соответствующих правил; сравнение достижений.

Статья 17. Наименование достижения

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

Статья 18. Формула рекорда

Для количественных рекордов рекомендуется структурировать результат: что измеряется + в каком количестве + за какой период/условие + кем/где установлено. Это позволяет избежать неоднозначности естественного языка.

Статья 19. Значение результата

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

Статья 20. Единица измерения

Единица измерения хранится отдельно от числового значения. Например: value: 104.5, unit: kg.

Статья 21. Временные параметры

При необходимости фиксируются: дата; время; продолжительность; часовой пояс; период измерения.

Статья 22. Географические параметры

При необходимости фиксируются: страна; субъект; населённый пункт; место; координаты — если это необходимо и допустимо.

Статья 23. Дата достижения и дата регистрации

Должны различаться: Achievement Date — дата установления достижения; Registration Date — дата его регистрации RURECORD. Это принципиально разные события.

Статья 24. Статус

Каждая запись должна иметь актуальный статус. Например: REGISTERED, CONFIRMED, UNDER REVIEW, SUSPENDED, SUPERSEDED, REVOKED, RESTORED, ARCHIVED.

Статья 25. История статусов

Изменение текущего статуса не должно уничтожать предыдущий статус. Фиксируется: прежний статус; новый статус; дата; основание; Decision ID; ответственное лицо или система.

Статья 26. Регистрационное дело

Каждое дело получает собственный внутренний идентификатор: Case ID или может быть непосредственно связано с Record ID.

Статья 40. Audit

Содержит сведения о проведённых аудитах.

Статья 41. Review

Содержит материалы пересмотров.

Статья 42. Status History

Содержит последовательность изменений статуса.

Статья 43. Archive

Содержит архивные версии документов и материалов, подлежащих сохранению.

Статья 44. Связь с EVS-001

Доказательства не обязательно должны физически находиться внутри одного файлового контейнера регистрационного дела. В архитектуре EVS регистрационное дело может содержать ссылки на соответствующие Evidence ID. При этом должна сохраняться возможность однозначно установить связь между доказательством и конкретным регистрационным делом.

Статья 45. Реестр как индекс

Цифровой реестр может рассматриваться как индекс регистрационной системы. Упрощённо: РЕЕСТР → показывает, что зарегистрировано. РЕГИСТРАЦИОННОЕ ДЕЛО → показывает, почему зарегистрировано. EVS → хранит/обеспечивает доказательную основу. DRP → представляет цифровой паспорт зарегистрированного достижения.

Статья 46. Публичная карточка

Для каждого публичного рекорда может формироваться цифровая карточка. Она должна содержать основные сведения: Record ID; название; рекордсмен; результат; дата; место; категория; статус; дата регистрации; сведения о подтверждении; ссылка на цифровой паспорт — если предусмотрено режимом доступа.

Статья 47. Проверка регистрации

Публичная карточка должна позволять пользователю проверить, что Record ID действительно существует в реестре.

Статья 48. QR-код

Для зарегистрированных рекордов может использоваться QR-код, ведущий на официальную страницу записи. QR-код не является самостоятельным доказательством. Он является средством навигации к цифровой записи.

Статья 49. Машинная проверка

Для цифровых сервисов рекомендуется предоставить API или иной стандартизированный механизм проверки Record ID.

Статья 55. Версия реестра

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

Статья 56. Стабильность данных

При обновлении программного обеспечения существующие Record ID и исторические данные должны сохранять возможность интерпретации.

Статья 57. Дата публикации

Для публичной записи может фиксироваться Published At.

Статья 58. Дата обновления

Также фиксируется Updated At. Это позволяет определить актуальность отображаемой информации.

Статья 59. Дата последнего подтверждения

Отдельно может фиксироваться Last Confirmed At. Она не должна смешиваться с датой последнего технического обновления страницы.

Статья 60. Дата последнего аудита

При наличии аудита: Last Audited At.

Статья 61. Актуальность

Актуальность записи определяется не только датой изменения веб-страницы. Она определяется текущим статусом и историей регистрационных событий.

Статья 69. Централизованный реестр

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

Статья 70. Гибридная архитектура

Рекомендуется архитектура: операционная БД + защищённое файловое/объектное хранилище + EVS + криптографический слой + при необходимости блокчейн-якорь.

Статья 71. Резервное хранение

Реестр и критические регистрационные данные должны иметь резервные копии.

Статья 72. Географическое резервирование

Для критической инфраструктуры может применяться резервирование в независимой инфраструктуре или нескольких географических зонах.

Статья 73. Защита от потери

Архитектура должна обеспечивать восстановление: реестра; регистрационных дел; DRP; доказательных связей; истории статусов.

Статья 74. Аварийное восстановление

RURECORD рекомендуется иметь план Disaster Recovery Plan. Он должен определять порядок восстановления критических сервисов после: аппаратного сбоя; программной ошибки; потери данных; киберинцидента; повреждения инфраструктуры.

Статья 75. Независимость домена и реестра

Публичный веб-сайт является интерфейсом доступа к реестру. Он не должен быть единственным местом хранения регистрационных данных.

Статья 76. Принцип «сайт не равен реестру»

Если веб-сайт временно недоступен, это не должно означать утрату регистрационной записи.

Статья 77. Долговременное хранение

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

Статья 78. Форматы данных

Структурированные регистрационные данные рекомендуется хранить в машиночитаемом формате. Например: JSON; XML; SQL; иные стандартизированные форматы.

Статья 79. Независимость от CMS

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

Статья 83. Связь DRP и регистрационного дела

DRP является структурированным цифровым представлением зарегистрированного достижения. Регистрационное дело является более широким объектом. Следовательно: DRP ⊂ Registration Case в функциональном смысле.

Статья 84. Версионность регистрационного дела

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

Статья 85. Неизменяемые события

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

Статья 86. Журнал событий

Рекомендуется вести Registration Event Log. Он может содержать: Event ID; Event Type; Record ID; Actor; Timestamp; Previous State; New State; Related Document; Decision ID.

Статья 87. Actor ID

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

Статья 88. Автоматические события

События, сформированные программным обеспечением, должны отличаться от действий человека. Например: Actor Type: HUMAN или Actor Type: SYSTEM.

Статья 89. Администратор не должен иметь возможности незаметно переписать историю

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

Статья 105. Логическое удаление

При необходимости исключения объекта из текущего представления может использоваться soft delete при сохранении архивной записи.

Статья 106. Физическое уничтожение

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

Статья 107. Цифровая подпись записи

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

Статья 108. Проверяемый Record

Публичная запись может предоставлять пользователю возможность проверить: Record ID → Status → Registration Date → Current DRP Version.

Статья 109. Проверяемый DRP

DRP может содержать QR-код или уникальный URL, позволяющий перейти к соответствующей записи реестра.

Статья 110. Проверяемость паспорта достижения

Паспорт достижения не должен быть единственным источником информации о регистрации. Его подлинность должна проверяться через Record ID или иной официальный идентификатор.

Статья 111. Подлинность цифрового документа

Проверка может осуществляться по: Record ID; QR-коду; цифровой подписи; хешу; официальной записи реестра.

Статья 112. Архивная запись

Даже если рекорд получил статус SUPERSEDED или REVOKED, его историческая запись может оставаться доступной с соответствующей маркировкой.

Статья 113. Историческая ценность

Архивные рекорды могут представлять самостоятельную историческую ценность для системы RURECORD.

Статья 131. Регистрационное дело как доказательство процедуры

Регистрационное дело должно позволять восстановить последовательность: заявление → проверка → доказательства → экспертиза → решение → регистрация → сопровождение → аудит.

Статья 132. Полнота дела

Регистрационное дело считается структурно полным, если в нём присутствуют все обязательные объекты, предусмотренные процедурой соответствующей категории.

Статья 133. Неполное дело

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

Статья 134. Контроль комплектности

Система может автоматически проверять наличие обязательных элементов. Например: Application ✓; Evidence ✓; Expert Opinion ✓; Decision ✓; DRP ✓.

Статья 135. Статус комплектности

Для внутреннего использования может применяться: COMPLETE; INCOMPLETE; REQUIRES REVIEW.

Статья 136. Автоматизированная проверка

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

Статья 137. Человеческий контроль

Автоматическая проверка не заменяет содержательную проверку регистрационного дела.

Статья 138. Искусственный интеллект

RURECORD может использовать AI для: классификации; поиска дубликатов; анализа метаданных; обнаружения аномалий; автоматической проверки комплектности; технического анализа. Однако окончательное регистрационное решение не должно основываться исключительно на автоматическом выводе AI без предусмотренного процедурой человеческого контроля.

Статья 139. Аномалии

Система может автоматически выявлять: одинаковые доказательства; одинаковые даты; совпадающие результаты; противоречивые данные; необычные изменения; подозрительные изменения файлов.

Статья 140. Аномалия не равна нарушению

Автоматическое обнаружение аномалии является основанием для проверки, но не доказательством недостоверности.

Статья 141. Реестр и доверие

Основная функция цифрового реестра заключается не только в публикации списка рекордов. Он должен обеспечивать: идентифицируемость + проверяемость + трассируемость + историческую сохранность.

Статья 153. Архивный пакет

Для особо значимых достижений может формироваться отдельный архивный пакет, содержащий: Record ID; DRP; Decision; Evidence manifest; хеши; историю статусов; ключевые экспертные заключения.

Статья 154. Evidence Manifest

Evidence Manifest представляет собой структурированный перечень доказательств. Для каждого объекта может указываться: Evidence ID; тип; описание; дата; размер; хеш; статус; связь с Record ID.

Статья 155. Manifest и доказательства

Evidence Manifest не заменяет сами доказательства. Он обеспечивает их структурированный учёт и контроль целостности.

Статья 156. Регистрационный манифест

Для всего регистрационного дела может формироваться Registration Manifest. Он содержит перечень основных цифровых объектов дела.

Статья 157. Пример цифровой связи

Record ID: RUR-2026-000123; DRP ID: DRP-RUR-2026-000123; Case ID: CASE-2026-000456; Evidence: EV-0001, EV-0002, EV-0003; Expert Opinion: EXP-0007; Decision: DEC-0009; Audit: AUD-0012.

Статья 158. Цифровая проверка

Пользователь, получивший паспорт достижения, может проверить: Record ID → официальный реестр → актуальный статус → DRP. При наличии соответствующего доступа уполномоченный пользователь может пройти дальше: DRP → Evidence → Expert Opinion → Decision.

Статья 159. Уровни доступа

Рекомендуется использовать как минимум: Public; Verified User; Registrar; Expert; Auditor; Administrator; Commission.

Статья 160. Публичный доступ

Публичный пользователь получает сведения, предназначенные для общего распространения.

Статья 161. Верифицированный доступ

Верифицированный пользователь может получить дополнительные сведения в случаях, предусмотренных правилами RURECORD.

Статья 162. Регистраторский доступ

Регистратор получает доступ к регистрационным материалам в пределах своей компетенции.

Статья 163. Экспертный доступ

Эксперт получает только те материалы, которые необходимы для конкретного экспертного задания.

Статья 164. Аудиторский доступ

Аудитор получает доступ к материалам, необходимым для проведения проверки.

Статья 165. Административный доступ

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

Статья 166. Комиссионный доступ

Члены соответствующего органа получают материалы, необходимые для принятия решений.

Статья 167. Разделение данных и файлов

Рекомендуется разделять: структурированные данные и неструктурированные файлы. Например: База данных → метаданные. EVS → доказательства.

Статья 168. Масштабируемость

Архитектура должна позволять добавлять новые категории достижений без изменения фундаментального идентификатора Record ID.

Статья 169. Расширяемые поля

Новые типы достижений могут использовать дополнительные атрибуты. Например: speed; distance; weight; duration; height; quantity при сохранении общей модели.

Статья 170. Семантическая структура

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

Статья 171. Цифровая идентичность достижения

В совокупности: Record ID + DRP + Evidence Manifest + Status History формируют цифровую идентичность зарегистрированного достижения.

Статья 172. Неотчуждаемость регистрационной истории

История регистрации должна оставаться связанной с Record ID независимо от смены: владельца сайта; программной платформы; доменного интерфейса; визуального оформления.

Статья 173. Архивный принцип

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

Статья 174. Целостность регистрационной системы

Цифровой реестр, DRP, EVS и регистрационные дела должны рассматриваться как единая взаимосвязанная информационная система.

Статья 175. Основной принцип BR-010

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

Статья 176. Второй фундаментальный принцип

Реестр фиксирует факт и статус регистрации; регистрационное дело фиксирует основания и историю регистрации.

Статья 177. Третий фундаментальный принцип

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

Статья 178. Четвёртый фундаментальный принцип

Изменение данных не должно уничтожать историю регистрационных событий.

Статья 179. Пятый фундаментальный принцип

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

Статья 180. Итоговая архитектура BR-010

В окончательном виде цифровая регистрационная архитектура RURECORD может быть представлена следующим образом: RURECORD → DIGITAL REGISTRY (Record ID) и REGISTRATION CASE (Application ID, Case ID, Evidence, EVS, Expert Opinion, Decision) → DRP → STATUS HISTORY → AUDIT / REVIEW → ARCHIVE.

Статья 181. Единая цифровая модель RURECORD и заключительное положение

С учётом BR-003 — BR-010 архитектура проекта формирует последовательную систему: BR-003 (Принципы признания) → BR-004 (Регистрация национального достижения) → BR-005 (Регистрационные документы + DRP) → BR-006 (Цифровая идентификация и сопровождение) → BR-007 (Доказательная база) → BR-008 (Экспертная оценка) → BR-009 (Аудит и пересмотр) → BR-010 (Цифровой реестр и регистрационные дела).

BR-010 формирует фундамент цифровой регистрационной инфраструктуры RURECORD. В рамках настоящего стандарта зарегистрированное достижение рассматривается не как отдельная веб-страница, паспорт достижения или строка в базе данных, а как единый цифровой регистрационный объект, обладающий собственной идентичностью, доказательной основой, регистрационным делом, цифровым паспортом, историей решений и контролируемым жизненным циклом. Таким образом: Record ID идентифицирует достижение; DRP представляет его цифровой паспорт; EVS обеспечивает доказательную основу; Expert Opinion фиксирует профессиональную оценку; Decision фиксирует регистрационное решение; Digital Registry обеспечивает официальный цифровой учёт; Registration Case сохраняет историю формирования и сопровождения регистрации; Audit / Review обеспечивают последующую проверяемость; Archive обеспечивает историческую преемственность. Именно эта совокупность образует цифровую регистрационную систему RURECORD, в которой ценность зарегистрированного достижения определяется не только самим результатом, но и возможностью спустя годы восстановить и проверить идентичность, доказательства, процедуру, решение и историю его признания.