Ledger: целостность графа состояния по построению
Ledger — детерминированный движок целостности (не нейросеть). Он поддерживает граф обязательств согласованным by-construction: каждая операция проходит восемь инвариантов-вето до любого вероятностного вывода. В сравнении с LLM-оркестрацией, которая выводит структуру заново на каждом шаге и дрейфует (17% слома структуры, 54% разброса статуса), Ledger даёт 0% структурного дрейфа и полную аудируемость через append-only историю.
1. Проблема: дрейф состояния
Если структуру доски выводит языковая модель на каждом шаге заново, состояние дрейфует: владельцы переназначаются, задачи закрываются с открытыми подзадачами, статусы рассыпаются. Измеренный масштаб на LLM-оркестрации:
| наблюдаемое | LLM-оркестрация | |---|---| | слом структуры обязательств | 17% | | разброс статуса | 54% |
Это не «плохой промпт» — это другой класс проблемы. Согласованность нельзя гарантировать вероятностным выводом; её нужно обеспечивать конструктивно.
2. Принцип: вето перед мягким выводом
Нерушимый инвариант архитектуры: операции над обязательствами проходят детерминированные вето ДО любого free-energy-скоринга. Вето — жёсткий шлюз; мягкий вывод — предпочтение поверх легального множества. Никогда наоборот.
3. Восемь инвариантов
| вето | правило | |---|---| | duplicate-id | id уже существует | | unknown-dep | предусловие не существует | | orphan-dependency | нельзя закрыть с открытыми зависимостями | | owner-teleport | смена ответственного только через передачу (handoff) | | cycle | зависимость не создаёт цикл (X→Y→X запрещён) | | no-op-transfer | передача не самому себе | | illegal-edge | переход вне разрешённого жизненного цикла | | terminal-mutation | нельзя менять discharged / cancelled |
Каждое вето реализовано как чистая проверка (can_*) плюс мутатор (*_); вся история append-only; есть аудит инвариантов.
4. Назначение с транскрипта
Кора даёт (from, to, op). Ledger выполняет propose(id, creator=from, owner=to). Если to ≠ говорящий — задача авто-назначается на ответственного (например, «Богдан»), а не на спикера. Последующая смена ответственного — только через transfer, который проходит вето owner-teleport. Это и есть «назначение с транскрипта» без потери целостности.
5. Видимый статус ↔ формальный жизненный цикл
UI-богатство статусов (proposed / committed / in_progress / blocked / in_review / done / cancelled) маппится на формальный каркас proposed → accepted → discharged | cancelled. Богатство — в поле; гарантии — в инвариантах. discharge (закрытие) проверяет orphan-dependency.
6. Почему это моат
LLM-конкуренты теряют структуру by-cognition (модель «постаралась»). Ledger держит её by-construction плюс аудит — это другой класс гарантии. Сочетание жёсткой целостности (Ledger) и правильной онтологии (направленный граф, см. направленные обязательства) образует двойной ров: интегритет × правильная модель мира.
7. Связь с временны́ми операциями
Отмены каскадируются на потомков; supersede заменяет X на Y; reopen поднимает закрытое; return_to_topic поднимает дремлющую тему без дубля; transfer меняет ответственного, сохраняя «заряд» обязательства. Все — через те же вето.