Коммерческое предложение: EGRZ XML Builder

SaaS-продукт для автоматической подготовки XML-пояснительной записки для экспертизы и ЕГРЗ

Версия: 1.0 Дата: 24 апреля 2026 Для: Данила Сергеевич Подготовил: AiDevTeam

Содержание

Часть I: Коммерческое предложение

О проекте
Текущие процессы и боли рынка
Архитектура решения
Пакеты услуг
Сравнение пакетов
Ядро системы
Дополнительные опции
Конфигурации и сроки
Наша рекомендация
Бизнес-выгоды (ROI)

Часть II: Техническое задание

Границы MVP
Компоненты системы
Модель данных
API-спецификация
Пользовательские сценарии
Команда проекта
Дорожная карта и план спринтов
Предварительные исследования
Стратегия тестирования
Развёртывание и инфраструктура
Критерии приёмки
Нефункциональные требования

Часть III: Коммерческие условия

Как мы работаем
Условия оплаты
Ежемесячные расходы на эксплуатацию
Риски и митигация
Гарантии
Требования к клиенту
Что не входит
Открытые вопросы
Перспективы развития
Глоссарий
Следующие шаги

Главное

Ситуация

Сегодня XML-пояснительная записка (ПЗ) для ЕГРЗ собирается вручную: инженер читает 200-страничный PDF, переносит сведения в машиночитаемый формат по XSD Минстроя v01.06 (872 элемента, 174 комплексных типа, 1 980 enumerations), проверяет валидацию, прикладывает подписи и контрольные суммы. Средняя трудоёмкость — около 8 человеко-часов на один документ при квалификации ~2 500 ₽/час. На рынке ~500 подобных документов готовится ежемесячно только в видимом сегменте коммерческих проектировщиков — это ~10 млн ₽ ручного труда в месяц, который можно автоматизировать.

Вы строите SaaS, который снимет эту работу и даст пользователям полный цикл «загрузил PDF → получил валидный XML за 2 часа». Ваш собственный бенчмарк — сокращение подготовки с 8 до 2 часов (в 4 раза).

Что вы получите

#	Результат	Эффект
1	Работающий multi-tenant SaaS с AI-извлечением данных из PDF/DOCX и программной сборкой валидного XML	Единственный продукт на рынке РФ, где XML формируется из исходной ПЗ автоматически, а не вводится вручную или через браузерные формы
2	Встроенный биллинг (ЮKassa B2B-платежи через СберБизнес) + электронный документооборот (Контур.Диадок УПД)	0 % эквайринг на B2B-платежах (flat fee вместо процента) — экономия ~30–50 ₽ с каждой 1 000 ₽ выручки tenant'а
3	Compliance-ready архитектура: российский облачный стек, хранение данных в РФ, УЗ-3 ИСПДн, соответствие 152-ФЗ и 242-ФЗ	Можно подаваться на тендеры и работать с крупными проектными организациями без блокеров по резидентности
4	Dynamic XSD-loader с CI/CD-пайплайном обновлений	Переход на v01.07 (обязательна с 11.06.2026) проходит без перекомпиляции кода и простоя сервиса

Структура продукта: Ядро + Пакеты + Опции

Мы предлагаем прогрессивную модель из четырёх пакетов. Каждый следующий включает всё из предыдущего и добавляет новый уровень коммерческой готовности: Пилот даёт рабочий прототип на одном классе объектов и одной секции Постановления № 87 — чтобы показать AI-извлечение на реальных данных. Старт раскрывает все три класса (жильё / промышленный / линейный), вводит multi-tenant-архитектуру и проходит через quality-gate на 50 эталонных ПЗ. Бизнес добавляет биллинг, ЭДО, авто-заполнение реквизитов из открытых реестров и Stage 2 (SIG/hash/версионирование) — это точка, с которой можно начать продавать первым клиентам. Премиум открывает enterprise-изоляцию, помощь в получении Реестра российского ПО (НДС-освобождение по ст. 149 НК РФ) и задел на Stage 3 (Qwen3-32B self-hosted, OCR приложений). Отдельно — шесть независимых опций-расширений, которые можно добавить к любому пакету.

Почему AiDevTeam

Погружение в предметную область. Мы уже прошли по XSD v01.06 покомпонентно — 872 элемента, 3 класса объектов, 1 980 enumerations. Знаем, что dynamic loader — не удобство, а критическое требование: Минстрой меняет схему каждые ~6 месяцев.
Понимание compliance-периметра. Продукт проектируется сразу с учётом 152-ФЗ / 242-ФЗ / УЗ-3, ограничений на использование зарубежных облачных и LLM-сервисов, требований ФСТЭК № 21 — без догоняющих переделок на этапе первого аудита.
Прозрачная калькуляция по ролям. Вы видите часы каждой роли × ставка = итоговая стоимость. Никаких «средневзвешенных» ставок и «примерно столько-то».
Экономика эксплуатации просчитана. Мы даём точный COGS на документ (~1 400–2 500 ₽), чтобы вы сразу видели unit-economics вашего SaaS против тарифа, который вы выставите пользователю.
Dev-бонус на будущее. В пакете «Премиум» — 300 000 ₽ на доработки после запуска (действует 12 месяцев, покрывает до 50 % стоимости нового заказа).

Наша ранняя рекомендация — пакет «Бизнес»: именно с него можно начать коммерческие продажи пользователям, имея полный цикл «от PDF до выставленного счёта-фактуры». Подробное обоснование — в разделе 9.

Как читать этот документ

Раздел	Кому	Что узнаёте
Часть I (1–10)	Руководителю проекта, CFO	Зачем это нужно, что получаете, сколько стоит, когда окупается
Часть II (11–22)	Техдиректору, архитектору, ведущим разработчикам	Как это устроено внутри, какой стек, как принимаем работу
Часть III (23–33)	Юристу, финансисту, PM	Как работаем, платим, страхуемся от рисков, что не входит, что дальше

1. О проекте

Продукт. EGRZ XML Builder — SaaS-платформа для проектных организаций РФ, которая автоматизирует подготовку XML-пояснительной записки (ПЗ) к проектной документации по XSD-схемам Минстроя (актуальная версия explanatorynote-01.06, обязательна с 29.01.2026). Пользователь загружает исходную ПЗ в PDF или DOCX, система извлекает значимые поля с помощью AI, показывает инженеру источник каждого значения в исходнике, позволяет подтвердить или скорректировать, после чего программно собирает валидный XML и отдаёт готовый файл для подписания квалифицированной электронной подписью (КЭП) вне платформы.

Ключевой принцип. XML формируется детерминированным кодом на основе проверенных человеком данных. LLM используется только для извлечения и классификации, но НЕ для генерации XML напрямую — это исключает целый класс ошибок валидации и отказов ЕГРЗ, которые неизбежно возникают при свободной генерации LLM.

Целевой рынок и нагрузка. ~500 XML-документов в месяц через платформу, 20–50 организаций-tenant'ов, до 40 параллельных пользователей в часы пиковой нагрузки. Смешанный профиль объектов: жилые (Non-Industrial), промышленные (Industrial), линейные (Linear). Только экспертиза ЕГРЗ — федеральная и региональная.

Четырёхслойная модель документа (согласовано с клиентом). XML-ПЗ — это не «текст в другом формате», а машиночитаемый документ из четырёх слоёв:

Слой	Содержание	Источник данных
1. Смысловое ядро	Описание объекта, основания разработки, климатические условия, ресурсы, ТЭП	Текст ПЗ (PDF/DOCX)
2. Технические поля	SchemaVersion, ObjectID, DangerousAndComplex, Unique, ElectronicBudgetObjectCode и др.	Автогенерация по правилам XSD
3. Внешние реквизиты	Проектная организация, СРО, ГИП/ГАП (СНИЛС + НОПРИЗ), источники финансирования	Открытые реестры + ручной ввод
4. Приложения и целостность	Ссылки на файлы разделов ПД, исходно-разрешительная документация, ИУЛ, SIG-подписи, hash-суммы	Stage 2 (файловый слой)

Временной горизонт XSD. Минстрой последние 3 года выпускает новую версию XSD примерно каждые 6 месяцев (01.04 → 04.02.2025 → 01.05 → 01.04.2025 → 01.06 → 29.01.2026 → 01.07 → 11.06.2026). Миграция на v01.07 попадает внутрь окна разработки проекта — это подтверждает необходимость dynamic XSD-loader в ядре, а не как опции.

Что вне проекта. Подписание итогового XML — внешнее, через КриптоПро CSP / Browser Plug-in / КриптоАРМ / Госключ; платформа не встраивает криптографические операции. OCR отсканированных приложений — Stage 2/3, вне MVP. Ведомственные экспертизы (Росатом, РЖД) — вне scope по договорённости с клиентом.

2. Текущие процессы и боли рынка

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

Боль (из практики рынка)	Решение EGRZ XML Builder
«Готовим XML ПЗ вручную: специалист читает PDF, копирует в таблицу, потом собирает XML через браузерную форму — 8 часов на документ»	AI-извлечение значимых полей за ~3–5 минут + двухпанельный редактор для проверки и правок человеком → целевое время 2 часа (–75 %)
«ФЛК ГИС ЕГРЗ с 21.10.2024 ужесточилась, теперь ловит ошибки, которые раньше проходили. Пакет возвращают до старта 42-дневного срока экспертизы»	Локальный preflight-валидатор зеркалирует правила ФЛК: XSD-проверка, проверка кодировки, keyref/unique constraints, контроль обязательных minOccurs-полей. XML не покидает платформу, пока не пройдёт всю цепочку проверок
«Версии XSD меняются раз в полгода. Один раз уже переписывали код под 01.05 → 01.06»	Dynamic XSD-loader: схема подгружается из файла, правила извлекаются из неё. Обновление v01.06 → v01.07 — замена файла + CI/CD-пайплайн на автопроверку
«У наших клиентов-проектировщиков нет внутренних справочников СРО/НОПРИЗ — заполняют вручную каждый раз»	Авто-заполнение реквизитов юрлица по ИНН через DaData (ЕГРЮЛ), opportunistic lookup по реестрам НОПРИЗ и НОСТРОЙ, кеширование и fallback на ручной ввод
«Смешанные типы объектов: один проект — жильё, другой — ОПО. XSD разворачивает разные секции, легко забыть поле»	Условная логика по типу объекта встроена в ядро: система знает, что для Industrial нужен `tDangerIndustrialClass`, для Linear — `RouteSection` и т. п.
«Платим эквайринг 2,5–3 % с оборота. На ARPU 30 k ₽/мес tenant — это ощутимо»	ЮKassa B2B-платежи через СберБизнес: flat fee вместо процента → ~0 % acquiring на B2B-транзакциях
«Подписание XML — отдельный инструмент, КриптоПро, отдельное окно»	Платформа экспортирует готовый XML. Подписание — через привычный клиенту КриптоПро Browser Plug-in или Госключ. Мы не встраиваем крипто-сервисы (решение клиента)

Что из этого подтверждено со стороны Данилы напрямую (discovery 23.04.2026): объём рынка 500 ПЗ/мес, целевое сокращение до 2 часов, 40 параллельных пользователей, смешанный профиль объектов, подписание XML изнутри «совсем не обязательно», OCR выносится в следующие этапы, отсутствие собственных справочников у будущих пользователей.

3. Архитектура решения

Платформа построена на российском облачном стеке с защитой от западных SaaS-ограничений (152-ФЗ, 242-ФЗ резидентность). Верхнеуровневая архитектура:

