Capítulo 19 — O sistema aprende

Corrigir não é aprender

Um bug pode ser corrigido em minutos.

Isso não significa que o sistema aprendeu.

Se nada muda em:

• testes;
• gates;
• runbooks;
• políticas;
• contexto;
• qualificação;

o mesmo padrão de falha pode voltar.

Hassan propõe que incidentes produzam learning packs que atualizam artefatos operacionais e de governança, em vez de terminarem apenas no fix. ¹

A tese deste capítulo é:

aprendizagem operacional precisa aterrissar em artefatos duráveis.

O learning loop

No método deste livro:

Incident
  ↓
Evidence
  ↓
Postmortem
  ↓
Action items
  ↓
Artifact updates
  ↓
Requalification
  ↓
Verification

Isso é método deste livro.

POSTMORTEM.md

Artefato central:

# Postmortem
## Summary
## Impact
## Detection
## Timeline
## Contributing Factors
## What Worked
## What Failed
## Evidence
## Action Items
## Artifact Updates
## Requalification
## Verification

Blameless não significa sem responsabilidade

O objetivo é entender condições do sistema, não escolher culpado conveniente.

Mas decisões ainda precisam de owners.

Um postmortem sem ownership produz intenção sem execução.

Contributing factors

Evite uma única “root cause” quando o incidente dependeu de vários fatores.

Exemplos:

• Spec ambígua;
• gate ausente;
• test data pobre;
• permissão ampla;
• alert tardio;
• rollback não ensaiado;
• documentação desatualizada.

Action items verificáveis

Adkins et al. recomendam action items explícitos, com owners, horizonte temporal e atenção aos controles que poderiam ter detectado o problema antes. ²

Um action item fraco:

melhorar os testes

Um action item melhor:

owner: payments-team
action: add duplicate-charge integration test
due: 2026-10-02
evidência: CI gate required

Short-term vs long-term

Nem toda correção tem o mesmo horizonte.

Curto prazo

• adicionar teste;
• bloquear configuração;
• ajustar alerta;
• revogar permissão.

Longo prazo

• redesign de boundary;
• nova arquitetura;
• troca de provider;
• política organizacional.

Incident → test

Se o incidente foi causado por comportamento reproduzível, transforme-o em regression test quando possível.

Fluxo:

failure observed
  ↓
minimal reproducer
  ↓
failing test
  ↓
fix
  ↓
permanent gate

Incident → gate

Nem toda aprendizagem vira teste.

Pode virar:

• schema check;
• security scan;
• permission policy;
• release gate;
• migration check;
• runtime threshold.

Incident → contexto

Se o erro veio de conhecimento ausente ou desatualizado, contexto também precisa mudar.

Exemplos:

• architecture decision;
• domain invariant;
• service ownership;
• forbidden dependency;
• migration constraint.

Context rot

Contexto acumulado também pode ficar errado.

Portanto, learning não é apenas adicionar.

Também é:

• remover;
• substituir;
• marcar deprecated;
• versionar;
• expirar.

Durable learning

método deste livro:

Uma aprendizagem só é considerada incorporada quando existe pelo menos um artefato durável atualizado.

Exemplos:

• test;
• gate;
• Spec;
• contexto pack;
• runbook;
• policy;
• qualification suite.

Requalification

Hassan observa que mudanças de política, ferramentas ou modelos podem invalidar pressupostos anteriores; por isso, requalification deve ser tratada como operação normal. ³

Isso evita assumir:

“funcionou antes, então continua confiável.”

Qualification suite

método deste livro:

Uma qualification suite pode medir se um agente/workflow ainda satisfaz:

• ferramenta usage rules;
• permission boundaries;
• evidência obligations;
• quality gates;
• escalation behavior;
• recovery behavior.

Quando requalificar

Triggers possíveis:

• novo modelo;
• nova toolchain;
• policy change;
• permission change;
• incidente relevante;
• grande mudança arquitetural.

Autonomia é revogável

Requalification torna autonomia dinâmica.

Ela pode:

• aumentar;
• permanecer;
• reduzir.

A decisão deve se basear em evidência, não em reputação informal.

Learning update

Artefato auxiliar:

incident_id:
lesson:
changed_artifacts:
new_gate:
requalification_required:
owner:
verification_status:

Isso conecta postmortem à execução.

Action item sem verificação

Um item marcado “done” porque o código mudou pode ainda não resolver o risco.

Por isso, cada action item deve ter acceptance evidência.

Anti-pattern: postmortem narrativo

Documento longo, sem owner, sem gate, sem mudança de sistema.

Resultado:

• boa história;
• pouca aprendizagem operacional.

Hassan resume esse problema: se a aprendizagem não aterrissa em artefatos, resta apenas narrativa. ¹

Anti-pattern: adicionar contexto para sempre

Cada incidente adiciona novas instruções.

Depois de dezenas de ciclos:

• contradições;
• contexto obsoleto;
• maior custo;
• menor clareza.

