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