Документация Сибирь.Документы 0.2.0

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

Подготовлено правообладателем — ООО «ФИИ», ИНН 5402076457. Редакция от 29 сентября 2026 года.

ОПИСАНИЕ ФУНКЦИОНАЛЬНЫХ ХАРАКТЕРИСТИК

программы для ЭВМ «Сибирь.Документы», версия 0.2.0

Правообладатель: ООО «Финансовый искусственный интеллект», ОГРН 1235400001870.

1. Назначение. Программа предназначена для хранения документов организации, их индексации и поиска по ним с выдачей ответа на естественном языке со ссылкой на документ-источник, а также для расшифровки звукозаписей в текст. Развертывается в инфраструктуре эксплуатанта. В поставляемой конфигурации программа не обращается к внешним сервисам и не передает обрабатываемые материалы за пределы контура эксплуатанта, работа в закрытом контуре без доступа к сети «Интернет» предусмотрена и является штатным режимом.

2. Функциональные возможности.

2.1. Прием документов через программный интерфейс с ограничением размера загружаемого материала. Тип файла определяется по сигнатуре содержимого, а не по расширению имени.

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

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

2.4. Построение индекса по фрагментам двумя способами одновременно: по словам и по векторному представлению текста. Результаты обоих способов объединяются при поиске.

2.5. Выдача ответа на вопрос на естественном языке. Ответ сопровождается ссылкой на документ-источник и заголовок раздела, из которого он взят.

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

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

2.8. Расшифровка звукозаписей и звуковых дорожек видеозаписей в текст с сохранением разметки по времени.

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

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

2.11. Разметка говорящих в записи с несколькими участниками.

2.12. Выдача результата расшифровки в виде текста, субтитров и документа.

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

2.14. Разграничение доступа по ключам с разделением прав администратора и заказчика. Проверка прав объявлена на уровне маршрутизатора программного интерфейса, а не в отдельных обработчиках. В базе данных хранится не ключ, а его хеш.

2.15. Шифрование секретов заказчика в базе данных симметричным алгоритмом с ключом, выводимым из основного секрета установки.

2.16. Программный интерфейс управления с автоматически формируемым описанием в открытом формате.

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

3. Чего в версии 0.2.0 нет. Графического интерфейса пользователя: продукт встраивается программным интерфейсом. Распознавания текста на изображении: скан без текстового слоя дает пустой результат, а не ошибку, и такие документы следует готовить заранее. Автоматического удаления материалов по истечении срока хранения: удаление выполняет эксплуатант собственными средствами. Средств миграции схемы базы данных между версиями.

4. Требования к среде. Язык реализации Python версии 3.12. Хранилище PostgreSQL версии 16. Операционная система семейства Linux. Для расшифровки звука требуется декодер мультимедиа, устанавливаемый средствами операционной системы.

5. Состав экземпляра. 33 файла исходного текста, 3 910 строк. Устанавливаемый дистрибутив siberia_dokumenty-0.2.0-py3-none-any.whl, 77 748 байт, контрольная сумма SHA-256 ee08caa43df4ce590a86b47257655b44941b4e1b42351b7d52bacff5e61f617e (исправленная сборка, см. п. 5.1). Сборка дистрибутива повторяется побайтно на чистой выписке из репозитория.

5.1. Исправленная сборка. С 29.09.2026 для экспертной проверки подготовлена исправленная сборка 0.2.0, файл siberia_dokumenty-0.2.0-py3-none-any.whl, 77 748 байт, SHA-256 ee08caa43df4ce590a86b47257655b44941b4e1b42351b7d52bacff5e61f617e. Исправлено: в сборке, поданной 24.09.2026, операции базы знаний не выполнялись и отвечали кодом 500, потому что при отделении продукта от исходной платформы функция сеанса базы данных потеряла декоратор, а три функции работы с колонкой вектора и модуль шлюза языковой модели не были перенесены. Все они восстановлены из исходного текста платформы. В пакет включена проверка установки siberia_dokumenty.proverit_ustanovku, на которую ссылаются руководства и которой в поданной сборке не было. Версия и состав функций не менялись, 33 файла исходного текста, 3 910 строк. Сборка повторяется побайтно.

