Voltar

Postmortems sem culpa são um método para obter fatos exatos, e o teste é o que muda depois

·23 min de leitura

No resumo que a Amazon Web Services publicou sobre a interrupção do S3 de 28 de fevereiro de 2017, o gatilho cabe numa frase. Às 9h37, no horário do Pacífico, um integrante autorizado da equipe, seguindo um procedimento estabelecido, executou um comando para retirar um pequeno número de servidores, e um dos parâmetros foi digitado errado, de modo que saíram muito mais servidores do que o pretendido. Dois subsistemas de que o S3 precisa para atender requisições tiveram de reiniciar. Às 12h26 o subsistema de índice já tinha capacidade para atender requisições GET, LIST e DELETE, voltou a operar por completo às 13h18, e o subsistema de posicionamento, do qual as requisições PUT também dependem, terminou de se recuperar às 13h54. A lista de ações corretivas da AWS tratava de ferramentas e de arquitetura: a ferramenta passou a retirar capacidade mais devagar, recusa remoções que deixariam um subsistema abaixo da capacidade mínima exigida, e as demais ferramentas operacionais seriam auditadas atrás de verificações parecidas. O documento não nomeia ninguém e não manda o engenheiro ter mais cuidado.

Minha tese é que a ausência de culpa é um instrumento, e o resto deste ensaio defende essa leitura. Trata-se de um método para coletar informação correta de pessoas que têm boas razões para escondê-la. As organizações o escolhem porque a punição muda o que as pessoas dizem, e um postmortem só vale tanto quanto o que as pessoas dizem nele. O método tem um produto, que é uma linha do tempo, um conjunto de fatores contribuintes e ações de acompanhamento com responsáveis, e tem um teste, que é saber se algo no sistema está diferente um mês depois. Por esse teste, algumas revisões que se dizem sem culpa fracassam, e suspeito que a falha esteja na lista de ações. Não tenho nenhuma contagem de quantas vezes isso acontece.

A mesma lógica vale para incidentes de IA, em que dois alvos de culpa estão à mão: "o modelo" e "quem escreveu o prompt". Os dois explicam pouco, e vou mostrar por quê com uma decisão de tribunal sobre um chatbot e três postmortems de fornecedores sobre qualidade de modelo. Antes vem a evidência a favor do método, inclusive nos pontos em que ela é frágil.

As pessoas relatam aquilo que não serão punidas por relatar

O caso empírico começa nos hospitais. Amy Edmondson quis testar uma expectativa que parece óbvia: unidades hospitalares com melhor trabalho em equipe deveriam cometer menos erros de medicação. Num artigo de 1996 no Journal of Applied Behavioral Science, ela relatou, nos dados registrados de oito unidades de enfermagem, o padrão oposto. Segundo o resumo do artigo no PSNet, da AHRQ, as unidades com mais direção e orientação por parte do gerente de enfermagem e com melhores relações internas tinham taxas mais altas de erros detectados. A explicação dela é que uma taxa detectada depende de duas quantidades, quantos erros ocorrem e quantos são relatados. O relato da Harvard Magazine de 2001 diz que as unidades iam das autoritárias e punitivas às abertas e acolhedoras, e que a taxa de erros detectados tinha uma relação quase linear direta com a abertura. Um resumo do artigo no site Field Guide acrescenta que um segundo pesquisador, sem acesso aos dados de erro, observou cada unidade e a classificou quanto à abertura, e que essa classificação coincidiu com a ordem das taxas de erro quase unidade por unidade. Li o artigo apenas por esses relatos secundários.

A inferência tem limites. Com oito unidades, a análise se apoia em oito pontos, as unidades diferem em muitos aspectos, e erros não relatados não podem ser contados, por definição. O que o estudo estabeleceu é mais estreito do que o slogan em que virou: uma contagem registrada de erros diz pouco sobre segurança enquanto não se conhece o clima de relato. Um gerente que punisse a unidade com mais relatos estaria punindo a unidade mais aberta.

