Por dentro da stack de dMRV da CarbonVision

Deixando a linguagem de lado, um crédito de carbono é uma linha de base de dados: uma quantidade, uma data, um método, um proprietário. O que o torna valioso não é a linha (qualquer um pode escrever uma linha), mas tudo o que está por trás dela. O dMRV, medição, reporte e verificação digitais, é a disciplina de tornar esse suporte real: instrumentar o processo físico para que cada número declarado tenha uma cadeia de custódia até uma medição em bruto que ninguém possa editar em silêncio [1].

Estamos a construir essa camada como uma plataforma independente, a CarbonVision (carbonvision.io), em vez de a comprarmos, por uma razão que vale a pena afirmar claramente: a prova de que uma remoção certificada precisa não pode ser reconstruída depois do facto. Ou a registámos no momento, numa forma que um auditor aceita, ou não. Este artigo é a arquitetura, e o raciocínio por trás de cada camada.

As quatro camadas

Cada camada existe para derrotar uma falha específica. O edge existe porque a transcrição humana é o elo mais fraco em qualquer cadeia de medição. O gateway existe porque os sítios industriais rurais perdem conectividade, e os dados que só existem em trânsito são dados que se acabam por perder. O ledger existe porque um número que um auditor não consegue rastrear é um número que tem de descontar. E a interface do registo existe porque as metodologias mudam: o registo em bruto tem de sobreviver às regras que lhe são aplicadas.

O edge: medir o que muda, onde muda

Os instrumentos ficam na própria linha de produção: massa à entrada e massa à saída, perfil de temperatura do reator, humidade da matéria-prima, limites da corrida. O princípio de design é que uma medição deve ser feita o mais perto possível do evento físico, com o menor número de passos humanos pelo meio que consigamos gerir. Cada reintrodução manual de um número é uma oportunidade para um erro que fica invisível depois: um erro de digitação e uma fraude parecem idênticos numa folha de cálculo.

Os dados contínuos fazem algo que a amostragem periódica não consegue: estabelecem o que é o normal, para que o anormal se torne visível. Uma excursão de temperatura numa corrida, um desequilíbrio de massa que não devia existir, uma falha de secagem às três da manhã: estes são os eventos que alteram em silêncio o teor de carbono de um lote, e são invisíveis para quem lê um resumo mensal.

O gateway: sobreviver ao mundo real

A pirólise acontece onde está a biomassa: sítios rurais com conectividade pouco fiável, poeira, vibração e interrupções de energia. Por isso, o gateway faz buffer localmente e reencaminha quando pode, em vez de assumir uma rede. Coloca timestamp e assina as leituras no ponto de captura, para que a proveniência de um registo viaje com ele, e degrada-se de forma graciosa: um sítio que perde a ligação continua a produzir prova, e reconcilia quando a ligação regressa.

O ledger: o lote é a unidade de verdade

Esta é a decisão de design central, e é uma decisão de modelação de dados. Tudo (fluxos de sensores, certificados de laboratório, origem da matéria-prima, transporte, energia de ciclo de vida) se liga a um lote. Não a um mês, não a um sítio, não a um projeto. O lote é a mais pequena unidade que tem um número de carbono defensável, por isso é a unidade em torno da qual todo o sistema está delimitado, e é o que torna uma única tonelada emitida rastreável em vez de meramente plausível.

Os registos são apenas de acréscimo (append-only). Uma correção não sobrescreve o original; é um novo registo que o substitui, com a razão anexada. Isto parece pedante até se ser o auditor: a diferença entre um sistema que mostra as suas correções e um que mostra apenas as suas conclusões é a diferença entre prova e afirmação.

A regra de reconciliação também vive aqui. Quando o valor de carbono derivado dos sensores e o resultado de laboratório divergem, o ledger transporta o valor conservador, tal como definido pela metodologia aplicável, e regista a diferença: o tema de um artigo separado. Uma regra que vive no software é aplicada a cada lote; uma regra que vive num documento de política é aplicada quando alguém se lembra.

A interface do registo: as regras mudam, os registos não

A camada final aplica uma metodologia de registo (a metodologia de biochar da Puro.earth e, com o tempo, o que quer que os atos delegados do CRCF da UE especifiquem [2][3][4]) ao registo do lote, e produz o pacote de prova que um auditor percorre. Manter esta camada separada é deliberado: as metodologias são revistas, os fatores de permanência são atualizados, chegam novos enquadramentos. Quando chegam, queremos voltar a correr o cálculo sobre os mesmos registos em bruto, em vez de irmos à procura de dados que nunca captámos. As medições são o ativo; a metodologia é uma função que lhes é aplicada.

O que não estamos a afirmar

Isto é uma arquitetura e um conjunto de compromissos, não uma vaidade sobre um sistema em funcionamento. A CarbonVision está a ser construída em paralelo com a nossa primeira capacidade de produção, e o estado honesto é que o design é aquilo a que nos vinculamos à medida que os sítios entram em funcionamento, incluindo a integração com os nossos parceiros de laboratório acreditados e altamente especializados, onde a permanência medida por petrografia de R₀ chega como dados estruturados em vez de um PDF anexado a um email. Preferimos publicar o padrão para o qual estamos a construir e ser responsabilizados por ele do que descrever um sistema acabado que ainda não existe.

As Figuras 1 e 2 descrevem a arquitetura para a qual estamos a construir; são diagramas de design, não capturas de ecrã de um sistema em produção. Os termos estão definidos no glossário.