Sentinela.

Validar que o alerta tem base antes de investir tempo de diagnóstico.

• Conferir o que chega no deep-link: janela, etapa afetada, recorte (canal, campanha, executor), n de leads, versão do agente ativa e parâmetros do monitor (banda da etapa, N_periodos). Se faltar item, devolver ao Sentinela antes de começar.
• Checar o n da janela contra n_minimo_leitura(conta), parâmetro a calibrar. Se o n está abaixo do mínimo, o alerta fecha como leitura sem base e o desfecho vai para o log.
• Confirmar que o disparo respeitou o critério da casa: taxa_etapa(etapa, janela_movel) < banda_inferior(etapa, conta) por N_periodos seguidos, nunca contra número redondo. Disparo fora desse critério volta para calibração do monitor.
• Comparar a janela com período equivalente (mesmo dia da semana, mesma campanha ativa). Se a referência não é comparável, trocar a referência antes de ler o delta.

Descartar ou confirmar que o desvio nasce do canal ou da infraestrutura, antes de olhar comportamento. Regra da casa: investigar o canal antes de culpar o modelo.

• Listar eventos técnicos da janela (troca de provedor, migração de número, deploy, incidente de uptime). Se o início do desvio coincide com o timestamp de um evento técnico, a hipótese vira artefato e o caso roteia para o PB-F.
• Checar régua de terceiro ativa no canal: mensagem automática do provedor dentro da conversa muda o funil sem ninguém perceber (caso real: régua de carrinho abandonado do GupShup invadindo a contratação; não era o agente).
• Checar reprocessamento e duplicação de eventos: contagem de leads ou de transições inflada ou zerada por reprocessamento explica desvio sem mudança na operação. Decisão: recontar com dedupe e comparar com o número do alerta.

Descartar ilusão estatística: o número caiu de verdade ou a conta está errada?

• Recalcular a taxa com média ponderada de volumes absolutos (regra G8). Se o alerta nasceu de média de percentuais entre dias ou campanhas, refazer a conta pode dissolver o desvio.
• Estratificar por mix de entrada (origem, campanha, temperatura, perfil). Se a taxa dentro de cada segmento segue na banda e só o agregado caiu, a hipótese é mudança de mix, não de execução: o funil recebe outro lead.
• Declarar o par de versões do agente: versão ativa na janela do alerta vs versão do período de referência. Delta medido entre versões diferentes sem essa declaração não é leitura válida.
• Checar dado atrasado: venda ou transição registrada com atraso derruba a ponta do funil de forma artificial. Recalcular respeitando janela_maturacao(etapa) antes de declarar queda.

Localizar o degrau exato da perda e isolar a variável que mudou, confirmando o que NÃO mudou.

• Abrir o funil degrau a degrau e comparar cada taxa com a própria banda (exemplo calibrado, junho/2026 Hapvida: A1 26,93% chegam na Seller, A2 14,36% de handoff, A3 5,10% de qualificação, A4 35,51% de conversão). O diagnóstico aponta o primeiro degrau fora da banda, não o agregado.
• Confirmar o que segue estável: score de pitch estável descarta discurso; distribuição de tempos estável descarta cadência; fit de entrada estável descarta qualidade do lead. Registrar cada descarte como hipótese eliminada.
• Cruzar o degrau afetado com o recorte: se a perda concentra em um executor, uma campanha ou uma faixa de horário, a variável que mudou mora ali. Amostrar conversas do recorte para ver a mudança com os olhos.

Nomear a classe com medição que prova. A candidata entra como hipótese e só vira causa quando a query ou a amostra confirma e as alternativas estão descartadas.