Сборка, поданная 24.09.2026, SHA-256 06ff7ccae7a1ae5d50c15c9ec7d6b6e41a0fddfdf3a788672294d9c2a67c26db, выдается по запросу.

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

Сибирь.Документы — руководство по установке

Версия 0.2.0. Документ 5 описи заявления в реестр.

Каждому шагу соответствует проверка siberia_dokumenty.proverit_ustanovku. Руководство, которое

нельзя выполнить и проверить, это рассказ, поэтому проверка печатает список с причиной

отказа по каждому пункту, а не одно слово «готово».

В конце документа отдельный раздел: что из написанного здесь проверено прогоном, а что

написано по коду и на живой установке не проверялось.

1. Что ставится

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

Без файла модели эмбеддингов векторный поиск отключается и поиск идет по словам с учетом

русской морфологии. Без ffmpeg речевой слой отказывает с причиной, а работа с документами

не затрагивается.

2. Требования к оборудованию

3. Установка

3.1. Окружение и колесо

python3.12 -m venv /opt/sibir-dokumenty/venv

/opt/sibir-dokumenty/venv/bin/pip install siberia_dokumenty-0.2.0-py3-none-any.whl

Продукт тянет свои зависимости сам. Перечень с лицензиями в

13-storonnie-komponenty.md, он снимается с установленного окружения, а не из файла

зависимостей.

3.2. База данных

sudo -u postgres createuser --pwprompt dokumenty

sudo -u postgres createdb --owner dokumenty dokumenty

Проверьте, что в pg_hba.conf для этого пользователя стоит scram-sha-256 либо md5,

а не ident: при ident приложение не пройдет по паролю.

Расширение pgvector не обязательно. Если оно есть, векторы хранятся колонкой этого типа,

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

старте и в обоих случаях работает.

3.3. Настройки

Создайте файл .env рядом с рабочим каталогом:

SECRET_KEY=<не менее 32 знаков>

API_ADMIN_KEY=<не менее 24 знаков>

DATABASE_URL=postgresql+asyncpg://dokumenty:<пароль>@localhost:5432/dokumenty

DATA_DIR=/var/lib/sibir-dokumenty

KNOWLEDGE_MODEL_PATH=/opt/sibir-dokumenty/models/embedder.onnx

KNOWLEDGE_VOCAB_PATH=/opt/sibir-dokumenty/models/vocab.txt

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

Это сделано намеренно: значения по умолчанию у ключей доступа означали бы, что установка

с забытым файлом настроек работает и выглядит защищенной.

Речевой слой настраивается ключами с приставкой RECH_:

RECH_MODEL=large-v3

RECH_MODELI_DIR=/opt/sibir-dokumenty/models/rech

RECH_RABOCHIY_DIR=/var/lib/sibir-dokumenty/rech-rabota

RECH_KARTA=true

RECH_VRAM_NUZHNO=4500

RECH_ZHDAT_MINUT=20

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

поиска и выдачи фрагментов-источников, а ответ на естественном языке не собирается. Задать

его можно ключом GATEWAY_URL, и адрес должен указывать на сервис в контуре

эксплуатирующей организации.

3.4. Создание схемы

SOZDAT_SHEMU=1 /opt/sibir-dokumenty/venv/bin/uvicorn siberia_dokumenty.api.app:app \

--host 127.0.0.1 --port 8080

После строки «Application startup complete.» сервер останавливается Ctrl+C. Схему создает

обработчик запуска сервера, поэтому импорт модуля командой python -c ее не создает.

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

лишь сообщает о ее состоянии в /health. Причина: приложение, поднятое с опечаткой в

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

Пять таблиц: customers, kb_collections, kb_documents, kb_chunks, kb_queries.

3.5. Запуск

/opt/sibir-dokumenty/venv/bin/uvicorn siberia_dokumenty.api.app:app \

