MCC-100 Annex B — Monitoring Report Template v1.1

Document type: Normative annex to MCC-100 Programme Standard v2.2 (Tier 3; amended with the Standard, MCC-001 cl. 0081, 30 days' notice) Status: v1.1 DRAFT for adoption under FD-2026-08-24 item 3 — NOT ADOPTED. Supersedes Annex B v1.0 (14 November 2025, "Draft — Not for Public Release") on adoption. Related: MCC-100 v2.2 (cl. 0146–0162 issuance preconditions; 0167 credit types; 0183.1 permanence horizons; 0186–0188 buffer; 0191 reversal); MCC-200 v2.0; MCC-400 v1.1 arts. 49–65 and Addendum 1; Buffer Pool Management Policy v1.0; ESS Policy v1.0; SDCF v1.0; MCC-CADCP v1.0; Definitions Register v1.0; PDD Template v1.1; Verification Report Template v1.0 Prepared: 25 August 2026

---

1. Purpose and scope

This annex sets the mandatory structure and content of the Monitoring Report (MR) a project developer submits for each monitoring period for which issuance is requested (MCC-100 v2.2 cl. 0152). The MR is the developer's account of what the project did and measured; the Verification Report (MCC-400 art. 64; Verification Report Template v1.0) is the VVB's independent opinion on it. The MR, its annexes and the VVB's report together form the issuance file assessed against the seven preconditions of cl. 0162.

The MR demonstrates that: monitoring was implemented as validated in the PDD; every parameter required by the applied methodology was measured, collected or calculated as the methodology prescribes; the creditable outcome was quantified accurately and conservatively on the basis the credit type defines (cl. 0167); safeguards were respected; and every deviation was reported and corrected.

2. How to use this template

Complete every section in the order given. Do not renumber or delete headings. A section that does not apply is retained with "Not applicable" and a one-sentence justification. Information must be consistent with the validated PDD (PDD Template v1.1); changes are documented in B.3.3 or B.8, never silently.

Write for a reader who has not seen the project. VVBs under MCC-400 art. 49–65 reject MRs that assert without evidence; where professional judgement was exercised, say what was judged, on what evidence, and under which methodology clause.

The MR is uploaded through the registry (D10): each file's SHA-256 is recorded on upload and the submission is signed by a named person (B.13). The AI Analysis Layer scores the MR for completeness and cross-references it against the registry's structured fields (MCC-400 Addendum 1, art. 95); the developer sees the completeness score before submission and the VVB sees it during verification. An AI finding is not a verification finding (art. 104–105).

3. Structure

B.1 Project identification · B.2 Monitoring period · B.3 Implementation status · B.4 Data and parameters monitored · B.5 Quantification of the creditable outcome · B.6 Quality assurance and quality control · B.7 Environmental and social safeguards · B.8 Deviations and corrective actions · B.9 Verification history · B.10 Sustainable development contribution · B.11 Declarations · B.12 Annex 1: Monitoring data tables · B.13 Annex 2: Supporting documents and integrity record

---

B.1 Project identification

B.1.1 Project title — as recorded in the MCC Registry. B.1.2 Registry project identifier — the registry id and, where assigned, the project code used in serial numbers (MCC-800 v1.1 art. 27: {ISO3}{NNNN}). B.1.3 Project developer — legal name, registration number, address; the individual responsible for the MR. B.1.4 Applied methodology — code, title, version and approval date (e.g. MCC-M008 Ghost Gear Recovery v1.0, APPROVED per FD-2026-08-24 item D6). The MR may only apply the methodology version the PDD was validated against, or a later version the developer has elected under the methodology's transition rule; state which. B.1.5 Methodology family — F01 Blue Carbon · F02 Restoration · F03 Fisheries · F04 Pollution Prevention · F05 MPA Management (Definitions Register v1.0 §2). Where the project spans families, name the primary family; secondary outcomes are reported, not credited, unless the PDD validated a second methodology. B.1.6 Credit type — exactly one of MCC-CC (1 t CO₂e removed/reduced; F01), MCC-HYB (1 t CO₂e plus specified co-benefits; F02, F05), MCC-MCU (the methodology's non-carbon unit; F03, F04). State the unit basis in the methodology's words (for M008: one MCU = 100 kg of recovered and documented gear, FD-2026-08-24 item D6). For MCC-MCU projects the MR makes no CO₂e statement anywhere (Definitions Register §1; Claims Policy v1.1). B.1.7 Host country and position — country; the host-country position recorded in the registry (use case CONTRIBUTION with engagement status, or the Letter of Authority status and expiry); confirm no change since the last MR or report the change (MCC-HCA v1.0; FD item D8). B.1.8 Crediting period — start and end dates of the crediting period as validated; which year of the crediting period this MR covers.

