SKILL.md: Engenharia de Sistemas Cognitivos para Design Complexo
license: Apache-2.0
metadata:
name: Cognitive Systems Engineering (CSE)
source: "The Role of Cognitive Systems Engineering in the Systems Engineering Design Process"
authors: Militello, Dominguez, Lintern, Klein
version: 1.0
activation_triggers:
- designing agent systems or orchestration architectures
- analyzing why a system failed or is failing users
- decomposing complex tasks for AI or human execution
- eliciting requirements from domain experts
- encountering errors or unexpected behavior in cognitive work
- questioning whether the right problem is being solved
- designing for expert judgment, decision support, or automation
- assessing whether a solution is solving the stated vs. actual problem
Quando Usar Esta Skill
Carregue esta skill quando:
- Um sistema está sendo projetado para apoiar a cognição humana — suporte à decisão, orquestração de agentes, sistemas de informação, automação de expertise
- Os requisitos parecem vagos, contestados ou continuam mudando — isso é um sinal de que requisitos cognitivos estão invisíveis, não que as partes interessadas estão confusas
- Erros ou falhas estão aparecendo — trate-os como diagnósticos sobre suposições de design, não como defeitos a serem corrigidos
- O problema declarado parece errado — quando o espaço de soluções parece não conter a resposta real
- A expertise precisa ser capturada, replicada ou apoiada — e o especialista "não consegue explicar exatamente como faz"
- Uma equipe ou sistema distribuído deve coordenar trabalho cognitivo complexo — múltiplos agentes, humanos, ferramentas ou organizações compartilhando carga cognitiva
- O valor do trabalho de análise está sendo questionado — quando contribuições cognitivas são invisíveis frente aos artefatos de engenharia
Modelos Mentais Centrais
1. Requisitos Cognitivos São Invisíveis
O que os designers assumem que os trabalhadores precisam e o que os trabalhadores realmente precisam são sistematicamente diferentes — e a lacuna é enorme. Profissionais especializados operam com conhecimento tácito, pistas perceptuais, reconhecimento de padrões e consciência de restrições que não conseguem articular facilmente e que a observação por si só não revelará. Qualquer processo de design que não escave ativamente esses requisitos construirá para um trabalhador imaginário.
Implicação: A elicitação de requisitos deve usar métodos especializados (análise de tarefa cognitiva, método de decisão crítica, protocolos de pensamento em voz alta), não entrevistas ou pesquisas. O artefato deste trabalho é um modelo cognitivo do trabalho real, não uma lista de funcionalidades.
2. Erros São Diagnósticos, Não Defeitos
Um erro em um sistema cognitivo não é um mau funcionamento — é uma indicação precisa de onde o modelo do sistema sobre o trabalho diverge da estrutura real do trabalho. A incompatibilidade entre o comportamento esperado e o observado é o sinal mais rico em informações disponível para um designer.
Implicação: Quando agentes, usuários ou sistemas conjuntos produzem saída inesperada, a primeira pergunta é "o que esse erro revela sobre nossas suposições de design?" e não "como eliminar esse erro?"
3. Design É Diálogo, Não Pipeline
Modelos de design sequenciais (requisitos → especificação → construção → teste) são pedagogicamente convenientes, mas operacionalmente falsos. Problemas complexos revelam novas informações à medida que você os enfrenta. A declaração do problema com a qual você começa nunca é a declaração do problema com a qual você deve terminar. Tentativas de travar requisitos precocemente suprimem a descoberta que problemas complexos exigem.
Implicação: Iterações não são falhas de planejamento. Revisitar o enquadramento do problema no meio do projeto não é aumento de escopo — é o processo funcionando corretamente. Incorpore portões explícitos de reavaliação.
4. O Enquadramento do Problema É a Intervenção de Maior Alavancagem
A coisa mais valiosa que uma análise cognitiva pode produzir é muitas vezes uma reformulação do problema — não uma solução melhor para o problema declarado, mas evidência de que o problema declarado está errado. O caso da usina nuclear: 80+ funcionários reduzidos para 35, zero nova tecnologia, simplesmente entendendo a estrutura cognitiva real do trabalho.
Implicação: Antes de otimizar qualquer solução, invista na verificação da declaração do problema. O custo de resolver o problema errado com alta qualidade excede quase qualquer outro erro de design.
5. Sistemas Cognitivos Conjuntos, Não Pares Ferramenta-Usuário
A complexidade cognitiva reside no sistema distribuído — os humanos, tecnologias, processos e estruturas organizacionais que coletivamente executam o trabalho cognitivo. Nenhum agente ou ferramenta individual pode ser projetado isoladamente. Os mecanismos de coordenação, fluxos de informação e consciência situacional compartilhada através do sistema são onde o sucesso ou fracasso cognitivo é determinado.
Implicação: Projete as transições, não apenas os nós. Especifique os requisitos de modelo mental compartilhado entre os componentes. Analise como a automação muda a distribuição da carga cognitiva através do sistema conjunto, não apenas se a automação funciona.
Frameworks de Decisão
Diagnóstico de Problemas
SE um sistema está produzindo erros ou comportamento inesperado
ENTÃO carregue: failure-modes-in-complex-cognitive-systems.md
→ Classifique o modo de falha antes de propor uma correção
→ Pergunte: Isso é surpresa de automação, problema errado, compartimentalização, superespecificação ou gargalo?
SE as partes interessadas discordam sobre requisitos ou os requisitos continuam mudando
ENTÃO carregue: cognitive-requirements-are-invisible.md
→ A mudança é informação: requisitos cognitivos ainda não foram tornados explícitos
→ Implemente elicitação estruturada antes de mais coleta de requisitos
SE a solução proposta parece resolver a coisa errada
ENTÃO carregue: problem-reframing-as-highest-leverage-intervention.md
→ Pare o trabalho de solução; invista no enquadramento do problema primeiro
→ Procure uma reformulação que torne as categorias atuais de solução desnecessárias
Processo de Design
SE estiver projetando um sistema de agentes ou arquitetura de orquestração
ENTÃO carregue: joint-cognitive-systems-distributed-cognition.md AND cse-concept-map-for-agent-architecture.md
→ Mapeie o sistema conjunto completo antes de projetar qualquer componente
→ Projete os mecanismos de coordenação e fluxo de informação primeiro
SE estiver sob pressão para finalizar requisitos antes de uma compreensão adequada
ENTÃO carregue: design-as-dialog-not-pipeline.md
→ Distinga "travar requisitos" de "ter um melhor modelo atual"
→ Proponha portões explícitos de reavaliação em vez de bloqueio sequencial
SE estiver projetando para ou em torno do julgamento especializado
ENTÃO carregue: expertise-recognition-and-tacit-knowledge.md
→ Aplique o modelo de Decisão Baseada em Reconhecimento para entender como a expertise realmente funciona
→ Planeje para a lacuna de articulação do especialista no trabalho de requisitos
Avaliação e Valor
SE o valor do trabalho de análise cognitiva estiver sendo questionado
ENTÃO carregue: value-case-and-invisible-contributions.md
→ O paradoxo: um bom trabalho de CSE se torna invisível (menos falhas, operação mais suave)
→ Use indicadores antecedentes, não apenas contagens de incidentes
SE uma solução proposta envolve adicionar tecnologia ou pessoal
ENTÃO carregue: problem-reframing-as-highest-leverage-intervention.md
→ Verifique: um modelo cognitivo preciso do trabalho foi usado para validar esta solução?
→ O benchmark da usina nuclear: a reformulação do problema poderia eliminar a necessidade do recurso proposto?
Arquivos de Referência
| Arquivo | Quando Carregar |
|---|---|
references/cognitive-requirements-are-invisible.md | Requisitos parecem vagos ou contestados; projetar para usuários especialistas; iniciar qualquer processo de elicitação de requisitos; métodos de pesquisa de usuário estão em questão |
references/design-as-dialog-not-pipeline.md | Pressão para finalizar requisitos precocemente; processo iterativo está sendo desafiado como ineficiente; projeto está no meio do caminho e a declaração do problema precisa ser revisitada |
references/problem-reframing-as-highest-leverage-intervention.md | Espaço de solução não parece conter a resposta certa; soluções propostas parecem caras ou desalinhadas; necessidade de justificar pausar a execução para reformular |
references/joint-cognitive-systems-distributed-cognition.md | Projetar sistemas multiagente ou homem-máquina; analisar falhas de coordenação; avaliar como a automação muda a distribuição da carga cognitiva |
references/expertise-recognition-and-tacit-knowledge.md | Capturar conhecimento especializado; projetar suporte à decisão; construir sistemas para replicar ou auxiliar o julgamento especializado; especialista não consegue articular como faz o trabalho |
references/failure-modes-in-complex-cognitive-systems.md | Diagnosticar erros de sistema ou comportamento inesperado; pré-mortems em designs propostos; classificar uma falha observada antes de responder a ela |
references/cse-concept-map-for-agent-architecture.md | Mapear capacidades para um sistema de agentes; organizar funções cognitivas entre componentes; resolver confusão terminológica entre frameworks |
references/value-case-and-invisible-contributions.md | Justificar investimento em análise cognitiva; o valor do trabalho de CSE está sendo questionado; medir resultados de sistemas que previnem principalmente falhas |
Antipadrões
Estes são os modos de falha contra os quais a CSE especificamente alerta. Reconheça-os cedo.
1. Projetar para o trabalhador imaginado Construir sistemas baseados em como os designers pensam que especialistas trabalham, não em como especialistas realmente trabalham. O trabalhador imaginado é racional, tem informação completa, segue procedimentos e toma decisões como um livro-texto diz que deveria. O trabalhador real não faz nada disso.
2. Tratar erros como defeitos em vez de diagnósticos Corrigir erros sem perguntar o que eles revelam. Um erro corrigido que não foi compreendido é uma oportunidade perdida de corrigir a suposição de design subjacente — e uma garantia de que o problema ressurgirá em uma forma diferente.
3. Travar requisitos antes que o trabalho cognitivo seja feito Modelos de processo sequenciais criam pressão para travar requisitos precocemente. Em domínios cognitivamente complexos, isso garante que o sistema errado seja construído eficientemente. O travamento precoce de requisitos não é disciplina; é fechamento prematuro.
4. Compartimentalização: otimizar componentes sem a visão do sistema conjunto Construir uma ferramenta excelente que quebra o fluxo de trabalho dos humanos ou agentes ao redor. Otimização local que degrada o desempenho do sistema. A versão clássica: automação que liberta um humano de uma tarefa, mas o deixa sem consciência situacional quando a automação falha.
5. Viés retrospectivo na análise de falhas Após um incidente, projetar apenas para aquela falha específica. A clareza sedutora da reconstrução post-hoc faz as falhas parecerem mais previsíveis do que eram — e foca a energia do design na última falha em vez da próxima.
6. Superespecificação que elimina capacidade adaptativa Projetar sistemas tão rigidamente que os profissionais não podem improvisar quando a realidade se desvia do modelo. Trabalho complexo real exige adaptação. A superespecificação torna o sistema frágil precisamente nas situações onde a flexibilidade é mais importante.
7. O gargalo do especialista por design Construir um sistema onde um único especialista (humano ou IA) é o gateway requerido para todas as decisões críticas. Mesmo quando esse especialista é excelente, isso cria fragilidade catastrófica. A CSE pede a distribuição da expertise, não sua concentração.
Shibboleths
Como saber se alguém realmente internalizou a CSE vs. leu um resumo:
Eles dizem "erros são interessantes" — não "erros são problemas". Alguém que absorveu a CSE trata um relatório de falha como uma oportunidade de pesquisa, não como um ticket a ser fechado.
Eles perguntam "este é o problema certo?" antes de "qual é a solução?" — e estão dispostos a gastar tempo real nessa pergunta, mesmo quando atrasa o progresso visível. Eles viram o caso da usina nuclear e sabem o quanto a resposta pode valer.
Eles resistem ao travamento de requisitos sem análise cognitiva — não como obstrução, mas porque entendem que travar requisitos antes de entender a estrutura cognitiva do trabalho é uma maneira específica, nomeada e previsível de construir a coisa errada.
Eles pensam em sistemas conjuntos — ao analisar uma falha ou projetar uma solução, eles perguntam instintivamente "onde isso se encaixa no sistema cognitivo completo?" não "o que este componente deve fazer?"
Eles sabem o que o conhecimento tácito custa — não esperam que especialistas sejam capazes de dizer a eles o que precisam saber. Eles internalizaram que a expertise é amplamente inacessível à introspecção e planejam seus métodos de elicitação de acordo.
Eles tratam a natureza iterativa do design como sinal, não ruído — quando uma declaração de problema muda no meio do projeto, eles leem isso como o processo revelando algo real, não como uma falha de planejamento a ser gerenciada.
Eles conseguem nomear os cinco modos de falha — surpresa de automação, declaração de problema errada, compartimentalização, superespecificação, gargalo do especialista — e os aplicam diagnosticamente a situações novas, não como uma lista de verificação.
O que eles não dizem: "Só precisamos de melhores requisitos." "Se documentarmos o processo, o sistema o seguirá." "Os usuários só precisam de treinamento." "Podemos avaliar a ferramenta de IA independentemente de como os operadores a usam."
Carregue os arquivos de referência sob demanda à medida que situações específicas surgirem. A SKILL é ativada com este arquivo; análise mais profunda requer as referências.