Тип: contract · Статус: сведения требуют сверки с действующей установкой; архитектурные правила сформулированы как целевой контракт.

Раздел: Доменная модель заказов и исполнения

• D — наличие и соответствие документов.
• C — проверки через CheckDefinition / RequirementCheck, включая ручные и автоматические.
• B — bindings и предикаты, учитывающие субъект, объект, роль и контекст.

Требование — политика. Проверка — доказательство выполнения. Permission — конкретное разрешение. Initial activation и последующий effective access — разные фазы.

Для актуального запроса проверки существует единый осмысленный ST_REQUEST. Повторный запрос после FAILED оформляется новой ревизией/операцией по контракту; параллельные дубли не должны давать неоднозначный результат.

Истечение срока, изменение документа или результата Moodle/appointments запускают re-evaluation. Обработчик выполняет шаг бизнес-процесса, backend хранит определение и результат; не следует помещать собственные доменные модели в workflow-хранилище.

• ST_REQUEST: запросы документов и проверок
• Автоматизированная верификация и fallback
• Идентичность: LDAP, Django и единый вход