Реестр и Relay¶

Оба модуля работают с мастер-данными организации (а не с данными отдельного гражданина), поэтому RLS у них нет — защита выставлена на уровне HTTP по правам.

Ring System · R1 — реестр услуг¶

Реестр отвечает на управленческий вопрос: насколько полон инвентарь государственных услуг, насколько он цифровой и насколько близок к принципу once-only? Каждый паспорт услуги соответствует словарю CPSV-AP.

Статус паспорта¶

Статус	Значение
`draft`	Черновик — в публичном каталоге не виден
`published`	Опубликован — отдаётся через `/api/v1/catalog/*`
`archived`	В архиве

Уровни проактивности¶

По эстонской модели — от простой информации до автоматической услуги:

Уровень	Значение
`information`	Опубликована только информация
`online`	Заявления принимаются онлайн
`once_only`	Уже имеющиеся данные повторно не запрашиваются
`proactive`	Услуга предлагается без заявления гражданина

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

Доказательства и once-only¶

registry_evidences — каталог доказательных документов. У каждой записи есть признак in_khur: есть ли эти сведения в государственном обмене данными.

Связь «паспорт ↔ доказательство» несёт признак from_citizen: требуют ли документ у гражданина, или ведомство само получает его из системы.

Нарушение принципа once-only

Каждый случай, где in_khur = true и from_citizen = true, — нарушение once-only: у гражданина просят то, что у государства уже есть. GET /api/v1/registry/once-only перечисляет такие случаи и по годовой частоте оценивает нагрузку на граждан.

Версии и delta¶

Каждая публикация создаёт версию паспорта (registry_service_versions). Поля Delta* хранят разницу с базовой линией до реинжиниринга — отрицательное значение означает улучшение (меньше шагов, меньше времени).

Эндпоинты¶

registry.view — чтение, registry.manage — запись. admin покрывает оба.

Метод	Путь	Право
`GET`	`/api/v1/registry/overview`	view
`GET`	`/api/v1/registry/catalog`	view
`GET`	`/api/v1/registry/once-only`	view
`GET`	`/api/v1/registry/services` · `/{id}`	view
`GET`	`/api/v1/registry/services/{id}/versions`	view
`GET`	`/api/v1/registry/services/{id}/once-only`	view
`GET`	`/api/v1/registry/evidences` · `/life-events`	view
`POST` `PUT` `DELETE`	`/api/v1/registry/services…`	manage
`POST`	`/api/v1/registry/services/{id}/publish` · `/archive`	manage
`PUT`	`/api/v1/registry/services/{id}/evidences`	manage
`POST` `PUT` `DELETE`	`/api/v1/registry/evidences…`	manage
`POST` `DELETE`	`/api/v1/registry/life-events…`	manage

UI: Admin → Registry (/admin/registry, /admin/registry/services, /admin/registry/evidences).

Relay — маршрутизация запросов между платформами¶

Relay принимает срочные запросы от вышестоящей платформы, рассылает их нижестоящим, следит за SLA и собирает ответы.

flowchart LR
    U[Upstream platform] -->|POST /relay/requests| R[(Relay)]
    R -->|assignment| D1[Downstream A]
    R -->|assignment| D2[Downstream B]
    D1 -->|respond| R
    D2 -->|respond| R
    R -->|forward-up webhook| U

Статусы¶

Запрос: received → dispatched → in_progress → fulfilled (либо overdue, rejected).

Назначение: pending → acknowledged → in_progress → done (либо overdue, rejected).

Контроль SLA¶

Механизм	Поведение
Напоминания	Нижестоящим уходят напоминания на 75% и 90% окна SLA
Эскалация	Через дополнительный период после просрочки назначение автоматически эскалируется руководителю
Timeline	`received` · `dispatched` · `reminded` · `escalated` · `responded` · `fulfilled` · `overdue` · `breach_notified` · `forwarded_up`

Отсрочка эскалации

В базовом модуле RelayEscalateGrace равен 2 минутам — это значение шаблона. В production его удлиняют под реальный SLA.

Эндпоинты¶

Метод	Путь	Право
`POST`	`/api/v1/relay/webhook`	— (вызов платформы-партнёра)
`POST`	`/api/v1/relay/requests`	manage
`POST`	`/api/v1/relay/assignments/{id}/respond`	manage
`POST`	`/api/v1/relay/requests/{id}/forward`	manage
`GET`	`/api/v1/relay/overview` · `/requests` · `/requests/{id}`	view
`GET` `POST` `DELETE`	`/api/v1/relay/platforms…`	view / manage
`GET` `POST` `DELETE`	`/api/v1/relay/routes…`	view / manage

RelayRoute — правило маршрутизации service_code → platform со своим SLA для каждой цели.

UI: Admin → Relay (/admin/relay, /admin/relay/config, /admin/relay/{id}).

Как защищены ingest/respond

В этой эталонной реализации записи requests и assignments защищены JWT + relay.manage. В production правильная форма — вызовы вышестоящих и нижестоящих платформ через шлюз (m2m OAuth).