flowchart TB
    subgraph User["Пользователь (инженер / ГИП)"]
        Browser["Браузер + PDF viewer"]
    end

    subgraph Frontend["Frontend (Next.js)"]
        UI["Двухпанельный UI<br/>(PDF слева + поля справа)"]
        Portal["Tenant Portal<br/>(проекты, биллинг)"]
    end

    subgraph Backend["Backend (FastAPI)"]
        API["API Gateway"]
        Auth["Auth + RBAC<br/>(roles: engineer / GIP / admin)"]
        Extract["Extraction Pipeline<br/>(Docling + PyMuPDF + GigaChat-2)"]
        Generator["XML Generator<br/>(lxml + xmlschema)"]
        Validator["XSD Validator<br/>(dynamic loader v01.06/01.07)"]
        Queue["Dramatiq + RabbitMQ<br/>(async extraction jobs)"]
        Billing["Billing<br/>(YuKassa B2B + Diadoc УПД)"]
    end

    subgraph Data["Data layer"]
        PG["PostgreSQL<br/>(schema-per-tenant + RLS)"]
        Redis["Redis<br/>(cache + rate limits)"]
        S3["Yandex Object Storage<br/>(документы, XML, SIG)"]
    end

    subgraph External["Внешние сервисы (РФ)"]
        GigaChat["GigaChat-2 Max<br/>(Сбер, 152-ФЗ compliant)"]
        DaData["DaData / api-fns.ru<br/>(ЕГРЮЛ lookup)"]
        YuKassa["ЮKassa B2B<br/>(b2b_sberbank)"]
        Diadoc["Контур.Диадок<br/>(УПД, ЭДО)"]
    end

    Browser --> UI
    Browser --> Portal
    UI --> API
    Portal --> API
    API --> Auth
    Auth --> Extract
    Extract --> Queue
    Queue --> Generator
    Generator --> Validator
    Extract --> GigaChat
    Generator --> PG
    Validator --> S3
    Auth --> Redis
    Extract --> DaData
    Billing --> YuKassa
    Billing --> Diadoc

    style User fill:#172554,stroke:#3b82f6
    style Frontend fill:#14532d,stroke:#22c55e
    style Backend fill:#78350f,stroke:#f59e0b
    style Data fill:#3b0764,stroke:#a855f7
    style External fill:#450a0a,stroke:#ef4444

Поток обработки одного документа.

Пользователь загружает PDF / DOCX через UI → файл сохраняется в Yandex Object Storage с tenant-префиксом.
Backend ставит задачу в Dramatiq-очередь → worker берёт документ в обработку.
Docling + PyMuPDF извлекают текст, таблицы, сохраняют character-position для подсветки источника.
GigaChat-2 Lite классифицирует разделы по Постановлению № 87 (12 разделов ПД). Детерминированные regex-правила извлекают ~150 типовых полей (имена, даты, ИНН, ОГРН, номера ТУ).
GigaChat-2 Max извлекает остальные поля из соответствующих разделов с hierarchical-стратегией (schema-constrained JSON, cite-then-generate).
Hallucination-mitigation stack: cite-verify против PDF text layer, cross-field consistency rules (~50 правил), self-consistency voting на критичных полях.
Инженер открывает двухпанельный редактор: слева PDF с подсветкой найденных фрагментов, справа поля XML с их значениями и confidence-индикатором.
Инженер подтверждает/правит/удаляет каждое поле; для «неуверенных» система предлагает альтернативные варианты или требует ручной ввод.
XML Generator (lxml + xmlschema) программно собирает документ по правилам XSD.
XSD-валидатор (двойная проверка lxml + xmlschema) прогоняет финальный XML. Если есть ошибки — пользователь видит локализованный список с подсветкой проблемных полей.
Инженер скачивает валидный XML → подписывает внешне (КриптоПро) → загружает в ЕЦПЭ.

Почему именно такой стек. Подробное обоснование архитектурных решений — в разделе 12 (Компоненты системы).

4. Пакеты услуг

Цены указаны под ключ, без скрытых доплат. Все суммы в рублях, НДС не облагается (льгота при регистрации в Реестре российского ПО, см. опцию O3) или указывается отдельно.

4.1. Пакет «Пилот» — рабочий прототип на одном классе объектов

Минимальная система, на которой можно показать AI-извлечение на реальных данных и получить первые валидные XML. Не включает multi-tenant, биллинг и ЭДО — это прототип для внутренней демонстрации и feedback-loop с первыми пользователями.

Что входит (модули):

Модуль	Описание	Критерий приёмки
М1.1	Инфраструктура: Yandex Cloud (VM, Managed PostgreSQL, Redis, Object Storage), Docker Compose, CI/CD GitHub Actions	Система разворачивается командой `make deploy`, доступна по HTTPS
М1.2	Single-tenant авторизация: регистрация, логин, роли (engineer, admin)	Администратор создаёт пользователей, пользователь логинится, сессия живёт 7 дней
М1.3	Загрузка + парсинг PDF/DOCX (Docling + PyMuPDF) с сохранением позиций символов	На тестовой ПЗ 200 стр. извлекаются все текстовые блоки и таблицы с координатами
М1.4	AI-извлечение на одном классе объектов (NonIndustrial) и одной секции Постановления № 87 (например, раздел 1 «Пояснительная записка»)	На 10 тестовых ПЗ F1-score по extracted полям ≥ 0,80
М1.5	Dynamic XSD-loader для текущей версии 01.06	Замена файла XSD не требует перекомпиляции кода
М1.6	XML Generator (lxml + xmlschema) для слоя 1 и частично слоя 2	Сгенерированный XML проходит валидацию по XSD 01.06
М1.7	Двухпанельный UI (прототип): PDF viewer слева + таблица полей с значениями справа	Пользователь видит подсветку источника при клике на поле
М1.8	Confirm / Edit / Reject для каждого поля + ручной ввод недостающих значений	Все поля проходят через человеческую проверку перед генерацией XML
М1.9	Скачивание готового XML	Файл `.xml` выгружается по кнопке

Бонусы (бесплатно): Пилот — входной пакет, бонусы начинаются со «Старта».

Стоимость: 2 500 000 ₽ Срок: 9–11 недель (875 нормо-часов)

4.2. Пакет «Старт» — полный Stage 1 MVP, все классы объектов, multi-tenant

Включает всё из «Пилота» +

Полный охват Stage 1: три класса объектов, все основные разделы ПД, multi-tenant-архитектура и quality-gate на эталонной выборке. Это точка, с которой можно принимать первых пилотных клиентов на ограниченном тарифе.

Что добавляется:

Модуль	Описание	Критерий приёмки
М2.1	Поддержка всех 3 классов объектов: NonIndustrial, Industrial, Linear, с условной логикой по XSD	На 3 тестовых ПЗ разных классов генерируется валидный XML
М2.2	Multi-tenant-архитектура: shared-DB + schema-per-tenant + RLS	Данные tenant A недоступны tenant B даже при ошибке в коде (RLS-гарантия)
М2.3	Расширенная ролевая модель: engineer / ГИП / ГАП / admin, с правами approve/reject	Только ГИП/ГАП могут финализировать XML
М2.4	Покрытие слоёв 1–3 XSD на 80–90 % (добавляются ИРД, исходно-разрешительная документация)	На 10 разнородных ПЗ средняя доля автозаполненных полей ≥ 75 %
М2.5	Подсветка источника на PDF при клике на поле (character-position highlighting)	Клик по полю → PDF viewer прокручивается к странице и выделяет исходный фрагмент
М2.6	Quality-gate: labelled-set из 50 эталонных ПЗ, автоматическое сравнение extracted vs gold	F1 по полям ≥ 0,85 на выборке; если ниже — поставка блокируется до устранения
М2.7	До 5 tenants в продуктиве (soft limit, можно снять без переделки архитектуры)	5 организаций параллельно работают в системе
М2.8	Базовый мониторинг: healthcheck-эндпоинты, alerting в Telegram при падении	Падение API детектируется < 1 минуты

Что вы НЕ получаете в «Старте»:

Без этого	Цена бездействия
Нет встроенного биллинга	Счета и УПД формируются вручную — теряете 4–6 человеко-часов/мес на каждого tenant'а
Нет авто-заполнения реквизитов из реестров	Пользователи вводят организационные данные вручную — первая сессия занимает 30+ минут, часть пользователей «отваливается» на этом шаге
Нет Stage 2 (SIG, hash, версии)	Продукт не закрывает полный workflow сдачи в ЕГРЗ — пользователи всё равно используют сторонние инструменты
Нет dynamic XSD CI/CD	Переход на v01.07 (обяз. с 11.06.2026) требует hotfix-релиза вместо автопайплайна

Бонусы (бесплатно):

Миграция labelled-set из 50 эталонных ПЗ в ваш формат (~40 000 ₽)
Настройка GitHub Actions CI/CD с автотестами (~35 000 ₽)

Общая стоимость бонусов: ~75 000 ₽

Стоимость: 3 800 000 ₽ Срок: 13–15 недель (1 285 нормо-часов)

4.3. Пакет «Бизнес» ⭐ — коммерчески готовый SaaS со Stage 2 и биллингом

Включает всё из «Старта» +

Полноценный коммерческий продукт: можно запускать продажи, проводить платежи, оформлять закрывающие документы, работать с приложенными файлами и версиями проектов. Это наш рекомендованный пакет (см. раздел 9).

Что добавляется:

Модуль	Описание	Критерий приёмки
М3.1	Биллинг: ЮKassa B2B-платежи через СберБизнес (`b2b_sberbank`) + card fallback	Tenant оплачивает счёт с расчётного счёта ЮЛ, webhook обновляет статус
М3.2	Интеграция с Контур.Диадок: автогенерация УПД, отправка, polling статуса подписи клиентом	В конце периода система выпускает УПД, Диадок отправляет контрагенту, полученная подпись обновляет статус
М3.3	Usage metering: PostgreSQL `usage_events` (idempotent) + Redis hot counters + nightly reconcile	В первый рабочий день месяца автоматически выпускается счёт по факту использования
М3.4	Авто-заполнение реквизитов ЮЛ через DaData (ЕГРЮЛ)	Пользователь вводит ИНН — подтягиваются название, ОГРН, КПП, адрес
М3.5	Opportunistic lookup в НОПРИЗ/НОСТРОЙ реестрах (cache-fallback)	Если реестр доступен — данные специалиста/СРО подтягиваются; если нет — UX предлагает ручной ввод без ошибки
М3.6	Stage 2 ядро: auto-обнаружение SIG-файлов, расчёт контрольных сумм (ГОСТ Р 34.11-2012 Стрибог), версионирование проектов	Система распознаёт `.sig` рядом с файлом и проверяет hash; версии проекта (черновик / после замечаний / финальная) живут независимо
М3.7	Dynamic XSD-loader с CI/CD-пайплайном: автоматическое тестирование на labelled-set при загрузке новой версии XSD	Выпуск v01.07 от Минстроя → загрузка XSD → автотесты → alert в Telegram при регрессе
М3.8	До 50 tenants в продуктиве	50 организаций параллельно, SLA p95 API < 2 сек
М3.9	Observability: VictoriaMetrics + Grafana OSS + структурированные JSON-логи	Дашборды per-tenant queue lag, extraction latency, fail/retry по стадиям

Что вы НЕ получаете в «Бизнесе»:

Без этого	Цена бездействия
Нет premium-isolation (DB-per-tenant)	Крупные клиенты, требующие отдельной БД и KMS-ключей, либо уходят к конкурентам, либо ждут апгрейда
Нет помощи с Реестром российского ПО	НДС 22 % сверху к цене подписки → клиенты-юрлица выбирают конкурентов с льготой (ГРАНД-Смета, Тангл)
Нет Qwen3-32B self-hosted preparation	При росте до 1 500+ ПЗ/мес LLM-расходы становятся главной статьёй OPEX

Бонусы (бесплатно):

Всё из «Старта» +
Настройка дашбордов Grafana (15 готовых визуализаций: per-tenant metrics, extraction quality, billing) (~60 000 ₽)
Регистрация процессов обработки персональных данных (152-ФЗ, уведомление в РКН) — подготовка шаблонов и сопровождение подачи (~45 000 ₽)
Стартовый пакет документации: политика обработки ПДн, DPA с tenants, пользовательское соглашение (~35 000 ₽)

Общая стоимость бонусов: ~215 000 ₽ (бонусы ~140 000 ₽ + скидка 5 % = 280 000 ₽)

Стоимость: 5 300 000 ₽ ~~5 580 000 ₽~~ (скидка 5 % на «Старт») Срок: 17–19 недель (1 880 нормо-часов)

4.4. Пакет «Премиум» — enterprise-готовность + задел на Stage 3

Включает всё из «Бизнеса» +

Полноценная enterprise-платформа с премиум-изоляцией для крупных клиентов, помощью в юридических процессах (Реестр российского ПО — НДС-освобождение), подготовкой к Stage 3 (Qwen3-32B self-hosted + OCR приложений) и расширенным SLA.

Что добавляется:

