текущий контур
Нормоконтур
требования и версии
Нормоконтур держит правила, а не растворяется в текучке объекта
Если пакеты ИД и материалы площадки живут отдельно от блока требований, команда быстро начинает спорить не о сути, а о версиях, шаблонах и обязательных полях. Этот раздел нужен, чтобы официальная опора была одной, а её влияние на сборку, доказательства и выдачу оставалось прозрачным.
шаблоны и обязательные поля
версии документов и правил
impact map по пакетам и ролям
что хранится здесь
Нормоконтур должен владеть не только ссылками на документы, но и логикой применения
Полезный раздел требований - это не склад нормативки. Он знает, какие шаблоны действуют, какие поля обязательны, как изменился выпуск после новой редакции и какие пакеты нужно пересобрать после изменения требований.
База требований
Официальные документы и внутренние правила собраны как единая рамка для РД, ПД, ИД и сопутствующих комплектов.
Шаблоны и обязательные поля
Команда должна понимать, какой шаблон действующий, а какой уже нельзя тянуть в новый выпуск.
История редакций
Если правило поменялось, система фиксирует момент изменения и показывает, какие рабочие сценарии оно затронуло.
Карта влияния
Нормоконтур нужен, чтобы заранее видеть, как изменение правила ударит по пакету ИД, медиадоказательствам и архивной выдаче.
Связь со сборкой
Сборка применяет правило на живом объекте, но сам набор правил должен оставаться чистым и прослеживаемым в этом разделе.
Связь с архивом
Архив версий и внешняя выдача должны знать, на какой нормативной редакции был собран конкретный пакет.
официальные опоры
Раздел требований остаётся связанным с живыми официальными источниками
ГОСТ Р 21.101-2026
Базовая опора, когда нужно сверить правила оформления, структуру комплектов и логику выпуска документации.
Приказ Минстроя № 344/пр
Нормативная рамка для состава и ведения ИД, от которой потом зависит прикладная сборка пакета.
Публикации по сводам правил
Когда важна не точечная норма, а динамика изменений по отрасли, этот раздел опирается на живой поток публикаций Минстроя.
Дальше правило должно попасть в выпуск
После проверки требований работа почти всегда уходит в сборку, где правило превращается в живой пакет, замечание или контрольное условие.
зачем это нужно всем остальным
Каждая рабочая зона берёт из требований своё
Как правило спускается дальше
- Требования -> сборка превращение нормы в рабочий шаблон, обязательное поле, чек-лист или условие выпуска
- Требования -> медиа определение, какие фото и видео нужны как подтверждение, а какие остаются только рабочим следом
- Требования -> архив привязка архивной версии к той редакции требований, по которой пакет был собран и выдан наружу
практический смысл
single source
Без управляемых требований портал выглядит богаче, но работает слабее
- Без нормоконтроля сборка ИД быстро превращается в спор о том, кто какую версию документа держал в голове
- Без истории изменений невозможно честно объяснить, почему старый пакет и новый пакет собраны по разной логике
- Без связи с выдачей архив перестаёт быть доказуемым, потому что непонятно, на каком правиле основана каждая версия