Как это работает

От события к проверяемому решению

Представим сервисную заявку. Она находится в состоянии «Новая». Сотрудник хочет принять её в работу. Тяпкин проверяет допустимость такого перехода относительно контракта; приложение решает, как хранить заявку и что делать дальше.

1. Опишите правила на Capkin

В сценарии укажите участника, полномочие, Input, Guard и допустимый Transition. Компилятор принимает закрытый набор конструкций. Неизвестная фраза становится ошибкой, а не неявным правилом.

2. Передайте Input

Приложение передаёт проверенный контракт, текущий checkpoint, Input и claims. Principal обозначает участника, Capability — его допустимое действие. Проверка внешней личности и источников доверия принадлежит приложению.

3. Проверьте условия

Guard задаёт условие перехода. CAP проверяет решение в рамках контракта и предоставленных evidence. Он не превращает внешний факт в истину: за происхождение и достоверность факта отвечает выбранный источник доверия.

4. Получите State и Output

Если переход допустим, формируются новый State, Output intentions и Commitment. Приложение сохраняет своё состояние и организует исполнение. При недопустимом входе успешный переход не должен появиться.

5. Проверьте Trace

Trace связывает последовательность Commitment. Проверка сверяет историю с контрактом и доверенным checkpoint. Это позволяет воспроизвести решение и обнаружить нарушение цепочки.

Кто за что отвечает

Связать несколько Machine можно отдельным Flow. Каждая Machine всё равно принимает собственный Input и имеет самостоятельную историю.

От объяснения к первому запуску

Откройте быстрый старт, чтобы скомпилировать готовый пример. Для деталей используйте границу малого ядра и описание Rust runtime.