--host 0.0.0.0 --port 8080

Единица systemd:

[Unit]

Description=Сибирь.Документы

After=network.target postgresql.service

[Service]

User=sibir

WorkingDirectory=/opt/sibir-dokumenty

EnvironmentFile=/opt/sibir-dokumenty/.env

ExecStart=/opt/sibir-dokumenty/venv/bin/uvicorn siberia_dokumenty.api.app:app \

--host 0.0.0.0 --port 8080

Restart=on-failure

[Install]

WantedBy=multi-user.target

4. Проверка установки

/opt/sibir-dokumenty/venv/bin/python -m siberia_dokumenty.proverit_ustanovku \

--adres http://127.0.0.1:8080

Проверяются: наличие продукта и совпадение версии пакета с версией в коде, подъем настроек,

обязательные и речевые зависимости, файл модели эмбеддингов, ffmpeg, доступность базы и

наличие схемы, ответы /health и /about, и отдельно то, что маршрут базы знаний закрыт

ключом. Открытый маршрут это не отсутствие проверки, а отсутствие защиты, и увидеть это

надо при установке, а не при аудите заказчика.

Код возврата 0 означает, что пройдено все обязательное. Необязательное печатается отдельной

пометкой и на код не влияет.

5. Обновление

Остановить службу, поставить новое колесо в то же окружение, запустить службу.

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

не поддержано ничем, кроме ручных команд. Это ограничение версии 0.2.0, и оно названо

здесь, а не умолчано.

6. Удаление

systemctl disable --now sibir-dokumenty

rm -rf /opt/sibir-dokumenty

Данные остаются: каталог DATA_DIR и база dokumenty удаляются по решению

эксплуатирующей организации.

7. Что проверено прогоном, а что нет

Разделение обязательное: руководство, где проверенное и непроверенное перемешаны, читается

как полностью проверенное.

Проверено 19.09.2026 прогоном в изолированном окружении, где диалогового ядра нет

физически:

• установка колеса в чистое окружение и подъем всех модулей продукта;
• отказ настроек без SECRET_KEY и API_ADMIN_KEY;
• запуск через uvicorn и ответы по адресу: /health дает 200 и без базы, /about дает

наименование, версию 0.2.0, ИНН, ОГРН и класс 05.10, маршрут базы знаний без ключа

отвечает 401;

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

Написано по коду и на живой установке не проверялось:

• создание пользователя и базы в PostgreSQL, строки pg_hba.conf: на машине сборки

Доступен только сторонний экземпляр PostgreSQL. Новая тестовая база в нем не создавалась.

• создание схемы ключом SOZDAT_SHEMU=1 и работа с базой: следует из предыдущего пункта;
• единица systemd: собрана по образцу, на живой машине не запускалась;
• поведение при наличии и отсутствии расширения pgvector;
• установка на ALT Linux и Astra Linux. Протоколы совместимости с двумя российскими

операционными системами не снимались.

Сибирь.Документы — руководство администратора и пользователя

Версия 0.2.0. Документ 4 описи заявления в реестр.

Продукт встраивается в информационные системы заказчика через программный интерфейс.

Собственного интерфейса пользователя в версии 0.2.0 нет, и это сказано здесь прямо, а не

обойдено: пользователь работает с продуктом из своей системы, а не из его окна.

Часть I. Руководство администратора

1. Ключи доступа

Два ключа задаются при установке и без них продукт не стартует.

Ключ передается заголовком X-API-Key. Обращение без ключа или с неизвестным ключом получает

код 401. Ключ заказчика с чужим идентификатором заказчика в пути запроса получает 403. Чужая

коллекция под своим идентификатором заказчика отвечает 404, как несуществующая: по коду

ответа нельзя узнать, существует ли она. Это сделано намеренно.

Ключ заказчика в базе не хранится: в колонке customers.api_key_hash лежит только его SHA-256.

Восстановить ключ по базе нельзя, утерянный ключ заменяется записью SHA-256 нового ключа.

