Identidade resolvida
Canal e conexão com o serviço são tratados como camadas diferentes; cada usuário opera seu contexto.
Cortex coloca identidade, policy, confirmação, idempotência e evidência na fronteira em que uma intenção vira efeito.
Approval isolado não basta. A proposta precisa continuar ligada à identidade, à policy, ao payload e à evidência de execução.
Canal e conexão com o serviço são tratados como camadas diferentes; cada usuário opera seu contexto.
Invariants e policies limitam quais tools podem ser expostas e invocadas.
Uma ação sensível preserva payload canônico, hash e versão antes da confirmação.
O ato de confirmar referencia a proposta pendente e seu conteúdo concreto.
A plataforma verifica novamente policy e alcance antes de disparar o efeito.
O resultado distingue estados e pode incorporar read-back quando a integração o declara.
Isolamento multi-tenant e invariants antes da policy.
Confirmação tipada para tools sensíveis configuradas.
Idempotência, leases, outbox e proteção contra repetição.
Receipts para efeito aceito, ausente, sustentado ou incerto.
Evals, snapshots, diffs, health e traces para mudanças.
O modelo continua variável e pode interpretar algo incorretamente.
Nem toda operação atual declara read-back pós-escrita.
Escala, SLO e disponibilidade comercial ainda não estão publicados.
Não há certificações SOC 2, ISO ou equivalentes declaradas.
Cada integração depende de API, auth e semantics utilizáveis.
Branches, snapshots, diffs, testes, tool health e traces permitem avaliar alterações antes e depois da publicação.
Arquitetura aplicada
A avaliação identifica qual identidade, confirmação e evidência o primeiro caso realmente exige.