Estrutura Mínima do MvF

Visão geral

Esta página define a estrutura mínima que um Framework de Verificação de Metodologia (MvF) deve conter para ser implementável, auditável e governável dentro do ecossistema dMRV da Carrot. A intenção não é forçar todas as metodologias em um formato rígido, mas garantir que qualquer framework submetido ao ecossistema contenha os blocos essenciais para execução digital consistente, formação de pacote de evidências, validação técnica e padronização.

A estrutura abaixo serve como referência para Autores de MvF, como base para avaliação interna pelo time de Operações e Metodologias e — no futuro — para processos de RFP e revisão comunitária. Toda seção segue o princípio de design for verification: cada requisito deve ser expresso de forma que a MvA (em execução automatizada) ou um auditor (em verificação independente) consiga responder, com base em evidências, se o requisito foi atendido.

As oito seções obrigatórias são:

1. Escopo e conceito
2. Referência metodológica e registry
3. Elegibilidade, critérios e exclusões
4. Eventos dMRV e catálogo de eventos
5. Entradas, evidências e política de evidências
6. Regras de validação e controles
7. Cálculos, fórmulas e parâmetros
8. Outputs e pacote de evidências digitais

---

Escopo e conceito

O MvF deve começar estabelecendo, de forma transparente, qual problema ambiental ou propósito o dMRV pretende endereçar e qual é o mecanismo de geração de impacto que será quantificado e reportado. Esta seção define o "contrato conceitual" do framework: o que ele mede, em que condições e com quais limites. Sem esse enquadramento, critérios e cálculos posteriores ficam sujeitos a interpretações e se tornam difíceis de verificar.

O autor deve descrever o escopo do dMRV, incluindo:

• Problema e propósito — O problema ambiental sendo endereçado e o mecanismo de impacto específico que a metodologia quantifica.
• Fronteira do sistema — Quais atividades, etapas do processo ou fluxos estão incluídos na quantificação — e quais são explicitamente excluídos e por quê — em alinhamento com a metodologia validada por terceiros.
• Unidade de quantificação — A unidade de medida e o tipo de output esperado no contexto metodológico aplicável (ex.: tCO2e de emissões evitadas, toneladas de material reciclado). O objetivo não é inventar parâmetros, mas indicar claramente o que será contabilizado e como se conecta à referência metodológica.
• Tipo de output — Se a metodologia produz créditos, certificados, ou ambos, e em quais condições.
• Contexto de aplicabilidade — Setor, tipo de operação, recorte geográfico, condições operacionais mínimas e quaisquer pressupostos críticos que condicionem a validade do framework. Essa delimitação é essencial para integridade — evita que o dMRV seja aplicado fora do contexto para o qual foi desenhado.

Saída esperada: ao final desta seção, qualquer leitor técnico deve conseguir responder claramente: "O que este dMRV mede, em qual contexto se aplica, qual é sua fronteira e qual output pretende produzir conforme a metodologia validada de referência?"

---

Referência metodológica e registry

Após definir escopo e conceito, o MvF deve declarar com precisão qual metodologia validada por terceiros fundamenta o dMRV. Isso é crítico para integridade e auditabilidade: o framework não pode "flutuar" sem ancoragem e validação externa, pois é justamente essa referência metodológica que delimita premissas, lógica de quantificação, requisitos de evidência e condições de validade.

O autor deve identificar a metodologia de referência com detalhe suficiente para eliminar ambiguidades, incluindo:

• Nome oficial, versão, data e entidade responsável
• Um identificador permanente ou referência pública estável (ex.: link permanente ou registro equivalente de publicação)
• Anexos, tabelas, apêndices ou versões substitutivas relevantes para os cálculos