• entrada/lead: o fit de entrada caiu no mesmo recorte e na mesma janela do desvio. Prova: conversão por faixa de fit estável (o funil converte igual o lead igual; o lead que chega é outro).
• esforço/cadência: intervalo entre contatos ou volume de follow-up mudou no recorte afetado com discurso estável. Prova: distribuição de intervalos antes vs depois.
• qualidade/discurso: score de pitch caiu no critério ligado ao degrau afetado. Prova: rubrica por critério com quote literal.
• técnica/canal: desvio sincronizado com evento técnico confirmado na etapa 1. Prova: série temporal com o degrau no timestamp do evento.
• capacidade: leads por executor acima da capacidade planejada no período. Prova: leads_dia(executor) vs capacidade_planejada(executor).

Transformar causa medida em ação reversível com dono e prazo, e fechar o ciclo que calibra a Sentinela.

• Escolher a ação pelo gabarito indicador → gap → ação da doutrina, sempre com dono e prazo. Mudança de comportamento de agente entra por A/B com canary em fração do tráfego, nunca direto em 100%.
• Agendar a re-medição N+2: a taxa do degrau afetado volta para dentro da banda? Se não volta, a causa foi mal medida e o diagnóstico reabre.
• Se a causa é nova, cadastrar no catálogo de erros com o Bibliotecário (sinal, prova, ação que funcionou).
• Gravar o desfecho no log do alerta (ação real ou falso positivo): é esse log que calibra a precisão da Sentinela (alvo do processo de análise contínua: 60% ou mais dos alertas gerando ação real).

Garantir que a leitura de tempo é de distribuição, no relógio certo, com n suficiente.

• Conferir o deep-link: janela, distribuição de tempos (não médias), recorte (executor, canal, faixa de horário), n de conversas, SLA de referência da conta, versão do agente e parâmetros do monitor.
• Ler distribuição, nunca média: um caso extremo puxa a média sem mudar a experiência típica. Critério: pct_dentro_de_sla(janela) < alvo_sla(conta) por N_periodos seguidos. Referência da doutrina para motion transacional: 1ª resposta em 5 min; o valor da conta é parâmetro a calibrar.
• Checar n mínimo de conversas por recorte (n_minimo_leitura, a calibrar): faixa de madrugada com poucas conversas não sustenta leitura.
• Separar os três relógios já no pré-voo: 1ª resposta, intervalos de meio de conversa e follow-up pós-proposta. O alerta precisa dizer qual estourou.

Descartar que a demora é criada pelo canal ou pela infraestrutura antes de cobrar qualquer executor.

• Checar debounce do canal: mensagens seguradas e agrupadas fazem o agente parecer lento ou repetitivo sem nenhuma mudança no agente (caso real: 6.804 ocorrências em 14 dias com gap mediano de 9,7s). Decisão: comparar timestamp de envio do lead vs timestamp de entrega ao agente.
• Checar fila e limite de requisições da infraestrutura (ex.: API do cliente recusando chamadas): espera criada pela infra não é decisão de ninguém e pede transbordo, não coaching.
• Checar régua de terceiro: mensagem automática do provedor no meio da conversa reseta o relógio e distorce o intervalo medido. Conferir o emissor real das mensagens da janela.
• Checar reprocessamento: mensagem duplicada cria turnos falsos e intervalos falsos. Recontar com dedupe.

Garantir relógio, fuso e agregação corretos antes de ler tendência.

• Medir do relógio certo: a latência conta do momento em que a mensagem do lead chega ao sistema até a entrega da resposta ao lead, no mesmo fuso em todas as visões (caso real: visões divergindo por fuso e regra de agregação).
• Ponderar por volume por faixa de horário (G8): a distribuição do dia é a soma ponderada das faixas, nunca a média das médias.
• Estratificar por mix (G10): executor que recebe lead de campanha de pico opera com fila maior; comparar executores só dentro do mesmo mix de origem e horário.
• Declarar o par de versões do agente entre o período de referência e a janela do alerta.

Localizar o relógio que estourou, isolar a variável que mudou e confirmar o que não mudou.

