MvA — Methodology Verification Application

What is an MvA?

A Methodology Verification Application (MvA) is the software that implements a Methodology Verification Framework (MvF) as executable validation rules. It receives dMRV documents, evaluates them against every rule defined in the MvF, and returns deterministic PASSED or FAILED results with explanations.

The key distinction: the MvF is the specification (what to verify), the MvA is the implementation (the code that verifies it).

Methodology (scientific basis) → MvF (verification specification) → MvA (software implementation)

What an MvA does

An MvA processes MassID documents through its rule set:

Validates supply chain documents — Each rule inspects specific aspects of a MassID: actor identities, event data, weighing records, manifests, geolocation, and more.
Applies calculation rules — Certain rules perform calculations such as emission quantification (CO2e prevented) or geographic distance measurements.
Feeds the audit system — Every rule evaluation produces a traceable result with the exact data that was checked and why it passed or failed.

Each rule is a deterministic function: given the same input document and the same rule version, it always produces the same output. This makes the verification system fully auditable and reproducible.

Design principles

The MvA is built on four principles that ensure the integrity of automated verification:

Fidelity — The MvA mirrors the MvF exactly. Every rule in the MvF has a corresponding rule processor in the MvA, and the evaluation logic matches the specification.
Traceability — Every PASSED or FAILED result is linked to the specific source data that was evaluated, making results independently verifiable.
Determinism — Same input always produces the same output. No randomness, no external state that could change results between runs.
Standard compliance — All MvAs follow the Carrot dMRV Standard requirements for structure, testing, and documentation.

Architecture

The MvA is implemented as an open-source monorepo deployed as serverless functions:

Repository: github.com/carrot-foundation/methodology-rules
License: LGPL-3.0 — anyone can audit, fork, or contribute

The codebase follows a two-layer architecture:

Shared rule libraries — Contain the actual verification logic. Shared rule processors are reused across methodologies. Each rule is an independent module with its own tests.
Methodology application wrappers — Thin deployment layers that wrap shared libraries as serverless functions. Each methodology deploys its own set of rules, including any methodology-specific rules.

This architecture means a rule like weighing is implemented once in the shared library and deployed to multiple methodologies (e.g., BOLD Recycling and BOLD Carbon (CH₄)). Methodology-specific rules (such as prevented-emissions) live only in that methodology's application layer.

Framework rules vs. application rules

The Carrot methodology system uses a two-layer rules architecture:

Framework rules define what must be verified at the specification level. These are the requirements from the MvF — for example, "the document must have a value greater than zero" or "a recycler actor must be present."
Application rules define how verification is executed as open-source code. Each application rule is an independent function that evaluates a MassID document and returns PASSED or FAILED.

The mapping between the two layers is not one-to-one. A single application rule may satisfy multiple framework rules (e.g., mass-id-qualifications verifies document value, unit, category, and type in one pass). Conversely, a framework rule may require multiple application rules to fully verify.

See the framework rules and application rules for each methodology:

BOLD Carbon (CH₄): Framework Rules · Application Rules
BOLD Recycling: Framework Rules · Application Rules

The MvA Developer role

MvA Developers are engineers who implement and maintain rule processors. The role requires:

Proficiency with the monorepo's programming language and tooling
Understanding of the rule processor pattern
Ability to translate MvF specifications into deterministic code
Rigorous testing practices: unit tests, integration tests with seed documents, and end-to-end tests

See the MvA Developer Guide for the step-by-step implementation process.

Learn about MvF