Além de apontar a fonte, o MvF deve deixar claro como a metodologia será operacionalizada no framework. Não se trata de repetir o conteúdo da metodologia, mas de explicar a relação entre a referência externa e o MvF: quais seções da metodologia são materialmente relevantes, quais requisitos serão traduzidos em eventos, regras e fórmulas, e quais dependências são assumidas. Esse contexto narrativo prepara o leitor para a Matriz de Rastreabilidade, que faz o mapeamento estruturado requisito a requisito.

Um aspecto importante é registrar os limites de interoperabilidade: o que o MvF assume como pré-requisito externo (ex.: validação metodológica, decisões de elegibilidade macro, processos de homologação de participante, regras de registro) versus o que é executado pelo dMRV na plataforma (regras operacionais, validações digitais, evidências e outputs auditáveis). Essa separação mantém a documentação consistente com o posicionamento da Carrot como plataforma de orquestração dMRV.

Saída esperada: ao final, deve estar inequívoco qual metodologia externa embasa o dMRV, quais dependências e limites se aplicam, e se existe um registry relacionado — incluindo o papel desse registry e a fronteira entre o que é externo e o que o dMRV executa.

---

Elegibilidade, critérios e exclusões

A definição de critérios de elegibilidade, exclusão e exceção é uma das etapas mais sensíveis na construção de um MvF. Critérios mal formulados geram dois tipos de problema: ou permitem a entrada de participantes e processos que comprometem a integridade dos créditos, ou excluem indevidamente operações legítimas que atendem aos objetivos da metodologia.

O princípio orientador é o design for verification: cada critério de elegibilidade deve ser descrito de forma que alguém — seja a MvA em execução automatizada, seja um auditor em verificação independente — consiga responder, com base em evidências, se o requisito foi atendido, sem margem para interpretação subjetiva.

Critérios verificáveis vs. narrativos

A diferença entre um critério narrativo e um critério verificável é a diferença entre intenção e operacionalidade.

Um critério narrativo declara uma condição de forma genérica:

O participante deve possuir licença ambiental vigente.

Isso comunica a intenção, mas não orienta a verificação: o que significa "vigente"? Qual documento comprova? Que campo ou metadado deve ser validado? Qual é a regra de rejeição? Existe critério de exceção?

Um critério verificável descreve a mesma condição em termos que permitem validação objetiva:

O participante deve submeter documento de licença ambiental emitido por órgão competente, com data de validade igual ou superior à data de início do período de monitoramento. O sistema deve verificar a presença do campo 'data de validade' e comparar com a data de referência do período. Caso a licença esteja vencida ou o campo ausente, o participante é impedido de prosseguir no fluxo de homologação.

Ao escrever cada critério, o Autor do MvF deve se perguntar: "Se eu entregar apenas esse texto ao developer, ele consegue implementar a validação sem me consultar?" Se a resposta for não, o critério precisa ser refinado.

Três camadas de elegibilidade

O MvF deve organizar seus critérios em três camadas distintas:

1. Elegibilidade de participantes — Requisitos mínimos que cada tipo de participante (gerador de resíduos, transportador, processador, reciclador) deve atender para ser homologado e operar dentro do dMRV. Tipicamente envolvem:

• Documentação legal e regulatória (licenças, alvarás, registros)
• Capacidade operacional comprovável (capacidade instalada, equipamentos, certificações técnicas)
• Localização geográfica (quando a metodologia tem recorte territorial)
• Vínculos ou impedimentos cadastrais (conflitos de interesse, histórico de não conformidades, restrições regulatórias)

2. Elegibilidade de materiais e processos — Quais tipos de resíduos, atividades ou fluxos operacionais o dMRV aceita. Essa definição deve ser precisa o suficiente para evitar ambiguidade. Em vez de "Resíduos Orgânicos", o framework deve especificar as categorias aceitas por código de classificação oficial, condições de aceitação com limites de contaminação, requisitos de separação na fonte e quaisquer restrições aplicáveis (ex.: exclusão de resíduos perigosos ou de origem industrial específica).

