ТИМ | BIM | Литература | НПА | НТД

В статье Романова Д. А., Гаранкиной С. А. рассматриваются практические вопросы нормализации и дедупликации корпоративного справочника материально-технических ресурсов с применением технологий искусственного интеллекта, основанные на переходе от сравнения текстовых наименований к анализу технических характеристик объектов. Особое внимание уделяется роли методологии нормализации и дедупликации, сочетанию ИИ с формальными алгоритмами и экспертным контролем, переходу от разовой очистки накопленных данных к непрерывному управлению качеством справочника МТР

Предлагаемая статья Топчего Д.В. подготовлена по материалам доклада, сделанного на научно-практической конференции НОПРИЗ «Новые возможности инжиниринга архитектурно-строительного проектирования — искусственный интеллект в изысканиях и проектировании», состоявшейся 16 сентября 2026 года в НИУ МГСУ. В статье анализируется фактическое состояние применения искусственного интеллекта в инженерных изысканиях, архитектурно-строительном проектировании и государственной экспертизе. Разграничены зоны естественного и искусственного интеллекта: алгоритм принимает воспроизводимые операции — обработку и интерпретацию данных изысканий, построение цифровых моделей, нормоконтроль, сетевые разделы, проект организации строительства, сметную и оформительскую часть, тогда как полевое получение данных, архитектурный замысел, выбор конструктивной схемы уникального объекта, инженерное суждение при неполных данных и ответственность за решение не передаются. Рассмотрен зарубежный опыт автоматизированной проверки проектов. Значительное место уделено рассмотрению нивелирования функций ГИП и ГАП при одновременном росте их персональной ответственности с 1 марта 2026 года. Проанализирован ключевой риск шаблонного подхода к проверке проектных документов, который приводит к утрате уникальности проектных и строительных решений. Автором предложены правила применения инженерного искусственного интеллекта.

Материалы для BIM-менеджера и Проектирощика, которые всегда должны быть под рукой ℹ️ Реестр требований Московская государственная экспертиза (МГЭ) ▶️ Требования v 4.1 к ЦИМ ОКС ▶️ Требования v 5.0 (КР и ТХ, общие) + IDS для КР, ТХ ▶️ Требования к ЦИМ ЛО Московская областная государственная экспертиза (МОГЭ) ▶️ Требования v 3.3 к ЦИМ + IDS Центр государственной экспертизы (г. Санкт-Петербург) ▶️ Требования к ЦИМ + IDS Классификаторы ▶️ Коды МССК ▶️ Классификатор строительной информации (КСИ) ▶️ КЭЦИМ (Карельский) Раз ссылка, два ссылка Материалы от ДГП и требования к ЦИМ АГР ⚫ Сервисы ДГП и МГЭ ⚫ Материалы от ДГП ⚫ Как получить АГР, пошаговая инструкция на mos.ru ⚫ Требования* АГР к ЦИМ .pdf ⚫ Требования* АГР к ЦИМ .doc ⚫ Требования к ВПМ, НПМ ⚫ Плагин «Якорь IFC» ⚫ Канал ДГП по АГР ⚫ Шаблон презентации на АГР ⚫ Чек-лист проверок АГР и шаблоны Larix ⚫ Доска Holst по АГР

Есть, что добавить?)

Прочитала у Дататим, как они добиваются максимально точного результата от своего ИИ-агента — с помощью четкой инструкции. Это значительно экономит время и токены. На примере решения задачи одного из своих клиентов — по сверке спецификации дверей (594 позиции, на 12 параметров каждая) с 95 листами чертежей, читаемых только как изображения — команда поделилась тем, что заложила в инструкцию агенту: 🟣 Читать не весь лист, а только смысловые зоны: таблицу марок, штамп, примечания. Распознавание через LLM, сравнение — код. 🟣 Связывать чертёж со спецификацией по марке двери. По номеру позиции нельзя — нумерация меняется при добавлении строк, марка же остаётся неизменной. 🟣 Кешировать разобранные листы: чертежи между редакциями не меняются, повторная сверка из кеша намного быстрее. 🟣 Обрабатывать листы параллельно, в несколько потоков. Результат: — Обработка объема заняла час машинного времени вместо 3 дней ручной работы. — 23 двери совпали полностью, по остальным были указаны расхождения с указанием обоих значений. — Точная размеченная спецификация на выходе. «ИИ и роботы в стройке» в MAX