От SECRET_KEY ключи заказчиков не зависят. Как завести заказчика, сказано в п. 8.

2. Заказчики и разделение данных

Заказчик это единица разделения. Документы, коллекции, индексы и журнал запросов каждого

заказчика отделены от чужих на уровне запросов к базе.

Исходный файл документа кладется по пути {DATA_DIR}/customers/{идентификатор}/knowledge/

под именем из SHA-256 своего содержимого. Имя проверяется на соответствие шестидесяти

четырем шестнадцатеричным знакам, поэтому увести путь за пределы каталога заказчика нельзя.

Повторная загрузка того же файла второй копии не создает.

3. Коллекции документов

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

коллекций, например по подразделениям или по видам документов.

Имя коллекции от 1 до 255 знаков, описание до 2000.

4. Документы

При загрузке документ разбирается, режется на фрагменты и индексируется двумя способами:

словесным поиском с учетом русской морфологии и векторным поиском на модели эмбеддингов.

Если файла модели нет, работает только словесный поиск, и продукт сообщает об этом при

проверке установки.

Предельный размер файла задается настройкой MAX_UPLOAD_MB, по умолчанию 20 МБ.

5. Поиск и ответ

POST /api/customers/{заказчик}/knowledge/{коллекция}/query

{"question": "вопрос", "top_k": 4}

question от 1 до 2000 знаков, top_k от 1 до 20, по умолчанию берется из настроек.

Ответ содержит найденные фрагменты со ссылками на документы-источники. Если релевантных

фрагментов нет, продукт так и говорит, а не собирает ответ из ничего. Это основное

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

проверить его нечем.

Если задан адрес шлюза языковой модели, по найденным фрагментам собирается связный ответ.

Если не задан, выдаются сами фрагменты. Модель в поставку не входит, ее размещает

эксплуатирующая организация в своем контуре.

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

Журнал нужен, чтобы видеть вопросы, на которые продукт не отвечает.

6. Расшифровка записей

Речевой слой вызывается из кода, отдельного маршрута в версии 0.2.0 у него нет.

      from siberia_dokumenty.rech import rasshifrovat_fayl
      from siberia_dokumenty.settings import settings
      
      itog = rasshifrovat_fayl(put_k_zapisi, katalog_vyhoda, settings,
                               s_golosami=True, zhurnal=print)
      

На выходе пять файлов: текст, разметка, субтитры, документ и разбор. Документ отдается для

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

Два отказа встроены намеренно.

Файл короче, чем обещает его собственный заголовок, дает отказ с обоими числами, а не

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

отчет сказал «готово».

Запись длиннее двух минут, из которой не вышло ни одной реплики, дает отказ до записи

файлов. Повод тот же: пустые файлы и слово «готово» неотличимы от успеха, а на деле это

битый звук, не та дорожка или не тот канал.

7. Эксплуатация

/health отвечает кодом 200 и без базы намеренно. Проверка живости, которая падает вместе

с базой, бесполезна ровно в тот момент, когда ее спрашивают: администратору надо отличить

«приложение упало» от «приложение живо, база недоступна».

8. Загрузка и запуск

Программа не имеет собственного окна. В память ее загружает сервер uvicorn, который устанавливается вместе с ней как зависимость. Пользователь и информационная система заказчика управляют программой запросами HTTP к ее программному интерфейсу (п. 9), речевой слой вызывается из кода на Python (п. 9.4). Команды ниже приведены для Linux и окружения из раздела установки (/opt/sibir-dokumenty/venv). Графа «Проверка» говорит, что выполнено 29.09.2026 на исправленной сборке 0.2.0, а что нет. База данных в прогоне SQLite, на PostgreSQL прогон не выполнялся.

Ответ программы на запуск без обязательных ключей (код возврата 1, строки со ссылками на описание ошибок опущены):

Если ключ задан, но короче положенного, в той же форме называется поле и причина, например String should have at least 24 characters.