3. Exclusões e exceções — Exclusões são condições que impedem definitivamente a aprovação, independentemente de outros critérios atendidos. Exceções são situações atípicas, previstas e documentadas, nas quais um critério padrão pode ser flexibilizado sob condições específicas. A distinção é importante: exclusões são absolutas (se o critério de exclusão for atingido, não há caminho alternativo), enquanto exceções devem ser acompanhadas de justificativa, evidência adicional e — quando aplicável — aprovação formal.

Critérios condicionais e contextuais

Em muitas metodologias, os critérios de elegibilidade não são uniformes — variam conforme o contexto de aplicação. Por exemplo, uma metodologia com abrangência geográfica ampla pode ter requisitos diferentes por país ou região, devido a diferenças regulatórias ou de infraestrutura. O MvF deve declarar explicitamente quais critérios são universais (aplicáveis a todos os participantes e contextos) e quais são condicionais (aplicáveis apenas sob certas circunstâncias), identificando o gatilho que ativa cada condição.

Da mesma forma, critérios podem ter temporalidade: um requisito que se aplica na homologação inicial pode ser diferente de um requisito de manutenção ou renovação. O framework deve deixar claro em que momento do ciclo cada critério é verificado e com que frequência.

Saída esperada: ao final desta seção, qualquer leitor técnico — incluindo o developer da MvA e o auditor — deve conseguir responder, para cada tipo de participante e material: "Este candidato é elegível?", "Sob quais condições?", "O que o impede?" e "Há alguma exceção aplicável?" — sem precisar consultar o autor do framework.

---

Eventos dMRV e catálogo de eventos

No ecossistema dMRV da Carrot, o evento é a unidade fundamental de verificação. Um evento dMRV representa uma ocorrência operacional relevante no fluxo da cadeia de suprimentos que precisa ser registrada, verificada e rastreada. É no nível do evento que entradas (dados e documentos) ganham significado, validações são aplicadas, evidências são geradas e a trilha de auditoria é construída.

Se o MvF fosse a planta de uma construção, o catálogo de eventos seria a lista detalhada de cada etapa da obra, com materiais necessários, verificações obrigatórias e critérios de aceitação para cada fase. Sem essa lista, o developer da MvA recebe uma planta sem instruções de execução, e o auditor não sabe quais pontos inspecionar.

Como identificar eventos relevantes

O primeiro passo na construção do catálogo é identificar todos os eventos que compõem o fluxo operacional da metodologia. O autor deve mapear a jornada completa do objeto rastreado (um resíduo, um lote, uma atividade) desde sua origem até sua disposição final ou transformação, considerando todas as movimentações, ações e intervenções que ele pode sofrer.

Cada ponto no fluxo em que ocorre uma das seguintes situações configura, potencialmente, um evento dMRV:

• Transferência de custódia — O objeto muda de responsável ou de localização (ex.: coleta, transporte, entrega)
• Transformação ou processamento — O objeto sofre alteração física, química ou de classificação (ex.: triagem, compostagem, reciclagem)
• Mensuração ou registro — Uma medida é realizada ou um documento é gerado (ex.: pesagem, medição de temperatura, emissão de manifesto ou certificado)
• Verificação ou auditoria — Uma regra é aplicada e um resultado é registrado (ex.: auditoria do MassID, emissão de crédito)
• Decisão ou classificação — O objeto é classificado, aceito, rejeitado ou reclassificado com base em critérios do framework

Orientação sobre granularidade

A granularidade dos eventos é uma decisão de design do framework. Eventos muito agregados (ex.: "processamento" como evento único) perdem poder de verificação porque agrupam etapas que poderiam ser validadas separadamente. Eventos excessivamente granulares (ex.: cada minuto de revolvimento de leira como evento separado) geram complexidade operacional sem ganho proporcional de integridade. O equilíbrio ideal é granularidade suficiente para que cada evento represente um ponto de verificação significativo — um momento em que algo verificável acontece e uma evidência deve ser registrada.

Tabela padrão de descrição de eventos