Três outras fontes apontam na mesma direção. O artigo de Edmondson de 1999 na Administrative Science Quarterly estudou 51 equipes de uma empresa industrial e definiu segurança psicológica como a crença compartilhada de que a equipe é um lugar seguro para correr riscos interpessoais. Encontrou que essa crença estava ligada a comportamentos de aprendizagem, e que esses comportamentos estavam ligados ao desempenho da equipe. Lucian Leape, em depoimento ao Congresso americano em 2000, nas palavras citadas no posicionamento de 2010 da American Nurses Association sobre cultura justa, disse que punir indivíduos dá às pessoas um forte incentivo para relatar somente os erros que não conseguem esconder. James Reason, num artigo de 2000 no BMJ, ligou a boa gestão de risco a uma cultura de relato, que depende de confiança, que por sua vez exige uma cultura justa, com entendimento coletivo de onde passa a linha entre ações sem culpa e ações culpáveis. Para dar escala, ele cita uma fonte de 1997 segundo a qual cerca de 90% das falhas de qualidade na manutenção de aeronaves foram julgadas sem culpa.

John Allspaw expôs a mesma lógica em termos de engenharia no Etsy, em 2012. No texto, conforme arquivado pela Internet Archive, ele argumenta que o engenheiro que espera uma bronca é desestimulado a dar os detalhes necessários para entender uma falha, que a confiança entre engenheiros e gestão se desgasta, e que as condições latentes da falha continuam sem identificação porque as pessoas se calam. As mesmas falhas voltam. O remédio dele é pedir aos engenheiros um relato completo de suas ações, observações, expectativas e suposições, e tratá-los como os maiores especialistas nos próprios erros.

O produto de um postmortem é uma linha do tempo, fatores contribuintes e ações com responsável

O livro de SRE do Google descreve o postmortem como um registro escrito de um incidente: seu impacto, as medidas tomadas para mitigá-lo ou resolvê-lo, as causas-raiz e as ações de acompanhamento para evitar que se repita. Diz também que as equipes devem definir de antemão o que dispara um postmortem, com exemplos como indisponibilidade visível para o usuário acima de um limite, qualquer perda de dados, uma intervenção do plantão como um rollback e uma falha de monitoramento. Gatilhos fixados de antemão mantêm a decisão de escrever um postmortem separada de qualquer veredito sobre uma pessoa. Os revisores devem conferir se os itens de ação são adequados e priorizados.

Os três produtos fazem trabalhos diferentes. A linha do tempo é a evidência, e precisa ser construída para a frente, a partir do que as pessoas envolvidas conseguiam ver em cada etapa, porque o olhar retrospectivo faz o movimento certo parecer óbvio. O guia de campo de Sidney Dekker, no rascunho de agosto de 2000 que consegui ler, define a tarefa do investigador como descobrir como as avaliações e ações das pessoas faziam sentido na hora, dadas as circunstâncias ao redor, e o texto de Allspaw no Etsy se apoia na mesma ideia. Os fatores contribuintes são a explicação, e o plural é deliberado, já que uma causa-raiz única convida a um único culpado. Só as ações podem mudar o que acontece a seguir, e é por isso que as considero o produto do exercício.

O resumo da AWS mostra como as ações ficam quando o método funciona. A AWS mudou a ferramenta para retirar capacidade mais devagar e acrescentou uma verificação contra remoções abaixo da capacidade mínima de um subsistema. Começou a auditar outras ferramentas atrás da mesma brecha e antecipou o trabalho de dividir o subsistema de índice em mais células, para reduzir o tempo de recuperação. Mudou também o console de administração do painel de status para rodar em várias regiões, já que a dependência dele em relação ao S3 havia impedido a atualização do status até as 11h37. Cada uma dessas ações pode ser marcada como feita ou não feita, e nenhuma depende de alguém se lembrar de algo no momento certo. A entrada digitada errada continuou sendo o gatilho imediato. A revisão a tratou como um evento que o sistema deveria ter sido construído para tolerar.

No Etsy, segundo a descrição da InfoQ em 2014, os itens de ação dos postmortems tinham prioridade sobre outros trabalhos, inclusive o lançamento de produto, o que é um jeito de tornar vinculante o teste da mudança.