Кейс: как ПИК перевел исполнительную документацию с корпоративной системы на «Билдокс» Лилия Карасева и Ольга Абражевич из команды автоматизации девелопмента в ПИК рассказали на Хабре о том, почему технически правильное решение не гарантирует принятия пользователями. Исполнительная документация (500+ объектов, 250 тыс. документов в год) велась в корпоративной системе Тесса. Для пользователей это был привычный инструмент. Но отрасль переходила на XML, и поддержка процессов внутри универсальной системы становилась всё дороже. Поэтому начали переход на профильное решение и выбрали «Билдокс». Это усложнило работу пользователей: вместо одного файла — привязка документа к объекту, работам, материалам. Действий стало больше, привычный сценарий сломался. Началось: «верните как было». С чем столкнулись Пилот на трёх объектах прошёл успешно, но при масштабировании выяснилось: то, что работает на малой выборке, не гарантирует принятия тысячами пользователей. Люди проходили обучение, знали процессы, но не могли работать — не были настроены доступы, роли, не созданы объекты. А пока старая система оставалась доступной, большинство откладывало переход. Что помогло Запустили War Room — отдельный канал связи с ежедневным мониторингом проблем в первые две недели после отключения старой системы. Вместо формальных спонсоров-руководителей нашли амбассадоров — опытных сотрудников, к которым коллеги привыкли обращаться за советом. Обучение перестроили с разделов системы на сценарии. Результаты 800+ объектов переведены, SLA достиг 99%, затраты на техподдержку снизились на 70%. Весь цикл занял 10 месяцев. Главный вывод: сопротивление неизбежно, но если новый инструмент решает задачи, а старого больше нет, пользователи адаптируются. «Альянс Цифровых Лидеров в стройке» в MAX

Интервью уважаемого начальника Главгосэкспертизы Игоря Евгеньевича Манылова, конечно, больше рекламное, в части допуслуг и сервисов ГГЭ. С другой стороны — почему нет, могут себе позволить, да и необходимость назрела: особенно на фоне свежей проверки Счётной палаты, которая нашла на счетах учреждения около 11,9 млрд рублей свободных остатков (доходы выросли с 6,6 млрд в 2020-м до 12,1 млрд в 2025-м) и предложила перечислить в бюджет половину. На таком фоне подробный рассказ о новых сервисах — вполне объяснимое желание показать, зачем нужны деньги. Центр инженерии данных: XSD как запоздалое признание

В первую очередь центр займётся разработкой методологии работы с данными... в том числе разработкой XSD-схем — формализованных правил структуры XML-файла

Вот это мы любим: сначала наплодили кучу XML-схем, теперь спохватились про правила их создания. Хорошо, что вообще спохватились. Но раз стандартов для приведения схем в порядок до сих пор не было — это заодно и трудозатраты, и доработка ПО у всех, кто с этими схемами работает. Отдельный нюанс: не все XML-схемы в принципе разрабатывает Главгосэкспертиза — так что методология для чужих схем это либо межведомственная координация, либо заход на чужую поляну и расширение полномочий. 🙂 И главное: внедрение ИИ — это не только про XSD и машиночитаемый формат, хотя кормить его действительно нужно упорядоченными данными, а не мусором. Но мало «упорядочить» — данные ещё нужно анализировать содержательно. А вот с этим у нас по-прежнему большие пробелы: собирать научились, извлекать смысл — пока нет. «Работаем на себя» — но, кажется, уже с оговоркой Задачи ЦДИ в интервью в первую очередь про саму ГГЭ: административные процессы, управление стоимостью, геоданные. Но дальше — судя по всему, после неоднократных напоминаний министра — появляется формулировка: доступ к разрабатываемым решениям нужно обеспечить всем участникам отрасли, для чего потребуются отдельные платформенные решения. Хорошо, что появилась. Вопрос — окажется ли это доступом к самим данным (база КАЦ, XML-сметы прошедших экспертизу объектов, XML-ВОР), или только к готовым сервисам поверх них, которые ГГЭ сама решит, что показывать. Экономия и повторные экспертизы — тот самый неудобный вопрос

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