Para cada evento identificado, o MvF deve fornecer uma descrição estruturada contendo, no mínimo, os seguintes elementos:

---

Entradas, evidências e política de evidências

Se os eventos são a espinha dorsal do dMRV, as entradas e evidências são a substância que os torna verificáveis. Uma entrada é o dado ou documento que alimenta um evento; uma evidência é o registro que comprova que aquele evento ocorreu em conformidade com as regras do framework. Sem entradas adequadas, o evento não pode ser validado. Sem evidências rastreáveis, o evento não pode ser auditado.

Especificação de entradas por evento

Cada evento do catálogo exige um conjunto de entradas para ser executado. Ao especificar essas entradas, o autor deve ir além de uma lista genérica de "documentos necessários" e fornecer uma descrição operacional completa que permita tanto a implementação na MvA quanto a verificação por auditores.

Para cada entrada, o MvF deve declarar:

• Tipo de entrada — Dado estruturado, documento digitalizado, registro de sistema, declaração assinada, etc.
• Campos ou metadados obrigatórios — Ex.: para uma pesagem: peso bruto, tara, peso líquido, tipo de balança, método de captura, data/hora, geolocalização.
• Formatos e unidades aceitos — Ex.: peso em quilogramas, datas em formato ISO, valores numéricos com até duas casas decimais.
• Condições de aceitação — O que torna a entrada válida (ex.: peso bruto maior que zero, data dentro do período de monitoramento).
• Condições de rejeição — O que torna a entrada inválida e impede o prosseguimento do evento.
• Condições de exceção — Quais dados são desejáveis vs. obrigatórios, e flexibilidades aceitáveis para projetos iniciais ou tipos específicos de participante.

A diferença entre uma entrada bem especificada e uma entrada vaga separa um framework implementável de um que depende de interpretação.

Requisitos de metadados

Toda entrada em dMRV precisa carregar contexto suficiente para sustentar a rastreabilidade. Esse contexto é composto por metadados que respondem às perguntas fundamentais da cadeia de custódia:

• Quem submeteu (identificação do participante responsável)
• Quando (data e hora do registro)
• Onde (geolocalização ou endereço vinculado)
• Em qual contexto (evento associado, etapa do fluxo)
• Sob qual versão (do MvF e da MvA em execução)

O MvF deve declarar quais metadados são obrigatórios (sem os quais a entrada não pode ser aceita) e quais são opcionais (enriquecem a rastreabilidade mas não bloqueiam a validação). Em caso de dúvida, a recomendação é tratar o metadado como obrigatório — é mais fácil flexibilizar posteriormente do que criar retroativamente um requisito que não existia.

Política de evidências por evento

A Política de Evidências consolida, evento por evento, como cada requisito será comprovado. Deve distinguir duas categorias fundamentais: evidências que podem ser aceitas por verificação digital operacional (cuja robustez pode ser sustentada pela trilha digital, metadados e consistência entre eventos) e evidências que, pela sua natureza, criticidade ou risco, exigem auditoria ou inspeção adicional.

Para cada evento, a política deve registrar:

Categorias de gatilhos de escalonamento

Gatilhos de escalonamento são condições que, quando detectadas durante a verificação digital, indicam que a evidência disponível não é suficiente para sustentar conformidade e que procedimentos adicionais (auditoria, inspeção, coleta de evidências complementares) são necessários. O Autor do MvF deve definir esses gatilhos de forma explícita e vinculá-los a ações proporcionais ao risco identificado.

Os gatilhos tipicamente se dividem em três categorias:

• Inconsistência — Divergência entre dados esperados e fornecidos (ex.: pesagem que resulta em peso líquido negativo, ou geolocalização incompatível com o endereço cadastrado).
• Ausência — Falta de metadado obrigatório ou de evidência requerida (ex.: ausência de manifesto de transporte sem justificativa de isenção).
• Anomalia — Padrão incomum detectado ao longo do tempo (ex.: volumes sistematicamente superiores à capacidade declarada, ou frequência atípica de isenções).