Заказчик заводится одной командой. Идентификатор заказчика 32 шестнадцатеричных знака в нижнем регистре. Ключ заказчика придумывает администратор и передает заказчику, в базу записывается только его SHA-256, которую считает команда printf %s "{ключ заказчика}" | sha256sum. Значения в фигурных скобках подставляет администратор.

Признак успешного запуска сервера в журнале (прогон 29.09.2026, адрес и номер процесса из прогона):

Сервер запускается и тогда, когда база данных недоступна: при запуске программа к базе не обращается. Недоступность базы видна в ответе /health. Ключи сервера uvicorn: --host адрес, --port порт, полный перечень выводит uvicorn --help.

9. Команды и ответы программы

9.1. Общие правила. Команда программе это запрос HTTP к адресу сервера. Тела запросов и ответов в формате JSON в кодировке UTF-8, документ загружается формой multipart/form-data. Запросы к базе знаний сопровождаются заголовком X-API-Key с ключом администратора (API_ADMIN_KEY, доступ к любому заказчику) или ключом заказчика (доступ только к своему заказчику). Адреса /health, /about, /openapi.json, /docs и /redoc ключа не требуют. Ответ об ошибке содержит поле detail. Ошибки проверки входных данных приходят с кодом 422 списком, пример из прогона:

9.2. Служебные адреса.

9.3. База знаний. Все адреса начинаются с /api/customers/{customer_id}/knowledge, ниже это начало заменено многоточием. Доступ: администратор и заказчик в пределах своего customer_id. Все ответы в таблице получены 29.09.2026 на исправленной сборке, операции выполнены ключом заказчика, удаление коллекции ключом администратора. Идентификаторы и даты из прогона.

Ответ на вопрос, для которого в коллекции есть фрагмент. Поле answer содержит выдержку и ссылку на документ, sources фрагменты-источники с полями document_id, document_title, citation, page, heading, text, score:

Ответ, когда в коллекции нет подходящего фрагмента:

Если заданы GATEWAY_URL и GATEWAY_API_KEY, ответ формулирует языковая модель в контуре заказчика по найденным фрагментам, и поле generated равно true. Проверено с имитацией модели на локальном адресе: {"answer":"Срок ответа на обращение жителя составляет 10 рабочих дней.","found":true,"generated":true,"sources":[...]}. С настоящей моделью не проверялось. Файл модели эмбеддингов в прогоне не устанавливался, поиск шел по словам, и программа сообщила об этом в журнале строкой модель эмбеддингов недоступна (...): база знаний работает на поиске по словам.

9.4. Расшифровка записей. Команда речевому слою это вызов функции из кода на Python, пример вызова приведен в п. 6.

Ответ программы. При успехе функция возвращает объект с полями segmenty (реплики), svodka (итог одной строкой), dlitelnost_sek, ustroystvo, sekund_scheta, puti (записанные файлы по видам), golosa_razmecheny и pochemu_bez_golosov. Если разметка говорящих не удалась, расшифровка выдается без нее, а причина записывается в pochemu_bez_golosov. Отказы программа выдает исключениями с причиной. Два первых получены в прогоне 29.09.2026:

По исходному тексту, в прогоне не получены: PustayaRasshifrovka (запись длиннее 120 секунд, из которой не вышло ни одной реплики) и RuntimeError с последними строками сообщения ffmpeg, если звук не удалось подготовить. Строки хода работы в прогоне: файл ton.wav, 0.1 МБ, длительность 00:03. Полная расшифровка в прогоне 29.09.2026 не выполнялась: модель распознавания не устанавливалась.

10. Завершение работы

Сервер программного интерфейса завершается сигналом SIGTERM или SIGINT. Для единицы systemd это команда systemctl stop sibir-dokumenty, при запуске из консоли сочетание Ctrl+C. Получив сигнал, сервер перестает принимать новые соединения и завершает приложение. Собственных действий при завершении у программы нет: данные к этому моменту уже записаны в базу и в каталог DATA_DIR. Ответ программы, журнал корректной остановки (прогон 29.09.2026 на Windows, сигнал Ctrl+Break, который сервер обрабатывает так же, как SIGTERM, остановка заняла 0,2-0,5 секунды):