• Localizar o relógio e o ponto da conversa: 1ª resposta estável com follow-up estourando conta outra história que o inverso. O diagnóstico nomeia o trecho exato.
• Confirmar o que não mudou: volume de entrada estável descarta pico de demanda; score de pitch estável descarta que a demora vem de conversa mais difícil. Caso de referência já validado no produto: intervalo entre proposta e follow-up subiu de 4h para 19h no time B com discurso estável, padrão de queda de esforço, não de qualidade.
• Para pipeline esfriando (F6): medir tempo parado por etapa contra a banda da própria etapa e checar se a estagnação concentra em uma etapa, um executor ou uma faixa de valor.

Nomear a classe com medição que prova. A candidata entra como hipótese e só vira causa com a prova registrada e as alternativas descartadas.

• esforço/cadência: intervalos sobem com volume de entrada estável e discurso estável. Prova: distribuição de intervalos por executor antes vs depois, estratificada por mix.
• capacidade: intervalos sobem junto com leads por executor acima da capacidade planejada. Prova: leads_dia(executor) vs capacidade_planejada(executor) na mesma janela.
• técnica/canal: latência concentrada nas janelas de incidente do canal ou da infra. Prova: sobreposição da série de latência com o log de incidentes.
• entrada/lead: pico de campanha encheu a fila de todos ao mesmo tempo. Prova: volume por origem na janela vs referência.

Devolver o tempo ao lead com ação reversível, dono e prazo, e fechar o ciclo.

• Humano: rotina de blocos com o bloco de lead quente protegido. Agente: capacidade, fila e transbordo (gabarito da doutrina). Sempre com dono e prazo.
• Ação reversível: mudança de régua ou de prioridade entra por A/B ou por fração do tráfego antes de virar padrão.
• N+2: re-medir a distribuição de tempos contra o SLA e o tempo parado por etapa contra a banda.
• Causa nova no catálogo do Bibliotecário; desfecho gravado no log do alerta para calibrar a Sentinela.

Garantir que a comparação é válida: mesma rubrica, n suficiente, baseline do próprio executor.

• Conferir o deep-link: executor e tipo (humano ou agente), score em queda (pitch, processo ou esforço), janela da média móvel, n de conversas pontuadas, rubrica_versao, versão do agente e parâmetros do monitor.
• Checar n mínimo de conversas pontuadas na janela (n_minimo_scoring, a calibrar): score de poucas conversas não sustenta diagnóstico.
• Confirmar rubrica_versao única na comparação: score de versões diferentes da rubrica só compara via ponte de dual-scoring.
• Confirmar que o disparo foi contra a baseline do próprio executor: media_movel(score, executor) abaixo de baseline(executor) menos tolerancia(conta) por N_periodos seguidos, nunca contra número redondo nem contra outro executor sem estratificação.

Descartar que a nota caiu por artefato de canal, não por mudança de comportamento.

• Para agente: checar se a queda de score coincide com artefato de canal. Debounce que faz o agente repetir pergunta já respondida derruba score de conversa sem qualquer mudança no agente (caso real: 6.804 ocorrências em 14 dias, gap mediano de 9,7s).
• Checar transcrições contaminadas: mensagem reprocessada ou duplicada dentro da conversa avaliada distorce a nota. Decisão: reavaliar uma amostra com transcrição limpa e comparar as notas.
• Para humano: checar mudança de ferramenta, canal ou carteira na janela (troca de fila, canal novo de atendimento) que mude o terreno antes de mudar a nota.

Separar comportamento de seleção de lead: sem estratificação, a comparação atribui a pessoa o que é sorteio.

• Estratificar por mix de lead SEMPRE (G10): a distribuição meritocrática entrega leads melhores a quem converte mais; comparar executor vs time sem estratificar por origem, temperatura, perfil e horário atribui a comportamento o que é seleção.
• Agregar por média ponderada do volume de conversas (G8), nunca média de percentuais entre semanas.
• Para agente: declarar o par de versões (prompt, fluxo, guardrail) entre o período de referência e a janela do alerta. Queda que começa junto com versão nova aponta a hipótese para a versão.
• Auditar a amostra: estratificada por etapa e desfecho, nunca só as conversas que confirmam a tese.