Fred Hebert, escrevendo para a Resilience in Software Foundation em abril de 2026, dá nome ao modo de falha: ausência de culpa superficial. Evita-se a retaliação, mas a remediação continua centrada em indivíduos, com mais treinamento, lembretes para prestar atenção, mais um revisor. O texto dele é um argumento de prática, sem dados, e por isso o uso como lista de conferência e não como achado. Uma heurística dele ainda assim serve: se a maior parte das ações trata do que pessoas específicas deveriam fazer melhor, desconfie de que a revisão parou nos indivíduos, e pergunte de cada item se ele muda as condições em que a próxima pessoa vai decidir.

Há uma lacuna na evidência. As fontes que abri estabelecem um mecanismo, o de que a punição suprime o relato, e incluem relatos de praticantes sobre como os postmortems são conduzidos. Não encontrei um estudo controlado mostrando que organizações que adotam postmortems sem culpa têm incidentes menos numerosos ou mais curtos. O que existe é um mecanismo plausível somado a uma prática consistente.

A objeção da responsabilização está meio certa

A objeção mais forte diz que a ausência de culpa tira a pressão que faz as pessoas terem cuidado. Se a equipe sabe que um deploy descuidado vai render um documento educado e nenhuma consequência, o descuido fica mais barato. Uma segunda versão é mais cínica e, penso, mais próxima de como o método falha na prática. As organizações adotam o termo para proteger gente sênior, de modo que as decisões sobre quanta gente alocar, que prazos fixar e que risco aceitar nunca são examinadas, enquanto as teclas que um engenheiro apertou são examinadas em detalhe.

O método tem resposta à primeira versão, e a resposta está na tradição de onde ele vem. O modelo de cultura justa de David Marx, resumido no posicionamento da ANA, separa três tipos de comportamento. Diante do erro humano simples, fazer algo diferente do que se pretendia, cabe consolar a pessoa e mudar processos, procedimentos, treinamento ou projeto. Já o comportamento de risco é uma escolha que aumenta o risco quando este não é reconhecido ou é tido por engano como justificado, e pede orientação e a remoção dos incentivos que premiam o atalho. Quando há desprezo consciente por um risco substancial e injustificável, tem-se o comportamento imprudente, que pede ação corretiva ou punitiva. No resumo da ANA, Marx defendia que a disciplina deve se vincular ao comportamento e ao risco que ele carregava, mais do que ao resultado efetivo. O posicionamento acrescenta que isso difere de uma cultura cujo princípio é a ausência de culpa, porque uma cultura justa não tolera o desprezo consciente por riscos claros.

A cláusula sobre resultados é a parte que me parece mais persuasiva. Tome o caso do S3: um parâmetro digitado errado é o mesmo comportamento quer remova dez servidores de que ninguém sente falta, quer remova os servidores de que uma região depende, e uma regra que pune só o segundo caso pune a sorte. A responsabilização no sentido da cultura justa se prende ao que a pessoa sabia e escolheu, e só pode ser aplicada com coerência quando a revisão primeiro estabeleceu o que era isso, o que explica por que a revisão precisa de relatos francos.

A versão de Allspaw acrescenta um sentido voltado para o futuro da palavra. No relato dele, os engenheiros são responsáveis ao dar um relato detalhado da sua contribuição e ao ajudar a projetar e a ensinar a correção. Quem cometeu o erro acaba dono de parte do acompanhamento, uma carga mais pesada do que uma repreensão.

A segunda versão da objeção, porém, está certa. A ausência de culpa aplicada só na ponta move a responsabilização para um lugar onde ninguém olha. O comportamento de risco é a categoria que põe isso à prova, porque costuma ser produzido por incentivos, como o atalho que poupa uma hora e é elogiado por isso. O remédio de Marx é remover esses incentivos, tarefa de gestor. Um postmortem que orienta o engenheiro e deixa o incentivo no lugar cumpriu metade da resposta prescrita, e a lista de remediações voltadas a indivíduos de Hebert é uma lista de maneiras de isso acontecer. Uma versão defensável do método é, portanto, mais estreita do que "ninguém tem culpa". Ela diz que a culpa não deve ser o mecanismo para coletar fatos, que as sanções pertencem a um processo separado, com padrão próprio, e que as decisões da própria organização entram no escopo da revisão.