Para cada gatilho, o MvF deve indicar a ação esperada: bloqueio do evento (impedindo a continuidade do fluxo até resolução), sinalização para revisão operacional (o evento prossegue, mas é marcado para análise, e a emissão do crédito fica temporariamente bloqueada), ou escalonamento para auditoria (o evento é encaminhado para verificação independente). A proporcionalidade entre gatilho e ação é uma decisão de design do framework que deve considerar o risco associado ao evento e a materialidade do impacto na integridade do crédito.

Saída esperada: uma Política de Evidências completa, organizada evento por evento, que permita ao developer da MvA implementar todas as validações digitais e ao auditor compreender quais pontos exigem verificação adicional.

---

Regras de validação e controles

As regras de validação são o mecanismo operacional que garante conformidade entre as entradas fornecidas pelos participantes e os critérios definidos no MvF. Enquanto o catálogo de eventos define o que acontece e a política de evidências define o que comprova, as regras de validação definem como cada entrada é verificada — qual condição é testada, qual padrão é esperado, o que acontece quando a condição falha e qual evidência é registrada.

Para o developer da MvA, as regras de validação são o elemento mais diretamente implementável de todo o MvF. Cada regra bem especificada se traduz em uma verificação no código — uma condição lógica que produz um resultado binário (aprovado/reprovado) ou um escalonamento (sinalizado para revisão).

Taxonomia de regras

A experiência operacional com as metodologias BOLD sugere uma classificação prática de regras em três tipos:

Regras de Estrutura verificam a integridade formal e a completude dos dados. Essas regras são independentes da metodologia — asseguram que a "embalagem" da informação está correta antes que o conteúdo seja avaliado. Exemplos:

• Todos os campos obrigatórios estão preenchidos
• A unidade de medida é a esperada (quilogramas)
• O formato numérico é válido
• A categoria do documento corresponde ao esperado
• Metadados de identificação do participante estão presentes e consistentes

Regras de Metodologia verificam a conformidade dos dados com os critérios e parâmetros da metodologia científica traduzidos pelo MvF. Essas regras dependem do conteúdo técnico do framework. Exemplos:

• O tipo de resíduo pertence à lista de subtipos elegíveis
• A distância entre coleta e destino não excede o limite da fronteira do projeto
• O intervalo temporal entre eventos está dentro do range aceitável
• O tamanho do projeto não excede o limite de elegibilidade

Regras de Auditoria verificam consistência cruzada entre eventos e padrões comportamentais que exigem análise mais profunda e não podem ser resolvidos por verificação determinística simples. Tipicamente envolvem comparação com dados de homologação, cruzamento entre eventos, verificação de duplicidade, controle de limites operacionais e validações que geram sinalizações para revisão humana. Exemplos:

• A somatória de massas de um gerador no mês não excede o teto declarado
• A placa do veículo e a data/hora do drop-off não conflitam com outro MassID
• O coeficiente de conversão do fertilizante é compatível com os dados de homologação

Especificação de regra em 12 campos

Para cada regra de validação, o MvF deve fornecer uma especificação que o developer consiga implementar sem interpretação e o auditor consiga verificar de forma independente:

Regras com dependência entre eventos

Algumas regras não operam sobre um único evento isolado, mas dependem de informações de múltiplos eventos ou dados históricos. Por exemplo, uma regra de limite de distância (RV-008 no exemplo COM) cruza a geolocalização do evento de coleta (EVT-001) com a do evento de recebimento (EVT-005). Da mesma forma, a regra de teto de massas (RV-009) acumula informações de todos os MassIDs de um mesmo gerador ao longo do mês.

Quando uma regra depende de cruzamento entre eventos, o MvF deve declarar explicitamente: quais eventos são cruzados, quais campos de cada evento são utilizados, qual é a lógica de agregação ou comparação, e em que momento do fluxo a verificação cruzada é executada. Essa clareza é fundamental para implementação determinística e auditoria reproduzível.