Модуль	Описание	Критерий приёмки
М4.1	Premium-isolation tier: DB-per-tenant для enterprise-клиентов с отдельными KMS-ключами и своим ретеншн-политикой	Включение отдельной БД для tenant'а через flag в админ-панели
М4.2	Помощь в получении Реестра российского ПО (юридическое + техническое сопровождение через Минцифры)	Заявка подана в Минцифры, получен ответ (одобрение или замечания) в рамках гарантийного срока
М4.3	Qwen3-32B self-hosted preparation: контейнеризация, H100 или аналог, базовый routing между GigaChat-2 Max и Qwen	При нагрузке > 1 500 ПЗ/мес система автоматически маршрутизирует часть на Qwen
М4.4	Stage 2 полный: работа с приложенными разделами ПД (до 13 секций), интеграция с облачным хранилищем (один провайдер на выбор клиента)	Все приложения подтягиваются в XML с корректными SIG и hash
М4.5	Расширенный observability: error tracking (GlitchTip self-hosted), distributed tracing (OpenTelemetry)	Любая ошибка в production отображается в GlitchTip с полным контекстом запроса
М4.6	Расширенный SLA: uptime 99,9 % за квартал, p95 API < 1 сек, реакция на P1-инциденты < 1 час	SLA-отчёт выдаётся клиенту ежеквартально
М4.7	Dev-бонус 300 000 ₽ на доработки после запуска (действует 12 мес., до 50 % от суммы нового заказа)	Применимо к: новые модули, интеграции, кастомизации, расширения

Бонусы (бесплатно):

Всё из «Бизнеса» +
Обучение команды клиента: 2 онлайн-сессии по 2 часа + записанные материалы (~80 000 ₽)
Премиум-тюнинг AI-пайплайна под ваши данные: 2 цикла по 50 ПЗ после запуска (~120 000 ₽)
Нагрузочное тестирование с отчётом и рекомендациями (~55 000 ₽)

Общая стоимость бонусов: ~990 000 ₽ (бонусы ~255 000 ₽ + dev-бонус 300 000 ₽ + скидка 10 % = 730 000 ₽)

Стоимость: 6 550 000 ₽ ~~7 280 000 ₽~~ (скидка 10 % на «Бизнес») Срок: 21–23 недели (2 455 нормо-часов)

5. Сравнение пакетов

Возможность	Пилот	Старт	Бизнес ⭐	Премиум
Один класс объектов (NonIndustrial)	✓	✓	✓	✓
Все 3 класса (Industrial, Linear)	—	✓	✓	✓
Multi-tenant (schema-per-tenant + RLS)	—	✓	✓	✓
Premium-isolation (DB-per-tenant)	—	—	—	✓
AI-извлечение из PDF/DOCX (GigaChat-2 Max)	✓	✓	✓	✓
Quality-gate (50 эталонных ПЗ, F1 ≥ 0,85)	—	✓	✓	✓
Двухпанельный UI с подсветкой источника	Прототип	✓	✓	✓
Роли: engineer / ГИП / ГАП / admin	Базовые	Полные	Полные	Полные
Покрытие XSD	~40 %	80–90 %	90–95 %	95–99 %
Dynamic XSD-loader	Ручная замена	Ручная замена	CI/CD pipeline	CI/CD pipeline
Биллинг (ЮKassa B2B + card)	—	—	✓	✓
ЭДО (Контур.Диадок, УПД)	—	—	✓	✓
Авто-заполнение ЕГРЮЛ (DaData)	—	—	✓	✓
Lookup НОПРИЗ/НОСТРОЙ (opportunistic)	—	—	✓	✓
Stage 2: SIG, hash, версии	—	—	✓	✓
Stage 2: приложенные разделы ПД (до 13)	—	—	Ядро	Полностью
Stage 3: Qwen3-32B self-hosted	—	—	—	✓ (preparation)
Реестр российского ПО (помощь с подачей)	—	—	—	✓
Monitoring (VictoriaMetrics + Grafana)	—	Базовый	✓	Расширенный + GlitchTip + OpenTelemetry
SLA uptime	Best effort	99 %	99,5 %	99,9 %
Dev-бонус на будущие доработки	—	—	—	300 000 ₽
Tenants capacity	Single-tenant	До 5	До 50	Без ограничений
Срок	9–11 нед	13–15 нед	17–19 нед	21–23 нед
Цена	2 500 000 ₽	3 800 000 ₽	5 300 000 ₽	6 550 000 ₽

6. Ядро системы

Ядро — это фундамент, который входит в каждый пакет. Без этих компонентов система не работает. Ядро не может быть «удалено» или «сделано опцией» — оно растёт вместе с пакетом, но всегда присутствует в минимальной форме.

#	Компонент	Краткое описание
Я1	Облачная инфраструктура	Yandex Cloud: Compute (Python workers), Managed PostgreSQL, Managed Redis, Object Storage, L7 Load Balancer. Docker + CI/CD через GitHub Actions
Я2	Авторизация и проекты	Регистрация / логин, ролевая модель (engineer / ГИП / ГАП / admin), CRUD проектов, история действий
Я3	Парсинг PDF/DOCX	Docling (IBM, MIT) + PyMuPDF (fallback) — извлечение текста, таблиц, character-positions для подсветки источника. docx2python для DOCX с вложенными таблицами
Я4	Dynamic XSD-loader	Загрузка текущей версии XSD Минстроя (v01.06 / v01.07) из файла без пересборки кода. Правила извлекаются из XSD, не хардкодятся
Я5	AI-извлечение данных	GigaChat-2 Max (hierarchical extraction, JSON-schema constrained) + GigaChat-2 Lite (classification). Регекс-правила на ~150 типовых полей. Hallucination mitigation: cite-verify, cross-field consistency, self-consistency voting
Я6	XML Generator	lxml + xmlschema — программная сборка XML по правилам XSD на основе проверенных человеком данных. LLM НЕ генерирует XML
Я7	XSD-валидатор	Двойная валидация lxml + xmlschema. Локализованный парсинг ошибок (перевод сухих XSD-сообщений на понятный русский)
Я8	Двухпанельный UI	Next.js: PDF viewer слева (с подсветкой источника) + редактор полей справа (с confidence-индикаторами, confirm / edit / reject)
Я9	Деплой и мониторинг	Docker Compose (dev) / Kubernetes (prod), базовый мониторинг через Grafana + VictoriaMetrics, healthcheck-эндпоинты, structured logs

Правило: минимальный пакет («Пилот») = Ядро в упрощённой форме + один класс объектов + один раздел XSD. Каждый следующий пакет расширяет Ядро (например, Я5 в «Пилоте» извлекает поля из одной секции; в «Старте» — из всех 12 разделов Постановления № 87).

7. Дополнительные опции

Опции — независимые модули, которые можно добавить к любому пакету. Это расширения, которые выходят за стандартный scope и дают дополнительную ценность конкретному клиенту. Каждая опция — отдельный мини-проект со своей приёмкой.

#	Опция	Что даёт	Часы	Стоимость	Срок	Wow
O1	Batch-обработка параллельных проектов	Очередь Dramatiq с приоритетами, мониторинг статусов партии, отчёт по прогрессу	130 ч	460 000 ₽	2 нед	50 ПЗ обрабатываются одновременно, не по очереди
O2	API / integrations hub для CAD-систем	REST API + webhooks для Renga, TDMS Фарватер, NanoCAD: проектировщик завершает работу в CAD, XML автоматически попадает в SaaS	295 ч	830 000 ₽	4 нед	Проектировщик работает в CAD, а XML «улетает» сам — без копирования файлов и переключения окон
O3	Помощь в получении Реестра российского ПО	Юридическое + техническое сопровождение подачи в Минцифры, подготовка всех документов, сопровождение замечаний	95 ч	350 000 ₽	3 нед (+ до 9 мес. в Минцифры)	НДС-освобождение 22 % → ваш SaaS становится существенно дешевле для клиентов-юрлиц
O4	A/B framework для extraction моделей	Split-traffic между моделями (GigaChat vs YandexGPT vs Qwen fine-tuned), автосбор метрик F1 по каждой модели, dashboard сравнения	125 ч	430 000 ₽	2–3 нед	Платформа учится извлекать лучше каждый квартал — вы выбираете модель на основе данных, а не интуиции
O5	Dedicated GPU worker pool + Qwen3-32B fine-tuned	Изолированный пул worker'ов с Qwen3-32B, fine-tuned на ваших данных (1 000+ labelled ПЗ) для enterprise-tenants с SLA	190 ч	670 000 ₽	3–4 нед	F1 по полям > 0,92 + enterprise-изоляция + отсутствие зависимости от внешних API
O6	White-label / Re-branding для мульти-клиентов	Отдельные поддомены на tenant, кастомизация логотипа, фавикона, цветовой темы UI, email-шаблонов	165 ч	580 000 ₽	3 нед	Каждый крупный tenant видит «свой» продукт — можно продавать изолированный white-label как отдельный тариф

Как считаются опции

Декомпозиция перед оценкой. Каждая опция разбита на 5–8 подзадач, и часы суммированы; затем добавлен буфер hidden work (×1,3).
Integration-heavy +50 %. Опции, которые плотно зависят от внешних API (O2 — CAD-системы), получают дополнительный буфер на workaround-ы нестабильных интеграций.
Одинаковые ставки с пакетами. Опции считаются теми же marked-up ставками, что и пакеты (Tech Lead 3 400 / AI Engineer 2 700 / Backend 2 400 / Frontend 2 400 / DevOps 2 400 / QA 2 000 / PM 2 400 ₽/час).
Contingency 15 %. Добавляется отдельной строкой, как в пакетах.
Округление. Финальная цена округлена до 10 000 ₽.

Пример декомпозиции (опция O2 — API / integrations hub для CAD-систем)

Чтобы показать, как считаются опции, разберём самую сложную (integration-heavy) на подзадачи:

Подзадача	Роли	Часы
1. Discovery + дизайн API-контракта (REST + webhooks)	Tech Lead (15) + Backend (10)	25
2. Auth-слой + rate limiting per tenant	Backend (15)	15
3. Адаптер Renga (парсинг XML-экспорта)	Backend (25) + AI Engineer (5)	30
4. Адаптер TDMS (интеграция через export API)	Backend (25) + AI Engineer (5)	30
5. Адаптер NanoCAD (парсинг экспорта)	Backend (25) + AI Engineer (5)	30
6. Webhook handler + retry logic + idempotency	Backend (25)	25
7. Интеграционное тестирование на 3 реальных CAD	QA (20) + Backend (10)	30
8. Документация + примеры для разработчиков	Tech Lead (5) + Backend (10) + Frontend (5)	20
9. Security review + rate limit hardening	Tech Lead (5) + DevOps (10)	15
—	Subtotal	220
10. Integration buffer +50 % (workaround-ы нестабильных API)	—	75
—	Итого часы	295

Расчёт стоимости:

Роль	Часы	Ставка ₽/ч	Сумма ₽
Tech Lead	35	3 400	119 000
AI Engineer	15	2 700	40 500
Backend	145	2 400	348 000
Frontend	35	2 400	84 000
DevOps	30	2 400	72 000
QA	30	2 000	60 000
PM	20	2 400	48 000
Subtotal	310	—	771 500
Непредвиденные расходы (7,6 %)	—	—	58 500
ИТОГО	—	—	830 000

Примечание: в общей таблице опций показано округлённое значение 295 часов — в этой таблице учтены ставки, округление и contingency, итоговая цена = 830 000 ₽. Декомпозиция остальных опций предоставляется по запросу.

8. Конфигурации и сроки

Разные комбинации пакетов и опций дают разный срок и бюджет. Ниже — типовые конфигурации, которые мы видим для SaaS-проектов вашего профиля.

#	Конфигурация	Состав	Сумма	Срок
К1	Минимум для демонстрации	Пилот	2 500 000 ₽	9–11 нед
К2	MVP для первых пилотных клиентов	Старт	3 800 000 ₽	13–15 нед
К3	Коммерческий запуск ⭐	Бизнес	5 300 000 ₽	17–19 нед
К4	Enterprise-готовность	Премиум	6 550 000 ₽	21–23 нед
К5	Бизнес + CAD-интеграции	Бизнес + O2	6 130 000 ₽	20–22 нед
К6	Бизнес + CAD + Реестр рос. ПО	Бизнес + O2 + O3	6 480 000 ₽	21–23 нед
К7	Бизнес + все «quality» опции	Бизнес + O1 + O3 + O4	6 540 000 ₽	20–22 нед
К8	Премиум + White-label	Премиум + O6	7 130 000 ₽	24–26 нед
К9	Полный «максимум»	Премиум + все 6 опций	9 870 000 ₽	28–30 нед

