using Ban.Sdaid.Notation.Documents;
using Ban.Sdaid.Notation.Glossary;
using Ban.Sdaid.Icd.Glossary.Terms;
using Ban.Sdaid.Icd.Ui.Pages;
namespace Ban.Sdaid.Icd.Vision
{
/// <summary>
/// Видение СОК — «Сервис оцифровки информационных карт документов Библиотеки
/// Российской академии наук». Постановка задачи: зачем сервис, что он делает,
/// где его границы.
/// <para>
/// Icd в именах проекта спеки, сборки и пространств имён — техническое имя проекта
/// (Information Card Digitization), не обозначение сервиса: заказчик знает «Сервис» и «СОК».
/// </para>
/// <para>
/// Источник — ТЗ заказчика (<c>temp/ТЗ-Оцифровка-ИК.htm</c>, разделы 1–4.1.2) и решения,
/// принятые при проработке UI-прототипов. ТЗ на момент переноса обрывается на п. 4.1.2 —
/// незакрытые места помечены как открытые вопросы.
/// </para>
/// </summary>
public class IcdVision : IVisionDocument
{
public static string _refName = "видение Сервиса";
public string Name => "Сервис оцифровки информационных карт";
public string Description =>
@"Постановка задачи на разработку **СОК** — сервиса оцифровки информационных карт документов
Библиотеки Российской академии наук. Сервис переводит архив бумажных форм информационных карт
(~50 тыс. штук) в электронные документы: изображение → распознавание → извлечение атрибутов →
верификация оператором → электронная ИК → выгрузка в АБИС.";
public string Version => "0.3";
public string Status => "draft";
public string[] Comments => new[]
{
"2026-08-05. Первичный перенос из ТЗ заказчика и из решений, принятых при проработке прототипов UI.",
"2026-09-02. Условное обозначение сокращено с СОИК до СОК; полное наименование прежнее.",
};
// ═══════════════════════════════════════════════════════════════════════
// 1. Общие сведения
// ═══════════════════════════════════════════════════════════════════════
public static string V_S1_General = """
## 1. Общие сведения
**Полное наименование:** Сервис оцифровки информационных карт документов Библиотеки
Российской академии наук.
**Условное обозначение:** Сервис, СОК.
**Заказчик:** Библиотека Российской академии наук (БАН).
**Разработчик:** Библиотека технологий.
""";
public static string V_S2_Purpose = $"""
## 2. Назначение и цели
Сервис предназначен для перевода архива бумажных форм {GlossaryAnchors.RefTo<InformationMap>("информационных карт")} документов
библиотечного фонда в форму электронных документов.
Сервис должен решать задачи:
1) Ввод и предварительная обработка изображений информационных карт. Загрузка изображения с диска, по ссылке или с камеры. Выравнивание, обрезка фона, устранение искажений геометрии и т.д.
2) Распознавание текста на изображениях информационных карт. Распознавание печатного и рукописного текста на изображении.
3) Сегментация изображения и извлечение атрибутов информационной карты. Определение вида ИК, выделение полей данных (Инв. номер, Автор, Год, …), извлечение атрибутом ИК, идентификация документа.
4) Оценка достоверности распознавания информационной карты. Формирование и отображение метрики достоверности распознавания ИК для пользователя.
5) Верификация и корректировка данных пользователем. Отображение для пользователя исходного изображения и результатов распознавания и привязки к документу с возможность корректировки пользователем и сохранения пакета обработки.
6) Формирование и сохранение электронной информационной карты в базе данных Сервиса. Создание на основании пакетов обработки электронных информационных карт в БД Сервиса.
7) Экспорт информационной карты. Экспорт выборки информационных карт из БД Сервиса в текстовый формат, пригодный для загрузки в автоматизированную библиотечную информационную систему Заказчика ({GlossaryAnchors.RefTo<Abis>("АБИС")}).
""";
// ═══════════════════════════════════════════════════════════════════════
// 3. Объект автоматизации
// ═══════════════════════════════════════════════════════════════════════
public static string V_S3_Object = $"""
## 3. Характеристика объекта автоматизации
Объект автоматизации — процесс оцифровки архива бумажных информационных карт документов
фонда БАН. Накоплен архив ~50 тыс. ИК, подлежащих внесению в АБИС.
При передаче экземпляра фонда в обработку хранитель прикладывает к документу бланк информационной карты. В процессе обрабоки бланк информационной карты запоняется вручную специалистом отдела консервации и реставрации и возвращается после обработки вместе с документом в фонд.
Далее хрнитель вручную переносит рукописные результаты обработки из печатного бланка информационной карты в электронный документ информационной карты в АБИС.
Ручной перенос результатов обработки трудоёмкий процесс, не поспевает за поступлением карт, поэтому необработанные печатные бланки ИК накапливаются: на сегодня их
около 50 тыс.
### Что такое информационная карта
Документ, фиксирующий факт проведения, состояние и результаты {GlossaryAnchors.RefTo<DocumentProcessing>("обработки документа")} библиотечного фонда. Заводится на каждую обработку документа, поэтому у одного экземпляра фонда может быть несколько карт.
Содержит:
- библиографическое описание документа;
- сведения о материальной основе и её состоянии;
- сведения о рекомендуемых и выполненных мероприятиях стабилизации состояния;
- сведения об исполнении — дата, эксперт, ФИО исполнителя.
Заполняется специалистами:
- хранитель вносит библиографическое описание — распечатанное из АБИС либо написанное от руки;
- специалист отдела консервации и реставрации вписывает ход и результаты обработки документа от руки.
Вид карты определяется {GlossaryAnchors.RefTo<DocumentKind>("видом документа")} (издание или рукопись и подвид) и задаёт состав полей и количество страниц формы.
Идентификация карты от её вида не зависит и во всех случаях состоит из четырёх значений: шифр, инвентарный номер, место хранения, дата. Первые три опознают экземпляр фонда, дата различает события обработки одного документа.
### Обработка экземпляра фонда
Работы по оценке и стабилизации состояния документов библиотечного фонда. Выполняются специалистами отдела консервации и реставрации.
Состоят из этапов:
- биологический контроль;
- гигиеническая обработка;
- описание материальной основы и её повреждений;
- химические анализы;
- рекомендации по стабилизации и обработке;
- измерение, изготовление контейнера из картона или конверта из плёнки;
- размещение в контейнере;
- возврат в фонд.
Порядок этапов не меняется.
Факт проведения и результат работ фиксируются в информационной карте: на каждую обработку документа заводится отдельная карта.
### Виды документов и виды ИК
Для разных видов документов формируются **разные виды ИК** — отличаются составом полей,
количеством и назначением страниц формы. Для следующих видов документов существуют свои виды информационных карт:
- Рукописи;
- Издания:
- Листовой документ;
- Книга;
- Вложение.
Идентификация карты при этом единая для всех видов: шифр, инвентарный номер, место хранения и дата.
### Участники процесса
- **Хранитель** — отвечает за сохранность документа. При передаче документа в обработку создаёт
и прикладывает к нему печатную форму ИК с заполненным библиографическим описанием. После
возврата документа в фонд вручную вносит данные из печатной формы в АБИС.
- **Реставратор** (специалист отдела консервации и реставрации) — проводит экспертизу и обработку
документа, результаты этапов вносит в печатную форму ИК вручную.
""";
// ═══════════════════════════════════════════════════════════════════════
// 4. Требования к сервису
// ═══════════════════════════════════════════════════════════════════════
public static string V_S4_Requirements = $@"
## 4. Требования к сервису
### 4.1. Требования к Сервису в целом
#### 4.1.1. Требования к структуре и функционированию
Сервис должен быть реализован как **клиент-серверное приложение**. Клиентская часть — веб-приложение
(тонкий клиент), работающее в среде стандартных браузеров; доступ по защищённому протоколу
HTTPS. Локальная установка программного обеспечения на рабочие станции пользователей не
требуется.
Разрешение монитора автоматизированного рабочего места — не менее **1920 × 1080 пикселей
(Full HD)**.
#### 4.1.2. Взаимодействие сервиса со смежными системами и пользователями
Сервис будут использовать пользователи ролей:
- хранитель:
- для ввода изображений ИК и информации, идентифицирующей изображения;
- для проверки, корректировки и обогащения данных ИК, распознанных на изображениях;
- для экспорта реестра ИК в файл формата, пригодный для загрузки в {GlossaryAnchors.RefTo<Abis>("АБИС")}.
- администратор:
- для конфигурации процесса обработки ИК.
Сервис взаимодействует с {GlossaryAnchors.RefTo<Abis>("АБИС")} **в одну сторону**: формирует файл
информационных карт для загрузки в АБИС. Загрузку файла выполняет принимающая сторона средствами
АБИС; данные из АБИС Сервис не получает.
Получение реестров из АБИС и привязка карт к её идентификаторам в состав Сервиса не входят —
это возможная доработка (раздел 6).
### 4.2. Требования к функциям Сервиса
Функциональность модуля должна обеспечивать следующий процесс обработки бумажной формы информационной карты.
```mermaid
flowchart LR
A[[Бумажная ИК]] --> B[4.2.1<br/>Ввод изображений]
B --> C[[Пакет ввода<br/>в очереди]]
C --> D[4.2.2<br/>Предобработка]
D --> E[4.2.3<br/>Проверка и корректировка]
E --> F[[Электронная ИК]]
F --> G[[Файл для АБИС]]
```
1. **Ввод изображений ИК**: хранитель снимает кадры бумажной ИК, Сервис формирует пакет ввода и размещает его в очереди обработки.
2. **Предобработка**: данные пакета ввода автоматически обрабатываются Сервисом, выполняется коррекция и сегментация изображений, распознавание текста, извлечение атрибутов ИК.
3. **Проверка и корректировка**: хранитель проверяет и подтверждает результаты распознавания, после чего создаётся электронная ИК в базе Сервиса.
4. **Выгрузка в АБИС**: вместе с созданием карты Сервис формирует файл для загрузки в АБИС. Отдельного действия хранитель не выполняет.
#### 4.2.1. Ввод изображений ИК
Ввод идёт **без плана**: пользователь снимает или загружает кадры страниц карты подряд, ничего
не выбирая заранее. Что за карта введена и какой странице формы соответствует кадр, определяется на этапе обработки пакета кадров.
Сервис должен обеспечивать:
- ввод изображения тремя способами, одновременно доступными пользователю: съёмка камерой рабочего
места (с живым превью), загрузка файла с диска, загрузка по ссылке;
- присвоение кадру очередного номера и изменение порядка кадров перетаскиванием;
- накопление кадров в {GlossaryAnchors.RefTo<InputPacket>("пакете ввода")} с возможностью просмотреть,
заменить и удалить любой кадр до завершения ввода;
- ограничение размера пакета настраиваемым пределом (по умолчанию пять кадров) с сообщением
при попытке добавить кадр сверх него;
- завершение ввода карты одной командой и немедленный переход к вводу следующей, с отображением
списка созданных за смену пакетов (номер, время) и возможностью вернуться к любому из них.
Идентификация карты при вводе не вводится: шифр, инвентарный номер и дата вписаны на самой форме
и извлекаются при обработке, а недостающее пользователь вносит на проверке.
Завершённый пакет автоматически поступает в очередь обработки — отдельного действия постановки
в очередь от пользователя не требуется.
Прототип экрана ввода — {SdaidAnchors.RefTo<InputDataPage>()}:
{SdaidHtml.LinkTo<InputDataPage>("input-card.html", "Открыть прототип в новой вкладке")}
{SdaidHtml.IframeOf<InputDataPage>("input-card.html", 720)}
#### 4.2.2. Предобработка изображений ИК
Выполняется Сервисом автоматически, без участия пользователя, после поступления пакета в очередь.
Состав действий:
- нормализация изображений: выравнивание, обрезка фона, устранение геометрических искажений,
подготовка изображения к распознаванию;
- распознавание печатного и рукописного текста;
- определение вида ИК и формы бланка, распределение кадров по страницам этой формы;
- сегментация изображения на области, соответствующие полям формы;
- извлечение значений атрибутов ИК и привязка каждого значения к его источнику — странице формы
и области на ней;
- извлечение идентификации карты — шифра, инвентарного номера и даты — наравне с прочими полями;
исправленное пользователем повторной обработкой не перезаписывается;
- расчёт {GlossaryAnchors.RefTo<RecognitionConfidence>("уверенности распознавания")} для каждого поля и для пакета в целом.
Результат предобработки не подменяет решение пользователя: он предъявляется как предположение,
подлежащее проверке. Пакет, в котором вид ИК определить не удалось, разобрать невозможно, ждёт вмешательства пользователя.
#### 4.2.3. Проверка и корректировка результатов предобработки
Пользователь работает с очередью пакетов: поиск по номеру пакета, шифру, инвентарному номеру, заглавию; фильтры по состоянию пакета и по принадлежности. Пакет берётся в работу — явным выбором
из очереди либо действием, выдающим первый свободный, — и может быть возвращён.
У пакета четыре состояния: **в очереди**, **проверка**, **завершён**, **ошибка**. Прежняя модель
с пятью подтверждаемыми этапами упразднена: проверка полей, сверка экземпляра и сверка экспертизы
оказались одной работой, разделённой на три подтверждения.
{GlossaryAnchors.RefTo<Verification>("Проверка")} идёт на двух вкладках.
Все действия выполняются на {SdaidAnchors.RefTo<ProcessingQueuePage>()}: слева очередь пакетов
с поиском и фильтрами, справа — вкладки выбранного пакета.
{SdaidHtml.LinkTo<ProcessingQueuePage>("queue.html", "Открыть прототип в новой вкладке")}
##### 4.2.3.1. Пакет ввода
Показываются опознанный вид ИК, форма бланка и состав её страниц; каждой странице формы сопоставлен кадр изображения. Если страниц в форме больше, чем кадров, предлогается доснять недостающие кадры. По клику на миниатюре кара Кадр открывается в полном
размере с лупой и переключателем «оригинал / обработанное».
Пользователь может переснять, удалить кадр, переназначить ему страницу или снять назначение.
Кадр, не отнесённый ни к одной странице, — лишний: он не распознаётся, удалять его необязательно.
Правка кадров, участвующих в разборе, делает результаты распознавания недействительными: пакет
возвращается в очередь по команде пользователя, после чего предлагается взять следующий.
Если вид ИК определён неверно, пользователь отклоняет его и может указать верный — пакет уходит
на повторную обработку с этим контекстом. Если верный вид неизвестен и опознать нечего, пакет
помечается как Ошибка.
{SdaidHtml.IframeOf<ProcessingQueuePage>("queue.html", 720)}
##### 4.2.3.2. Проверка карты
Отдельным блоком над полями бланка — реквизиты самой карты, которых на бумаге нет: **место хранения**
выбирается из справочника, по умолчанию берётся из профиля пользователя.
Значения полей показываются так, как они размещены на бланке — страница, раздел, подпись поля, —
с уверенностью распознавания у каждого. Значение можно исправить; распознанное при этом сохраняется
и остаётся видимым, а повторная обработка внесённое пользователем не затирает.
Выбор поля показывает страницу-источник с подсвеченной областью, из которой получено значение;
лупа позволяет разобрать мелкий текст.
Часть полей бланка — не текст, а **отметка в клетке**: материалы переплёта, повреждения, степень
повреждения, роль эксперта. Такие поля заполняются выбором из перечня допустимых значений, а не
вводом с клавиатуры; перечни ведёт заказчик, и в АБИС уходит принятый у него код значения. Где
на бланке отмечено несколько клеток сразу, выбирается несколько значений. Если распознанного
значения в перечне нет, поле остаётся незаполненным, а прочитанное показывается рядом: выбрать
верное — работа пользователя. Переданные заказчиком перечни —
{SdaidAnchors.RefTo<Ban.Sdaid.Icd.Domain.Cards.Template.Vocabularies.VocabularyCatalog>()}.
**Состав экспертов** сверяется со справочником; отсутствующего специалиста можно внести в справочник,
не покидая проверки.
Обязательные поля выделены так, чтобы незаполненное было видно сразу. Какие поля обязательны, зависит
от вида документа и задаётся настройкой: для книги это десять полей — место хранения, шифр, инвентарный
номер, дата, заглавие, место издания, издательство, год издания, количество страниц и формат. Где на
бланке принято записывать отсутствие значения явно, пользователь так и делает: «Б.м.» вместо места
издания, «Б.и.» вместо издательства. Полный перечень —
{SdaidAnchors.RefTo<Ban.Sdaid.Icd.Domain.Cards.Template.RequiredAttributes>()}.
Проверка завершается созданием электронной {GlossaryAnchors.RefTo<InformationMap>("информационной карты")}.
Той же командой Сервис формирует файл для загрузки в АБИС — отдельного действия выгрузки пользователь
не выполняет (4.2.4). Создание недоступно, пока не заполнены обязательные поля: неполной карты
Сервис не заводит. Это
единственный контроль полноты, сколько кадров в пакете и все ли страницы сняты, значения не имеет —
Сервис предзаполнит то, что распознал, остальное может внести пользователь.
Если сведений не хватает, работу можно отложить: внесённые значения остаются в пакете ввода,
пользователь берёт следующий пакет, а к отложенному возвращается через очередь, когда сведения
найдутся.
Прототип — вкладка «Проверка карты» на {SdaidAnchors.RefTo<ProcessingQueuePage>()}:
{SdaidHtml.LinkTo<ProcessingQueuePage>("queue.html#card", "Открыть прототип в новой вкладке")}
{SdaidHtml.IframeOf<ProcessingQueuePage>("queue.html#card", 720)}
#### 4.2.4. Реестр ИК и выгрузка в АБИС
Созданные электронные ИК накапливаются в реестре Сервиса. Сервис должен обеспечивать:
- просмотр реестра ИК со сведениями о документе (наименование, инвентарный номер, автор, год и место
издания), дате обработки и о пользователе, выполнившем ввод;
- поиск, сортировку и фильтрацию, в том числе по состоянию выгрузки;
- формирование файла текстового формата, пригодного для загрузки в АБИС.
Идентификаторов документов и карт АБИС в файле нет: Сервис экземпляр фонда не опознаёт
(возможная доработка — раздел 6). Сопоставить карту с записью АБИС предстоит принимающей
стороне — по шифру и инвентарному номеру, которые в карте обязательны.
Файл формируется **вместе с созданием карты**, без отдельного действия пользователя: отбор выборки
и работа с файлом обмена — не занятие для библиотечного специалиста. Ручное формирование остаётся
как административное действие, если файл утрачен. Сервис файл кладёт, а не отправляет: загрузка
в АБИС выполняется вне Сервиса.
Раз файл появляется без участия человека, нужно место, где видно, что он появился: **журнал
выгрузок** показывает сформированные файлы — когда, из каких карт, в каком формате, где лежат
и что в них написано. Отдельно журнал предупреждает о картах, для которых файл не сформировался:
обычный ход работы таких карт не оставляет, и это единственная причина открыть журнал без повода.
Экран административный, хранителю в нём делать нечего.
Прототип журнала — {SdaidAnchors.RefTo<ExportLogPage>()}:
{SdaidHtml.LinkTo<ExportLogPage>("exports.html", "Открыть прототип в новой вкладке")}
{SdaidHtml.IframeOf<ExportLogPage>("exports.html", 720)}
Прототип реестра ИК — {SdaidAnchors.RefTo<InformationCardsPage>()}:
{SdaidHtml.LinkTo<InformationCardsPage>("cards.html", "Открыть прототип в новой вкладке")}
{SdaidHtml.IframeOf<InformationCardsPage>("cards.html", 720)}
#### 4.2.5. Конфигурирование процесса обработки ИК
Администратор должен иметь возможность настраивать обработку без изменения кода Сервиса:
- ведение форм документов: страницы бланка, разделы и размещение полей;
- ведение состава видов ИК: атрибуты, их обязательность и типы значений;
- ведение справочников: места хранения, специалисты, виды документов;
- настройка предела числа кадров в пакете;
- настройка профиля пользователя: место хранения по умолчанию, условия отбора пакетов при взятии
в работу.
";
public static string V_S5_Boundaries = $"""
## 5. Границы системы
**Входит в систему:**
- ввод изображений ИК (камера, диск, ссылка) и формирование пакетов;
- автоматическая обработка: нормализация, распознавание, извлечение атрибутов, оценка достоверности;
- рабочее место верификации результатов распознавания;
- хранение электронных ИК;
- формирование файлов ИК в формате для загрузки в АБИС и журнал таких файлов.
**Не входит:**
- **заведение новых информационных карт** — Сервис только оцифровывает существующие бумажные
формы; ведение электронных карт в {GlossaryAnchors.RefTo<Abis>("АБИС")} остаётся за библиотекой;
- реестр экземпляров фонда и привязка карты к экземпляру — возможная доработка (раздел 6);
- собственно обработка документа (биоконтроль, реставрация, стабилизация) — работа библиотеки;
- загрузка выгруженных данных в АБИС — выполняется средствами АБИС на стороне заказчика.
""";
public static string V_S55_Roadmap = $"""
## 6. Перспективы развития
Перечисленное ниже в состав Сервиса не входит и может быть выполнено отдельной
доработкой.
### Привязка карты к экземпляру фонда
**Что можно реализовать.** Получение реестра экземпляров фонда из АБИС; поиск экземпляра
в этом реестре по библиографическому описанию, распознанному в карте; привязку карты
к найденному экземпляру. Вместе с ними — предъявление кандидатов с оценкой совпадения,
чтобы решение Сервиса можно было оспорить; заведение документа, когда подходящего
в реестре нет; реестр экземпляров как экран
({SdaidAnchors.RefTo<Ban.Sdaid.Icd.Requirements.FR_010_DocumentRegistry>()}).
**Как Сервис работает без этого.** Карта уходит в АБИС без идентификатора документа.
Сопоставить её с записью АБИС предстоит принимающей стороне — по шифру и инвентарному
номеру: они обязательны, значит присутствуют в каждой карте.
**Почему это не входит в состав.** Оцифровка бумажного архива от привязки не зависит:
карта остаётся полной и пригодной к передаче и без ссылки на запись АБИС. Отказ снимает
целое направление обмена — приём данных из чужой системы — и нетривиальный поиск
по описанию, где ошибочная привязка хуже её отсутствия.
**Что появится вместе с доработкой.** Связь карты с экземпляром фонда в модели данных,
сама сущность экземпляра, экран реестра, а также вопрос о том, как заведённый в Сервисе
документ попадает в АБИС.
**Отступление от ТЗ.** Опознание документа названо в задачах технического задания
(раздел 2, задача 3), а двусторонний обмен с АБИС — в требованиях к взаимодействию
со смежными системами. Исключение их из состава требует согласования с заказчиком.
Исходная формулировка задания:
> Сервис должен взаимодействоать с АБИС:
>
> - получать из АБИС актуальные реестры:
> - экземпляры фонда;
> - электронные информационные карты, созданные в АБИС.
>
> Актуальный реестр документов АБИС должен использоваться для корректной привязки ИК,
> создаваемой в Сервисе, к идентификаторам экземпляра фонда в АБИС.
> Актуальный реестр ИК АБИС должен использоваться для корректной привязки ИК,
> выгружаемых из Сервсиа в файл для загрузки в АБИС, к идентификаторам ИК в АБИС.
""";
public static string V_S6_ImageRequirements = """
## 7. Требования к обрабатываемым изображениям
Сервис обеспечивает обработку изображений ИК, подготовленных с соблюдением требований:
| Параметр | Требование |
|---|---|
| Формат и размер документа | не более A4 (210 × 297 мм) |
| Условия получения изображения | наличие светодиодного источника освещения для компенсации недостаточного внешнего освещения |
| Технические параметры | оптическое разрешение сенсора камеры не менее 4608 × 3456 пикселей (16 Мп) |
Поддерживаемые форматы файлов при загрузке с диска или по ссылке: JPG, PNG, TIFF, PDF, TXT.
""";
public static string V_S7_OpenQuestions = """
## 8. Открытые вопросы видения
Перенесены из ТЗ и проработки прототипов; закрываются по мере уточнения у заказчика.
| № | Вопрос |
|---|---|
| OQ-V-1 | ТЗ обрывается на п. 4.1.2. Требования к надёжности, безопасности, производительности, а также состав ролей и прав доступа не заданы |
| OQ-V-2 | Состав полей раздела «Мероприятия стабилизации» не определён |
| OQ-V-3 | Состав раздела «Материальная основа» описан только для переплёта; для листовых документов и свитков состав неизвестен и, вероятно, зависит от вида ИК |
| OQ-V-4 | Конкретный формат выгрузки в АБИС не назван — в ТЗ сказано лишь «текстовый формат, пригодный для загрузки» |
| OQ-V-5 | Структура справочника мест хранения (фонд → отдел → шкаф → полка) не задана |
| OQ-V-6 | Порядок раздачи пакетов операторам: ручной выбор из очереди либо автоматическое назначение — требует согласования с организацией работ в БАН |
| OQ-V-7 | Требования к развёртыванию Сервиса и способ реализации распознавания подлежат уточнению; проектные решения по внутреннему устройству будут оформлены отдельными ADR |
| ~~OQ-V-8~~ | Снят: документы в Сервисе не создаются — реестра экземпляров в составе Сервиса нет (раздел 6) |
""";
}
}