Abrir o score por critério e aplicar a leitura processo/discurso/esforço (G6) para localizar o gap.

• Abrir o score por critério da rubrica com a quote literal: qual critério caiu e quais seguem estáveis. Exemplo do padrão: critério de âncora antes do preço caindo com abertura e sondagem estáveis localiza o gap na negociação.
• Aplicar a leitura G6: pitch alto com esforço em queda pede disciplina e volume, não retreino de discurso; pitch em queda com esforço estável pede coaching de discurso. O que ficou estável é a prova do que descartar.
• Humano vs agente na mesma régua: se o agente destoa do humano no mesmo critério e no mesmo mix de lead, o diff vira hipótese de ajuste do agente com valor estimado pela matemática do valor do ponto (V14).

Nomear a classe com medição que prova. A candidata é hipótese até a query ou a amostra confirmar e as alternativas caírem.

• esforço/cadência: volume, cobertura ou follow-up caiu com discurso estável. Prova: fato de esforço diário antes vs depois.
• qualidade/discurso: critério específico da rubrica caiu, com quote que mostra o comportamento. Prova: score por critério na mesma rubrica_versao.
• entrada/lead: o mix recebido piorou (fit, temperatura, origem). Prova: fit de entrada por executor na janela vs referência.
• capacidade: executor saturado tria em vez de vender. Prova: leads_dia acima da capacidade planejada com tempo por conversa caindo.
• técnica/canal: artefato contaminou a avaliação. Prova: a nota volta ao normal ao reavaliar transcrição limpa.

Converter o gap em coaching (humano) ou hipótese de ajuste (agente), com re-medição pareada ao desfecho comercial.

• Humano: pauta de 1:1 com UM gap prioritário, quote literal e ação do gabarito. Score é coaching antes de ser cobrança nos primeiros ciclos.
• Agente: hipótese quantificada → A/B com canary e critério pré-registrado. Nunca editar o agente direto em produção por causa de uma conversa ruim: anedota não é padrão.
• N+2: re-medir o score do critério afetado pareado ao desfecho comercial (score que sobe sem a conversão acompanhar é sinal de gaming, não de melhoria).
• Causa nova no catálogo do Bibliotecário; desfecho gravado no log do alerta.

Reproduzir antes de concluir e classificar a severidade na entrada.

• Conferir o deep-link: IDs de conversa e sessão sinalizadas, regra ou padrão violado, n de ocorrências na janela, versão do agente e dos guardrails, recorte.
• Reproduzir antes de qualquer conclusão: falha sem evidência reproduzida não entra no diagnóstico. Registrar: reproduzível sempre, intermitente (com a condição) ou não reproduzível.
• Classificar a severidade na entrada: violação com risco regulatório (condição comercial não aprovada, promessa de carência, orientação regulatória indevida) sobe na hora para o dono da conta, sem esperar o ciclo. Caso real: agente inventou '12x sem juros' e a lead fechou por causa disso.
• Congelar a evidência: transcrição, IDs e registros salvos antes de qualquer correção.

Investigar o canal antes de culpar o modelo: boa parte dos 'bugs do agente' nasce fora do agente.

• Régua de terceiro: mensagem automática do provedor dentro da conversa parece fala do agente (caso real: régua de carrinho abandonado do GupShup invadindo a contratação; o agente estava inocente). Decisão: conferir o emissor real de cada mensagem da transcrição.
• Debounce: mensagens do lead seguradas e agrupadas fazem o agente responder pergunta já respondida, o que parece loop do modelo (caso real: 6.804 ocorrências em 14 dias, gap mediano de 9,7s). Decisão: comparar timestamps de envio vs entrega.
• Reprocessamento: mensagem duplicada tratada como turno novo gera repetição que não é decisão do agente. Decisão: recontar as ocorrências com dedupe.
• Fechar a etapa com veredito medido: canal descartado por medição, nunca por opinião. Se o artefato explica o caso, o desvio fecha como técnica/canal e o agente sai da mira.