Как читать таблицу. Сроки указаны при работе команды полным составом (см. раздел 16). Параллелизация нескольких опций возможна — например, O3 (Реестр российского ПО) идёт отдельным юридическим треком и не добавляет времени на основной разработке. Опции, которые трогают backend-архитектуру (O2, O5), требуют последовательной интеграции — они добавляют чистое время.

9. Наша рекомендация

Для вашей ситуации мы рекомендуем пакет «Бизнес» (5 300 000 ₽, 17–19 недель).

Четыре причины:

Полный коммерческий цикл с первого дня запуска. Пакет включает биллинг (ЮKassa B2B) + ЭДО (Контур.Диадок УПД) + автовыставление счетов. Это значит: в день запуска вы можете подписать первый договор с клиентом, выставить счёт, получить оплату на расчётный счёт и отправить закрывающий УПД — без ручной работы бухгалтера. В «Старте» это всё — руками.
Авто-заполнение реквизитов снимает главную боль onboarding. Ваши будущие клиенты — проектные организации — не имеют внутренних справочников СРО/НОПРИЗ. Первая сессия без авто-заполнения — это 30+ минут ручного ввода организационных данных; часть пользователей «отваливается» на этом шаге. В «Бизнесе» пользователь вводит ИНН → подтягивается вся карточка ЕГРЮЛ (DaData), подтягивается членство в СРО (НОПРИЗ/НОСТРОЙ opportunistic lookup) → onboarding сокращается до 5 минут.
Dynamic XSD CI/CD — страховка от v01.07 и последующих миграций. Версия v01.07 XSD уже опубликована (11.03.2026) и становится обязательной 11.06.2026 — внутри срока разработки нашего проекта. В «Бизнесе» CI/CD-пайплайн автоматически тестирует новую схему на labelled-set и алертит при регрессе. В «Старте» миграция потребует hotfix-релиза вручную. Рынок таких «пропусков» не прощает — ФЛК ЕЦПЭ с 29.01.2026 автоматически отклоняет пакеты старой версии.
0 % эквайринг на B2B-платежах — реальный выигрыш в unit economics. При целевом ARPU 30 000 ₽/tenant/мес ЮKassa B2B-платежи через СберБизнес экономят вам ~1 000 ₽/tenant/мес по сравнению с картами (2,5–2,8 % + НДС 22 %). На 50 tenants это ~50 000 ₽/мес — больше, чем стоит Диадок и месячная инфраструктура, вместе взятые.

Апгрейд до «Премиум» имеет смысл, если у вас на горизонте крупные корпоративные клиенты (>1 000 ПЗ/мес), требующие изолированной БД, — или если вам важна помощь в получении Реестра российского ПО сразу в основном проекте (иначе — через опцию O3).

Допустимый минимум — «Старт», если вы готовы первые 3–6 месяцев работать без биллинга и ЭДО, выставляя счета вручную, и потом добавить эти модули отдельным заказом (ориентировочно ~1 500 000 ₽).

10. Бизнес-выгоды (ROI)

Ниже — количественные оценки выгод от запуска продукта. Все цифры — на основе ответов Данилы на discovery (2026-04-23) и бенчмарков рынка РФ construction SaaS.

#	Выгода	Количественный эффект
B1	Сокращение времени подготовки XML ПЗ	С 8 до 2 часов на документ (–75 %). При ставке инженера 2 500 ₽/час — экономия ~15 000 ₽ на каждый документ
B2	Охват целевого рынка	500 ПЗ/мес на платформе × ~15 000 ₽ экономии = 7,5 млн ₽/мес ценности, которую продукт генерирует для пользователей
B3	Потенциальная выручка SaaS	При 20–30 tenants × 20 000–30 000 ₽/мес базовой подписки + 5–10 included docs + 50–100 ₽/PZ overage → ARR 0,6–1,5 млн ₽/мес
B4	Окупаемость разработки (Бизнес-пакет)	5,3 млн ₽ ÷ средний ARR 1 млн ₽/мес = 5–9 месяцев при плановом темпе привлечения tenants
B5	Маржа на документ (COGS vs. тариф)	Цена: 100 ₽/ПЗ overage vs. COGS: 25–50 ₽/ПЗ (LLM + инфра на документ) = валовая маржа 50–75 %
B6	Снижение числа возвратов ФЛК	Preflight-валидатор ловит XSD-ошибки до выгрузки в ЕГРЗ → ожидаемое сокращение возвратов на 70–80 % у пользователей
B7	Сокращение onboarding tenant'а	С 30+ минут (ручной ввод реквизитов) до 5 минут (авто-заполнение) — критично для снижения drop-off на старте пробного периода

Дополнительный эффект — позиционирование. На рынке РФ нет ни одного продукта, который делает AI-извлечение из исходной ПЗ в XML — все конкуренты работают через ручной ввод или браузерные формы. Это ваш главный дифференциатор, который позволит устанавливать цену на 30–50 % выше, чем у простых XML-редакторов.

Часть II: Техническое задание

11. Границы MVP

MVP определяется как рекомендованный пакет «Бизнес» — ядро + весь Stage 1 + Stage 2 ядро + биллинг + ЭДО + авто-заполнение. Ниже — полный перечень компонентов MVP и их зависимости.

flowchart TB
    subgraph CORE["Ядро (все пакеты)"]
        Y1["Я1: Инфраструктура"]
        Y2["Я2: Auth + проекты"]
        Y3["Я3: PDF/DOCX парсинг"]
        Y4["Я4: Dynamic XSD loader"]
        Y5["Я5: AI-извлечение"]
        Y6["Я6: XML Generator"]
        Y7["Я7: XSD-валидатор"]
        Y8["Я8: Двухпанельный UI"]
        Y9["Я9: Деплой + мониторинг"]
    end

    subgraph START["Старт (поверх Ядра)"]
        S1["3 класса объектов"]
        S2["Multi-tenant + RLS"]
        S3["Quality-gate 50 PZ"]
        S4["Полный XSD охват Stage 1"]
    end

    subgraph BIZ["Бизнес (поверх Старта)"]
        B1["ЮKassa B2B биллинг"]
        B2["Контур.Диадок УПД"]
        B3["DaData ЕГРЮЛ"]
        B4["НОПРИЗ/НОСТРОЙ lookup"]
        B5["Stage 2 ядро: SIG + hash + версии"]
        B6["Dynamic XSD CI/CD"]
    end

    subgraph PREM["Премиум (поверх Бизнеса)"]
        P1["DB-per-tenant isolation"]
        P2["Реестр российского ПО"]
        P3["Qwen3-32B preparation"]
        P4["OpenTelemetry + GlitchTip"]
    end

    Y1 --> Y2 --> Y3 --> Y5
    Y4 --> Y6 --> Y7
    Y5 --> Y6
    Y7 --> Y8
    Y9 --> Y1

    CORE --> S1
    S1 --> S2 --> S3 --> S4
    S4 --> B1
    B1 --> B2 --> B3 --> B4
    B4 --> B5 --> B6
    B6 --> P1

    style CORE fill:#14532d,stroke:#22c55e
    style START fill:#172554,stroke:#3b82f6
    style BIZ fill:#78350f,stroke:#f59e0b
    style PREM fill:#3b0764,stroke:#a855f7

Что входит в MVP (пакет «Бизнес») — чек-лист:

Что НЕ входит в MVP, но входит в дорожную карту Stage 3:

OCR отсканированных приложений (планируется после достижения 1 500 ПЗ/мес)
Qwen3-32B self-hosted как primary LLM (рассматривается, когда COGS на LLM начнёт превышать GigaChat-рейты)
Полная автоматизация раскладывания приложенных файлов по секциям XSD (сейчас — полуавтоматически)
Поддержка ведомственных экспертиз (Росатом, РЖД) — вне scope по договорённости

12. Компоненты системы

Ниже — подробное описание каждого компонента MVP: что делает, как устроено, какие технологии, критерии готовности.

12.1. Extraction Pipeline (Я3 + Я5)

Назначение. Превратить исходный PDF/DOCX в структурированный JSON с полями для XSD + confidence-score для каждого поля + source-pointer (страница/координаты) для UI-подсветки.

Алгоритм:

flowchart LR
    A["PDF/DOCX<br/>200+ стр"] --> B["Docling + PyMuPDF<br/>текст + таблицы<br/>+ char positions"]
    B --> C["GigaChat-2 Lite<br/>classify sections<br/>(12 разделов ПП 87)"]
    C --> D["Regex rules<br/>~150 typed fields<br/>(ИНН, СНИЛС, даты)"]
    D --> E["GigaChat-2 Max<br/>hierarchical extraction<br/>per section, JSON-schema<br/>constrained"]
    E --> F["Hallucination<br/>mitigation stack:<br/>cite-verify,<br/>cross-field rules,<br/>self-consistency"]
    F --> G["Structured JSON<br/>+ confidence scores<br/>+ source pointers"]

    style A fill:#172554,stroke:#3b82f6
    style B fill:#14532d,stroke:#22c55e
    style C fill:#78350f,stroke:#f59e0b
    style D fill:#78350f,stroke:#f59e0b
    style E fill:#78350f,stroke:#f59e0b
    style F fill:#450a0a,stroke:#ef4444
    style G fill:#3b0764,stroke:#a855f7

Технологии:

Docling (IBM, MIT-license) — основной экстрактор с TableFormer для сложных таблиц
PyMuPDF — character-positions, fallback на простой текст
GigaChat-2 Max / Lite (Сбер, РФ-размещение, 152-ФЗ-friendly) — классификация и извлечение
Regex-правила — ~150 детерминированных полей (ФИО паттерны, СНИЛС checksum, ИНН/ОГРН валидация, даты, числа с единицами)
XGrammar — JSON-schema constrained decoding

Конкретный пример извлечения поля ProjectName (название объекта):

Исходный PDF (стр. 3, строка 12):
"Наименование объекта: Жилой комплекс «Восход» (2-я очередь,
блок-секции 7-10), г. Нижний Новгород, Канавинский район"

Regex-правило: "Наименование объекта:\s*(.+?)(?=\n[А-Я])"
→ Match: "Жилой комплекс «Восход» (2-я очередь, блок-секции 7-10), г. Нижний Новгород, Канавинский район"
→ confidence: 0.95 (regex уверенность)
→ source_page: 3, bbox: [120, 245, 580, 268]

Бенчмарки (из research, labelled-set 50 ПЗ):

Детерминированные поля (regex): F1 = 0,95
LLM-извлечение (GigaChat-2 Max hierarchical): F1 = 0,85–0,90
Гибрид (regex + LLM + hallucination stack): F1 = 0,88–0,92

12.2. XML Generator (Я4 + Я6)

Назначение. Программная сборка XML-документа из проверенных человеком данных по правилам XSD. LLM НЕ задействован.

Алгоритм:

Dynamic XSD loader подгружает активную версию схемы (v01.06 / v01.07) из файла.
xmlschema парсит XSD и строит Python-классы полей с типами.
Бэкенд мапит пользовательские значения ({field_name: value}) на структуру XSD.
Для условных полей (Industrial-специфичные, Linear-специфичные) применяется классификатор типа объекта.
Автоматически генерируются технические поля (Слой 2): SchemaVersion, ObjectID (GUID), DangerousAndComplex (false по умолчанию), и др.
lxml сериализует итоговый XML с правильными namespace'ами и порядком элементов.

Технологии:

lxml (быстрая C-привязка к libxml2) — быстрая сериализация и первичная валидация
xmlschema (Python, чистый XSD 1.1) — детальная работа с assertions, keyref, union-типами

Почему именно этот стек: lxml в 5–10 раз быстрее, но не поддерживает XSD 1.1 assertions; xmlschema поддерживает XSD 1.1, но медленнее. Двухступенчатый пайплайн (lxml для быстрого pass, xmlschema для детальной финальной проверки) даёт лучшее из двух миров.

12.3. XSD Validator (Я7)

Назначение. Финальная проверка сгенерированного XML против актуальной XSD Минстроя + локализация ошибок на понятный русский.

Что делает:

Запускает двойную валидацию: lxml (быстрый pass) → xmlschema (детальный pass с assertions)
Переводит XSD-сообщения об ошибках (например, [xsd:pattern] violation on element 'SNILS') в человекочитаемое («СНИЛС должен содержать 11 цифр»)
Подсвечивает проблемные поля в UI-редакторе
Блокирует экспорт XML до устранения всех ошибок

Пример:

XSD: <xs:element name="SNILS">
       <xs:simpleType>
         <xs:restriction base="xs:string">
           <xs:pattern value="\d{11}"/>
         </xs:restriction>
       </xs:simpleType>
     </xs:element>

