Подход: профиль вариативности и проверяемые констрейнты для пакета лицензирования¶

Контекст¶

Состав пакета документов на лицензирование зависит от набора параметров организации: организационно-правовая форма, форма обучения (очная / дистанционная / смешанная), наличие специальных программ (гостайна, водительские категории, медицина и т.п.), платформа ЭИОС. Один и тот же фреймворк должен обслуживать и собственную ОО, и консультанта, который собирает пакеты для разных заказчиков.

Проблема¶

Если требования к пакету документов «зашиты» в текст шаблонов и инструкций, при смене параметров организации (например, переход с очной на смешанную форму, или регистрация ИП вместо ООО) приходится вручную перепроверять весь комплект — высок риск пропустить требование или, наоборот, приложить лишний/недопустимый документ.

Решение¶

Описать вариативность как набор осей профиля (profile.<key> → значение) и констрейнтов («если выполнено условие — следствие для пакета»). Сборка пакета читает профиль организации, выбирает применимые ветки требований и список документов, проверяет констрейнты до формирования описи.

Оси вариативности (пример)¶

Ось	Значения	Что определяет
`subject_type`	`ip` / `ooo` / `ano_dpo` / `edu_org` / ...	допустимые виды программ, состав уставных документов
`delivery`	`distance_only` / `blended` / `in_person`	требования к помещению, СЭЗ, МТО, условия ОВЗ
`eios_platform`	`saas` / `self_hosted` / `custom`	состав технического описания ЭИОС
`special_programs`	`gostayna` / `drivers` / `medicine` / `security`	дополнительные согласования (ФСБ, ГИБДД и др.)

Констрейнты (примеры)¶

subject_type = ip ⇒ перечень программ не может содержать ДПО (ст. 32, 76 ФЗ-273) — см. D02-P03, «Типовые ошибки».
delivery = distance_only ⇒ документы на помещение, заключения МЧС/Роспотребнадзора и СЭЗ не требуются; техническое описание ЭИОС обязательно.
delivery = blended | in_person ⇒ требуются документы на помещение (нежилое), СЭЗ, МТО, условия для лиц с ОВЗ.
special_programs содержит gostayna ⇒ требуется отдельная лицензия ФСБ — отдельный процесс, не покрывается D02-P01/P03.
special_programs содержит drivers ⇒ программы согласуются с ГИБДД.

Результат¶

Опись пакета документов формируется автоматически по профилю — нет «ручной» сверки при изменении параметров организации.
Констрейнты ловят несовместимые комбинации (например, ИП + ДПО) до подачи заявления, а не после отказа лицензирующего органа.
Один репозиторий правил обслуживает разные экземпляры организаций — меняется только профиль, правила и шаблоны переиспользуются.

Связь с другими доменами¶

D11-P01 — те же данные организации (org.*, programs[]) используются для раздела /sveden/ сайта; ось delivery влияет на применимость подразделов сайта (например, «Стипендии и меры поддержки», «Организация питания» неприменимы при distance_only).
standards/sveden/schema/instance.schema.yaml — каноническая схема данных, используемая обеими проекциями (лицензионный пакет и сайт).

Источник¶

Изначальная формулировка подхода: рабочий каркас лицензирования ДО/ДПО (handoff, iMironRU, 2026), обобщено для фреймворка.
Оформление: Claude Sonnet 4.6.