Checar se o dado que alimentou o agente estava certo antes de mexer no comportamento.

• Fonte oficial: preço e condição vêm só da fonte oficial, sem cálculo alternativo (caso real: fallback de cálculo divergindo do portal oficial; caso real: cidade mapeada para a tabela de outra região gerou preço errado).
• Valor falado = valor gravado: comparar a conversa com a proposta registrada (caso real: agente fala R$ 309, proposta grava R$ 284).
• Recontar o n de ocorrências com dedupe: mensagens duplicadas inflam a contagem e mudam a severidade do caso.
• Declarar o par de versões: o desvio existe nas duas versões ou começou com a versão nova? A resposta direciona a hipótese.

Com canal e dado descartados, isolar a instrução ou condição que dispara o desvio e confirmar o que não mudou.

• Isolar o gatilho: comparar conversas com e sem o desvio na mesma versão do agente para achar a condição de entrada que dispara a resposta errada.
• Confirmar o que não mudou: o desvio concentra em um fluxo, um produto ou um perfil de lead? O restante do comportamento segue dentro da rubrica? Registrar os descartes.
• Rodar o checklist de modos de falha da categoria (precificação, cadastro, conformidade, conversa/UX, handoff) para varrer falhas irmãs da mesma família antes de fechar o escopo.
• Handoff correto se confirma, não se corrige: se o comportamento certo era passar para humano, a investigação registra OK com evidência e o caso fecha sem mudança.

Nomear a classe com a prova que a confirma. Toda candidata é hipótese até a reprodução controlada fechar.

• técnica/canal: artefato reproduzido no canal com o agente inocente. Prova: emissor real da mensagem ou timestamps que mostram o artefato.
• qualidade/discurso (instrução ou fluxo): condição de entrada reproduzível gera a resposta errada de forma consistente. Prova: reprodução controlada com a condição isolada.
• entrada/lead (dado): dado de entrada errado ou incompleto alimentou a resposta. Prova: diff entre o dado usado e a fonte oficial.
• capacidade: degradação sob fila ou limite de requisições. Prova: concentração das ocorrências nas janelas de saturação.
• Regra inegociável: conformidade que não pode falhar nunca se corrige com prompt. A correção é guardrail em código com bateria de casos adversariais.

Corrigir com validação de ponta a ponta e rollout gradual, e alimentar o catálogo.

• Fix com teste de ponta a ponta em caso distinto do original; conformidade vira guardrail determinístico com bateria adversarial, com dono e prazo.
• Mudança de comportamento entra por canary em fração do tráfego antes de 100%, com critério de sucesso pré-registrado.
• N+2: re-medir a taxa de ocorrência do desvio. Para conformidade o alvo é zero; qualquer recorrência reabre o caso.
• Modo de falha novo entra no catálogo do Bibliotecário; desfecho gravado no log do alerta.

Separar falha de sistema de abandono do lead antes de qualquer leitura.

• Conferir o deep-link: janela, n de propostas e links emitidos, taxa link → pagamento vs banda, recorte (produto, filial, forma de pagamento, faixa de valor), versão do agente.
• Confirmar o disparo contra a banda da própria etapa: taxa(link→pagamento, janela_movel) < banda_inferior(checkout, conta) por N_periodos seguidos.
• Separar dois universos: propostas que falharam por erro de sistema vs links entregues que o lead abandonou. São dois diagnósticos com donos diferentes.
• Checar janela de maturação: pagamento registrado com atraso não é abandono. Recalcular com janela_maturacao(pagamento), parâmetro a calibrar.

Confirmar que o link chegou, a página funcionou e nenhuma régua externa atravessou o resgate.