Essa resposta tem um limite. O comportamento imprudente existe como categoria no papel, e não sei com que frequência as organizações o invocam. Uma linha que nunca é invocada é difícil de distinguir de uma linha que não existe, e não encontrei dados sobre quantas vezes alguém a cruza na prática.

A promessa errada de um chatbot pertence à empresa que o colocou no ar

Em novembro de 2022, Jake Moffatt perguntou ao chatbot do site da Air Canada sobre tarifas de luto enquanto organizava uma viagem. Segundo a imprensa e escritórios de advocacia, já que não consegui abrir a decisão em si, o chatbot disse que ele poderia comprar a passagem pelo preço normal e pedir a tarifa de luto depois, dentro de 90 dias da data de emissão do bilhete. A resposta trazia um link para uma página que dizia o contrário, que a política de luto não valia para pedidos feitos depois da viagem. O pedido dele foi negado, funcionários da companhia disseram que pedidos retroativos não eram aceitos e, em fevereiro de 2023, um funcionário lhe contou que o chatbot havia usado palavras enganosas. Em 14 de fevereiro de 2024, o Civil Resolution Tribunal da Colúmbia Britânica, em Moffatt v. Air Canada, 2024 BCCRT 149, mandou a companhia pagar CA$ 650,88 de indenização por declaração enganosa por negligência, CA$ 36,14 de juros e CA$ 125 em taxas do tribunal.

A defesa da Air Canada é a parte que importa aqui. Ela sustentou, em essência, que o chatbot era uma entidade jurídica separada, responsável pelos próprios atos, e que a política correta estava numa página com link, na qual o cliente deveria ter confiado mais do que no chatbot. O tribunal rejeitou as duas teses. Tratou o chatbot como parte do site da companhia, não viu diferença entre uma página estática e um chatbot, não achou razão para que o cliente tivesse de conferir um contra o outro e concluiu que a Air Canada não tomou o cuidado razoável de garantir que o chatbot fosse exato. O valor em jogo eram algumas centenas de dólares e não verifiquei como tribunais posteriores tratam a decisão, de modo que ela registra o raciocínio de um julgador e não é jurisprudência consolidada. O que ela mostra, num contexto jurídico, é o que aconteceu quando uma organização tentou negar a responsabilidade pelo que o próprio sistema respondeu.

Uma revisão sem culpa desse incidente teria de responder a perguntas que a decisão deixa em aberto. A decisão não descreve como a Air Canada construiu o bot, então só posso listar as perguntas, e são as que a defesa da entidade separada pula. A linha do tempo começaria no texto da política e na data em que o bot deu pela primeira vez a resposta dos 90 dias, e não no chat do cliente. Entre os fatores contribuintes a examinar estariam de onde veio a resposta do bot, se algo a comparava com a página de política para a qual ele apontava, quem era dono da coerência entre política e bot, e se as tarifas de luto, uma questão de política com dinheiro envolvido, apareciam em algum conjunto de testes. Por último viria o que aconteceu depois da admissão do funcionário em fevereiro de 2023, porque esse foi um momento documentado em que a empresa soube que o bot havia dito algo que a própria política contradizia. Cada um desses pontos tem um responsável a quem se pode dar um prazo, e nenhum exige decidir que uma pessoa em particular foi negligente.

Agora tome os dois alvos de culpa, um de cada vez. "O modelo alucinou" descreve o sintoma. Para um gerador probabilístico de texto, produzir uma resposta plausível e errada em alguma taxa é comportamento esperado, de modo que tratar isso como causa é o equivalente em IA de escrever "erro do operador" no relatório: nomeia o evento de superfície e encerra a investigação. "Quem escreveu o prompt" transfere a culpa para uma pessoa cujas instruções não poderiam, por si sós, garantir resposta nenhuma, e ensina o próximo a ficar longe de prompts. Os dois deixam intocados os fatores contribuintes de verdade, a verificação ausente entre a resposta e a política e o responsável ausente. Esse é o meu julgamento sobre onde a correção deve ficar. A revisão deve registrar, ainda assim, como prompts e modelos falharam.