Пользовательский ввод: "123-456-789 00"
XSD-ошибка: "Pattern violation on SNILS"
Локализованная: "СНИЛС должен содержать ровно 11 цифр подряд, без пробелов и тире. Попробуйте: 12345678900"

12.4. Multi-tenant layer (Я2)

Модель: shared-DB + schema-per-tenant + RLS defence-in-depth (см. раздел 3 и post-research stack).

Реализация:

Каждый tenant получает отдельный Postgres schema (tenant_a, tenant_b, ...) с одинаковым набором таблиц.
Общие данные (plans, usage_events, system-wide audit) — в shared schema public, защищены RLS-политиками.
Все Python-запросы идут от tenant-scoped роли с SET LOCAL app.current_tenant.
Admin-операции (миграции, backup) выполняются отдельной ролью с explicit BYPASSRLS, недоступной приложению.
PgBouncer transaction pooling: SELECT set_config('app.current_tenant', :tid, true) (transaction-scoped).

Footguns, от которых защищаемся:

Superuser и owner-доступы bypass RLS по умолчанию → применяем ALTER TABLE … FORCE ROW LEVEL SECURITY.
USING без WITH CHECK → всегда пишем оба.
Supabase MCP-incident 2025: anon/service_role ключи на request-path — мы используем tenant-scoped ключи только server-side.

12.5. Billing + ЭДО (Бизнес+)

Поток от заявки до закрывающего документа:

flowchart LR
    A["Клиент подписал оферту<br/>(click-wrap, без КЭП)"] --> B["Выставлен счёт<br/>(API ЮKassa)"]
    B --> C["Клиент платит<br/>с р/с через СберБизнес<br/>(b2b_sberbank)"]
    C --> D["Webhook: статус paid"]
    D --> E["Ежемесячный cron<br/>собирает usage_events"]
    E --> F["Генерация УПД через<br/>Контур.Диадок API"]
    F --> G["Клиент подписывает<br/>УПД со своей КЭП"]
    G --> H["Polling статуса<br/>от Диадока"]

    style A fill:#172554,stroke:#3b82f6
    style B fill:#14532d,stroke:#22c55e
    style C fill:#14532d,stroke:#22c55e
    style D fill:#78350f,stroke:#f59e0b
    style E fill:#78350f,stroke:#f59e0b
    style F fill:#3b0764,stroke:#a855f7
    style G fill:#3b0764,stroke:#a855f7
    style H fill:#450a0a,stroke:#ef4444

Usage metering: PostgreSQL таблица usage_events с полями (tenant_id, event_type, quantity, idempotency_key, created_at). idempotency_key UNIQUE + ON CONFLICT DO NOTHING = защита от двойного списания. Nightly cron агрегирует события за период и обновляет period_usage для биллинга.

13. Модель данных

Основные JSON-схемы для API и внутреннего хранения.

13.1. Project (проект-ПЗ пользователя)

{
  "id": "uuid",
  "tenant_id": "uuid",
  "created_by": "uuid",
  "name": "Жилой комплекс «Восход», 2 очередь",
  "object_class": "NonIndustrial",
  "schema_version": "01.06",
  "status": "draft | in_review | validated | exported",
  "source_file_id": "uuid",
  "created_at": "2026-04-24T10:00:00Z",
  "updated_at": "2026-04-24T14:30:00Z",
  "version": 3,
  "parent_version_id": "uuid | null"
}

13.2. ExtractedField (извлечённое поле с source-pointer)

{
  "id": "uuid",
  "project_id": "uuid",
  "xsd_path": "/ExplanatoryNote/NonIndustrialObject/Name",
  "value": "Жилой комплекс «Восход» (2-я очередь, блок-секции 7-10), г. Нижний Новгород, Канавинский район",
  "confidence": 0.92,
  "source": {
    "type": "regex | llm | manual",
    "page": 3,
    "bbox": [120, 245, 580, 268],
    "quote": "Наименование объекта: Жилой комплекс «Восход» ..."
  },
  "status": "suggested | confirmed | edited | rejected",
  "edited_by": "uuid | null",
  "edited_at": "2026-04-24T15:00:00Z"
}

13.3. UsageEvent (для биллинга)

{
  "id": "uuid",
  "tenant_id": "uuid",
  "event_type": "pz_generated | pz_validated | tenant_active",
  "quantity": 1,
  "metadata": {
    "project_id": "uuid",
    "schema_version": "01.06"
  },
  "idempotency_key": "sha256(project_id + event_type + date)",
  "created_at": "2026-04-24T15:00:00Z"
}

13.4. Tenant

{
  "id": "uuid",
  "name": "ООО «ПроектСтройМонтаж»",
  "inn": "7709123456",
  "plan": "starter | business | enterprise",
  "isolation_tier": "schema | database",
  "created_at": "2026-04-01T00:00:00Z",
  "status": "trial | active | suspended",
  "contact_email": "admin@company.ru",
  "diadoc_boxid": "string | null"
}

13.5. XSD Schema (динамический loader)

{
  "id": "uuid",
  "version": "01.06",
  "file_path": "s3://egrz-xsd/explanatorynote-01-06.xsd",
  "published_at": "2025-10-29",
  "mandatory_from": "2026-01-29",
  "status": "active | upcoming | deprecated",
  "quality_gate_passed": true,
  "quality_gate_results": {
    "labelled_set_size": 50,
    "f1_score": 0.88,
    "regressions_vs_previous": []
  }
}

14. API-спецификация

Минимальный набор endpoints для интеграции внешних систем (CAD, корпоративных порталов). Полная OpenAPI-спека генерируется автоматически из FastAPI.

14.1. Endpoints

Метод	Путь	Описание
POST	`/api/v1/auth/login`	Авторизация, возвращает JWT
POST	`/api/v1/projects`	Создать проект
GET	`/api/v1/projects`	Список проектов tenant'а
GET	`/api/v1/projects/{id}`	Детали проекта
POST	`/api/v1/projects/{id}/upload`	Загрузить PDF/DOCX
POST	`/api/v1/projects/{id}/extract`	Запустить AI-извлечение (async)
GET	`/api/v1/projects/{id}/fields`	Список извлечённых полей
PATCH	`/api/v1/projects/{id}/fields/{field_id}`	Подтвердить / исправить / отклонить поле
POST	`/api/v1/projects/{id}/generate`	Сгенерировать XML
GET	`/api/v1/projects/{id}/download`	Скачать готовый XML
GET	`/api/v1/billing/usage`	Текущее использование за период
GET	`/api/v1/billing/invoices`	Список счетов
POST	`/api/v1/webhooks/yukassa`	Webhook от ЮKassa
POST	`/api/v1/webhooks/diadoc`	Webhook от Контур.Диадок

14.2. Пример: создание проекта

Request:

POST /api/v1/projects
Authorization: Bearer eyJ...
Content-Type: application/json

{
  "name": "Жилой комплекс «Восход»",
  "object_class": "NonIndustrial",
  "schema_version": "01.06"
}

Response 201:

{
  "id": "550e8400-e29b-41d4-a716-446655440000",
  "name": "Жилой комплекс «Восход»",
  "object_class": "NonIndustrial",
  "schema_version": "01.06",
  "status": "draft",
  "created_at": "2026-04-24T10:00:00Z"
}

14.3. Пример: webhook от ЮKassa (paid)

{
  "event": "payment.succeeded",
  "object": {
    "id": "pay_abc123",
    "status": "succeeded",
    "amount": { "value": "30000.00", "currency": "RUB" },
    "payment_method": { "type": "b2b_sberbank" },
    "metadata": { "tenant_id": "uuid", "invoice_id": "uuid" }
  }
}

14.4. Коды ошибок

Код	Значение	Пример
400	Invalid payload	Отсутствует обязательное поле
401	Unauthorized	Истёк JWT, нужен refresh
403	Forbidden	Недостаточно прав роли (например, engineer пытается финализировать без ГИП)
404	Not found	Проект с указанным ID не существует в контексте tenant'а
409	Conflict	Пытаемся сгенерировать XML, пока не все поля подтверждены
422	XSD validation failed	Готовый XML не проходит валидацию (подробности в payload.errors[])
429	Rate limit exceeded	Tenant превысил лимит API-вызовов (по тарифу)
500	Internal error	Неожиданная ошибка, alert в GlitchTip

15. Пользовательские сценарии

Ключевые user-stories для роли «инженер-проектировщик» (основной пользователь платформы). Формат Given / When / Then.

US-1: Первая генерация XML на платформе

«Как инженер-проектировщик, я хочу загрузить PDF с пояснительной запиской и получить валидный XML за 2 часа вместо 8».

Given: я авторизован в платформе, мой tenant активен, у меня есть PDF 150-страничной ПЗ. When: я создаю новый проект → загружаю PDF → запускаю извлечение → проверяю поля в двухпанельном редакторе → подтверждаю/правлю → нажимаю «Сгенерировать XML». Then: система генерирует валидный XML, проходящий XSD-проверку; я вижу финальный документ и могу его скачать. Полный цикл занимает ≤ 2 часа.

US-2: Коррекция ошибочно извлечённого поля

«Как инженер, я хочу увидеть, откуда взято каждое значение, и исправить его, если AI ошибся».

Given: проект на стадии review, AI извлёк значение для поля FunctionalPurpose. When: я кликаю на поле в правой панели. Then: PDF-viewer слева прокручивается к странице, где найдено значение, и подсвечивает исходный фрагмент. Я сравниваю, вижу ошибку, правлю значение в инпуте → система помечает поле как edited и подсвечивает его жёлтым в списке.

US-3: Валидация перед экспортом

«Как ГИП, я хочу быть уверен, что сгенерированный XML не будет отклонён ФЛК ЕЦПЭ».

Given: все поля в проекте подтверждены инженером. When: я нажимаю «Финализировать» → система запускает полный цикл: XSD-валидация → cross-field consistency checks → preflight-правила ФЛК. Then: если всё ok — статус validated, я могу скачать XML. Если ошибки — я вижу список с подсветкой проблемных полей и понятным описанием, что исправить.

US-4: Работа с новой версией XSD

«Как админ tenant'а, я хочу, чтобы при выходе новой версии XSD Минстроя мои инженеры автоматически переключились на неё без простоя».

Given: Минстрой опубликовал XSD v01.07 (обяз. с 11.06.2026). When: моя команда AiDevTeam получила сигнал о публикации → загрузила новую XSD в dynamic loader → CI/CD-пайплайн прогнал её на labelled-set → нет регрессий → schema помечается upcoming. Then: за 7 дней до даты mandatory_from система автоматически переключает active на v01.07. Инженеры видят уведомление в UI («с [дата] все новые проекты будут генерировать XML v01.07»), открытые проекты в статусе draft — апгрейдятся автоматически, validated — остаются в старой версии.

US-5: Биллинг конца месяца

«Как финансист tenant'а, я хочу получить УПД с акта выполненных работ и счётом-фактурой в одном файле, подписанным через Диадок».

Given: месяц закрылся, tenant сгенерировал 12 XML (6 included + 6 overage) по тарифу «Professional». When: 1-го числа следующего месяца cron запускает ежемесячный billing cycle → агрегирует usage_events → формирует счёт → отправляет УПД через Диадок. Then: я получаю уведомление в Диадоке о поступлении УПД, подписываю его своей КЭП, статус синхронизируется обратно в платформу.

US-6: Авто-заполнение реквизитов при onboarding

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

Given: я впервые захожу в платформу, нужно заполнить данные моей проектной организации. When: я ввожу ИНН в поле «ИНН организации». Then: система через DaData подтягивает ОГРН, КПП, адрес, название. Через НОПРИЗ/НОСТРОЙ (opportunistic) пытается найти членство в СРО. Я проверяю данные и подтверждаю → onboarding занял 5 минут вместо 30.

US-7: Работа с приложенными файлами (Stage 2)

«Как ГАП, я хочу, чтобы система автоматически связала SIG-файлы подписей с исходными разделами ПД».

Given: я загрузил в проект 12 PDF-разделов ПД + соответствующие .sig файлы. When: я запускаю auto-обнаружение. Then: система парсит имена файлов (по Приказу 783/пр) → сопоставляет .sig с исходным разделом → вычисляет SHA-GOST hash каждого документа → записывает в XML структуру ProjectDocumentation со ссылками на файлы и контрольными суммами.

16. Команда проекта