Только вот Счётная палата регулярно говорит ровно об обратном — о постоянных повторных экспертизах и перепроектировании. Например, июльский отчёт по трём арбитражным судам (Волгоград, Иркутск, Удмуртия). Если экспертиза действительно снижает риски перепроектирования на ранних стадиях — почему СП из отчёта в отчёт находит ровно этот сценарий? И ещё момент: проверка достоверности сметной стоимости — это сверка с действующей сметно-нормативной базой, а не независимая проверка конъюнктурного анализа цен и не ответственность за итоговую стоимость, которая вышла из экспертизы. Примеров хватало, когда после положительного заключения претензии по итогу предъявляют почему-то не Главгосэкспертизе, а заказчику.

Только в первом полугодии 2026 года мы сэкономили общему бюджету стройки более 144 млрд рублей, из них свыше 94 млрд — средства государственных бюджетов всех уровней

Отлично. А на сколько по факту подорожало? Есть такая статистика? В пресс-релизах и интервью — нет, только цифры в одну сторону. Ценообразование: справедливая цена — для кого?

За каждой методикой стоят вопросы точной и справедливой цены строительства. По плану на 2026 год уже разработаны 9 из 12 методик

Точная и справедливая — запишем. Справедливая для кого: бюджета, подрядчика, заказчика, который эту смету потом будет пересчитывать? И насколько точная, если по нашим расчётам по 86 регионам среднее наполнение КСР текущими ценами — 2,11%, ценообразующих ресурсов — 5,83%, при официальных ~41% по другому знаменателю. Про ресурсный метод и наполняемость ФГИС ЦС — в интервью снова ни слова. Биржи и ЭТП: зарегистрировались — не значит передают Регистрация организатора торгов — административный факт, а не поток цен. Интереснее была бы не констатация подключения, а цепочка: сколько ценовых предложений реально получено, сколько признано пригодными для расчёта, по скольким позициям КСР изменились текущие цены. Пока — только «зарегистрировались», а «в дальнейшем» без сроков. Ну да осталось немного: ждем невероятного прорыва по итогам публикации данных в ФГИС ЦС за III квартал. Иначе зачем все это было, правда? Что в сухом остатке Направление в целом верное — ЦДИ создан не для галочки, ИИ действительно внедряется, а оговорка про доступ для всей отрасли — правильный сдвиг, который стоит поддержать. Но пока каждый содержательный тезис интервью упирается ровно в то, что уже не раз подсвечивала Счётная палата: экономия без обратной статистики, доступ к сервисам без доступа к данным, наполнение ФГИС ЦС без конкретных цифр. Разница только в формулировке — там это «риск» и «нарушение», здесь — «эффективное использование» и «интеллектуальные инструменты».