Mudanças silenciosas de modelo pedem uma revisão que começa antes do incidente

Um segundo tipo de incidente de IA chega de fora. O modelo por trás de um produto muda, o produto piora, e nada visível mudou do lado do cliente. Os postmortems dos próprios fornecedores merecem leitura como exemplos do gênero, com a ressalva de que são o relato do fornecedor, publicados de modo seletivo e escritos para os fins dele.

Em 25 de abril de 2025, a OpenAI atualizou o GPT-4o no ChatGPT, e o modelo ficou visivelmente mais bajulador. A OpenAI aplicou uma mudança de prompt de sistema no fim de semana e reverteu a atualização na segunda-feira. No postmortem de 2 de maio, como o resumiu Simon Willison, as avaliações offline pareciam boas e pequenos testes A/B sugeriam que os usuários gostavam do modelo. Testadores internos especialistas disseram que o comportamento parecia um pouco estranho, e os sinais quantitativos pesaram mais do que essa impressão. A atualização não tinha sido anunciada porque a OpenAI esperava que fosse sutil. A empresa se comprometeu a tratar problemas de comportamento, como a personalidade, como impeditivos de lançamento e a comunicar atualizações mesmo quando parecerem pequenas. Li esse postmortem pelo relato de Willison e não na íntegra.

O postmortem da Anthropic de 17 de setembro de 2025 cobre três bugs de infraestrutura de agosto e do início de setembro. Um deles mandava algumas requisições do Sonnet 4 para servidores configurados para uma janela de contexto maior. No início afetava 0,8% das requisições e, na pior hora, em 31 de agosto, 16%, e cerca de 30% dos usuários do Claude Code no período tiveram pelo menos uma mensagem mal roteada. A detecção foi lenta, diz o texto, porque as avaliações comuns não captavam a degradação, porque os controles de privacidade limitavam o acesso dos engenheiros às interações dos usuários, a não ser que os usuários as enviassem como feedback, e porque bugs diferentes produziam sintomas diferentes em plataformas diferentes. O texto admite também que a empresa havia confiado demais em avaliações ruidosas e não tinha ligado os primeiros relatos a uma mudança recente de balanceamento de carga.

A atualização da Anthropic de abril de 2026 sobre o Claude Code atribuiu as reclamações a três mudanças. Um esforço de raciocínio padrão mais baixo vigorou de 4 de março a 7 de abril. Entre 26 de março e 10 de abril, um bug de cache, numa alteração pensada para apagar o raciocínio antigo só das sessões ociosas havia mais de uma hora, apagava-o a cada turno. Uma instrução de prompt de sistema que limitava a verbosidade vigorou de 16 a 20 de abril. Para esta última, semanas de testes internos não mostraram regressão nas avaliações rodadas na época, e um conjunto mais amplo, usado depois, mostrou queda de 3% em dois modelos. Pelo que li, nenhum dos três documentos atribui o incidente a uma pessoa nomeada. Eles nomeiam mudanças, limiares, testes e sinais, e os compromissos assumidos dizem respeito, na maior parte, a barreiras de lançamento, como avaliações por modelo, ablações de cada linha do prompt, períodos de observação e implantações graduais.

