A solução não é outro painel maior. É um registro de evidência cross-layer que reúne a ação do modelo, o resultado do chicote e o estado observado do sistema. Cada alteração automatizada deve conter a meta original, a meta proposta, a evidência usada para fazer a substituição, a pontuação de confiança, a afirmação resultante e um status explícito de revisão humana.
Para uma conversa de avaliação ou aquisição, eu faria cinco perguntas. Primeiro, a ferramenta consegue distinguir um reparo bem-sucedido de uma execução bem-sucedida no alvo errado? Em segundo lugar, ele mede curas falsas em localizadores perturbados pelo adversário, em vez de apenas medir se um teste é executado novamente? Terceiro, um engenheiro pode reproduzir a decisão a partir de um registro de auditoria? Quarto, a ferramenta se abstém quando as evidências são fracas ou ela otimiza para uma construção verde? Quinto, seus eventos podem ser correlacionados com os rastreamentos de tempo de execução do aplicativo e com as chamadas de ferramenta do modelo?
Eu também exigiria um modo de operação em estágios. A reparação autónoma pode propor uma mudança, mas as alterações de alto impacto devem entrar na triagem assistida até que a organização tenha provas de que a reparação preserva o significado. Isto é semelhante em espírito à ênfase da engenharia do caos em experiências disciplinadas e observáveis: o sistema deve revelar os seus modos de falha sob condições controladas antes de ser confiável numa situação não controlada.