• O link chegou? Conferir o status de entrega da mensagem com o link no canal, não só o envio.
• A página de pagamento estava no ar? Cruzar a janela do desvio com incidentes do provedor de pagamento e do checkout (uptime).
• Régua de terceiro: mensagem automática de carrinho abandonado do canal conflita com o resgate do agente e confunde o lead (caso real da régua do GupShup). Conferir o emissor de cada mensagem pós-link.
• Reprocessamento: proposta duplicada infla a base de links e derruba a taxa sem abandono real. Recontar com dedupe.

Checar a integridade da proposta: valor, cadastro e espelhamento. É onde moram as travas silenciosas.

• Valor falado = valor gravado: diff entre a conversa e a proposta registrada (caso real: agente fala R$ 309, proposta grava R$ 284; o lead abandona ao ver outro valor na tela).
• CPF tratado como texto: zero à esquerda truncado por campo numérico atinge cerca de 9% dos CPFs e trava o cadastro antes do pagamento (caso real).
• Composição da proposta: código de documento de dependente errado travou 100% das propostas com cônjuge ou filho (caso real). Testar de ponta a ponta a combinação concentrada no recorte.
• Proposta espelhada no sistema que o cliente consulta: gravar num sistema enquanto o time lê outro cria venda fantasma ou sumida.

Auditar o resgate: os últimos 10 minutos da venda são código e disciplina, não sorte.

• Timers de resgate dispararam no prazo? Acompanhar até a confirmação é código, não boa vontade (V6). Medir taxa de disparo e tempo até o resgate por conversa abandonada.
• O resgate traz valor novo ou só cobra? Amostrar mensagens de resgate da janela e pontuar pela rubrica de follow-up.
• Estratificar o abandono por forma de pagamento, faixa de valor e produto: concentração em uma combinação aponta a hipótese para ela, não para o discurso.
• Confirmar o que não mudou: conversão das etapas anteriores estável isola o problema no trecho link → pagamento.

Nomear a classe com a prova que a confirma. Candidata é hipótese até a reprodução ou o diff fechar.

• técnica/canal: erro reproduzido no fluxo de cadastro ou pagamento (CPF truncado, código de dependente, link não entregue). Prova: reprodução de ponta a ponta com dados de teste.
• entrada/lead (dado da proposta): valor ou composição divergente entre conversa e proposta. Prova: diff conversa vs proposta na amostra.
• esforço/cadência: timer de resgate não disparou ou disparou tarde. Prova: log de timers vs política da régua.
• qualidade/discurso: resgate sem valor novo, só cobrança. Prova: amostra de mensagens pontuada pela rubrica.
• entrada/lead (condição): abandono concentrado em leads sem condição de pagamento. Prova: recorte por perfil; o sinal volta para a qualificação anterior ao checkout.

Recuperar a venda que morre no fim do funil e provar a recuperação em R$.

• Fix técnico com teste de ponta a ponta em dados distintos do caso original; propostas travadas em produção reprocessadas, com dono e prazo.
• Ajuste de régua de resgate entra por A/B antes de virar padrão.
• N+2: taxa link → pagamento de volta à banda. Traduzir a recuperação em R$: cada venda recuperada vale o ticket do cliente e a receita da Khal (referência junho/2026: ticket de R$ 330 e R$ 82,50 de receita Khal por venda).
• Causa nova no catálogo do Bibliotecário; desfecho gravado no log do alerta.

Congelar a evidência e mapear quem já foi contaminado pelo número errado.

• Conferir o deep-link: métrica e fonte afetadas, janela, delta observado (vs banda ou vs fonte espelho), conectores da cadeia, última mudança conhecida de esquema ou taxonomia, histórico de reincidência do conector.
• Congelar a leitura errada (export ou captura) antes de mexer em qualquer coisa: sem o antes, não há prova do depois.
• Levantar quem já leu o número na janela: decisão tomada sobre dado ruim entra no escopo do fechamento.
• Checar o histórico de reincidência (F11): mesmo conector com a mesma causa nas ocorrências anteriores muda o objetivo de consertar para blindar.

