Proveniência de dados para cientistas, explicada por um engenheiro

Pegue um número da tabela de resultados de qualquer artigo. De onde ele veio? Não 'dos dados', mas precisamente: qual arquivo bruto, quais linhas, quais filtros, quais transformações, qual versão de qual script, rodado por quem, em que data. Se você responde isso em menos de um minuto, tem proveniência. Se a resposta envolve a memória de alguém, tem uma história.

Proveniência é cadeia de custódia

A perícia forense tem um nome para isso: cadeia de custódia. Cada vez que a prova muda de mãos, alguém assina. Se a cadeia quebra, a prova não vale, por mais convincente que pareça. Dados merecem o mesmo tratamento. A afirmação no final é tão forte quanto o elo mais fraco entre ela e a observação.

Em software, construímos isso nunca alterando nada no lugar. O dado bruto chega uma vez e é congelado. Cada etapa que deriva algo escreve um novo artefato e registra o que leu, que código rodou e o que produziu. O resultado é um grafo: os nós são datasets, as arestas são transformações. Percorra de trás para frente a partir de qualquer número e você chega ao instrumento que fez a medição.

As três coisas a registrar

• O quê: um hash de conteúdo de cada entrada e saída, para provar que nada foi alterado em silêncio
• Como: o código e o ambiente exatos que rodaram, por hash de commit e lock de dependências, não por descrição
• Quem e quando: a pessoa ou o processo que disparou a execução, e o horário

É isso. Três campos, registrados automaticamente pelo pipeline em vez de digitados num caderno de laboratório. A automação importa mais do que os campos. Proveniência que depende de alguém lembrar de anotar apodrece em um mês.

Como fica na prática

Você não precisa de um banco de grafos. Uma convenção de pastas e um script pequeno entregam a maior parte do valor. Cada dataset derivado mora na própria pasta com um arquivo de manifesto: entradas por hash, o commit do git, a linha de comando, o lock do ambiente, o horário da execução. O script que produz o dataset também escreve o manifesto. Se o manifesto não existe, o dataset não é confiável. Se o hash de uma entrada não bate com o manifesto, o pipeline se recusa a rodar.

Quando alguém pergunta por que o tamanho de efeito mudou entre o rascunho e a submissão, você compara dois manifestos em vez de marcar uma reunião.

Por que editar no lugar destrói tudo

A falha de proveniência mais comum que já vi em dados científicos é a edição bem-intencionada. Um colaborador nota um erro óbvio de digitação na planilha, corrige, salva. A correção estava certa. Agora ela também é invisível. Ninguém sabe quais células foram tocadas, se a edição veio antes ou depois da análise rodar, ou se uma segunda correção, menos óbvia, aconteceu na mesma sessão. O preço dessa conveniência é a cadeia de custódia inteira.

A regra é simples e inegociável: correção é transformação. Mora em código, com um comentário explicando o motivo, aplicada em cima do original intocado.

Proveniência é o que torna uma ferramenta confiável

Qualquer sistema que diga ajudar a pesquisa, incluindo qualquer coisa construída com IA, precisa carregar a proveniência por todas as etapas, ou está produzindo texto plausível, não evidência. A saída precisa conseguir dizer, para cada afirmação, quais fontes a sustentam e como. Cobro isso do meu próprio trabalho porque já vi o que acontece com conclusões que não podem ser rastreadas: são repetidas, depois citadas, depois acreditadas, e a essa altura ninguém lembra que nunca foram verificadas.