---

Cálculos, fórmulas e parâmetros

Os cálculos e fórmulas são o núcleo quantitativo do dMRV — traduzem evidências verificadas em resultados numéricos que sustentam a geração de créditos ambientais. A forma como o MvF especifica suas fórmulas determina não apenas a precisão dos resultados, mas também sua reprodutibilidade, auditabilidade e credibilidade perante o mercado.

O princípio central é a autocontenção: o MvF deve fornecer ao developer da MvA toda a informação necessária para implementar cada cálculo sem precisar consultar a metodologia científica original ou o autor do framework. O MvF mantém rastreabilidade à referência externa, mas o framework em si deve conter todas as informações operacionais necessárias para implementação e auditoria.

Especificação por fórmula

Cada fórmula deve ser apresentada com um conjunto mínimo de informações:

Equação — Expressa de forma inequívoca, com notação consistente ao longo do framework. Variáveis devem ter nomes descritivos e únicos. Quando a fórmula envolve somatórias, condições (se/então) ou iterações, a lógica deve ser explicitada passo a passo, não condensada em uma única expressão.

Variáveis — Para cada variável, o MvF deve declarar:

• Símbolo utilizado
• Nome completo da variável
• Unidade de medida
• Fonte do valor (dado de entrada, parâmetro fixo, resultado de outro cálculo, valor de homologação)
• Condições de aplicação (quando a variável é utilizada e quando não é)
• Limites ou restrições (valores mínimos/máximos, domínio válido)

Parâmetros fixos — Fatores de emissão, coeficientes de conversão e constantes devem ser acompanhados de sua fonte primária (artigo, metodologia, base de dados), data de referência e condições sob as quais o valor é válido. Quando um parâmetro varia conforme o contexto (ex.: fator de emissão diferente por tipo de resíduo ou por região), o MvF deve fornecer a tabela completa de valores e a regra de seleção.

Cenários de teste — Um conjunto de entradas de referência com o resultado esperado, que permite ao developer verificar se a implementação está correta. Ex.: "Se peso líquido = 14.949 kg, tipo de resíduo = lodo doméstico, e índice de compensação = 0,85 tCO2e por tonelada, o GasID esperado é 12,71 tCO2e." Cenários de teste reduzem significativamente o risco de erros de implementação.

Incerteza e fatores de desconto

Quando a metodologia de referência prevê margens de incerteza, fatores de desconto conservadores ou buffers de segurança, o MvF deve descrevê-los com a mesma precisão aplicada às fórmulas principais:

• Fórmula de cálculo da incerteza (quando quantificável)
• Fator de desconto aplicado e sua justificativa técnica
• Condições de ativação — Em quais circunstâncias o desconto é aplicado
• Impacto no resultado final — Como o desconto afeta a quantidade de créditos gerados

Fatores de desconto são especialmente relevantes para a credibilidade do dMRV porque demonstram uma abordagem conservadora — na dúvida, o framework credita menos, não mais. Essa postura é valorizada por compradores, auditores e pelo mercado, e deve ser explicitada no MvF como parte do design da metodologia.

---

Outputs e pacote de evidências digitais

O output metodológico auditável é o resultado final da execução do dMRV: o artefato que justifica, com base em evidências verificadas, que um determinado impacto ambiental foi quantificado em conformidade com a metodologia. No ecossistema Carrot, esses outputs são a base para processos subsequentes de emissão, rastreamento e — quando aplicável — aposentadoria de créditos, conforme o desenho institucional adotado.

Tipos de output

O MvF deve declarar explicitamente quais tipos de output a metodologia gera e em quais condições:

Outputs primários são resultados quantitativos que sustentam a geração de créditos. Ex.: quantidade de emissões evitadas (em tCO2e), quantidade de material reciclado (em toneladas), ou qualquer outra métrica definida pela metodologia. No exemplo fictício COM, os outputs primários seriam o GasID (créditos de carbono por evitação de metano) e o RecycledID (créditos de reciclagem por desvio de aterro).

