Suponha que o relatório final contenha a frase “as emissões de metano diminuíram 12%”. O revisor não pergunta apenas se esse número está correto. Ele retrocede para verificar quais fazendas e galpões foram incluídos, qual alimento foi fornecido, quando e em que quantidade, se havia dados ausentes ou problemas de calibração nos dados brutos, quem alterou a linha de base e a fórmula, quando isso ocorreu e quem aprovou o valor final. Essa conexão pode ser chamada de Evidence Chain, ou cadeia de evidências.
Uma cadeia de evidências não é o mesmo que armazenar muitos arquivos. Eventos de campo e observações, decisões de qualidade, resultados de cálculos e alegações devem estar ligados por identificadores exclusivos, datas, horários e versões. Mesmo que um dado sem conexão seja verdadeiro, é difícil usá-lo como evidência capaz de reproduzir uma alegação.
Projete de trás para a frente, começando pela alegação final
Coletar todos os dados disponíveis para só depois procurar um significado é caro e facilita a ausência de evidências essenciais. Primeiro, defina a unidade da alegação. Por exemplo: quanto os kg CH₄ mudaram, em comparação com uma linha de base pré-registrada, durante um período definido em uma fazenda e um galpão específicos. Registre o limite, o período, o indicador e a condição de comparação. Créditos de carbono, relatórios para clientes e melhorias operacionais internas exigem níveis diferentes de evidência e conservadorismo; por isso, informe também a finalidade de uso.
Em seguida, decomponha o cálculo que sustenta a alegação. Se a redução for emissões da linha de base − emissões do projeto, serão necessários os dados de atividade, concentração e fluxo, fatores de emissão, variáveis de ajuste e incertezas de ambas as emissões. Relacionar cada entrada aos dados brutos e registros de campo de que se originou transforma isso em requisitos de coleta. Se o processo revelar uma variável que não pode ser obtida, o plano de medição ou o nível da alegação deve ser ajustado.
Primeiro elo: registros que demonstram que a atividade ocorreu no campo
Primeiro é necessário demonstrar a existência da atividade de redução. No caso de alimento, registre o produto e o número do lote, a quantidade recebida, as instruções de mistura, o início e o fim do fornecimento, a dose-alvo, a quantidade efetivamente fornecida, as sobras e o grupo de animais abrangido. No caso de uma alteração operacional, registre a configuração dos ventiladores, a instalação dos equipamentos, o método de manejo do esterco e a confirmação do responsável. Um recibo de compra demonstra apenas que o produto chegou ao local; não constitui toda a evidência de que os animais-alvo realmente o ingeriram.
Os registros de campo devem incluir a data, o horário e o responsável. Dados inseridos em lote posteriormente com base na memória têm força probatória diferente de dados registrados logo após o evento. Mesmo em ambiente offline, salve-os localmente e, quando a conexão for restabelecida, preserve tanto o horário original de criação quanto o horário de envio. Fotografias podem servir como evidência complementar, mas é preciso confirmar o momento da captura, o objeto e o escopo do consentimento, além de proteger os dados pessoais.
Segundo elo: dados brutos dos sensores e estado dos dispositivos
Dados brutos são os valores e metadados originalmente gerados pelo dispositivo. Preserve em conjunto o ID do dispositivo, o canal do sensor, a unidade, o carimbo de data e hora, a localização, o firmware, os coeficientes de calibração e o estado de diagnóstico. Em vez de usar apenas a data no nome de um arquivo CSV, utilize IDs exclusivos da fazenda, do galpão, do dispositivo e da sessão de medição para facilitar a ligação com outros dados.
Não altere os dados brutos. Mesmo quando uma unidade ou um fuso horário incorreto for identificado, crie separadamente uma tabela de correções e um histórico de transformação. Atribuir um hash ao arquivo ou lote ajuda a verificar sua identidade posteriormente. No entanto, o hash não garante que os dados estejam corretos; ele apenas permite verificar se o arquivo foi alterado. A calibração do dispositivo e a representatividade da instalação exigem evidências separadas.
Terceiro elo: QA/QC e decisões sobre exceções
As regras automáticas de qualidade sinalizam a taxa de coleta, valores fora da faixa, valores fixos, mudanças bruscas, erros de relógio e possíveis derivas. Uma pessoa compara esses sinais com o diário de campo, os registros de calibração e os sensores próximos para decidir se se trata de um evento real ou de um problema do dispositivo. Registre a marcação, o responsável pela decisão, a data e a hora, a fundamentação e o tratamento adotado. Em vez de apagar valores, é mais útil para revisões futuras manter os estados usar, usar condicionalmente e excluir, gerenciando códigos que indiquem o motivo da exclusão.
A orientação da Agência de Proteção Ambiental dos Estados Unidos sobre o Inventory Management Plan apresenta como elementos principais de um plano de gestão os limites, os métodos de quantificação, as fontes e a coleta de dados, a garantia de qualidade, o ajuste do ano-base, as funções e a gestão de arquivos, as auditorias e verificações e as ações corretivas. O GHG Protocol também recomenda realizar o controle de qualidade em vários níveis, desde a coleta dos dados até a aprovação final, e manter procedimentos de documentação e arquivamento e ciclos de feedback.
Quarto elo: linhagem do cálculo e reprodutibilidade
Controle por versão todas as etapas em que os dados tratados se transformam em resultados. Registre as fórmulas, as conversões de unidades, a fonte e a versão dos fatores de emissão, o modelo da linha de base, a imputação de dados ausentes, o período de agregação e as regras de arredondamento. Cada execução do cálculo deve estar ligada à versão dos dados de entrada, à versão do código ou da planilha, à data e hora da execução e a quem a realizou.
Mesmo ao usar uma planilha, é possível manter um modelo original, células de fórmulas bloqueadas, validação de entrada, histórico de alterações e um procedimento independente de recálculo. Se uma API de software for usada, registre os esquemas da solicitação e da resposta, a versão do mecanismo de cálculo e o reprocessamento de falhas. O que importa não é uma tecnologia específica, mas a possibilidade de reproduzir o mesmo resultado com as mesmas entradas e versões.
Quando um resultado mudar, não sobrescreva o valor anterior; publique uma nova versão. Indique se o motivo foi calibração do sensor, correção dos dados de atividade, revisão do fator de emissão ou mudança de limite, e calcule o impacto. A versão do resultado usada na alegação final deve ficar fixada.
Quinto elo: revisão, aprovação e relato externo
Separar as funções de autor, revisor e aprovador reduz o risco de autorrevisão. A revisão técnica examina limites e métodos, unidades, cálculos e incertezas; a aprovação gerencial verifica a autorização de divulgação e se a redação não ultrapassa o alcance das evidências. Quando houver necessidade de verificação por uma 3ª parte, forneça um pacote somente leitura que permita ao verificador rastrear os dados brutos, as amostras e os cálculos.
O programa de relato de gases de efeito estufa da EPA aplica verificações eletrônicas aos dados enviados e, quando identifica um possível erro, solicita que o declarante o explique, corrija ou reenvie. A validação automática é útil, mas não confirma por si só os fatos de campo. A Evidence Chain também inclui as respostas aos alertas, as correções e a nova aprovação.
O relatório final não deve apresentar apenas a taxa de redução. Inclua o limite e o período do projeto, a linha de base, o método de medição e cálculo, a disponibilidade dos dados, as exclusões relevantes, a incerteza, o nível de revisão e as limitações da alegação. “Foi medido”, “foi verificado”, “foi certificado” e “foram emitidos créditos” são estados diferentes; expresse apenas as etapas efetivamente concluídas.
Estrutura mínima de dados
Ao implementar uma Evidence Chain, é útil separar as seguintes entidades. site e barn representam os limites espaciais; animal_group, o objeto da aplicação; intervention_event, a atividade de redução; device e calibration, o estado do dispositivo; observation_batch, os dados brutos; quality_review, a decisão de qualidade; calculation_run, a versão do cálculo; claim, a frase final; e approval, a revisão e a autorização de divulgação.
Cada entidade deve ter um ID exclusivo, datas e horários de criação e alteração, responsável, estado e ligação com a versão anterior. Deve ser possível navegar do registro da alegação até a execução do cálculo, desta até os lotes de entrada e revisões de qualidade, e das entradas até as atividades de campo e a calibração dos dispositivos. No sentido inverso, também deve ser possível identificar quais relatórios e alegações foram afetados por um determinado erro de calibração.
Divida as permissões de acesso conforme a função e a finalidade. Dados pessoais da fazenda e dados operacionais brutos, materiais para a entidade verificadora e versões destinadas à divulgação externa não são a mesma coisa. Proteja também o próprio log de auditoria e defina períodos de retenção e políticas de exclusão. Tecnologias específicas, como blockchain, são opcionais; primeiro implemente corretamente identificadores, permissões, versões, backup e recuperação.
Lista de verificação para execução
Especifique na alegação final o limite, o período, o indicador, a linha de base e a finalidade de uso.
Decomponha o cálculo da alegação até as variáveis de entrada e defina o proprietário dos dados brutos de cada variável.
Colete registros de lote, dose, objeto, horário e responsável pelas atividades de campo.
Preserve os dados brutos de forma imutável e mantenha separadas as correções, exclusões e agregações.
Relacione o ID, a localização, a calibração e o firmware do dispositivo aos lotes de observação na mesma linha do tempo.
Registre as marcações de QA/QC, a decisão humana, a fundamentação e as ações corretivas.
Assegure que o cálculo possa ser reproduzido com as versões das entradas, do código, dos fatores e do modelo.
Separe a revisão técnica e gerencial da aprovação de divulgação e fixe a versão da alegação.
Indique no relato externo a disponibilidade dos dados, a incerteza, as limitações e o estado da verificação.
Quando um erro for encontrado, rastreie de volta os cálculos e as alegações afetados e publique novas versões.
Conclusão
A confiança nos dados de redução de carbono depende mais das conexões que levam ao número final do que da quantidade de casas decimais desse número. Deve ser possível rastrear, nos dois sentidos, se a atividade realmente ocorreu em campo, em que estado o dispositivo gerou os valores, quais dados foram excluídos e por quê, quais fórmulas e versões produziram o resultado e quem revisou e aprovou cada elemento. A Evidence Chain não é um mecanismo que garante automaticamente a aprovação em uma verificação, mas uma estrutura operacional que permite detectar, explicar e corrigir erros. Somente com essa estrutura os registros de campo podem sustentar uma alegação responsável de redução de carbono.