Ниже — команда под рекомендованный пакет «Бизнес». Для «Пилота» состав меньше (не все роли); для «Премиум» — расширенный.

16.1. Состав и ставки

Роль	Основные задачи	Ставка, ₽/час
Tech Lead / AI-архитектор	Архитектура, design review, LLM-стратегия, ключевые решения	3 400
AI / ML Engineer	Prompt engineering, hallucination mitigation, labelled-set, quality gate	2 700
Senior Backend Engineer	FastAPI, multi-tenant, биллинг, интеграции (Диадок, ЮKassa, DaData)	2 400
Senior Frontend Engineer	Next.js, двухпанельный UI, tenant portal	2 400
DevOps Engineer	Yandex Cloud, Docker, CI/CD, мониторинг, compliance	2 400
QA Engineer	Тест-планы, автотесты, регрессии, интеграционное тестирование	2 000
Project Manager	Планирование, еженедельные демо, управление изменениями, коммуникация	2 400

16.2. Калькуляция стоимости по пакетам (полная, по ролям)

Статья	Пилот	Старт	Бизнес ⭐	Премиум
Tech Lead (100 / 160 / 220 / 300 ч)	340 000	544 000	748 000	1 020 000
AI Engineer (220 / 330 / 460 / 620 ч)	594 000	891 000	1 242 000	1 674 000
Senior Backend (200 / 290 / 440 / 580 ч)	480 000	696 000	1 056 000	1 392 000
Senior Frontend (160 / 230 / 320 / 410 ч)	384 000	552 000	768 000	984 000
DevOps (70 / 95 / 150 / 180 ч)	168 000	228 000	360 000	432 000
QA (60 / 85 / 140 / 170 ч)	120 000	170 000	280 000	340 000
PM (65 / 95 / 150 / 195 ч)	156 000	228 000	360 000	468 000
Итого разработка	2 242 000	3 309 000	4 814 000	6 310 000
Непредвиденные расходы (~11–15 %)	258 000	491 000	766 000	970 000
Итого без скидки	2 500 000	3 800 000	5 580 000	7 280 000
Скидка	—	—	−5 %	−10 %
ИТОГО к оплате	2 500 000	3 800 000	5 300 000	6 550 000

Итоговые часы:

Пакет	Всего часов	Срок календ.	Состав команды в спринте
Пилот	875	9–11 нед	1 Tech Lead (part-time) + 1 AI + 1 Backend + 1 Frontend + 1 DevOps (part-time) + 1 QA (part-time) + 1 PM (part-time)
Старт	1 285	13–15 нед	тот же + выделенный QA
Бизнес	1 880	17–19 нед	тот же + второй Backend на биллинг/ЭДО, выделенный DevOps
Премиум	2 455	21–23 нед	тот же + второй AI на Qwen prep, fulltime PM

17. Дорожная карта и план спринтов

План спринтов для рекомендованного пакета «Бизнес». Спринт = 2 недели. Всего 9 спринтов ≈ 18 недель.

gantt
    title Дорожная карта Бизнес 17-19 недель
    dateFormat YYYY-MM-DD
    excludes weekends

    section Sprint 0
    Kickoff и инфра setup          :a0, 2026-05-12, 5d
    section Sprint 1-2
    Ядро Auth проекты PDF parse    :a1, after a0, 18d
    section Sprint 3-4
    AI-пайплайн и XSD generator    :a2, after a1, 18d
    section Sprint 5
    Quality-gate 50 PZ Multi-tenant:a3, after a2, 9d
    section Sprint 6
    Биллинг ЮKassa и DaData        :a4, after a3, 9d
    section Sprint 7
    Диадок УПД и НОПРИЗ lookup     :a5, after a4, 9d
    section Sprint 8
    Stage 2 ядро SIG hash версии   :a6, after a5, 9d
    section Sprint 9
    Приёмка и деплой               :a7, after a6, 5d

17.1. Ключевые milestones

Sprint	Дата (ориент.)	Результат	Демо клиенту
0	12–16 мая	Инфра поднята, CI/CD работает, dev-окружение готово	Да
1–2	19 мая – 12 июня	Пользователь может загрузить PDF и увидеть извлечённый текст	Да
3–4	15 июня – 10 июля	Первый валидный XML на одном классе, двухпанельный редактор	Да (ключевое демо)
5	13–24 июля	3 класса объектов, multi-tenant, quality-gate пройдена	Да
6	27 июля – 7 авг	Биллинг работает, пользователь может оплатить через СберБизнес	Да
7	10–21 авг	УПД формируется и отправляется через Диадок; ЕГРЮЛ lookup работает	Да
8	24 авг – 4 сент	Stage 2: SIG, hash, версионирование	Да
9	7–11 сент	Финальная приёмка, деплой в продакшен	—

17.2. Управление изменениями

Изменения в середине проекта (Change Request) оцениваются отдельно:

Мелкие (< 8 часов) — бесплатно, если не ломают архитектуру
Средние (8–40 часов) — оценка за 2 рабочих дня, согласование через договор-приложение
Крупные (> 40 часов) — полный цикл оценки, возможно продление сроков

18. Предварительные исследования

В рамках подготовки КП мы уже провели серьёзное технологическое и регуляторное исследование. Ниже — ключевые результаты и открытые вопросы.

18.1. Выполненные исследования

#	Тема	Ключевой результат
И1	XSD Минстроя v01.06	872 элемента, 174 комплексных типа, 1 980 enumerations, 3 класса объектов — подтверждённая структура
И2	Таймлайн версий XSD	v01.01 → v01.07 публикации и даты обязательности. Миграция v01.06 → v01.07 попадает внутрь срока разработки — учтено в архитектуре (dynamic loader)
И3	Процесс подачи в ЕГРЗ 2026	ЕЦПЭ (`platformaexpert.ru`), validator `checkxml.platformaexpert.ru`, сроки 42 р.д. + 20 р.д. продление, проверка комплектности до 10 р.д.
И4	Подпись (crypto)	Только CAdES detached (BES/T/A). ГОСТ Р 34.11-2012 «Стрибог». XMLDSig/XAdES/Adobe PDF signatures отвергаются ЕЦПЭ
И5	Открытые реестры	НОПРИЗ НРС — нет публичного API. reestr.nopriz.ru / reestr.nostroy.ru — есть endpoints, но не документированы. ЕГРЮЛ через DaData — стабильный путь
И6	Библиотеки парсинга	Docling (IBM, MIT) + PyMuPDF + docx2python — оптимальный стек для русских construction docs
И7	LLM-стратегия	GigaChat-2 Max primary (152-ФЗ РФ, MERA топ-3) + GigaChat-2 Lite routing + Qwen3-32B self-hosted (Stage 2)
И8	Биллинг РФ	ЮKassa B2B через СберБизнес — уникальный 0 % канал для юрлиц. Контур.Диадок — primary для УПД
И9	Compliance	152-ФЗ УЗ-3 (не КИИ), 242-ФЗ резидентность, 63-ФЗ КЭП. Всё нужно проектировать изначально
И10	Ценовые бенчмарки	Рынок РФ construction SaaS: ~20–300 k ₽/мес на tenant, зависит от глубины продукта

18.2. Открытые вопросы (требуют валидации на первом этапе)

#	Вопрос	Как будем решать
В1	F1-score GigaChat-2 Max на полном 700-поле schema	Quality gate в Sprint 5: 50 эталонных ПЗ с разметкой, объективные метрики
В2	Доля scanned PDF среди реальных клиентских документов	Валидация на первых 3–5 tenants. Если > 50 % scan — добавляем OCR в scope (пересогласование)
В3	Стабильность endpoints reestr.nopriz.ru/nostroy.ru	Мониторим 30 дней. Если API «ломается» чаще раза в месяц — переходим на DaData-only + ручной ввод НРС
В4	Детальные ценники DaData/Контур.Фокус в 2026	Получаем коммерческое предложение DaData на старте проекта
В5	Реальная доля ИП среди tenants (для card-based billing)	Валидация на первых tenants. Если > 20 % ИП — приоритизируем CloudPayments subscription API
В6	Нужен ли отдельный путь для Мосгосэкспертизы	По текущему состоянию — тот же ЕЦПЭ, но возможны специфичные UI-wrappers. Валидируем на первом pilot-tenant из Москвы

19. Стратегия тестирования

Многоуровневая стратегия с чёткими критериями приёмки на каждом уровне.

Уровень	Инструменты	Что тестируем	Критерий
Unit-тесты	pytest, jest	Отдельные функции: regex-правила, XSD-генерация, валидаторы	Покрытие backend ≥ 70 %, frontend ≥ 50 %
Integration-тесты	pytest + testcontainers, playwright	Взаимодействие компонентов: API + DB, API + Redis, webhooks	Все критические user-flow проходят (10+ сценариев)
E2E-тесты	playwright, synthetic tests	Полный путь пользователя от логина до экспорта XML	5 базовых сценариев (US-1, US-3, US-5, US-6, US-7)
Quality-gate AI	Собственный framework + labelled-set 50 ПЗ	F1-score по полям, precision/recall	F1 ≥ 0,85 общий, F1 ≥ 0,95 на regex-полях
Performance	k6, locust	Нагрузочное 40 concurrent users, 500 PZ/мес	p95 API < 2 сек, p99 < 5 сек
Security	OWASP ZAP, bandit	Базовые sanity-чеки: SQL-injection, XSS, RLS bypass	0 критических / high находок
Compliance	Checklists 152-ФЗ/242-ФЗ/ФСТЭК-21	Уведомление РКН, хранение в РФ, audit log	Все пункты checklist пройдены

19.1. Quality Gate на labelled-set (ключевая проверка)

Labelled-set — 50 ПЗ с ручной разметкой всех полей эталонного XML. На старте Sprint 5:

Для каждой ПЗ:
  1. Прогнать extraction pipeline
  2. Сравнить extracted с gold-данными
  3. Считать precision, recall, F1 по каждому полю
  4. Агрегировать по классам: critical / important / nice-to-have
Критерий приёмки:
  - Critical поля (ИНН, СНИЛС, ОКС name, даты): F1 ≥ 0.95
  - Important (ТЭП, ресурсы): F1 ≥ 0.85
  - Nice-to-have: F1 ≥ 0.70
  - Общий F1 ≥ 0.85

Если F1 ниже — разработка AI-пайплайна продолжается до достижения порога. Без quality-gate pass пакет «Старт» и выше не принимается.

20. Развёртывание и инфраструктура

20.1. Целевая инфраструктура (Yandex Cloud)

Компонент	Сайзинг (Бизнес-пакет, 50 tenants, 500 ПЗ/мес)
API-серверы	2× Compute Cloud VM: 4 vCPU / 8 GB RAM, Ubuntu + Docker
Extraction workers	2× Compute Cloud VM: 8 vCPU / 16 GB RAM (CPU-only для MVP)
PostgreSQL	Managed PostgreSQL: 2 vCPU / 8 GB / 50 GB SSD, HA (2 replicas)
Redis	Managed Redis (Valkey-compatible): 2 vCPU / 4 GB
Object Storage	Yandex Object Storage, ~1 TB (growing)
Load Balancer	L7 Application Load Balancer с SSL termination
DNS	Cloud DNS, wildcard cert Let's Encrypt

Ориентировочная стоимость инфраструктуры (для клиента):

Low (no HA, no GPU): ~55 000 ₽/мес
Medium (basic HA, burst GPU): ~75 000 ₽/мес ← рекомендация для MVP
High (always-on GPU, full HA): ~130 000 ₽/мес

20.2. CI/CD pipeline

GitHub Actions:
  - lint (ruff, black, eslint)
  - type-check (mypy, tsc)
  - unit tests (pytest, jest)
  - integration tests (testcontainers)
  - build Docker images
  - push to Yandex Container Registry
  - deploy via Ansible / ArgoCD

20.3. Мониторинг и наблюдаемость

Слой	Инструмент
Метрики	VictoriaMetrics + Grafana OSS (15 дашбордов: per-tenant queue lag, extraction latency, billing events, storage growth)
Логи	Yandex Cloud Logging или self-hosted Loki, structured JSON format
Tracing	OpenTelemetry → Yandex Cloud Tracing (Премиум)
Error tracking	GlitchTip self-hosted (Премиум) или Sentry OSS
Alerts	vmalert → Telegram bot + email

20.4. Резервное копирование

