--- name: mrv-methodology-drafting description: Draft Measurement, Reporting, and Verification (MRV) methodology language for carbon projects — monitoring plans, sampling design, QA/QC procedures, sensor/instrumentation architecture, and the estimation-tier vs. in-situ-measurement distinction. Use whenever the user wants to write or refine an MRV plan, monitoring section of a PDD, dMRV (digital MRV) architecture description, sensor specification narrative, or wants to translate raw measurement/hardware specs into registry-acceptable methodology language. Trigger on "MRV," "monitoring plan," "dMRV," "measurement methodology," "sensor architecture for carbon," or "how do we document our measurement system for the registry." --- # MRV / Methodology Drafting Turns measurement architecture, whether estimation-based or hardware-verified in-situ, into the precise language registries and validators expect in a monitoring plan or standalone MRV methodology document. This is the skill that does the work AICo2 Methodology v3.0 did: take a real measurement system (sensors, sampling design, QA/QC, data pipeline) and write it up so a Validation/Verification Body (VVB) can assess it against the methodology's monitoring requirements without guessing what was actually measured versus assumed. ## Core distinction to enforce: measured vs. derived vs. estimated Every parameter in a monitoring plan falls into one of three tiers. State the tier explicitly for every parameter — this is the single biggest credibility lever in MRV writing, and most projects blur it. - **Measured** — direct instrument reading, in-situ, at the point of the activity. Highest confidence, often allows project-specific emission/removal factors instead of conservative defaults. - **Derived** — calculated from measured inputs via a model or formula (e.g. biomass from allometric equations applied to measured DBH). Confidence depends on the model's validation against the local context, not just the input measurement. - **Estimated** — default factors, remote sensing proxies, or literature values applied without direct project-level measurement. Lowest confidence, usually required to use conservative (discounted) default values per the methodology. Don't let a project's marketing language ("AI-powered precision monitoring") imply Measured tier for what is actually Estimated tier data. Validators catch this, and it damages credibility for the whole document, not just one section. If in doubt about a parameter's tier, ask the user which instrumentation actually produced the number. ## Monitoring plan structure 1. **Parameters monitored** — list every parameter the methodology requires, tagged with its tier (measured/derived/estimated). 2. **Monitoring frequency and timing** — continuous (sensor-based), periodic (field visits), or one-time (baseline-only) per parameter. 3. **Instrumentation / data collection method** — for measured parameters, specify the actual hardware: sensor type, accuracy/precision spec, calibration schedule, data logging interval. For hardware-verified dMRV systems, this is where cryptographic attestation (data signed at point of measurement, tamper-evidence, on-chain anchoring) gets documented — describe the attestation chain concretely, not as a black box. 4. **Sampling design** (where full-coverage measurement isn't feasible) — plot/sensor placement methodology, statistical basis for sample size, stratification approach. 5. **QA/QC procedures** — calibration verification, data validation rules, outlier handling, missing-data protocols, independent verification spot-checks. 6. **Data management** — collection, storage, chain of custody, who has access, retention period (registries typically require records retained for the life of the crediting period plus several years). 7. **Internal/third-party verification cadence** — how often the project undergoes verification audits and what the VVB will check against this plan. ## When the project uses phased measurement maturity Many real projects (including dMRV buildouts) start with Phase 1 estimation-tier methods and move to Phase 2 in-situ measurement as infrastructure deploys. Write this explicitly as a phased monitoring plan rather than presenting only the end-state — registries and buyers increasingly value documented progression toward higher measurement rigor, and it protects the project from over-claiming before the hardware is actually live. Structure as: - Phase 1: estimation-tier baseline (what's measured now, what's estimated, and why) - Phase 2: in-situ measurement rollout (what hardware, what timeline, what parameters move from estimated to measured) - Transition criteria: what triggers the move from Phase 1 reporting to Phase 2 reporting in actual verification cycles ## Regulatory alignment language If the project's MRV output also needs to satisfy adjacent frameworks (EU AI Act provisions on environmental claims if AI is used in the measurement pipeline, CSRD disclosure requirements, or SEC/CFTC digital asset classification questions if credits are tokenized), draft a short alignment note at the end of the MRV document cross-referencing which specific provisions the monitoring architecture satisfies. Don't claim full compliance with a regulatory framework in an MRV document — name the specific provisions addressed and flag what's outside scope. ## Output format Default to a standalone MRV/Methodology document (markdown or docx) that can either be embedded directly into a PDD's monitoring section (via `pdd-generator`) or submitted as a supporting methodology annex. Keep parameter tables in actual tables, not prose — VVBs scan these documents for the parameter table first. ## Related skills - `pdd-generator` — this document typically becomes Section 7 (Monitoring Plan) of the PDD. - `carbon-decision-memos` — for documenting why a particular measurement tier or instrumentation choice was made, especially cost/rigor tradeoffs.