Если в момент сигнала выполнялись запросы, сервер дожидается их окончания и между первой и второй строкой пишет Waiting for connections to close. (CTRL+C to force quit), повторный сигнал завершает его без ожидания. Это поведение сервера uvicorn описано по его исходному тексту и в прогоне не проверялось, как и остановка сигналом SIGTERM на Linux.

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

Расшифровка записи завершается возвратом из функции или исключением с причиной. Прервать ее можно только остановкой вызвавшего процесса. Промежуточный файл звука в каталоге RECH_RABOCHIY_DIR удаляется лишь после успешной расшифровки. После отказа или прерывания он остается (в прогоне 29.09.2026 остался файл ton-16k.wav), и его удаляет администратор.

Полное выключение и удаление описаны в разделе установки, п. 6. Каталог DATA_DIR и база данных при остановке сервера не затрагиваются.

Часть II. Руководство пользователя

Пользователь работает с продуктом из информационной системы своей организации: продукт

встраивается в нее программным интерфейсом. Поэтому вид окна, названия кнопок и порядок

действий определяет та система, а не продукт.

Со стороны продукта пользователю доступны три действия.

Положить документ в коллекцию. Поддерживаются PDF и текстовые форматы. После загрузки

документ доступен поиску не мгновенно: он сначала разбирается и индексируется.

Задать вопрос по коллекции. Ответ приходит со ссылками на документы, из которых он

собран. Если продукт отвечает, что не нашел, это значит, что в коллекции нет фрагментов,

относящихся к вопросу, а не что вопрос задан неправильно.

Открыть документ-источник. По ссылке из ответа скачивается тот самый файл, который был

загружен, а не его пересказ.

Чего пользователь делать не может

• Видеть документы чужой организации. Чужая коллекция для него неотличима от

несуществующей.

• Получить ответ без источника. Если источника нет, нет и ответа.
• Отредактировать документ внутри продукта. Документ заменяется загрузкой новой версии.

---

Чего в руководстве нет и почему

• Описания окна пользователя. Его в версии 0.2.0 нет: продукт встраивается программным

интерфейсом. Писать руководство по несуществующему окну нельзя.

• Маршрута для расшифровки записей. Речевой слой вызывается из кода, своего маршрута в

версии 0.2.0 у него нет.

Сибирь.Документы — описание процессов жизненного цикла

Версия 0.2.0. Документ 6 описи заявления в реестр, обязательный по пункту 6 Правил

(ПП РФ № 1236). Состояние на 19.09.2026.

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

поставлен не полностью, это сказано прямо: раздел 10.

1. Общие сведения

Правообладатель и разработчик — ООО «Финансовый искусственный интеллект», ОГРН

1235400001870, ИНН 5402076457, 630090, г. Новосибирск, ул. Демакова, д. 23/5.

Разработка ведется на территории Российской Федерации силами работников Общества.

Привлечение иностранных разработчиков и подрядчиков не производится.

Программа выделена в самостоятельный продукт 18.09.2026 из состава программы для ЭВМ

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

2. Процесс разработки

Исходный код хранится в системе управления версиями GitFlic (ООО «РеСолют», Российская

Федерация), репозиторий приватный, адрес gitflic.ru/project/vitaliyvino/siberia-dialog,

отдельная ветвь разработки продукта.

Изменение вносится в отдельной ветви и попадает в основную ветвь через запрос на слияние.

Прямая запись в основную ветвь не производится.

Принятый в разработке порядок: проверка пишется до изменения и обязана на нем краснеть.

Изменение, для которого нет проверки, падавшей до него, считается непринятым. Практическое

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

котором она падала.

Отдельно ведется учет дефектов вида «проверка была зеленой, а предмет сломан». Пример из

истории продукта: набор из двадцати проверок отделения был полностью зеленым, тогда как в