Отдельная государственная экспертиза информационной модели законодательством не предусмотрена Тринадцатый арбитражный апелляционный суд рассмотрел дело № А42-11389/2025, в котором заказчик отказался принимать и оплачивать выполненные проектные работы, ссылаясь, в частности, на отсутствие отдельного положительного заключения государственной экспертизы на информационную модель в формате IFC. Проектная документация при этом была представлена на государственную экспертизу, по результатам которой было выдано положительное заключение. Суд установил, что документация была разработана в бумажном и цифровом виде и в полном составе передана на экспертизу. Информационная модель в формате IFC также была передана заказчику. Поэтому предметом спора стала не передача информационной модели как таковой, а требование о наличии отдельного заключения государственной экспертизы именно на эту модель. Суд первой инстанции указал, что отдельного прохождения государственной экспертизы только информационной модели в рамках разработанной и получившей положительное заключение ПД и РИИ законодательством не предусмотрено. Апелляционный суд этот вывод подтвердил. Вывод судов основан на разграничении предмета государственной экспертизы и формы представления проектной документации. В соответствии со статьей 49 ГрК РФ государственной экспертизе подлежат ПД и РИИ. Результатом экспертизы ПД является заключение о ее соответствии установленным требованиям, результатам инженерных изысканий и заданию на проектирование. Отдельная государственная экспертиза информационной модели как самостоятельного объекта этой нормой не предусмотрена. При этом информационная модель может являться формой представления ПД. Ее наличие в составе проектного комплекта не превращает ее автоматически в дополнительный объект экспертизы. Это важно и с точки зрения договора. В рассматриваемом деле контракт предусматривал разработку и передачу информационной модели в формате IFC. Такая обязанность подрядчика могла подлежать исполнению и проверке заказчиком в рамках договорных отношений. Однако само договорное требование о передаче IFC не создает предусмотренной законом процедуры государственной экспертизы информационной модели. Иными словами, наличие обязанности разработать информационную модель и наличие обязанности получить положительное заключение государственной экспертизы на эту модель – не одно и то же. Отдельно следует обратить внимание на письмо Минстроя России от 27.11.2025 № 73021-КМ/14. Оно уже не относится непосредственно к обстоятельствам рассматриваемого спора, но представляет интерес для понимания действующего подхода к фиксации ПД в форме ИМ ОКС. В письме Минстрой рекомендовал считать проектную документацию подготовленной в форме информационной модели при наличии в составе комплекта документов файлов в формате XML и (или) IFC и указывать это обстоятельство в заключении государственной экспертизы. Рекомендация была связана прежде всего с унификацией учета таких заключений при расчете показателя цифровой зрелости строительной отрасли. Таким образом, наличие IFC может быть достаточным основанием для соответствующей отметки в заключении государственной экспертизы по предложенному Минстроем подходу и в целях учета документации при расчете соответствующего показателя. Но это не означает появления отдельной экспертизы информационной модели и не требует выдачи самостоятельного положительного заключения непосредственно на IFC. В результате дело № А42-11389/2025 показывает достаточно четкую границу: ПД может быть представлена на государственную экспертизу в форме информационной модели, а факт ее подготовки в такой форме может фиксироваться в заключении. Однако отдельная государственная экспертиза информационной модели после проведения экспертизы ПД законодательством не предусмотрена. Именно отсутствие такой самостоятельной процедуры не позволило заказчику обосновать отказ от приемки и оплаты работ ссылкой на отсутствие отдельного заключения на информационную модель. С заказчика было взыскано 5 840 400 рублей. Дело ушло в кассацию. 📸 bimsert

Как обещала, вот все типы проверок. Напоминаю, всё это прямо внутри Civil 3D. По этому функционалу есть, кстати, подробная видео-справка на Rutube. Если хотите в текстовом виде, напишите в комментах, я отправлю PDF. Общие - наложение CAD-блоков - наложение мультивыносок - наложение контуров семейств - наложение штриховок - пересечение санитарно-защитных зон - пересечение границ проектирования - проверка производителя материалов - самопересечения полилиний и штриховок - проверка соответствия слоя CAD-стандарту Бордюры - корректность прилегания покрытий к бордюрам (например, асфальт не доведён до бордюра или наоборот заходит за него) Озеленение - соответствие количества деревьев и кустарников в модели количеству, указанному в выносках МАФ - соответствие высоты падения толщине резинового покрытия - пересечения зон безопасности разных МАФ - соответствие зоны безопасности резиновому покрытию Освещение - проверка расстояния между деревьями и опорами освещения (по умолчанию используется радиус 4 м) Покрытия - наличие конструкций дорожной одежды (КДО) у покрытий Наружные сети - проверка нормативных расстояний и пересечений между элементами благоустройства и подземными коммуникациями 🤩Бесплатная пробная версия PikTools Генплан на 30 дней — по ссылке 🤩