B.2 Monitoring period

B.2.1 Start and end dates — exact dates; they must match the validated monitoring plan or be justified as a deviation (B.8). B.2.2 Duration — days. B.2.3 Continuity — the end date of the previous monitoring period and the verification report that closed it (B.9). Periods may not overlap and may not leave a gap; a gap is a deviation.

B.3 Implementation status

B.3.1 Summary of implementation — what the project did in the period, in the methodology's own activity terms (campaigns, hectares under management, patrols, vessel-days, installations). Unusual events (storms, closures, equipment loss) with dates. B.3.2 Technology and equipment status — uptime, failures, repairs and replacements for every monitoring device and data system; calibration status cross-referenced to B.6.3. B.3.3 Changes to project design or operations — every change to boundary, procedure, personnel with data custody, or data collection method; whether each required prior notification or approval (MCC-100 cl. 0146–0149; PDD Template v1.1 change rules); registry reference of the notification. B.3.4 Boundary — confirm the boundary is unchanged from the validated boundary_geojson, or attach the revised file with its SHA-256 and the approval reference.

B.4 Data and parameters monitored

B.4.1 Parameter summary — every parameter the methodology requires, its role in the quantification chain, and whether it was measured, calculated or defaulted in this period. B.4.2 Monitoring methods — per parameter: instrument, method, frequency, custody chain, data platform, redundancy. For evidence-record-based methodologies (M008: GPS at lift → landing → weighing → classification → reception receipt → photo), state how each link was recorded and reconciled with the registry's evidence records. B.4.3 Completeness and treatment of missing data — coverage achieved against the plan; causes of gaps; the methodology's conservative substitution rule applied, with the calculation shown. Substitution rules not in the methodology may not be invented in the MR. B.4.4 Data tables — in Annex 1 (B.12).

B.5 Quantification of the creditable outcome

The heading and content follow the credit type (B.1.6). Show every formula with its methodology clause, every input with its source in Annex 1, and every intermediate value. Round only at the end; state the rounding rule.

B.5.1 Baseline — baseline quantity for the period per the validated baseline (for MCC-MCU flow methodologies, the baseline is typically zero recovery/prevention and is stated as such; for F01/F02/F05 the baseline stock or trajectory, capped at measured stock — see Guidance Errata No. 1, B7). B.5.2 Project outcome — the measured project quantity: t CO₂e removed/reduced (CC, HYB) or the methodology's unit quantity (MCU: e.g. tonnes of gear recovered and prevented, by material class). B.5.3 Leakage — pathways assessed in the PDD; quantities this period; the deduction applied (absolute, per the methodology). B.5.4 Project emissions / own-footprint (where the methodology requires it) — e.g. vessel fuel for recovery campaigns where M008 requires disclosure; stated in the methodology's terms and never netted into an MCU count. B.5.5 Uncertainty — the methodology's uncertainty treatment (confidence interval, discount) with the calculation. B.5.6 Net creditable quantity — the quantity requested for issuance, in whole units, with the conversion from measured quantity to units shown (e.g. 41,320 kg documented gear → 413 MCU at 100 kg/MCU, remainder carried forward if the methodology permits). B.5.7 Buffer — the buffer rate is the project-specific rate assessed under the Buffer Pool Management Policy v1.0 (cl. 0012–0013, 0047–0049) within 10–40 % (MCC-100 v2.2 cl. 0186–0188), as validated in the PDD and confirmed or revised by the VVB in this verification (cl. 0152(h); MCC-400 art. 64). State the rate, its basis, and the resulting buffer units and issuable units. Where the methodology fixes the rate (M008: 10 %, FD item D6), say so. Family-level figures are reference values only and are not to be applied. B.5.8 References — every methodology clause, dataset, tool and version used.

B.6 Quality assurance and quality control

B.6.1 QA/QC procedures applied — as in the validated monitoring plan; sampling of records; second-person review. B.6.2 Data integrity — access control, backups, audit trail; confirmation that raw data files attached in Annex 2 carry the SHA-256 recorded in the registry at upload and have not been altered since (D10). B.6.3 Calibration and maintenance — per instrument: method, standard, date, result, certificate reference. Scales used for weighing under M008: calibration certificate and check-weight log.