Para uma empresa que consome um modelo por API ou por um produto, o postmortem do fornecedor é um insumo da sua revisão e não a substitui. A sua própria revisão deve abrir com a pergunta a que as revisões dos fornecedores voltam o tempo todo: por que o instrumento dizia que estava tudo bem? Um exemplo inventado mostra como isso pode acontecer sem que ninguém seja descuidado. Suponha que uma avaliação noturna de 200 casos tenha 90% de aprovação, e que uma mudança do fornecedor derrube a taxa verdadeira para 85%. Comparando a nota de uma noite com a da anterior e tratando as duas noites como amostras independentes, o erro-padrão da diferença é de cerca de 3,3 pontos, de modo que uma queda de cinco pontos fica em torno de 1,5 erro-padrão e não se distingue do ruído. Chegar a 2,6 erros-padrão, mais ou menos o corte usual de um teste bilateral a 1%, para a mesma queda exige cerca de 600 casos por noite. Esses 600 são o ponto em que a queda esperada apenas alcança o corte, de modo que detectá-la com confiabilidade exigiria mais. Se os mesmos 200 casos são rodados todas as noites, uma comparação pareada tem menos ruído, mas aí o conjunto só fala por esses 200 casos. O engenheiro de plantão que olhou o painel e não viu nada fez o que o instrumento permitia. A falha está num conjunto de testes pequeno demais para mostrar uma queda de cinco pontos, e é para lá que vai o item de ação.

Uma revisão de um incidente assim, quer a causa tenha sido uma mudança do fornecedor, o prompt da própria empresa ou os dois, conteria estes itens:

  1. Uma linha do tempo montada com os logs da própria empresa, com o identificador do modelo, a versão do prompt, a versão do índice de recuperação e eventuais avisos do fornecedor ao lado dos eventos visíveis ao usuário.
  2. A detecção: o que percebeu o problema, quanto tempo depois da primeira saída ruim, e quais monitores ficaram em silêncio e por quê.
  3. Os fatores contribuintes por camada: mudança no modelo ou na infraestrutura do fornecedor; prompt e configuração próprios; dados e recuperação; barreiras de proteção; e o processo humano em volta delas.
  4. Os pontos de decisão, com o que cada pessoa sabia na hora e por que a ação fazia sentido para ela.
  5. O impacto sobre clientes e tudo o que o sistema prometeu e que a empresa agora precisa honrar ou corrigir.
  6. A classificação dos comportamentos envolvidos como erro, comportamento de risco ou imprudência, com os incentivos que moldaram eventuais escolhas de risco.
  7. Itens de ação com um responsável, um prazo e uma forma declarada de verificar a conclusão, e ao menos um deles deve alterar a detecção.
  8. O que se pediu ao fornecedor, como avisos de mudança, fixação de versão ou um relatório de regressão, e o que a empresa se comprometeu a informar aos próprios clientes.

O teste de um postmortem é uma mudança que se possa apontar

Pegue os três últimos postmortems que a sua equipe escreveu. Para cada item de ação, registre o responsável, a data em que foi concluído e como alguém saberia que funcionou. Conte quantos itens alteram uma ferramenta, uma verificação, um padrão ou uma permissão, e quantos se resumem a mandar treinar, a lembrar ou a ter cuidado. Depois procure no sistema de incidentes repetições da mesma classe de falha, pois a repetição é a evidência mais simples de que uma ação anterior não mudou nada.

Se há um sistema de IA em produção, acrescente mais um exercício. Escolha o modelo do fornecedor de que ele depende, suponha que ontem à noite ele regrediu em silêncio cinco pontos na sua própria tarefa e descubra quanto tempo o seu monitoramento atual levaria para perceber. Qualquer que seja a resposta, ela é o primeiro item de ação da próxima revisão, e pode ter um responsável antes de o incidente acontecer.