Тип данных	Частота	Хранение	RPO / RTO
PostgreSQL WAL	Continuous	Yandex Managed PG auto-backup	RPO 1 мин, RTO 1 час
Object Storage	Versioning ON	90 дней	Немедленный откат
Конфигурация (K8s, secrets)	Daily snapshot	GitOps repo + Vault	1 час

20.5. Compliance (минимум для MVP)

Уведомление РКН об обработке ПДн до запуска (Бизнес-пакет, бонус)
Положение об обработке ПДн, модель угроз (Бизнес-пакет, бонус)
Все данные хранятся в РФ (Yandex Cloud / Cloud.ru), без cross-border
Audit log всех действий пользователей (retention 3 года минимум)
TLS 1.2+ on wire, encryption at rest в Object Storage
Подача заявки в Реестр российского ПО (опция O3 или Премиум-пакет)

21. Критерии приёмки

Чёткие, измеримые критерии для каждого модуля. Без субъективных формулировок.

21.1. Общие критерии (все пакеты)

Модуль	Критерий
Авторизация	Пользователь логинится за ≤ 3 сек, сессия живёт 7 дней, логаут мгновенный
Загрузка PDF/DOCX	Файл до 100 MB загружается за ≤ 30 сек на 10 Mbps
AI-извлечение (одна ПЗ)	Отрабатывает за ≤ 10 мин на 200-стр. документе
XSD-валидация	Отрабатывает за ≤ 5 сек
Скачивание XML	Файл отдаётся мгновенно (streaming response)
UI-редактор	Переключение между полями < 100 мс, подсветка источника < 500 мс

21.2. Бизнес-пакет (дополнительно)

Модуль	Критерий
ЮKassa B2B оплата	Счёт на оплату формируется за ≤ 5 сек, webhook обновляет статус за ≤ 30 сек
Диадок УПД	УПД генерируется и отправляется за ≤ 2 мин, polling каждые 10 минут
DaData ЕГРЮЛ lookup	Реквизиты ЮЛ подтягиваются за ≤ 3 сек
Multi-tenant изоляция	Тест: попытка обратиться к данным чужого tenant'а даже через прямой SQL — возвращает 0 строк
Quality gate (labelled-set 50 ПЗ)	F1 общий ≥ 0,85, критичные поля ≥ 0,95

21.3. Полный пакет с опциями — критерии приёмки добавляются согласно купленным опциям

22. Нефункциональные требования

#	Параметр	Порог (Бизнес)	Порог (Премиум)
N1	Время ответа API (p95)	≤ 2 сек	≤ 1 сек
N2	Время ответа API (p99)	≤ 5 сек	≤ 3 сек
N3	Параллельные пользователи	40	100+
N4	Uptime (SLA)	99,5 % за квартал	99,9 % за квартал
N5	Время загрузки UI (TTI)	≤ 3 сек на 3G	≤ 2 сек
N6	Покрытие тестами (backend)	≥ 70 %	≥ 80 %
N7	Покрытие тестами (frontend)	≥ 50 %	≥ 65 %
N8	Время обработки одной ПЗ (AI)	≤ 10 мин	≤ 5 мин (с GPU)
N9	Размер одного загружаемого документа	≤ 100 MB	≤ 500 MB
N10	RPO (recovery point objective)	15 мин	1 мин
N11	RTO (recovery time objective)	4 часа	1 час
N12	Audit log retention	3 года	20 лет (требование ГОСТ Р 7.0.97)

Часть III: Коммерческие условия

23. Как мы работаем

Подход — agile-спринты с чётким ритмом коммуникации и прозрачным управлением изменениями.

Активность	Частота	Формат
Демо спринта	Каждые 2 недели	Видеозвонок + демонстрация на staging-окружении
Еженедельный sync	1 раз в неделю (30 минут)	Статус, блокеры, решения
Доступ к staging	Постоянный	URL staging-сервера (с Sprint 0, обновляется после каждого merge в develop)
Канал связи	Постоянный	Telegram-группа + приоритетный email для продуктовых вопросов
Приёмка результатов	По завершении каждого спринта	Демо + чек-лист приёмки + sign-off от клиента

Управление изменениями: все изменения к ТЗ оформляются через Change Request (CR). Команда оценивает влияние на сроки и бюджет за 2 рабочих дня, обе стороны согласуют CR до начала работы.

Наше обещание по коммуникации: ответ на вопросы клиента в рабочие часы (10:00–19:00 МСК, пн–пт) — в течение 4 часов. P1-инциденты на staging/prod — в течение 1 часа.

24. Условия оплаты

Оплата привязана к достижению milestones, а не к прошедшему времени.

24.1. Пакет «Пилот» (2 500 000 ₽)

#	Событие	Оплата	Нарастающим итогом
1	Подписание договора (аванс)	750 000 ₽ (30 %)	750 000 ₽
2	Приёмка демо Sprint 3 (первый валидный XML)	1 250 000 ₽ (50 %)	2 000 000 ₽
3	Финальная приёмка + деплой	500 000 ₽ (20 %)	2 500 000 ₽

24.2. Пакет «Старт» (3 800 000 ₽)

#	Событие	Оплата	Нарастающим итогом
1	Подписание договора (аванс)	1 140 000 ₽ (30 %)	1 140 000 ₽
2	Приёмка demo Sprint 4 (multi-tenant + 3 класса)	1 520 000 ₽ (40 %)	2 660 000 ₽
3	Приёмка quality-gate Sprint 5 (F1 ≥ 0,85)	760 000 ₽ (20 %)	3 420 000 ₽
4	Финальная приёмка + деплой	380 000 ₽ (10 %)	3 800 000 ₽

24.3. Пакет «Бизнес» ⭐ (5 300 000 ₽)

#	Событие	Оплата	Нарастающим итогом
1	Подписание договора (аванс)	1 590 000 ₽ (30 %)	1 590 000 ₽
2	Приёмка demo Sprint 4 (валидный XML на 3 классах)	1 060 000 ₽ (20 %)	2 650 000 ₽
3	Приёмка Sprint 6 (биллинг ЮKassa работает)	1 060 000 ₽ (20 %)	3 710 000 ₽
4	Приёмка Sprint 8 (Stage 2 ядро, ЭДО Диадок)	1 060 000 ₽ (20 %)	4 770 000 ₽
5	Финальная приёмка + деплой	530 000 ₽ (10 %)	5 300 000 ₽

24.4. Пакет «Премиум» (6 550 000 ₽)

#	Событие	Оплата	Нарастающим итогом
1	Подписание договора (аванс)	1 965 000 ₽ (30 %)	1 965 000 ₽
2	Приёмка demo Sprint 4	982 500 ₽ (15 %)	2 947 500 ₽
3	Приёмка Sprint 6 (биллинг)	982 500 ₽ (15 %)	3 930 000 ₽
4	Приёмка Sprint 8 (Stage 2 ядро)	982 500 ₽ (15 %)	4 912 500 ₽
5	Приёмка Sprint 10 (DB-per-tenant + Реестр рос. ПО submitted)	982 500 ₽ (15 %)	5 895 000 ₽
6	Финальная приёмка + деплой	655 000 ₽ (10 %)	6 550 000 ₽

Форма оплаты: перевод на расчётный счёт ЮЛ / ИП. НДС — по стандартной схеме (или освобождение по п. 26 ст. 149 НК РФ после регистрации в Реестре российского ПО).

25. Ежемесячные расходы на эксплуатацию

После завершения разработки у клиента возникают повторяющиеся месячные расходы на инфраструктуру и сторонние сервисы. Ниже — прогноз для рекомендованного пакета «Бизнес» при нагрузке 20 tenants × 10 ПЗ/мес = 200 PZ/мес.

25.1. Инфраструктура Yandex Cloud

Статья	Low	Medium (реком.)	High
Compute (API + workers)	~14 000	~22 000	~45 000
Managed PostgreSQL + HA	~10 000	~15 000	~25 000
Managed Redis	~3 000	~4 500	~8 000
Object Storage (1 TB)	~2 200	~2 200	~2 200
Load Balancer + DNS	~2 000	~3 000	~5 000
Egress / Requests	~2 000	~4 000	~10 000
Monitoring (Yandex + VM)	~1 000	~2 000	~5 000
Резерв / страховка	~5 000	~7 000	~15 000
Инфра итого	~39 000	~60 000	~115 000

25.2. LLM-расходы (GigaChat-2 Max + Lite, гибрид с regex)

При расчёте 200 PZ/мес, hierarchical extraction с caching, hybrid (regex + LLM):

Статья	Оценка
GigaChat-2 Lite (classification)	~500 ₽/мес
GigaChat-2 Max (extraction, 150k токенов × 200 ПЗ × ₽0.65/1k)	~20 000 ₽/мес
Shadow evaluation (Claude Sonnet 4.5 на анонимизированной 50-PZ gold set)	~4 000 ₽/мес
LLM итого	~24 500 ₽/мес

Alternative: Qwen3-32B self-hosted (при росте > 1500 PZ/мес):

GPU инстанс (Yandex Cloud H100, part-time) ≈ 50 000 ₽/мес
Break-even ~1 500 PZ/мес

25.3. Сторонние сервисы

Сервис	Оценка ₽/мес
ЮKassa B2B (flat fee per transaction, 20 tenants × 1 payment/мес × ~100 ₽)	~2 000
ЮKassa card (card-fallback для 5 % платежей)	~1 500
Контур.Диадок (4 700 ₽/год за 600 УПД)	~400
DaData (API Standard Plan)	~500
КриптоПро лицензии (server-side не используются)	0
Сервисы итого	~4 400 ₽/мес

25.4. Итого OPEX

Сценарий	Итого ₽/мес	COGS на 1 PZ (при 200 PZ/мес)
Medium (рекомендованный)	~89 000	~440 ₽/PZ
High (с GPU для Qwen)	~144 000	~720 ₽/PZ

Unit-economics справка для целевого ценообразования SaaS:

Цена подписки конечному пользователю: 20 000–30 000 ₽/мес + 50–100 ₽/PZ overage
20 tenants × 25 000 ₽ = 500 000 ₽/мес ARR → после OPEX (89 000) валовая маржа ~82 %

26. Риски и митигация

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

#	Риск	Влияние	Митигация
R1	XSD v01.07 обязательна с 11.06.2026 — миграция внутри срока разработки	Высокое	Dynamic XSD loader в Ядре + CI/CD schema pipeline + автоматический тест на labelled-set при загрузке новой версии. Минстрой даёт 3-месячное окно миграции
R2	Русскоязычные LLM (GigaChat-2 Max) могут дать F1 < 0,85 на полном 500–800-поле schema	Высокое	Quality-gate на 50 эталонных ПЗ в Sprint 5 — поставка не принимается без достижения порога. Гибрид (regex на ~150 полей + LLM на остальное) + пятислойный hallucination mitigation stack (cite-verify, XSD-constrained decoding, cross-field consistency rules, self-consistency voting, NLI-верификация)
R3	152-ФЗ / 242-ФЗ резидентность + блокировки западных облаков и LLM API	Высокое	Весь prod-стек — на Yandex Cloud + Российские LLM (GigaChat / YandexGPT / Qwen local). Westward API (Sonnet) — только на анонимизированных данных для evaluation, не для prod-extraction
R4	Реестры НОПРИЗ / НОСТРОЙ неофициальны, могут сломаться в любой момент	Среднее	Opportunistic scraping с cache-fallback и monitoring schema changes. UX предлагает ручной ввод с pre-filled данными из ЕГРЮЛ (DaData), если НОПРИЗ недоступен. DaData для ИНН-lookup — стабильный коммерческий канал
R5	ФЛК ГИС ЕГРЗ автоотклоняет пакеты (с 21.10.2024 ужесточилась) — риск, что наш XML не пройдёт	Среднее	Локальный preflight-валидатор зеркалирует правила ФЛК. Обязательный XSD-pass перед кнопкой «Скачать». Включены проверки: кодировка UTF-8 без BOM, все `minOccurs=1` поля, keyref/unique constraints, enum values в словарях XSD
R6	Реестр российского ПО: процесс 3–9 месяцев, без него НДС 22 %	Среднее	Для пакета «Премиум» начинаем filing с Sprint 0 (параллельно разработке). Для других пакетов — опция O3. Реестровая заявка не блокирует запуск продукта
R7	Scanned PDF от клиентов (OCR вне MVP)	Среднее	В Stage 1 детектируем scan → показываем пользователю предупреждение и downgrade SLA. Ожидаемая доля scanned PDF < 30 % на рынке (современные CAD-системы экспортируют text-based). Если доля окажется выше — OCR добавляется в Stage 2 как изменение scope
R8	ЮKassa B2B-платежи имеют ограничения по банкам и юрлицам	Низкое	Card fallback через ту же ЮKassa обеспечивает 100 % покрытие. b2b_sberbank работает со всеми банками-контрагентами, имеющими СберБизнес Онлайн