XML для исполнительной документации: а где обещанный эффект? Недавно на Хабре вышла показательная статья о переходе к цифровой работе с исполнительной документацией. Ее ценность в том, что авторы показывают не просто замену бумажных документов электронными файлами, а изменение самого подхода: от «документа как файла» к структурированным данным, связанным с объектами, работами, материалами и другими документами. И здесь возникает вопрос, с которого, на наш взгляд, и стоило бы начинать разговор об XML. Не «нужна ли цифровизация исполнительной документации?». Безусловно, нужна. Вопрос другой: а обязательно ли для этого переводить исполнительную документацию именно в XML? Потому что основные преимущества, описанные в статье, связаны прежде всего со структурированием данных и установлением связей между ними. Это позволяет искать и анализировать информацию, контролировать комплектность, автоматизировать процессы, интегрировать данные с другими системами. Но это преимущества цифровой системы и структурированных данных, а не XML как такового. Структурированные данные и XML – не одно и то же. Можно построить цифровую систему, в которой PDF остается визуальным представлением документа, а необходимые сведения о нем хранятся в структурированном виде и используются для автоматической обработки. И наоборот, можно получить XML-файл, который формально соответствует XSD-схеме, но по существу остается электронной формой привычного документа. XML действительно удобен для формализации структуры, машинной обработки, валидации и межсистемного обмена. Но тогда возникает главный вопрос – какую дополнительную ценность дает именно XML? Причем этот вопрос особенно интересен, если посмотреть не на отдельную информационную систему, а на регулирование исполнительной документации в целом. В действующем перечне XML-схем Минстроя действительно есть схемы отдельных документов исполнительной документации – общего и специальных журналов, актов освидетельствования, актов испытаний и других документов. Но значительная часть перечня вообще относится не к исполнительной документации, а к документам государственного строительного надзора и административным процедурам. Да и сами XML-схемы появляются хаотично, а их содержание строиться на исключенных из сводов правил формах. И главное – состав исполнительной документации существенно шире набора документов, для которых сегодня разработаны XML-схемы. То есть мы имеем не перевод всей исполнительной документации в единый структурированный формат, а формирование XML-схем для определенной ее части. И здесь возникает самый интересный вопрос – где именно находится системный эффект от XML, если в XML переводится только часть массива исполнительной документации, а остальная документация продолжает существовать в иных форматах? Если преимущество XML заключается в структурированных данных – почему структурируется только часть данных? Если преимущество в межсистемном обмене – какой объем исполнительной документации реально участвует в таком обмене? Если преимущество в автоматизации контроля – какие конкретно процессы становятся эффективнее именно благодаря XML? Это не аргумент против цифровизации. Напротив, статья на Хабре достаточно убедительно показывает, зачем строительной отрасли нужны связанные и структурированные данные. Но она одновременно позволяет отделить ценность цифровизации от ценности конкретного формата. Полученный авторами эффект нельзя автоматически приписать XML, поскольку одновременно изменились процессы, архитектура данных и сама организация работы с исполнительной документацией. Есть и обратная сторона. Переход к структурированным данным увеличивает количество операций для пользователя – нужно заполнять дополнительные сведения, устанавливать связи между документами и поддерживать их структуру. Авторы проекта прямо описывают это как одну из проблем перехода. Поэтому возникает вполне рациональный вопрос: какой измеримый эффект компенсирует эту дополнительную нагрузку? Сколько времени экономится при поиске документов? Насколько сокращается количество ошибок? Как ускоряется проверка комплектности? Что получает заказчик, эксплуатация и государственные информационные системы? И вот здесь мы подходим к главному. Часто необходимость XML объясняется очень просто: «так требует законодательство». Но это не отвечает на вопрос, насколько обоснованно само законодательное требование. Если государству нужны структурированные и машиночитаемые данные – с этим трудно спорить. Если нужен межсистемный обмен – тоже. Но из необходимости получить структурированные данные еще не следует необходимость сделать обязательным именно XML. Это разные утверждения «нам нужны структурированные данные» и «значит, эти данные должны представляться именно в XML». Между ними должно находиться обоснование: почему именно XML, какую проблему он решает лучше альтернативных технических решений, какой измеримый эффект дает и соразмерен ли этот эффект затратам участников строительства. Особенно если нормативное регулирование в итоге приводит не к единой структурированной исполнительной документации, а к появлению XML только для отдельных ее видов. И тогда возникает уже не технический, а регуляторный вопрос – доказана ли необходимость делать именно этот технический способ обязательным? Возможно, правильнее было бы сначала определить конечный результат – какие данные должны быть структурированы, какие связи между ними должны сохраняться, какие автоматизированные операции должны обеспечиваться и какие системы должны уметь их использовать. А уже затем выбирать технический формат. Потому что цифровизация исполнительной документации нужна не ради XML. Она нужна ради данных и возможностей, которые эти данные дают. А XML – всего лишь один из инструментов. И прежде чем превращать этот инструмент в обязательное нормативное требование, хотелось бы увидеть главное – где именно доказан эффект от его применения и почему этот эффект нельзя получить более рациональным способом? 📸 bimsert