Fontes

  1. Amazon Web Services (28 de fevereiro de 2017). Summary of the Amazon S3 Service Disruption in the Northern Virginia (US-EAST-1) Region. https://aws.amazon.com/message/41926/
  2. Edmondson, A. C. (1996). Learning from mistakes is easier said than done: Group and organizational influences on the detection and correction of human error. Journal of Applied Behavioral Science 32(1), 5-28. O texto completo não foi aberto. Lido pelo resumo do PSNet da AHRQ (https://psnet.ahrq.gov/issue/learning-mistakes-easier-said-done-group-and-organizational-influences-detection-and), pela Harvard Magazine (2001), Secret Errors Kill (https://www.harvardmagazine.com/node/542), e por um resumo no site Field Guide (https://explore.psychsafety.com/n/edmondson-1996.md), que é comentário secundário.
  3. Edmondson, A. C. (1999). Psychological safety and learning behavior in work teams. Administrative Science Quarterly 44(2), 350-383. Resumo lido no registro do Harvard DASH (https://dash.harvard.edu/entities/publication/13a7b031-0fdd-45ec-a7e0-2b80e2bc679f); o texto completo não foi aberto.
  4. Reason, J. (2000). Human error: models and management. BMJ 320, 768-770. https://pmc.ncbi.nlm.nih.gov/articles/PMC1117770/
  5. Allspaw, J. (22 de maio de 2012). Blameless PostMortems and a Just Culture. Etsy, Code as Craft. https://www.etsy.com/codeascraft/blameless-postmortems/ (a página do Etsy bloqueou o acesso automatizado, então o texto foi lido na cópia da Internet Archive).
  6. Google (2016). Postmortem Culture: Learning from Failure. Capítulo 15 em Beyer, B., Jones, C., Petoff, J., Murphy, N. R. (orgs.), Site Reliability Engineering. https://sre.google/sre-book/postmortem-culture/
  7. American Nurses Association (28 de janeiro de 2010). Position Statement: Just Culture. https://anaprodsite1.nursingworld.org/globalassets/practiceandpolicy/health-and-safety/just_culture.pdf. O posicionamento foi lido na íntegra. Ele resume Marx, D. (2001), Patient Safety and the "Just Culture": A Primer for Health Care Executives (Columbia University), e cita o depoimento de Leape de 25 de janeiro de 2000 a um subcomitê do Senado americano; o texto de Marx e o depoimento foram lidos apenas por meio desse posicionamento.
  8. Dekker, S. (2006; 3ª ed. 2014). The Field Guide to Understanding 'Human Error'. Ashgate. Catálogos de bibliotecas descrevem o livro de 2006 como edição revista de seu Field Guide to Human Error Investigations, de 2002. Não li as edições publicadas. A frase citada no texto vem do rascunho de Dekker de agosto de 2000, The Field Guide to Human Error (https://www.leonardo-in-flight.nl/PDF/FieldGuide%20to%20Human%20Error.PDF), cuja redação pode diferir da dos livros publicados.
  9. Moffatt v. Air Canada, 2024 BCCRT 149 (Civil Resolution Tribunal da Colúmbia Britânica, 14 de fevereiro de 2024). O texto da decisão, no site do tribunal e no CanLII, bloqueou o acesso automatizado e não foi lido. Fatos, citações e a condenação (danos de CA$ 650,88, juros de CA$ 36,14, taxas do tribunal de CA$ 125) foram lidos pelo Daily Hive (15 de fevereiro de 2024, https://dailyhive.com/canada/air-canada-chatbot-decision) e por um artigo de escritório de advocacia em dww.com (https://www.dww.com/articles/bc-tribunal-finds-air-canada-liable-for-inaccurate-advice-given-by-website-chatbot), além de resumos em resultados de busca de outras coberturas jurídicas.
  10. Anthropic (17 de setembro de 2025). A postmortem of three recent issues. https://www.anthropic.com/engineering/a-postmortem-of-three-recent-issues
  11. Anthropic (23 de abril de 2026). An update on recent Claude Code quality reports. https://www.anthropic.com/engineering/april-23-postmortem
  12. OpenAI (2 de maio de 2025). Expanding on sycophancy. https://openai.com/index/expanding-on-sycophancy/ (lido por meio de Willison, S., 2 de maio de 2025, https://simonwillison.net/2025/May/2/what-we-missed-with-sycophancy/).
  13. Hebert, F. (15 de abril de 2026). Superficial blamelessness. Resilience in Software Foundation. https://resilienceinsoftware.org/news/11502437
  14. Miranda, J. (28 de julho de 2014). Blameless post-mortems. InfoQ. https://www.infoq.com/news/2014/07/blameless-post-mortems
  15. Aritmética ilustrativa de avaliação: um conjunto noturno de 200 casos, uma taxa de aprovação verdadeira caindo de 90 para 85%, um erro-padrão de cerca de 3,3 pontos para a diferença e cerca de 600 casos para 2,6 erros-padrão. Esses números são inventados para o exemplo.