B.7 Environmental and social safeguards

B.7.1 Compliance statement — against the ESS Policy v1.0's eight principles (cl. 0011–0045) and the project's ESMP (cl. 0083), by principle: compliant / non-compliance reported in B.7.2 / not applicable with reason. B.7.2 Monitoring results and incidents — safeguards indicators for the period; incidents; corrective actions and their status; HSE events in field operations. B.7.3 Stakeholder feedback and grievances — stakeholder input received; grievances lodged at project level (Level 1, MCC-700 §6.1.4) with status; any programme-level grievance (GR-YYYY-NNNN) concerning the project. B.7.4 Permanence and reversal monitoring — applies to stock-based families only. State the permanence horizon applicable to the family per MCC-100 v2.2 cl. 0183.1 (F01 100 years / 30-year post-crediting monitoring; F02 30 / 20; F05 30 / 10) and report the reversal-risk indicators monitored, any reversal event against the thresholds of cl. 0191 (>10 % loss in any 12 months or >20 % over the crediting period), and any buffer cancellation or top-up. For F03 and F04 (flow-based) state "Not applicable — flow-based crediting (MCC-100 cl. 0183.2)"; end-of-life disposition of recovered material is reported under B.5.4/B.7.2 as an integrity requirement, not as permanence.

B.8 Deviations and corrective actions

B.8.1 Deviations — from PDD, monitoring plan or methodology: cause, dates, scope. B.8.2 Corrective actions — taken, and their effectiveness. B.8.3 Effect on quantification — whether and how each deviation changed B.5; if a deviation required approval that was not obtained, the affected quantity is excluded from B.5.6.

B.9 Verification history

B.9.1 Previous verifications — VVB, report reference, opinion, issued quantity, findings and corrective action requests. B.9.2 Outstanding items — unresolved findings and how this MR addresses them. B.9.3 VVB independence — the VVB engaged for this verification, its accreditation record in the registry, and confirmation that its signed COI declaration for this engagement is on file (MCC-400 art. 47; /vvb/coi). Rotation status under MCC-400 Section 14.

B.10 Sustainable development contribution

Report the SD indicators validated in the PDD (minimum three; MCC-100 cl. 0086; SDCF v1.0): indicator, unit, baseline, value this period, method and evidence. Where an SD label is held or sought (MCC-700 §7.1.2), the VVB's SD score is reported here in the Verification Report, not by the developer.

B.11 Declarations

The developer declares, for this monitoring period: (a) the programme exclusivity and no-double-counting declaration made at registration remains true (MCC-CADCP v1.0 cl. 0115; Tunisia Pilot Pack Part B for the Gabès form); (b) no unit, credit or claim for the same outcome has been issued or sought elsewhere; (c) the host-country position in B.1.7 is current; (d) all data in Annex 1 are complete and unaltered; (e) the person signing is authorised. The declaration is signed in the registry with the signer's name and the SHA-256 of the MR file (D10).

B.12 Annex 1 — Monitoring data tables

One row per parameter: Parameter ID · Name · Description · Unit · Method · Frequency · Value(s) for the period · Source file (with SHA-256) · QA/QC applied · Notes. For evidence-record methodologies, the registry export of evidence records for the period is attached and its record count reconciled to B.5.2.

B.13 Annex 2 — Supporting documents and integrity record

List every attached file with: filename · description · SHA-256 as recorded by the registry at upload · upload date · uploader. Raw data, telemetry logs, calibration certificates, maintenance records, photographs, maps/GeoJSON, stakeholder and grievance records, reception/recycling receipts, permits current in the period. A document referenced in the MR but absent from this list is treated by the VVB as not provided.

---

Change log — v1.1 DRAFT (25 Aug 2026): retitled to MCC-100 v2.2; "Not for Public Release", "MCC Council" and Programme Bible references removed (D15); B.7.4 rewritten to cl. 0183.1/0191 with buffer determined per project under the BPM (K13) — the v1.0 family rates 30/20/10 % were never a programme rule; B.5 generalised from "emission reductions" to the credit-type basis (cl. 0167) so MCU projects can report; added B.1.6–B.1.8, B.3.4, B.5.6–B.5.7, B.9.3, B.10, B.11, integrity fields (D10) and the AI-layer note (MCC-400 Addendum 1). v1.0 archived on adoption.