Outputs intermediários são resultados parciais que alimentam cálculos subsequentes ou têm valor informacional para auditoria, mas não geram créditos diretamente. Ex.: o peso líquido após triagem é um output intermediário do evento de triagem que alimenta o cálculo final de créditos.

Outputs de verificação são registros gerados pela execução das regras de validação — aprovações, rejeições, sinalizações e resultados de auditoria que compõem a trilha de auditoria do MassID. Esses outputs não geram créditos, mas são essenciais para demonstrar conformidade.

Composição do pacote de evidências

O pacote de evidências digitais é o conjunto organizado de todos os registros, dados, documentos, logs e resultados de validação gerados ao longo da execução do dMRV para um determinado objeto rastreado (tipicamente, um MassID). Ele viabiliza tanto a verificação digital interna quanto a verificação independente por entidades terceiras, quando aplicável.

O MvF deve descrever o que compõe o pacote de evidências para a metodologia, incluindo:

• Dados e documentos submetidos pelos participantes em cada evento (entradas), com seus metadados
• Resultados de cada regra de validação executada (aprovado, reprovado, sinalizado), com a versão do MvF e da MvA utilizada
• Resultados de cada cálculo aplicado, com variáveis e parâmetros de entrada
• Outputs primários gerados, com sua justificativa técnica (como o número foi obtido)
• Registros de qualquer escalonamento, auditoria adicional ou intervenção humana que tenha ocorrido

A completude do pacote de evidências é o que permite a qualquer revisor — interno ou independente — percorrer o caminho completo entre as entradas originais e o output final, verificando cada etapa de forma independente. O MvF deve ser pensado de modo que nenhum output exista sem uma trilha de evidências que o sustente.

Versionamento e rastreabilidade temporal

Cada output gerado pelo dMRV deve carregar informação de versionamento suficiente para permitir sua reprodução futura. No mínimo, o output deve registrar:

• A versão do MvF que definiu as regras aplicadas
• A versão da MvA que executou as regras
• A data de execução
• Referências aos eventos e entradas que o sustentam

Essa rastreabilidade temporal é especialmente importante quando o framework passa por atualizações de versão. Um output gerado sob a versão 1.0 do MvF deve ser avaliado conforme as regras da versão 1.0, mesmo que uma versão 2.0 já esteja em operação. O MvF deve declarar como essa separação é mantida e o que acontece com outputs em trânsito durante uma transição de versão.

Conexão com processos externos

O MvF deve também indicar como os outputs se conectam a processos fora do perímetro da plataforma Carrot, quando aplicável. A plataforma viabiliza a execução de metodologias que suportam a geração de créditos, mas a emissão, o rastreamento e a aposentadoria desses créditos podem envolver infraestruturas externas com formatos e requisitos próprios.

Quando o desenho institucional do dMRV prevê essa interoperabilidade, o MvF deve declarar:

• Quais outputs são entregues a processos externos e em qual formato
• Quais metadados são exigidos pelo registry ou pela infraestrutura de destino
• Quais dependências externas existem (ex.: aprovação do registry necessária antes da emissão formal do crédito)

Essa declaração mantém a separação de responsabilidades clara e permite que a plataforma funcione como infraestrutura de execução sem confundir seu papel com o de certificação ou registro. Veja o Carrot Explorer para como os outputs são apresentados a stakeholders externos.

---

Artefatos e templates

As seções acima fazem referência a artefatos e templates que devem acompanhar o MvF como anexos padronizados. A tabela abaixo consolida os artefatos recomendados:

Cada artefato deve ser desenvolvido seguindo o template padronizado para garantir consistência entre os diferentes frameworks submetidos ao ecossistema.

---

Guia do Autor de MvF · Conceito de MvF · Ciclo de Vida da Metodologia