# Архитектура системы ГОСПЛАН 2.0 — Открытое планирование > Техническое устройство открытого планирования: шесть слоёв от реестров до публикации, как на них ложатся контуры целей, исполнения и проверки, какие артефакты имеют юридическую силу и что из этого уже работает. Источник / Source: https://gosplan2.ru/architecture Язык / Language: ru Обновлено / Updated: 2026-08-23 --- # АРХИТЕКТУРА СИСТЕМЫ Из чего собирается открытое планирование: шесть слоёв, три контура поверх них и правило, которое запрещает им сливаться. Три контура — это распределение полномочий: кто задаёт цели, кто исполняет, кто проверяет. Архитектура отвечает на другой вопрос: из чего они физически собраны. Какие хранилища, откуда берётся факт, что именно подписывается и чем подтверждается вывод. Ниже — состав системы, а не список технологий: технология здесь всегда следствие требования, и там, где требование закрывается бумагой и телефоном, ничего цифрового не появляется. ## Шесть слоёв Снизу вверх. Каждый слой существует потому, что его требует один из контуров, — и ни одного слоя нет «на будущее». Верхние слои бесполезны без нижних: расчёт без измерения даёт правдоподобные числа, а публикация без расчёта — красивую витрину. ### L0Реестры и справочники Основание всей конструкции: устойчивые идентификаторы территорий, участков, объектов, организаций и обязательств. Без общей идентичности любые два набора данных нельзя сопоставить, и система превращается в набор несводимых таблиц. Это самый скучный слой и самый частый источник провала. ### L1Измерение Источник факта. Приборы учёта, телеметрия транспорта и сетей, спутниковые снимки, датчики среды, регистраторы событий. Ключевое требование — измеряющий не должен зависеть от измеряемого: показатель, который считает тот, кому за него платят, деградирует за один контрактный цикл. ### L2Журнал событий Хронологическая запись того, что происходило: какие данные пришли, какое решение принято, какая версия расчёта действовала. Правится только добавлением: исправление — это новая запись со ссылкой на прежнюю, а не переписанная строка. Именно этот слой делает возможным вопрос «а что мы знали на тот момент». ### L3Расчёт Превращение наблюдений в показатели: агрегация, модели, прогнозы. Требование к слою одно и жёсткое — воспроизводимость: посторонний, получив те же исходные данные и ту же версию метода, обязан получить тот же результат. Расчёт, который нельзя повторить, юридического значения не имеет. ### L4Обязательства и расчёты Контракты, квоты, лимиты и выплаты. Здесь живёт контур исполнения: аукционы, конкурсы, оплата за достигнутый результат. Автоматизация уместна ровно настолько, насколько результат измерим слоем L1, — иначе смарт-контракт лишь ускоряет выплату по недостоверному основанию. ### L5Публикация Всё, что вышло из системы наружу: открытые данные в машиночитаемом виде, интерфейсы для жителя, для подрядчика, для проверяющего. Публикуется не отчёт о работе системы, а сами данные и метод — иначе проверить вывод со стороны невозможно, и слой L3 теряет смысл. ## Как контуры ложатся на слои Слои — это техника, контуры — полномочия. Их пересечение и есть архитектурное решение: важно не столько, какие слои контур использует, сколько какими он не имеет права распоряжаться. ### Контур целей Работает с опубликованными данными и с реестром объектов, о которых принимает решения. Не имеет доступа к слою расчёта и к слою обязательств: цель формулируется в терминах результата, а не в терминах того, кто его исполнит и на каких условиях. ### Контур исполнения Заключает обязательства и ведёт расчёты в рамке, заданной контуром целей. Показатели читает, но не считает и не правит методику: возможность подправить метод расчёта равнозначна возможности назначить себе результат. ### Контур проверки Владеет измерением, журналом и методикой расчёта. Не участвует в обязательствах и не формулирует целей. Его единственная функция — отвечать на вопрос, произошло ли то, о чём отчитались, и в каком объёме. Главное ограничение архитектуры: инфраструктура контура проверки не должна зависеть от инфраструктуры контура исполнения. Общий сервер, общий администратор или общий подрядчик поддержки сводят два контура в один технически, даже если на бумаге они разделены, — и модель вырождается в самоотчётность. ## Что имеет юридическую силу Система оперирует множеством данных, но лишь несколько артефактов создают обязательства. Их стоит перечислить прямо: всё остальное — вспомогательное, и спор в суде будет идти об этих пяти позициях. Разделение подписей — не формальность. Именно оно превращает правило «кто исполняет, тот не проверяет» из декларации в свойство системы: чтобы его нарушить, придётся подделать подпись другого субъекта, а не договориться внутри одного кабинета. ## Требования, из которых следует выбор технологий Порядок здесь обратный привычному. Сначала формулируется свойство, которым система обязана обладать, и лишь потом ищется способ его обеспечить. Технология, не закрывающая ни одного из этих требований, в архитектуру не входит, какой бы современной она ни была. ### Воспроизводимость Посторонний, имея опубликованные данные и версию метода, получает тот же результат. Это требование к L3 и L5 одновременно и главная причина, по которой методика версионируется. ### Независимость измерения Тот, кого измеряют, не управляет измерителем — ни организационно, ни через подрядчика обслуживания. Отсюда требование дублировать критичные показатели источниками разной природы. ### Неизменяемость журнала Прошлое не переписывается. Отсюда цепочка хешей в L2 — не потому, что блокчейн, а потому, что нужен ответ на вопрос «что было известно на тот момент». ### Деградация в ручной режим При отказе любого автоматизированного слоя процедура должна продолжаться на бумаге с теми же правилами разделения полномочий. Архитектура, которая при сбое останавливает управление, непригодна для инфраструктуры. ### Стоимость подтверждения Проверка факта должна стоить заметно дешевле самого факта. Это требование отсекает сквозной ончейн-учёт на национальном масштабе: подтверждение там дороже большинства подтверждаемых операций. ## Готовность по частям Смешивать работающее с проектируемым — самая дорогая ошибка в текстах о цифровом управлении. Поэтому готовность заявляется покомпонентно, а не одной оценкой для всей системы. ### Работает в эксплуатации - Публикация закупок в машиночитаемом виде — стандарт Open Contracting и национальные системы на его основе. - Приборный учёт и телеметрия сетей: слой L1 в энергетике и на транспорте существует и эксплуатируется десятилетиями. - Партиципаторное бюджетирование как процедура контура целей — практика с 1989 года, воспроизведённая сотнями городов. ### Собирается из готового - Журнал с цепочкой хешей на масштабе одной территории: технически рядовая задача, вопрос в регламенте, а не в криптографии. - Версионирование методик расчёта и публикация входных срезов — инженерно решено, организационно почти нигде не внедрено. - Выплата по подтверждённому результату в узком предмете с натуральной единицей — дорожные работы, вывоз, энергоэффективность. ### Нерешённое - Сквозной ончейн-учёт национального масштаба: пропускная способность и стоимость подтверждения — открытая задача, а не вопрос времени. - Целеполагание через DAO: голосование по весу токенов воспроизводит собрание акционеров, а не гражданский контур. - Независимость измерения в предметах без натуральной единицы результата — уход, образование, культура. Здесь архитектура сознательно не применяется. Ни одна из позиций правой колонки не является условием для позиций левой. Система проверяема по частям, и каждую часть честнее испытывать там, где ошибка не стоит слишком дорого. ## Чего архитектура не решает Перечислено здесь, а не в примечании: архитектура без заявленных границ читается как обещание, а обещание проверить нельзя. Не защищает от захвата целеполагания. Если контур целей формируется недемократически, безупречная техника лишь быстрее и точнее исполнит чужую волю. Не расширяет область применимости метрик. Там, где результат не сводится к единице учёта, слои L3 и L4 не разворачиваются вовсе — это проектное решение, а не недоработка. Не заменяет институты. Подпись, регламент и ответственность за недостоверные данные существуют вне системы; архитектура делает нарушение видимым, но не невозможным. Не масштабируется автоматически. Свойства, проверенные на одной территории, на национальном масштабе требуют отдельной проверки — прежде всего по стоимости подтверждения. ## Что здесь главное Архитектура намеренно скромная: в ней нет ни одного компонента, добавленного ради современности. Слои появляются там, где контуру нужен факт, запись, расчёт или подпись, и не появляются больше нигде. Это делает конструкцию проверяемой по частям — и позволяет отказаться от любой её технологической части, не разрушая логику. Уберите из этой схемы блокчейн, модели и телеметрию — останется бумажный вариант с теми же разделёнными подписями: медленнее и дороже, но с той же логикой. Уберите разделение контуров — останется автоматизированная самоотчётность, и никакая технология этого не исправит.