Varrer a cadeia de coleta: é aqui que a maioria dos números errados nasce.

• Whitelist de eventos completa: evento novo fora da lista zera conversões e explode o custo aparente (caso real: pixel fora da whitelist gerou CPA de R$ 110 mil por lead e quase induziu decisão de mídia errada). Decisão: diff entre eventos recebidos e eventos esperados.
• Taxonomia e esquema: mudança de nomenclatura de campanha ou de esquema quebra o conector em silêncio (caso real). Decisão: comparar a taxonomia atual com a que o conector espera.
• Limite de linhas e paginação da API: relatório truncado faz o período terminar antes da hora (caso real: o mês 'terminou' no dia 26 sem aviso). Decisão: conferir contagem de linhas vs volume esperado e sinal de truncamento.
• Fonte espelho: cruzar com uma segunda fonte independente (caso real: ferramenta de analytics sem dados apesar de volume real). O lado que diverge da realidade operacional é o lado quebrado.
• Reprocessamento ou backfill em curso na janela: número em movimento não é número errado. Aguardar a maturação declarada antes de concluir.

Descartar erro de conta: agregação, fuso, atraso e reconciliação por amostra.

• Agregação consistente entre visões: fuso horário e regra de agregação diferentes fazem uma visão divergir da outra (caso real: subaba diferente do dashboard). Decisão: recalcular as duas com a mesma regra e comparar.
• Média ponderada de volumes absolutos (G8), nunca média de percentuais: refazer a conta pode dissolver o desvio.
• Dado atrasado vs dado perdido: respeitar janela_maturacao(fonte) antes de declarar sumiço.
• Reconciliação por amostra: recontar na fonte primária um recorte pequeno e comparar com o painel. Critério: diff acima de tolerancia_reconciliacao(conta), parâmetro a calibrar, confirma problema de pipeline.

Decidir se o número conta uma história técnica ou uma história de negócio.

• Degrau ou rampa: desvio que começa num timestamp exato aponta mudança técnica; desvio em rampa acompanha a operação. Sobrepor a série com o log de mudanças e implantações.
• Confirmar o que não mudou: se a fonte primária mostra operação estável e só o painel desvia, o problema é o pipeline de dado; se as duas desviam juntas, o dado está íntegro e o alerta roteia para o playbook de negócio (PB-A ou PB-B).
• Testar a hipótese reversa: reprocessar um dia da janela pelo pipeline corrigido e conferir se o número passa a bater com a fonte primária.

Nomear a classe com a prova. Aqui a classe dominante é técnica/canal; a exceção relevante é o falso positivo por atraso.

• técnica/canal (conector): whitelist, esquema, limite de API ou fuso. Prova: o timestamp do degrau coincide com o timestamp da mudança técnica.
• reincidência estrutural (F11): mesma causa no mesmo conector em ocorrências repetidas. Prova: catálogo do Bibliotecário com as ocorrências anteriores. A ação muda de consertar para blindar (teste de contrato, alerta de esquema, monitor de frescor do dado).
• dado atrasado (falso positivo): o número completa sozinho dentro da janela de maturação. Prova: re-leitura após a maturação; o desfecho ajusta o monitor.
• operação real: fonte primária e painel desviam juntos. Prova: reconciliação fecha dentro da tolerância; o caso é de negócio, não de dado.

Corrigir, reprocessar, avisar quem leu errado e blindar contra reincidência.

• Corrigir o conector e reprocessar (backfill) o período afetado, com dono e prazo.
• Comunicar a janela contaminada a todo mundo que leu o número errado: decisão tomada sobre dado ruim se revisa, e material de cliente afetado se corrige.
• Reincidente: blindar, não só consertar (teste de contrato do conector, alerta de mudança de esquema, monitor de frescor do dado), com dono e prazo próprios.
• N+2: reconciliação fonte primária = painel dentro da tolerância; reincidência marcada no catálogo do Bibliotecário por conector; desfecho gravado no log do alerta.