Быстрый старт
Быстрый старт Concord Loom
Чтобы начать работу, не нужно разбираться во внутренних форматах Concord Loom. Обычный путь состоит из четырёх шагов:
- установить один навык Codex;
- разрешить ему исследовать репозиторий без изменений;
- проверить наглядный Атлас и исправить ошибки;
- подключить репозиторий, когда карта станет верной.
Схемы, проверки графов, служебные записи и правила доступа остаются внутри этого процесса.
Что получится
Первая сессия создаст черновой Атлас репозитория. В нём будут:
- найденные области работы;
- предполагаемые связи между циклами;
- основания для каждого вывода;
- части карты, в которых системе не хватает вашего решения.
Черновик не считается принятой конфигурацией и не даёт себе никаких прав. Пока вы его не одобрите, репозиторий останется без изменений.
1. Установите навык Codex
Попросите Codex:
Use $skill-installer to install
https://github.com/concordloom/concordloom/tree/v0.1.5/plugins/concordloom/skills/design-project-loops
После установки откройте новый диалог Codex в нужном репозитории. Новый диалог нужен, чтобы Codex загрузил установленный навык.
2. Попросите построить первый Атлас
Напишите:
Используй $design-project-loops: исследуй этот репозиторий и построй первый
Атлас. Не меняй репозиторий, пока я не одобрю карту.
Сначала навык задаст два коротких вопроса:
- на каком языке вести разговор и создавать материалы;
- как к вам обращаться.
Он не попросит придумывать роли, служебные идентификаторы, границы графа или пути для файлов.
Затем навык проверит, доступна ли команда Concord Loom. Если команды нет, он покажет один безопасный способ установки и попросит разрешение перед изменением окружения или обращением к сети. Предпочтительная команда:
pipx install \
"concordloom @ git+https://github.com/concordloom/concordloom@v0.1.5"
Не используйте --break-system-packages. Если pipx недоступен, навык может использовать uv tool или отдельное управляемое окружение.
3. Проверьте карту
Первое исследование работает только на чтение. Навык изучает отслеживаемые файлы, области репозитория, импорты, ограниченную историю Git и файлы, которые часто меняются вместе. Код самого проекта он не запускает.
Черновой Атлас сохраняется вне репозитория. Откройте его и пройдите по предложенным циклам. Для каждого цикла должны быть понятны три вещи:
- Какая это часть проекта?
- Какой результат даёт эта работа?
- От какой другой работы она зависит?
После просмотра ответьте на один вопрос: карта верно описывает проект?
Можно ответить обычными словами:
Да, всё верно.
или:
Нет. Заметки о выпуске относятся к выпуску, а не к документации.
Навык исправит черновик и снова покажет карту. Для обычной поправки не нужна особая роль или служебное название полномочий.
4. Подключите репозиторий
Когда карта станет верной, навык отдельно спросит, можно ли сохранить первую принятую конфигурацию внутри репозитория. Это будет первая запись в репозиторий, поэтому разрешение должно быть явным.
После подключения:
- принятый Атлас станет общей картой проекта;
- следующую задачу можно будет направлять в нужный цикл, не загружая всю
систему;
- Атлас можно будет заново собирать из принятой конфигурации;
- повторяющиеся проблемы смогут стать понятным предложением по улучшению;
- решение о включении новой версии всё равно останется за человеком.
Одобрение первой карты и включение будущего улучшения — разные решения. Система может предложить новую версию правил, но не может сама её включить.
Повседневная работа
Статус функции: предпросмотр маршрута пока есть только в невыпущенной версии из main, но не в стабильном пакете v0.1.5, установленном выше. Используйте v0.1.5 для онбординга и создания Атласа. Проверяйте предпросмотр только после отдельного согласия на установку невыпущенной версии или дождитесь следующего релиза.
Опишите задачу и попросите Codex сначала показать маршрут:
Используй $design-project-loops для этой задачи. Сначала покажи маршрут и
ничего не запускай без моего подтверждения.
Вы увидите короткую последовательность нужных циклов и понятное объяснение, зачем нужен каждый из них. На этом этапе ничего не запускается. Маршрут можно подтвердить или исправить обычными словами.
Подтверждение создаст точный черновик. Для запуска всё равно потребуется отдельная авторизация. После неё навык запишет фактический ход работы и покажет расхождения с планом. Изменение только для текущей задачи останется внутри запуска. Изменение для будущих задач станет отдельным предложением эволюции и не включится само.
Ручной запуск через командную строку
Навык — основной интерфейс. Команды пригодятся для автоматизации и разработки самого Concord Loom.
Исследование только для чтения:
WORK_DIR="$(mktemp -d /tmp/concordloom-quickstart-XXXXXX)"
concordloom inspect . \
--output "$WORK_DIR/observed-project-graph.json"
concordloom questions \
--graph "$WORK_DIR/observed-project-graph.json" \
--output "$WORK_DIR/questions.json"
Эти файлы содержат наблюдения и предположения, а не принятую карту проекта. Команда concordloom --help покажет справку о низкоуровневых операциях: предложении правил, сборке, запусках, Атласе и эволюции.
Что читать дальше
- Руководство по Атласу объясняет интерактивное и автономное
представления.
- Основные понятия объясняют два графа и состояния сведений.
- Модель доверия объясняет, почему проверка и разрешение —
разные вещи.
- Архитектура описывает ядро и адаптеры.
Циклы циклов
Циклы циклов: общая грамматика управляемых изменений
Как конечная вложенность, ограниченная обратная связь, доказательства и полномочия превращают итерации в наблюдаемую систему
Аннотация
Исследование, реагирование на инцидент, творческое производство, управление и поставка программного обеспечения устроены по-разному. Однако в каждой из этих областей вход превращают в результат, результат проверяют, а затем решают, что делать дальше. Каждый такой цикл содержит циклы меньшего масштаба. Эксперимент содержит калибровку и анализ; инцидент — диагностику и восстановление; фильм — монтаж и работу со звуком; принятие нормы — консультации и ратификацию. Поэтому ответственная деятельность часто представляет собой цикл, составленный из циклов.
Вложенность и итерации изобретены не здесь. Инженерная задача состоит в том, чтобы управлять их совместной работой. Проще говоря, для каждого цикла надо указать, что он получает, какой результат считается завершённым, чем этот результат подтверждён, кто принимает решение и когда следует прекратить повторы. Успех дочерней задачи ещё не означает успех всей системы.
В формальном описании циклу нужны типизированный контракт, терминальные исходы, ограниченная обратная связь, явные доказательства, названные полномочия и точное правило, по которому результат дочернего цикла влияет на родительский. Конечный граф вложенности следует отделять от локального графа управления каждого цикла. Наблюдаемые, предложенные, принятые, запланированные, фактические и проверенные сведения тоже нельзя смешивать.
Concord Loom задаёт такую общую грамматику, не навязывая предметную область, среду исполнения, поставщика моделей, платформу размещения или структуру репозитория. Фреймворк собирает свидетельства, просит оператора разрешить существенные вопросы о намерении, связывает принятые решения с конечными контрактами циклов, фиксирует управляемые попытки, строит атлас и может предложить преемника активной конфигурации. Эволюция вправе предложить изменение, но не вправе сама его активировать.
Ответственная работа уже состоит из циклов
Плоская схема изображает каждый этап атомарным. Практика показывает другую структуру.
В исследовании путь идёт от вопроса к гипотезе, эксперименту, интерпретации и пересмотру. Сам эксперимент может содержать калибровку, набор участников, контроль качества данных и анализ. Успешная калибровка не подтверждает гипотезу. Она создаёт доказательство, которое оценивает родительский цикл эксперимента.
При реагировании на инцидент сигнал запускает триаж, локализацию, диагностику, восстановление и разбор. Диагностика может вызвать сбор журналов, воспроизведение или взаимодействие с поставщиком. Восстановление одной зависимости не закрывает инцидент. Руководитель инцидента ещё должен оценить стабильность сервиса, коммуникацию с пользователями и дальнейшие действия.
В творческом производстве бриф ведёт к поиску, отбору, производству, критике и выпуску. Фильм, выставка или кампания может содержать циклы сценария, визуальной разработки, монтажа, звука, юридической проверки и доступности. Одобрение одного кадра не разрешает публикацию всей работы.
В управлении наблюдение ведёт к предложению, консультации, решению, исполнению решения и пересмотру. Консультация может содержать экспертную, общественную, юридическую и финансовую проверку. Протокол консультации сообщает факты органу, принимающему решение; сам протокол не голосует.
Поставка программного обеспечения — ещё одна реализация этого общего рисунка. Требования, реализация, тестирование, выпуск и эксплуатация содержат обратную связь и вызывают дочерние циклы. Успешный тест сообщает, что он наблюдал на конкретной версии результата. Он не принимает продукт и не разрешает публикацию.
Общая задача состоит не в том, чтобы «добавить итерации», а в том, чтобы определить:
- какие действия принадлежат какому родительскому циклу;
- какая обратная связь остаётся локальной;
- что принимает и возвращает каждая граница;
- какие доказательства поддерживают результат;
- кто вправе исполнять, проверять, принимать, публиковать и эскалировать;
- какие бюджеты принуждают к терминальному исходу;
- как заменить активную систему.
Историческое утверждение должно оставаться честным
Concord Loom не претендует на изобретение циклов, иерархии или итеративной работы. История программной инженерии даёт хорошо документированную линию предшественников. В статье 1970 года о крупных программных системах Уинстон Ройс описывал обратную связь между последовательными фазами, предупреждал об опасности позднего обнаружения крупных проблем и рекомендовал пилот, документацию и участие заказчика. В спиральной модели Барри Боэм сделал риск-ориентированные повторяющиеся циклы центральным механизмом разработки.
В публичном описании IEEE/ISO/IEC 12207-2026 говорится, что процессы могут применяться параллельно, итеративно и рекурсивно к программной системе и её элементам. Plan-Do-Study-Act Деминга рассматривает улучшение как повторяющееся обучение, создающее доказательства. Диаграммы состояний Давида Харела в 1987 году расширили автоматы иерархией, параллелизмом и взаимодействием.
Современные руководства также композируют практики, а не навязывают один универсальный процесс. Secure Software Development Framework NIST описывает ориентированные на результат практики безопасности, которые организации встраивают в собственные жизненные циклы.
Наше утверждение намеренно ограничено:
Concord Loom не претендует на изобретение вложенных циклов. Наш вклад — единый проверяемый контракт для их границ: какие циклы содержат какую работу, чем подтверждён результат, кто вправе принять решение, что произошло при исполнении и как предложить и включить новую версию правил.
«Исполнимый» здесь не означает произвольный код, спрятанный в диаграмме. Валидатор отклоняет неверное описание. Адаптер запускает работу только в границах принятого контракта. Любой значимый вывод должен указывать на точную версию результата, правил, попытки исполнения и подтверждающих данных.
Одна грамматика, разные реализации
Concord Loom описывает предметный процесс как реализацию общей грамматики изменения:
наблюдать
→ согласовать
→ связать
→ исполнить
→ проверить
→ опубликовать разрешённый эффект либо зафиксировать его отсутствие
→ предложить эволюцию
Наблюдать. Зафиксировать факты, их происхождение и пределы наблюдения. Наблюдение может включать файлы, измерения, интервью, сигналы датчиков, прежние решения и события исполнения. Оно может породить гипотезу, но не принять её.
Согласовать. Задать вопросы, ответы на которые изменят предлагаемую систему. Ответственный оператор подтверждает, отвергает или исправляет существенное намерение. Уверенность ранжирует вопрос, но не отвечает на него.
Зафиксировать правила. Превратить принятое намерение в точные контракты, границы действий и полномочия. Система отклонит правила, если вложенность зациклена, повторы не ограничены, работа не может завершиться или участник получает лишние полномочия.
Исполнить. Создать один проверяемый результат в границах действующей конфигурации. В машинных документах такой результат называется candidate. Им может быть набор данных, действие по восстановлению, мастер-копия, нормативный пакет или дерево исходного кода.
Проверить. Оценить зафиксированную версию результата по заранее объявленным требованиям. Проверка записывает, что именно подтверждают данные, но не получает полномочия автора.
Опубликовать. Выполнить явно разрешённый внешний эффект: выпустить набор данных, вернуть трафик, передать мастер, ввести норму, развернуть программу или осознанно ничего не менять. Успешная проверка даёт доказательство, а не разрешение на эффект.
Предложить изменение системы. Собрать повторяющиеся сигналы и подготовить точное предложение новой версии. Действующая конфигурация определяет, кто вправе принять и включить её.
Это грамматика, а не обязательный движок процессов. Конкретная реализация может уточнять названия и делегировать исполнение лабораторным системам, средствам реагирования, производственным пакетам, комитетским процедурам, CI, локальным процессам или графам агентов.
Два графа вместо рекурсивного клубка
Один «рекурсивный граф» смешивает две разные связи.
Граф вложенности показывает, что составное состояние одного цикла вызывает другой цикл. Эксперимент вызывает калибровку; инцидент — восстановление; производство — юридическую проверку. Вложенность задаёт уточнение, область и отношение родителя с потомком. Этот граф конечен и ацикличен.
Локальный граф управления описывает движение внутри одного цикла. Он может содержать обратную связь: анализ возвращается к измерению, проверка восстановления — к смягчению, критика — к редактуре. Каждый цикл обратной связи расходует конечный бюджет и сохраняет путь к завершению или эскалации.
Вложенность (конечный DAG) Локальный поток (ограниченный)
программа подготовить → сделать → оценить → ПРИНЯТЬ
├── направление ▲ │
│ └── проверка └ повтор ─┘
└── публикация │
бюджет исчерпан
▼
ЭСКАЛИРОВАТЬ
Атлас показывает несколько уровней вложенности, но их глубина конечна. Локальное повторение имеет конечное число проходов. Вложенность не маскирует повтор, а обратная связь не создаёт скрытого потомка.
Минимальная формальная модель
Пусть управляемая система имеет вид:
K = (H, {Lᵢ}, Π, V)
H — граф вложенности, {Lᵢ} — множество контрактов циклов, Π — политика преобразования дочерних квитанций в родительские решения, V — версионируемая конфигурация точных контрактов и политики.
Каждый цикл:
Lᵢ = (I, O, S, s₀, Δ, C, E, A, B, X)
IиOзадают контракты входа и выхода.Sиs₀задают состояния и единственный вход.Δзадаёт декларативные локальные переходы.Cзадаёт дочерние вызовы.Eзадаёт предикаты доказательств.Aзадаёт полномочия и разделение обязанностей.Bзадаёт бюджеты попыток, времени, стоимости и инструментов.Xзадаёт терминальные исходы:ACCEPTED,REVISE,ESCALATED,
CANCELLED и другие.
Ребро вложенности содержит не только пару «родитель вызывает потомка»:
h = (parent, state, child, map_in, map_out, deadline, receipt_predicate)
Отображения входа и выхода не дают скрытому общему состоянию подменить контракт. Срок и путь отмены или эскалации ограничивают вызов. Предикат квитанции определяет, что родитель вправе узнать от потомка.
Дочерняя квитанция должна связывать как минимум:
r = digest(
child_contract,
run_id,
input_digest,
output_digest,
candidate_digest,
policy_digest,
producer,
result,
evidence_refs
)
Родитель вычисляет receipt_predicate(r) и собственные предикаты доказательств. Он не копирует терминальный статус потомка. Только родитель знает, обязателен ли этот потомок, полон ли набор доказательств, независим ли производитель и не сделал ли другой потомок проверяемый результат недействительным.
Исполнение структурно конечно, если:
H— конечный ориентированный ациклический граф;- каждая циклическая компонента локального
Δстрого уменьшает конечный
бюджет, например число оставшихся попыток; внутри цикла этот бюджет нельзя пополнять;
- исчерпание бюджета, срок и отмена ведут к терминальному состоянию или
эскалации, и каждое достижимое нетерминальное состояние сохраняет такой путь.
Эти условия доказывают структурную завершаемость, но не правильность. Валидатор не может доказать ценность научного вопроса, полноту восстановления, качество творческого решения, справедливость нормы или полноту тестового оракула.
Истина сложнее зелёного и красного
Concord Loom разделяет состояния знания:
| Состояние | Значение |
|---|---|
| Наблюдаемое | Зафиксирован факт или измерение с источником |
| Предложенное | Кто-либо предложил интерпретацию или изменение |
| Принятое | Уполномоченный оператор принял точное намерение или структуру |
| Запланированное | Для запуска объявлены маршрут, роль, бюджет и инструменты |
| Фактическое | Попытка записала реального исполнителя, область, инструменты и результат |
| Проверенное | Данные для точной версии результата и правил выполнили требования проверки |
Статус меняется только после отдельного действия и записи. История репозитория, показание датчика и интервью — свидетельства, а не намерение продукта. Предложение не равно действующей конфигурации. План не равен попытке. Попытка не равна проверке. Проверка не равна разрешению на публикацию.
PyDriller извлекает метрики из истории коммитов. CodeScene находит файлы, которые часто меняются вместе; в его документации этот анализ называется change coupling. SCIP задаёт переносимый индекс символов, а карта репозитория Aider ранжирует символы для ограниченного контекста. Эти инструменты поддерживают наблюдение, но не принимают намерение.
Доказательства и полномочия
Доказательства отвечают на вопрос «что поддерживает утверждение?», полномочия — «кто вправе принять решение или совершить эффект?». Одно не заменяет другое.
Прибор создаёт калиброванные измерения, а руководитель исследования принимает интерпретацию. Мониторинг показывает стабильную задержку, а руководитель инцидента разрешает вернуть трафик. Юрист проверяет права, а продюсер принимает мастер. Консультация фиксирует мнения, а уполномоченный орган вводит правило. Тесты проходят, а владелец публикации решает, выпускать ли результат.
Требования проверки называют проверяемые утверждения, допустимые результаты, точную версию результата и правил, проверяемые данные, исполнителя, независимость проверяющего и родительское решение, которое может использовать квитанцию.
Политика полномочий перечисляет участников и службы, их роли, разрешённые действия, область чтения и изменения, границы сети и внешних эффектов. Она также разделяет авторство, проверку, приёмку и публикацию и указывает, кто может активировать следующую версию.
PASSED означает, что узел выполнил объявленные требования проверки для зафиксированной версии результата. Это не разрешение на выпуск, введение нормы, публикацию или продуктовую приёмку.
Примеры применения
Исследование. Подготовка образцов сообщает температуру, партию реагента, оператора и контроль качества для набора S4. Анализ сообщает результат для S4 по протоколу P2. Родитель отклоняет успешную квитанцию для S3 и требует независимую статистическую проверку. Новая версия протокола делает старые квитанции устаревшими, если политика явно не разрешает более узкое переиспользование.
Инцидент. Локализация блокирует сбойную зависимость и сообщает затронутые сервисы и окно времени. Восстановление возвращает трафик в два ограниченных этапа. Ни один потомок не закрывает инцидент: руководитель оценивает влияние, остаточный риск и коммуникацию. Исчерпание бюджета ведёт к эскалации, а не к бесконечному повтору.
Творческое производство. Циклы текста, визуала, доступности и юридической проверки возвращают квитанции для одной версии мастера. Изменение текста после проверки доступности делает её квитанцию неактуальной. Продюсер принимает пакет только после совпадения всех обязательных квитанций с закреплённой версией; право публикации может принадлежать другому участнику.
Управление. Анализ влияния, консультация и юридическая проверка обслуживают родительский цикл принятия нормы. Консультация фиксирует охват, ответы и возражения, но не принимает правило. Уполномоченный орган оценивает совокупность доказательств и фиксирует мотивированное решение.
Поставка ПО. Кандидат сервиса C7 проверяют сценарии контракта API, миграции, авторизации и производительности. Миграция проходит со второй попытки после исправления изолированного окружения и выдаёт PASS для C7/P3. Авторизация находит приём просроченного токена и выдаёт REVISE для тех же C7/P3; родитель обязан вернуть REVISE. После появления C8 квитанции только для C7 устаревают. Даже итоговый PASS родительского тестирования не даёт права на выпуск.
Как Concord Loom управляет собственной разработкой
Concord Loom управляет своей разработкой, не превращая поставку ПО в границу фреймворка. В действующей конфигурации один корень — steward-concordloom — и десять областей ответственности:
steward-concordloom
├── product-direction
├── research-theory
├── protocol-design
├── runtime-tooling
├── trust-assurance
├── bindings-adapters
├── knowledge-experience
├── release-distribution
├── adoption-feedback
└── system-evolution
В этих областях находятся ещё 56 более узких циклов: всего их 66. Они охватывают решения о продукте, теорию, протокол, реализацию, независимую проверку, адаптеры, документацию, перевод, сайт, выпуски, применение и полную схему эволюции. Семь этапов — наблюдение, согласование, фиксация правил, исполнение, проверка, публикация и эволюция — остаются общей схемой одного запуска. Это не верхний уровень разработки репозитория.
Конфигурацию принял оператор; история репозитория не превратилась в намерение сама собой. Самоприменение также не создаёт особых полномочий. Действующие правила ограничивают исполнение, отделяют независимую проверку и оставляют внешние изменения издателю или оператору. Эволюция создаёт предложение с activation_allowed: false; точные файлы следующей версии включает отдельное решение оператора.
Эти правила самоизменения не обязательны для пользователей. Лаборатория, студия, операционная команда, публичный орган и программный проект задают собственные политику, артефакты, идентичности, доказательства и топологию.
Границы исполнения и представления
Concord Loom v0.1 проверяет вложенность, локальные переходы, точную версию результата, полномочия и данные проверки. Встроенный исполнитель считает каждый запланированный узел одной управляемой единицей работы. Он не проигрывает каждый локальный переход, не планирует долговечные дочерние процессы, не транслирует живое исполнение и не превращает дочернюю квитанцию в родительскую приёмку.
Исполнение могут предоставлять специализированные системы. Temporal описывает Child Workflows с собственной историей и поведением при закрытии родителя. LangGraph описывает subgraphs с отображением состояния и вариантами хранения. Лабораторные и операционные системы, производственные пакеты, комитетские процедуры, CI и локальные исполнители могут играть ту же роль адаптера.
Атлас строится из принятых документов и записанных фактов запуска. Он объясняет систему и показывает расхождения, но не меняет действующие правила, не разрешает переходы и не перепроверяет данные по ссылкам.
Цикл эволюции
Ни одна первая конфигурация не остаётся правильной навсегда. Повторяющиеся тайм-ауты, неиспользуемые доказательства, неоднозначные вопросы и лишние барьеры становятся сигналами о самой системе.
наблюдать ограниченные сигналы
→ диагностировать трение в контрактах и маршрутах
→ предложить дельту графа или политики
→ оценить риск и совместимость
→ принять или отвергнуть по действующим полномочиям
→ активировать преемника
→ снова наблюдать
Активная версия Vₙ определяет, кто вправе принять Vₙ₊₁. Предложение не может выдать это право себе. Активация добавляет преемника в каталог и сохраняет предыдущие версии доступными по их точным хешам. Уже запущенная работа продолжает использовать ту версию правил, с которой началась.
Это правило не позволяет принять повторяющееся неудобство за разрешение удалить барьер, который его обнаружил. Эволюция предлагает бюджеты, доказательства, полномочия и границы. Действующая власть принимает или отвергает точные байты.
Связанные работы и границы наших утверждений
Concord Loom соединяет известные идеи: итеративные и рекурсивные процессы, риск-ориентированную спираль, PDSA, иерархические автоматы, SSDF, дочерние процессы систем длительного исполнения, композицию подграфов и сбор данных предметными инструментами.
Фреймворк не утверждает, что изобрёл эти идеи, что каждой деятельности нужен отдельный цикл, что всем организациям нужна одна топология или что DAG вложенности описывает все отношения. Графы коммуникации, зависимостей и общих ресурсов могут иметь другую структуру; ацикличность обязательна только для вложенности исполнения.
Без сравнительных данных здесь нет утверждений о производительности, качестве, безопасности, художественной ценности, научной истинности или качестве управления. Валидация устанавливает соответствие схеме, целостность хешей, ограниченность переходов и часть правил полномочий. Она не доказывает правдивость физического источника и мудрость уполномоченного решения.
Concord Loom не является игровым движком, платформой размещения, поставщиком моделей, движком процессов, песочницей ОС, центром идентификации или обязательной структурой репозитория. Во враждебной среде технические идентификаторы участников и служб нужно дополнять платформенным контролем и подписанными аттестациями.
Наш проверяемый вклад конкретен: Concord Loom описывает границы циклов, полномочия, факты исполнения и правила изменения системы в одной цепочке версионируемых документов. Поэтому для каждого значимого вывода можно указать точную версию результата, правил и данных проверки.
Программа исследований
Управляемую систему циклов следует сравнивать с той же работой, описанной обычной схемой процесса и текстовыми инструкциями. Полезные показатели: обнаружение данных от другой версии результата или правил, время объяснения незавершённого родительского цикла, причины исчерпания бюджетов, расхождение плана и факта, усилия оператора на принятое изменение и понятность разных уровней вложенности.
Предметные исследования должны проверить переносимость грамматики без потери местного смысла. Науке важны протокол и происхождение данных; инцидентам — оперативные полномочия и откат; творческому производству — версии и права; управлению — консультации и решения; поставке ПО — точная связь результата с выпуском.
Не менее важны враждебные тесты. Система должна закрываться отказом, если данные проверки относятся к другой версии результата, потомок расширяет область родителя, автор занимает независимую роль проверяющего, обратная связь не уменьшает бюджет, вывод из наблюдений требует полномочий или эволюция пытается активировать себя.
Заключение
Многие ответственные системы представляют собой циклы циклов. Предметные области различаются, но задача управления повторяется: явно задать границы, доказательства, полномочия, бюджеты, терминальные исходы и преемственность.
Concord Loom даёт общую грамматику этой задачи. Вложенность остаётся конечной, обратная связь — ограниченной, состояния истины — раздельными, дочерние квитанции — подчинёнными родительским решениям, а эволюция не может разрешить сама себя. Конкретная реализация придаёт правилам предметный смысл, не превращая один пример в границу продукта.