Learning inclui pruning.

Anti-pattern: corrigir só o caso observado

Pergunte:

• existem variantes?
• onde mais isso pode ocorrer?
• que classe de falha representa?

Adkins et al. enfatizam avaliar fatores relacionados e mecanismos que poderiam detectar problemas semelhantes antes. ²

Anti-pattern: policy que ninguém verifica

Uma nova regra em Markdown não garante cumprimento.

Se é obrigatória, considere mover para:

• hook;
• CI;
• policy engine;
• permission boundary;
• deterministic gate.

Anti-pattern: não requalificar após mudança

Trocar modelo ou toolchain e manter os mesmos privilégios por inércia cria trust drift. ³

Evidence of learning

Como provar que o sistema aprendeu?

Exemplos:

• novo regression test falha no estado antigo e passa no novo;
• novo gate bloqueia a classe de erro;
• runbook drill funciona;
• policy está enforced;
• qualification suite passa novamente.

Learning debt

método deste livro:

Action items vencidos representam learning debt.

Podemos acompanhar:

• open actions;
• overdue actions;
• repeated incidents;
• unverified fixes;
• stale contexto.

Repeated incident

Se a mesma classe de incidente volta, pelo menos uma destas coisas falhou:

• aprendizagem;
• enforcement;
• verification;
• ownership.

Recorrência é sinal de sistema, não apenas azar.

Bidirectional learning

O fluxo não é só humano → agente.

Agentes podem detectar:

• padrões de falha;
• missing gates;
• contexto inconsistencies;
• repeated manual intervention.

Mas humanos ainda decidem quais padrões devem virar policy organizacional.

Learning at different speeds

Falhas podem ocorrer em machine speed.

Mudanças de governança exigem julgamento.

Por isso:

• containment pode ser automático;
• learning structural pode exigir revisão humana.

Institutional memory

Quando decisões, incidentes e mudanças ficam ligadas:

Incident
  ↓
Postmortem
  ↓
Action
  ↓
Commit / Policy / Runbook
  ↓
Verification

criamos memória operacional recuperável.

Close criteria

método deste livro:

Um incidente não fecha apenas porque o serviço voltou.

Fechamento completo considera:

• recovery verified;
• postmortem concluído quando necessário;
• action items registrados;
• owners definidos;
• durable artifact updates consideradas;
• requalification avaliada.

Do learning local à escala organizacional

Este capítulo fecha o loop de um incidente: evidência → postmortem → action item → artifact update → requalification → verification.

Quando esse mecanismo passa a operar em muitos produtos, equipes e agentes, surge uma questão diferente. Já não basta saber se um incidente produziu aprendizagem; precisamos saber quem possui policies, plataformas, custos, capabilities e critérios de expansão de autonomia em escala.

O próximo capítulo sobe esse nível de abstração: Da prática individual à organização agêntica.

Fronteira de confiança

Learning updates podem alterar políticas, autonomia e permissões futuras. Por isso, mudanças em artefatos de governança precisam de ownership, revisão e versionamento compatíveis com seu impacto.

Evidência exigida

Postmortem relevante deve produzir evidência links, action items verificáveis e decisão explícita sobre quais artefatos duráveis precisam mudar. Um item só está concluído quando sua mitigação foi verificada.

Rollback e recuperação

Learning também deve revisar se containment e recovery funcionaram como esperado. Runbooks, rollback procedures e recovery gates que falharam durante o incidente entram automaticamente como candidatos a action items.

Proveniência das fontes

Rastreabilidade deste capítulo:

• CLM-065 — Hassan, incident learning loop precisa atualizar artefatos de governança e operação;
• CLM-066 — Adkins et al., postmortems com action items explícitos, owners e melhorias de controles;
• CLM-067 — Hassan, requalification após mudanças de policies, ferramentas ou models.

Learning Update, learning debt, close criteria e fluxo Incident → Evidence → Postmortem → Artifact Update → Requalification → Verification são método deste livro.

Fontes de acesso limitado não foram usadas como autoridade factual neste capítulo.

Recursos complementares

Recursos relacionados:

• POSTMORTEM.md template;
• Learning Update template;
• action-item tracker;
• requalification checklist;
• context-pruning checklist;
• incident-to-gate worksheet;
• futura visualização PCC de incident → lesson → artifact update → verification.

---

Footnotes

1. Ahmed E. Hassan, Agentic Software Engineering (2026), Practice 7: Incident learning loop and governance updates, pp. 301–302. Rastreabilidade interna: CLM-065. ↩ ↩²

2. Adkins et al., Building Secure & Reliable Systems (2020), Chapter 18: Recovery and Aftermath — Postmortems, pp. 472–473. Rastreabilidade interna: CLM-066. ↩ ↩²

3. Ahmed E. Hassan, Agentic Software Engineering (2026), Practice 8: Re-qualification as a normal operation, pp. 301–302. Rastreabilidade interna: CLM-067. ↩ ↩²