<sharix-knowledge-meta>
{
    "id": "ShariXKnowledgeOpenKnowledgeDomainRequirements",
    "page": "sharixopen:knowledge:domain:requirements",
    "area": "open",
    "type": "reference",
    "title": "Требования, проверки и effective access",
    "status": "review",
    "schema_version": 1,
    "relations": {
        "related_to": [
            "ShariXKnowledgeOpenKnowledgeDomainStart",
            "ShariXKnowledgeOpenKnowledgeDomainStrequest",
            "ShariXKnowledgeOpenKnowledgeDomainAutomatedverification",
            "ShariXKnowledgeOpenKnowledgeModulesIdentitylogin"
        ]
    },
    "extensions": {
        "taxonomy": {
            "domain": "reference",
            "lifecycle": "unspecified",
            "parents": [
                "ShariXKnowledgeOpenKnowledgeDomainStart"
            ],
            "terms": []
        },
        "glossary": []
    },
    "content_sha256": "3ed0ef4908210f07ff677bff77c10a259093ccbc80b0f7540fed0ddeb1c09f76",
    "schema": 1
}
</sharix-knowledge-meta>
====== Требования, проверки и effective access ======
~~NOCACHE~~

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

**Раздел:** [[sharixopen:knowledge:domain:start|Доменная модель заказов и исполнения]]

===== Три блока требований =====
  * ''D'' — наличие и соответствие документов.
  * ''C'' — проверки через CheckDefinition / RequirementCheck, включая ручные и автоматические.
  * ''B'' — bindings и предикаты, учитывающие субъект, объект, роль и контекст.
===== Правило доступа =====
Требование — политика. Проверка — доказательство выполнения. Permission — конкретное разрешение. Initial activation и последующий effective access — разные фазы.
===== Проверка =====
Для актуального запроса проверки существует единый осмысленный ''ST_REQUEST''. Повторный запрос после FAILED оформляется новой ревизией/операцией по контракту; параллельные дубли не должны давать неоднозначный результат.
===== Переоценка =====
Истечение срока, изменение документа или результата Moodle/appointments запускают re-evaluation. Обработчик выполняет шаг бизнес-процесса, backend хранит определение и результат; не следует помещать собственные доменные модели в workflow-хранилище.

===== Связанные понятия =====
  * [[sharixopen:knowledge:domain:st_request|ST_REQUEST: запросы документов и проверок]]
  * [[sharixopen:knowledge:domain:automated_verification|Автоматизированная верификация и fallback]]
  * [[sharixopen:knowledge:modules:identity_login|Идентичность: LDAP, Django и единый вход]]

~~SHARIX_KNOWLEDGE_RELATED~~