пакете отсутствовало само приложение, потому что все двадцать проверяли импорт модулей, а

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

он не кодом, а новой проверкой.

3. Процесс выпуска версий

Нумерация вида МАЖОРНАЯ.МИНОРНАЯ.ИСПРАВЛЕНИЕ.

Экземпляр собирается инструментом tools/sobrat_ekzemplyar.py в стороне от рабочего

дерева. Инструмент сверяет состав собранного колеса с закрытым перечнем обязательных

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

свой. Собранное колесо сопровождается контрольной суммой SHA-256.

Перед выпуском:

1. Набор проверок продукта прогоняется в окружении, где посторонние компоненты отсутствуют

физически, а не отключены настройкой.

2. Перечень сторонних компонентов снимается заново с установленного окружения

инструментом tools/sobrat_sbom.py, а не берется из файла зависимостей.

3. Числа и контрольная сумма в документах сверяются с самим колесом проверкой

docs/legal-dokumenty/proverka.py.

4. Процесс устранения неисправностей

Время реакции считается в рабочие часы по московскому времени.

Обращение принимается по адресу support@siberia-ai.ru или по телефону

+7 (383) 288-82-82. На обращение заводится запись с описанием, шагами воспроизведения и

сведениями об окружении.

Устранение неисправности сопровождается проверкой, которая падала на исходном случае.

Исправление без такой проверки не выпускается.

5. Процесс технической поддержки

Поддержка оказывается в период действия соответствующего договора и включает:

• консультации по эксплуатации продукта;
• разбор обращений об ошибках и их устранение по разделу 4;
• предоставление выпущенных версий и исправлений;
• помощь в установке обновления по запросу эксплуатирующей организации.

Обновление устанавливается только по решению эксплуатирующей организации. Технической

возможности обновить продукт или ограничить его функциональность извне в одностороннем

порядке в продукте нет.

6. Управление уязвимостями

Состав сторонних компонентов известен точно и снимается с установленного окружения.

Проверка состава выполняется при каждом выпуске.

При обнаружении уязвимости в стороннем компоненте: оценка применимости к продукту,

обновление компонента либо обоснование неприменимости, выпуск исправляющей версии в сроки

раздела 4 по уровню опасности.

Продукт спроектирован для работы без доступа к сети Интернет. Обращений к внешним сервисам

в поставляемой конфигурации нет, что сокращает поверхность атаки, но не отменяет

обновления компонентов.

7. Резервное копирование и восстановление

Состояние продукта хранится в двух местах: база PostgreSQL и каталог DATA_DIR с

исходными файлами документов.

Порядок резервного копирования определяет эксплуатирующая организация. Продукт этому не

препятствует: оба хранилища копируются штатными средствами, файлы документов лежат под

именами из SHA-256 своего содержимого, и повторная загрузка того же файла второй копии не

создает.

Восстановление: развернуть базу из копии, вернуть каталог DATA_DIR, запустить продукт.

Проверка восстановления выполняется инструментом tools/proverit_ustanovku.py.

8. Прекращение поддержки версии

Поддерживается текущая версия и одна предыдущая минорная. О прекращении поддержки версии

эксплуатирующие организации извещаются не менее чем за три месяца.

9. Развитие

Направление развития определяется правообладателем с учетом обращений эксплуатирующих

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

предоставление обращения не создает.

10. Чего в процессе пока нет

Раздел обязателен: описание процессов, где перечислено только имеющееся, читается как

полное.

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

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

изменением схемы требует участия разработчика.

• Автоматической сборки при каждом изменении. Набор проверок прогоняется разработчиком

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

нет.

• Протоколов совместимости с российскими операционными системами. Ни программы и

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

вторая операционная система не пройдена до сих пор: образ Astra Linux 1.8 отдается по

авторизации, а в открытом доступе лежит 1.7.5 с Python 3.7.3 при требуемом 3.12.

• Отдельного контура опытной эксплуатации. Проверка идет в изолированном окружении на

машине разработки, стенда для длительной эксплуатации нет.