27. Гарантии

Гарантийная поддержка 30 дней после приёмки каждого пакета — исправление дефектов без дополнительной оплаты. Дефект — несоответствие чеклисту приёмки или NFR.
Quality gate гарантия: если F1 AI-извлечения на 50 эталонных ПЗ ниже 0,85 на момент Sprint 5 — доработка AI-пайплайна за наш счёт до достижения порога (не входит в дополнительную смету, входит в цену пакета).
XSD migration гарантия (для пакетов Бизнес+): бесплатная адаптация под новую версию XSD Минстроя в течение 6 месяцев после приёмки, при условии соблюдения dynamic loader-архитектуры.
Продление поддержки после гарантийного периода — 15 % от стоимости проекта / год (включает хотфиксы, мониторинг, ежеквартальные отчёты по инцидентам).
Dev-бонус (только «Премиум»): 300 000 ₽ на доработки после запуска, действует 12 месяцев, покрывает до 50 % стоимости нового заказа.

28. Требования к клиенту

Для успешного старта и прохождения проекта в срок нам нужно от клиента:

Доступы. К ЕЦПЭ (или аналогичному тестовому окружению) для интеграционного тестирования, если клиент пожелает сразу тестировать XML на реальной подаче.
Юридические реквизиты. ОГРН, ИНН, КПП юрлица, банковские реквизиты — для выставления счетов и для того, чтобы Диадок мог нас найти в ЭДО.
Labelled-set (критично). 50 ПЗ с эталонными XML для quality-gate. Если у клиента готового labelled-set нет — мы можем собрать его из публичных примеров (опция O-extra, ~200 000 ₽) или привлечь сторонних экспертов (договариваемся отдельно).
Бренд-элементы (для «Бизнес» + O6). Логотип в SVG, гайдлайны цветовой схемы (если планируем white-label).
Контактное лицо со стороны клиента. Продуктовый owner (Данила?) с правом принимать решения по scope и приёмкам в рамках 24 часов.
КЭП для Диадока. Минимум один экземпляр КЭП юрлица (для подписания входящих УПД от платформы к вам и далее к конечным tenants).

29. Что не входит

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

Категория	Не входит
Подписание XML	Интеграция КриптоПро CSP внутри платформы для server-side подписания. Подписание выполняется пользователем внешне (КриптоПро Browser Plug-in / КриптоАРМ / Госключ)
OCR	Автоматическое распознавание отсканированных PDF и изображений — Stage 3, планируется после достижения 1 500 PZ/мес
Ведомственные экспертизы	Росатом, РЖД, Газпром — специфичные XSD и workflow не входят
Поддержка XSD, отличной от `explanatorynote`	`DesignAssignment`, `ProjectDecisionDocument`, `ExpertOpinion`, сметная документация — нужны отдельные модули
Маркетинг и продажи	Лендинг, CRM, email-рассылки, контекстная реклама, onboarding сессии с клиентами tenant'а — это отдельная работа
Обучение конечных пользователей	Записанные видео-уроки, live-тренинги для инженеров-проектировщиков — отдельный scope (может быть включён в Премиум-пакет как бонус)
Юридическое сопровождение	Типовые договоры с tenants, пользовательские соглашения, политики конфиденциальности — мы даём шаблоны (бонус Бизнес), финальную верификацию делает ваш юрист
Миграция с существующих систем	Если у вас уже есть база tenants / проектов в другой системе — миграцию оцениваем отдельно
Сертификация ФСТЭК	Аттестация ИСПДн по ФСТЭК № 21 — не требуется для УЗ-3 (самооценка достаточно), но если клиент хочет аттестацию — это отдельный договор с аккредитованной лабораторией
Поддержка в проде	После гарантийного периода (30 дней) поддержка оформляется отдельным договором (~15 % от стоимости проекта / год)

30. Открытые вопросы

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

В1. Сбор labelled-set для quality-gate

Контекст: для Sprint 5 нам нужны 50 ПЗ с эталонными XML, чтобы измерить F1 AI-извлечения.

Вариант	Плюсы	Минусы
A. Клиент предоставляет свои 50 ПЗ с разметкой	Максимальная релевантность, реальные данные	Требует 40–60 часов работы эксперта на стороне клиента
B. Мы собираем labelled-set из публичных примеров	Клиент не тратит время	Менее релевантно вашим будущим клиентам
C. Гибрид: клиент даёт 20 ПЗ, мы собираем 30 из открытых источников	Баланс	Требует ~20 часов клиента

Требуется решение: до начала Sprint 3.

В2. Выбор второго cloud-storage (для Премиум)

Контекст: в Премиум-пакете планируется подключение второго cloud-storage для enterprise-клиентов (основное — Yandex Object Storage).

Вариант	Плюсы	Минусы
A. Cloud.ru Evolution	10 TB/мес free egress, дешевле	Менее зрелая compliance-документация
B. Selectel S3 с А-ЦОД tier	ФСТЭК-аттестованный сегмент	Дороже
C. VK Cloud	Хорошая интеграция с российскими сервисами	Мало публичных цен, нужна коммерция

Требуется решение: до Sprint 7.

В3. Приоритет в Stage 2: versioning или cloud integration?

Контекст: в пакете «Бизнес» Stage 2 ядро включает версионирование проектов и работу с SIG/hash. В пакете «Премиум» добавляется cloud-интеграция. Если клиент хочет cloud-интеграцию в «Бизнесе» — можно заменить на один из компонентов «Бизнеса».

Требуется решение: до Sprint 6.

В4. Необходимость интеграции с CAD-системами в базовой комплектации

Контекст: опция O2 (API hub для CAD) — 830 000 ₽. Если клиент видит в своём roadmap интеграцию с Renga / TDMS / NanoCAD в первые 6 месяцев после запуска — лучше включить в базовую комплектацию.

Требуется решение: до окончания discovery.

В5. Продуктовый owner и окна принятия решений

Контекст: agile-команда должна иметь быстрый доступ к решениям. Нам важно знать, кто принимает решения по scope и приёмкам.

Требуется: назвать конкретное лицо и график его доступности.

31. Перспективы развития

Что можно добавить в проект после запуска MVP. Это не обязательства, а ориентиры на 1–2 года вперёд.

Направление	Что получите
Stage 3: OCR приложений	Автоматическая обработка отсканированных ИРД, ГПЗУ, ТУ — снятие последней «ручной» ручной работы при работе с приложениями
Автоматическая классификация файлов	Система сама определяет, в какой раздел ПД относится загруженный файл (по содержимому, а не по имени)
Другие XSD Минстроя	Модули для заключения экспертизы, сметной документации, ОЖР, технического задания — расширение платформы на смежные ниши
Интеграции со сметными системами	ГРАНД-Смета, Smeta.RU, Tangl — обмен сметными данными в XML
Мобильное приложение для ГИП/ГАП	Approve/reject ПЗ из Telegram или нативного приложения — критично для командировок и удалённой работы
Marketplace шаблонов	Tenants могут делиться шаблонами и заготовками между собой — network effect
AI-ассистент «проверь мою ПЗ»	Проактивные подсказки на основе опыта платформы: «в таких объектах обычно указывают X, а у вас пусто»
Экспорт в BIM-форматы (IFC)	Связь XML-ПЗ с 3D-моделью проекта
White-label для крупных застройщиков	Отдельная инсталляция платформы под бренд девелопера с эксклюзивным доступом для их команды
Внешний API для интеграторов	Публичный API со SDK (Python / .NET / 1C) для интеграторов, которые строят свои решения поверх платформы

32. Глоссарий

Термин	Определение
ЕГРЗ	Единый государственный реестр заключений экспертизы проектной документации. Оператор — ФАУ «Главгосэкспертиза России» под руководством Минстроя РФ
ЕЦПЭ	Единая цифровая платформа экспертизы (`platformaexpert.ru`) — государственная платформа для подачи документов в экспертизу
ПЗ	Пояснительная записка — основной раздел проектной документации (раздел 1 по ПП РФ № 87), описывающий объект, основания разработки, ТЭП, ресурсы, организацию строительства
XSD	XML Schema Definition — формальное описание структуры XML-документа. Для ПЗ Минстрой публикует XSD в `minstroyrf.gov.ru/tim/xml-skhemy/`; текущая версия `explanatorynote-01.06` обязательна с 29.01.2026
ФЛК	Форматно-логический контроль — автоматическая проверка загружаемого в ЕЦПЭ/ЕГРЗ пакета на соответствие XSD и правилам. С 21.10.2024 ужесточена
ТЭП	Технико-экономические показатели — таблица с площадями, мощностями, расходами ресурсов
ИРД	Исходно-разрешительная документация — техусловия, ГПЗУ, градостроительный план, задание на проектирование
ИУЛ	Информационно-удостоверяющий лист — приложение к тому ПД по ГОСТ Р 21.101-2020, содержит сведения о подписантах и контрольные суммы файлов
ГИП / ГАП	Главный инженер / главный архитектор проекта — роли с правом принятия финальных технических решений
СРО	Саморегулируемая организация — объединение проектных организаций с контролем квалификации и ответственности
НОПРИЗ	Национальное объединение изыскателей и проектировщиков — ведёт Национальный реестр специалистов (НРС) в проектировании и изысканиях
НОСТРОЙ	Национальное объединение строителей — аналог НОПРИЗ для строительных СРО
СНИЛС	Страховой номер индивидуального лицевого счёта — 11-значный идентификатор в системе пенсионного страхования, используется для идентификации специалистов в НРС
УКЭП	Усиленная квалифицированная электронная подпись — основная форма подписи для взаимодействия с государственными системами РФ
КЭП	Квалифицированная электронная подпись, сокращение от УКЭП
CAdES	CMS Advanced Electronic Signatures — европейский стандарт электронной подписи, принимается ЕЦПЭ в формах BES / T / A
ElectronicBudgetObjectCode	18-значный код объекта в системе ГИИС «Электронный бюджет» (Минфин) — для объектов, финансируемых из федерального бюджета
LLM	Large Language Model — большая языковая модель (например, GigaChat, YandexGPT, Qwen). В проекте используется для извлечения данных из ПЗ
VLM	Vision Language Model — модель, обрабатывающая изображения страниц вместе с текстом (Stage 2/3 для сложных таблиц и scan-ов)
RLS	Row-Level Security — механизм PostgreSQL, запрещающий доступ к строкам таблицы, не принадлежащим текущему tenant'у
Tenant	Организация-клиент в multi-tenant SaaS — изолированный инстанс данных и настроек
УПД	Универсальный передаточный документ — российский аналог счёт-фактуры и акта выполненных работ в одном документе
ЭДО	Электронный документооборот — обмен формализованными документами (УПД, договоры) между юрлицами через оператора (Контур.Диадок, СБИС) с КЭП
152-ФЗ / 242-ФЗ / 63-ФЗ	Федеральные законы: о персональных данных / о резидентности данных в РФ / об электронной подписи соответственно
ФСТЭК	Федеральная служба по техническому и экспортному контролю — регулятор по защите информации и ИСПДн

33. Следующие шаги

Что предлагаем сделать после ознакомления с этим документом:

#	Действие	Срок	Ответственный
1	Созвон 30 минут для обсуждения деталей и ответов на вопросы	3 рабочих дня	Данила + AiDevTeam
2	Принятие решения по выбранному пакету	5 рабочих дней	Данила
3	Ответы на открытые вопросы (раздел 30)	5 рабочих дней	Данила
4	Подписание договора с приложением-ТЗ (на базе этого документа)	2 рабочих дня после решения	AiDevTeam готовит проект договора
5	Получение аванса 30 %	3 банковских дня после подписания	Клиент
6	Kickoff (Sprint 0): команда стартует работу	Неделя после получения аванса	AiDevTeam

Ожидаемый старт разработки: через ~3 недели после получения данного КП.

Все оценки являются предварительными и будут уточнены на этапе ТЗ при необходимости. Финальные сроки и стоимость могут меняться только через процесс Change Request с согласованием обеих сторон.

Предложение действительно 30 дней с даты документа.

Разработка: AiDevTeam Контакт для оперативных вопросов: Telegram @maslennikovig, email maslennikov.ig@gmail.com