Опубликован ПНСТ 1080-2026 по ЦИМ поликлиник ПНСТ 1080-2026 Цифровые информационные модели объектов непроизводственного назначения. Поликлиники. Общие требования Стандарт разработан с целью внедрения ТИМ, используемых при разработке ЦИМ поликлиники в составе информационной модели поликлиники. Стандарт распространяется на ЦИМ ОКС непроизводственного назначения с функциональным назначением поликлиники (код 03.01.004.002). Настоящий стандарт устанавливает требования к формированию ЦИМ поликлиники для достижения целей базовых процессов ведения ЦИМ объекта капитального строительства, указанных в настоящем стандарте, на этапах осуществления предпроектной подготовки, архитектурно-строительного проектирования, строительства, реконструкции, капитального ремонта, эксплуатации и сноса. Стандарт определяет набор базовых процессов ведения ЦИМ объекта капитального строительства и наборы атрибутивных данных элементов ЦИМ поликлиники. Стандарт содержит описание наборов атрибутивных данных элементов ЦИМ поликлиники, объем которых зависит от базовых процессов ведения ЦИМ поликлиники, установленных застройщиком, техническим заказчиком, лицом, обеспечивающим или осуществляющим подготовку обоснования инвестиций, и (или) лицом, ответственным за эксплуатацию ОКС в договоре, задании на проектирование, техническом задании на ЦИМ ОКС. Настоящий стандарт устанавливает требования к наборам атрибутивных данных элементов ЦИМ поликлиники для реализации набора базовых процессов, при этом наборы атрибутивных данных элементов ЦИМ поликлиники включаются в ЦИМ, если это установлено законодательством Российской Федерации, а также если требование об их включении содержится в стандарте организации, договоре, задании на проектирование, техническом задании на ЦИМ объекта капитального строительства и (или) в плане реализации проекта с использованием информационного моделирования. Вступает в действие с 01.01.2027 г. 📸 bimsert

Вопрос/Ответ: о регистре хэш-сумм файлов при формировании Пояснительной записки (Раздел ПД №1) Вопрос: При подаче пояснительной записки в ФАУ «Главгосэкспертиза России» нам выставлено замечание, что контрольные суммы CRC-32 должны быть записаны в верхнем регистре. Однако XML-схема explanatorynote-01-07.xsd допускает любой регистр. Правомерно ли данное замечание? Ответ: Нет, замечание о необходимости верхнего регистра является требованием конкретной информационной системы (ЕЦПЭ), а не требованием XML-схемы explanatorynote-01-07.xsd. В схеме explanatorynote-01-07.xsd тип tFileChecksum определен следующим образом:

<xs:simpleType name="tFileChecksum">
    <xs:annotation>
        <xs:documentation xml:lang="ru">Текстовая строка длиной 8 символов</xs:documentation>
    </xs:annotation>
    <xs:restriction base="xs:string">
        <xs:pattern value="[0-9a-fA-F]{8}"/>
    </xs:restriction>
</xs:simpleType>

Регулярное выражение [0-9a-fA-F]{8} явно допускает: • 0-9 - цифры; • a-f - строчные буквы; • A-F - прописные буквы. Таким образом, с точки зрения XML-схемы файл с хэш-суммами в любом регистре является валидным. Если файл успешно прошел проверку по XML-схеме, а система требует верхний регистр - это ограничение программного обеспечения (ЕЦПЭ), которое должно быть устранено на стороне системы, так как оно противоречит принятой логике в данной версии XML-схемы. Примеры валидных значений по XML-схеме ПЗ версии 01.07: • 3c57452f - строчные: валидно; • 3C57452F - прописные: валидно; • 3c57452F - смешанный: валидно. С точки зрения XML-схемы - регистр не имеет значения, все варианты допустимы. Замечание ФАУ «Главгосэкспертиза России» о необходимости верхнего регистра не закреплено в схеме и по сути противоречит ей. Обращаем внимание, что для всех типов файлов, упоминаемых в XML-файле пояснительной записки, используется один и тот же тип tFileChecksum: • файлы проектной документации; • файлы отчетов по инженерным изысканиям; • файлы подписей; • файлы 3D-моделей; • любые другие файлы. Таким образом, правило одинаково для всех файлов, и указанное противоречие носит системный характер. Рекомендуется обратиться в Техподдержку ФАУ «Главгосэкспертиза России» для разъяснения данного требования и его приведения в соответствие с XML-схемой. 📸 bimsert