MCC-100 — Programme Standard

Document control

Field	Value
Document code	MCC-100
Title	Programme Standard
Version	3.0-draft
Status	DRAFT — FOR CONSULTATION
Date of this draft	3 September 2026
Tier	Tier 2 (Document Hierarchy & Precedence Register, per FD-2026-09-03 item D5)
Effective date	None. This document is not in force. It takes effect only on approval under clause 26.1.
Document owner	Programme Administrator (transitional, until a Secretariat is staffed — FD-2026-10-01 Schedule 1, C3)
Approved by	Not approved. Prepared for public consultation.
Decision basis	Founder Decisions FD-2026-09-03, items D1–D8 (adopted 3 September 2026 in the programme working channel; to be tabled for ratification by the Governing Board). FD-2026-09-03 is recorded in the decision register as attested by the founder on 7 September 2026; no executed copy has been filed (the register at /governance/decisions shows its status).
Supersedes	The circulated consolidated text carrying cover "MCC-100 v2.2 / In force from 17 August 2026 / APPROVED" over a document-control table reading "Version 2.1 (consolidated)", reclassified by FD-2026-09-03 item D5; the document register records it as in force until this version is adopted, when its withdrawal as a controlled copy is executed (FD-2026-09-07 item A8: scheduled, not executed). See the baseline declaration below.
Language convention	British English; RFC-style normative verbs (SHALL/MUST = mandatory; SHOULD = recommended, deviation to be documented; MAY = optional). Canonical registry enumeration values and status labels are quoted verbatim from the adopted control tables and retain their spelling (for example "AUTHORIZED").
Classification	Public — consultation draft
Consultation period	30 days (FD-2026-10-01 Schedule 1, C4; MCC-100 is in Tier 3 of the hierarchy in force, MCC-001 v2.0 cl. 0081), from the opening recorded on the consultation register (FD-2026-09-04 item 2; FD-2026-10-01 item 5). This draft proposes Tier 2, whose notice would be 60 days

Baseline declaration and version-identity resolution

The controlled identity of the predecessor text is defective and is resolved here, honestly, by declaring a new baseline:

1. The circulated PDF displays "Version 2.2" on its cover and "Version 2.1 (consolidated)" in its document-control table (Phase 0 source inventory, confirmed; audit finding 100-01/SYS-06).
2. The document's own Appendix A amendment history records versions 2.0 and 2.1 only; no adopting or consolidating instrument creating "v2.2" exists anywhere in the programme record (Phase 0; evidence gap E11).
3. MCC-100 Amendment 1 v1.0 directs its own incorporation "into MCC-100 v2.1", while the consolidated file styles itself v2.2 — the consolidation instrument and the consolidated file disagree about the resulting version number.
4. Amendment 1's editorial note rests its version-control appendix on clause 0249, which concerns lessons learned, not version control — a defect the consolidated text itself acknowledges (its Appendix A.5).

Resolution. This version 3.0-draft is declared the new baseline of MCC-100. It consolidates, where retained, the substance of MCC-100 v2.0 (March 2026) as validly amended by MCC-100 Amendment 1 v1.0 (whose operative provisions were competently directed at v2.0 and are consolidated here where they survive the FD-2026-09-03 decisions), and it does not adopt, perpetuate or legitimise the un-instrumented "v2.2" designation. The version number 3.0 is used precisely so that no reader can mistake this text for either disputed predecessor identity. The predecessor is reclassified by FD-2026-09-03 item D5; the document register records it as in force until this version is adopted, when the withdrawal of its PDF as a controlled copy, and its archiving as a superseded record with both printed identities noted, are executed (FD-2026-09-07 item A8: scheduled, not executed).

Change history

Version	Date	Change	Instrument
2.0	March 2026 (printed)	Base text; printed status APPROVED	No Governing Board adoption record for this version is in the programme record (Evidence Register ER-2026-001 §B3; evidence gap E10 stands). The Governing Board was constituted on 26 August 2026 (GB-2026-001, recorded in the decision register as attested by the founder, with no executed copy filed); no Board capable of adopting that version existed at the time it was issued.
2.1	17 August 2026 (printed)	Amendment 1 (revision loop, eight-stage workflow incl. SAFEGUARDS_SCREENING, prioritised sequencing) directed to be incorporated into v2.1	Printed as decision D-2026-08-01, Governing Board, two-thirds majority under cl. 0021, record MCC-BDR-2026-002. MCC-BDR-2026-002 exists only as an unsigned draft with blank attendance, apologies, chair, quorum count and voting tallies; it records a Governing Board meeting of 17 August 2026 — nine days before the Board was constituted on 26 August 2026 — and states of itself that it is drafted from the resolutions as reported. The adoption it is cited for is therefore unevidenced (Evidence Register ER-2026-001 §B1).
"2.2"	—	Cover designation on the circulated consolidated file; no creating instrument exists (evidence gap E11)	None known — identity defect resolved by the baseline declaration above. No such instrument is in the programme record. Version designations across this corpus — MCC-100 “v2.2”, MCC-850 “v1.2”, MCC-800 “v1.1” and MCC-M008 “v1.1” — were advanced editorially without an adopting instrument; the pattern is systematic, not incidental, and this revision resets it: the instrument, not the file, sets the version (Evidence Register ER-2026-001 §B3 and Part C, item 4).
3.0-draft	3 September 2026	Full rewrite against the independent audit of 3 September 2026 (findings SYS-01 to SYS-15 and 100-01 to 100-10) and Founder Decisions FD-2026-09-03 D1–D8: instruments and families generated from the canonical control tables; lifecycle text generated from MCC-700 v4.0 Annex B; voluntary-first Article 6 attribute model; substantive additionality, baseline, quantification, leakage, permanence and MRV requirements added; claims control subordinated to MCC-600; AI confidence bands replaced by task-specific calibrated indices; all local retention periods, decision thresholds and governance restatements removed	FD-2026-09-03 items D1–D8

NOTE (non-normative). This document is issued for public consultation. Nothing in it asserts that any approval, accreditation, eligibility, registration, issuance or operational history exists unless a linked record is identified in the MCC Evidence Register. Points the Programme has not decided, or on which it proposes a rule for comment, are listed under Consultation questions below and marked in the text.

Consultation questions

Each point below is open for comment. A proposal is the administration's proposal, put to consultation under founder direction FD-2026-10-01; it is not a rule in force. The suite is to be adopted as one instrument once its longest consultation period has closed (FD-2026-10-01 Schedule 1, C4). Because it includes the Constitution, whose amendment is within the competence of the constituted Governing Board (FD-2026-08-24 item D11, recorded in the decision register as attested by the founder, with no executed copy filed), each point below is decided by the Governing Board on adoption of the suite; a clause of this text that provides another route for adopting it alone is itself open to comment.

1. Clause 15.5 — the "MCC SD Gold" criterion. Proposed: no SD Gold designation is awarded, and this Standard states no criterion, until one criterion is adopted — to be resolved in the rewritten MCC-SDCF, one rule suite-wide. The record holds two criteria that conflict, and neither is evidenced as the decided rule: the predecessor clause 0093 requires "a score of 4 or higher on five or more SDG indicators"; MCC-SDCF clause 0120 requires "an average SD contribution score of 4.0 or greater on a minimum of three separate SDGs". The conformity review of MCC-SDCF v1.0 was completed on 3 September 2026 as CR-2026-001 and found it non-conforming, and MCC-SDCF v2.0-draft clause 8.3, put to consultation with this suite, proposes a third: "a score of 4 or higher on at least three indicators, spanning at least two Goals, with no indicator scoring below 3". Basis: the open decision recorded in this draft; FDP-2026-001 Part 3 (open decisions with an interim rule go to public consultation); FD-2026-10-01 item 4. Decided by: the Governing Board on adoption of the suite; the status of MCC-SDCF following its conformity review is reserved to it (FD-2026-09-04 item 6). Comments are invited on which criterion, if any, the Programme should adopt.

Table of contents

1. Purpose, scope and application
2. Normative references, definitions and interpretation
3. Governance interface
4. Programme instruments
5. Methodology families and methodology status
6. Project eligibility
7. Additionality
8. Baselines
9. Quantification, uncertainty and conservativeness
10. Leakage
11. Permanence, durability and reversals
12. Monitoring, reporting and verification data
13. Project lifecycle requirements
14. Environmental and social safeguards
15. Sustainable development contribution
16. Host-country requirements and Article 6 attributes
17. Double counting and finance stacking
18. Validation and verification
19. Credit issuance
20. Registry and transparency
21. Retirement and claims
22. Use of AI systems
23. Compliance and enforcement
24. Amendments
25. Transitional provisions
26. Entry into force

---

1. Purpose, scope and application

1.1 This Programme Standard (MCC-100) SHALL establish the core programme requirements of the Marine Conservation Credits (MCC) Programme for project eligibility, additionality, baselines, quantification, leakage, permanence, monitoring, validation and verification, issuance, registry transparency, retirement and claims, safeguards, sustainable development contribution, host-country legality and compliance.

1.2 This Standard SHALL apply to every project, methodology, participant and instrument within the MCC Programme.

1.3 The scope of the MCC Programme SHALL be limited to marine and coastal ecosystems, as scoped by MCC-001 clause 5.2; no terrestrial or freshwater activity SHALL be credited.

1.4 Every project SHALL demonstrate a direct and material connection to a marine or coastal ecosystem.

1.5 This Standard is a Tier 2 instrument under the Document Hierarchy & Precedence Register; precedence is governed by MCC-001 Section 2.

1.6 Where this Standard refers to another MCC document, form, tool or register, the reference SHALL be read against the Document Hierarchy & Precedence Register; a requirement of this Standard that depends on a referenced instrument is ineffective until MCC-001 clause 2.5 is satisfied for that instrument.

NOTE. The following instruments referenced in this Standard are not in force: MCC-600 (Claims Code), drafted as v1.0-draft and put to consultation with this suite (claims are governed meanwhile by the Claims Policy v1.1, adopted under FD-2026-08-24 and recorded in the document register as in force); the Record Retention Schedule (MCC-810), put to consultation with this suite; the versioned serial specification (MCC-800 v2.0-draft, Schedule 1), put to consultation with this suite, the serial format in force being that of MCC-800 v1.1 article 27 (FD-2026-08-24 item D13); the Fee Schedule (MCC-FEES, 1.0-draft), not yet put to consultation, no fee amount having been set (FD-2026-09-04 items 4 and 6); the validation and verification report templates, whose consultations closed on 8 September 2026 with closing protocols of 24 September 2026 recommending adoption, none of which is entered in the document register as adopted; the safeguards screening form; and the published lifecycle transition table implementation. The Definitions Register is in force (clause 2.1). Each dependent requirement is deferred under clause 1.6, never silently effective. The former references to "MCC-ORS"/"MCC-OPS" (given two different titles by the prior corpus) and to "MCC-PILOT" are not carried as normative references in this Standard.

1.7 Standard-setting, programme administration, registry operation, safeguards oversight and appeals functions of the Programme SHALL remain structurally separated in accordance with MCC-001 clause 9.9.1; nothing in this Standard SHALL be read as vesting more than one of those functions in the same person.

1.8 This Standard SHALL apply to all persons and entities participating in the MCC Programme, without exception.

1.9 The Programme SHALL maintain independence from any single government, market or regulatory jurisdiction.

2. Normative references, definitions and interpretation

2.1 Terms used with initial capitals in this Standard SHALL have the meanings assigned in the MCC Definitions Register, which is in force (v1.0; FD-2026-08-24 item D12, recorded in the decision register as attested by the founder, with no executed copy filed); where the Definitions Register does not define a term, the canonical meanings adopted through FD-2026-09-03 (the Unit/Product Dictionary and the canonical terminology annexed to the audit control tables) SHALL apply as interim definitions.

2.2 The normative verb conventions of MCC-001 clause 3.1 SHALL apply throughout this Standard: SHALL/MUST mandatory; SHOULD recommended with documented deviation; MAY optional; statements not using these verbs carry no normative force.

NOTE. Clause 2.2 replaces the citation, in the predecessor text's clause 0013, of a non-existent "MCC-001, Section 13.4"; the authoritative verb hierarchy is MCC-001 clause 3.1. The predecessor's use of "will" as a normative verb is discontinued.

2.3 Each numbered clause of this Standard SHALL state one testable requirement; text introduced by "NOTE" or "GUIDANCE" is non-normative.

2.4 A local definition MAY be created only for a term unique to a single methodology and SHALL NOT redefine any term in the Definitions Register.

3. Governance interface

3.1 Governance of the Programme — bodies, mandates, independence controls, decision-making, delegated authority, appeals and complaints — is established exclusively by MCC-001 Section 9 and MCC-700; this Standard SHALL NOT create, name or empower any governance body, role or function.

3.2 The owner, entry criteria, exit criteria, service levels and appealability of every project lifecycle transition are stated exclusively in MCC-700 Annex B; the recommending body, accountable decision-maker, quorum, voting threshold, conflict rule and appeal route for every decision type are stated exclusively in MCC-700 clauses 7.2 (default quorum) and 7.4 (default threshold) and Annex A; this Standard states neither a decision threshold nor a decision owner.

3.3 Where this Standard requires that a determination be made, the determination SHALL be made by the body designated for that decision type in MCC-700 Annex A, under the procedures of MCC-700.

3.4 Every decision made under this Standard SHALL carry the reasons, records, review rights and appeal rights provided by MCC-700 Sections 10 to 12.

NOTE. The predecessor text's governance apparatus — "Governance Board", "Methodology Standards Panel", "Review Authority", "Registry Authority", "Compliance Function" as a decision-maker, the nine named staff roles, and the reporting-line table — is superseded by the canonical architecture of FD-2026-09-03 item D4 and is not carried. Administrative functions formerly assigned to the "Programme Administrator" and "Registry Manager" are assigned to the Programme Secretariat within its delegated authority (MCC-700 clause 4.11), and compliance monitoring to the Programme Secretariat's non-decisional compliance monitoring function (MCC-700 clause 4.11.3); the Secretariat is not yet staffed (MCC-700 clause 4.11.4).

4. Programme instruments

4.1 The Programme SHALL recognise exactly three instruments, and no others, as defined in the Unit/Product Dictionary (canonical control table 1, adopted under FD-2026-09-03 item D1); the definitions in clauses 4.2 to 4.4 are generated from that Dictionary and are not locally variable.

4.2 MCC-CC (Carbon Credit) — a transferable unit representing exactly one metric tonne of CO2e reduced or removed, verified ex post under an approved carbon methodology.

4.3 MCC-MOU (Marine Outcome Unit) — a unit representing a methodology-specific, quantified and verified physical marine outcome (for example, kilograms of verified gear loss avoided, kilograms of plastic removed, or habitat-hectare-years).

4.4 MCC-CB (Verified Co-benefit Label) — a verified statement, with defined scope, indicator and period, attached to a specific MCC-CC or project record; a label is not a unit and is not transferable separately from the record it is attached to.

4.5 An MCC-CC SHALL be fungible only within its declared attributes, methodology and vintage, and SHALL NOT include any unquantified biodiversity or other non-carbon outcome as part of the tonne.

4.6 An MCC-MOU SHALL NOT be fungible across different outcome metrics, SHALL NOT be described as a carbon credit, an offset or avoided emissions, and SHALL support contribution and outcome claims only.

4.7 The former instrument "MCC-HYB" is abolished and SHALL NOT be issued, marketed or referenced as a credit type; a claim combining carbon and co-benefits SHALL be expressed only as an MCC-CC plus an MCC-CB label.

4.8 The former designation "MCC-MCU" is renamed MCC-MOU; migration of any existing registry records, serials and public text SHALL follow the versioned serial specification and migration rules made under MCC-800. No MCC-MCU unit has ever existed, in the live register or the archive. The live register holds no unit of any instrument, and the demonstration cohort archived on 31 August 2026 holds 8,700 MCC-HYB units, every serial carrying the MCC-DEMO- prefix; this migration therefore has no live subject (Evidence Register ER-2026-001 §A3; registry counts of 1 October 2026).

NOTE — GENERATED CONTENT. Clauses 4.2 to 4.8 reproduce verbatim their single source, the Unit/Product Dictionary (canonical control table 1, adopted under FD-2026-09-03 item D1), as restated identically in MCC-001 clauses 6.1 to 6.5. On any divergence, the source prevails and this reproduction is corrected; no local variation is permitted.

4.9 The instrument type of every unit SHALL be determined by the applied methodology and stated in the Project Design Document; no project document SHALL define an instrument locally.

Unit precision, divisibility and batches

4.10 The smallest unit of account SHALL be one whole unit: one MCC-CC (one tonne CO2e) or one MCC-MOU (one whole unit of the methodology-specific outcome metric at the precision fixed by the methodology).

4.11 Issuance quantities SHALL be expressed as whole units; any fractional remainder after all deductions SHALL be rounded down and SHALL NOT be issued, banked, carried forward as a credit balance or monetised.

4.12 Units SHALL be issued in batches, each batch carrying an immutable serial range under the versioned serial specification made under MCC-800; no serial SHALL be assigned other than under that specification.

4.13 A transfer or retirement SHALL be executed only in whole units; splitting of a batch SHALL preserve every unit's serial identity and the immutability of the original range, as specified in the versioned serial specification.

4.14 Ownership SHALL be recorded at serial-range level such that every unit in every batch has, at all times, exactly one account holder of record.

5. Methodology families and methodology status

5.1 The Programme SHALL operate one and only one methodology family catalogue, comprising families F01 to F05 as defined in the canonical Family–Methodology–Instrument Matrix (control table 2, adopted under FD-2026-09-03 item D2); the table in clause 5.2 is generated from that Matrix and is not locally variable.

5.2 The families, their activities and their instrument mapping are:

Code	Canonical family name	Activities	Instrument	Boundary control
F01	Coastal blue-carbon removals/restoration	Mangrove, tidal/salt marsh, seagrass restoration where an approved carbon methodology quantifies net removals	MCC-CC + optional MCC-CB label	Reversal-risk controls required
F02	Coastal blue-carbon avoided loss/protection	Avoided conversion/degradation of mangrove, tidal/salt marsh and seagrass	MCC-CC only where an approved baseline/additionality/leakage method exists	Avoided-emission flow; protect existing stock and address reversal risk
F03	Sustainable fisheries and fishing-gear interventions	Ghost-gear prevention/retrieval, gear life extension, fuel or replacement-gear manufacturing avoidance	Split: MCC-CC only for a separately quantified LCA/GHG outcome; MCC-MOU for the marine outcome	Home of the GFS pilot (FD-2026-09-03 item D6)
F04	Marine pollution prevention/removal	Plastic, waste, runoff and ship-source interventions	MCC-MOU by default; MCC-CC only under a separate approved GHG methodology	No carbon claim from mass removed alone
F05	Marine habitat and biodiversity conservation	MPAs, coral/oyster habitat, kelp-biodiversity and other conservation outcomes	MCC-MOU + co-benefit statements	No carbon tonnes absent a specific scientifically accepted carbon methodology

NOTE — GENERATED CONTENT. The table in clause 5.2 reproduces verbatim its single source, the Family–Methodology–Instrument Matrix (canonical control table 2, adopted under FD-2026-09-03 item D2), whose family codes and names MCC-001 clause 7.1 carries in summary form. On any divergence, the source prevails and this reproduction is corrected; no local variation is permitted.

5.3 Every family reference in every Programme document, serial number, registry field and platform display SHALL be generated from the Family–Methodology–Instrument Matrix; the prior family semantics printed in the superseded corpus SHALL NOT be used, and translation from legacy codes SHALL proceed only via the old-to-new mapping in control table 2.2.

5.4 A methodology SHALL NOT carry the status "Approved" or "Active" unless the complete methodology dossier, the public consultation record, the independent expert review and the signed approval decision exist and are linked in the Evidence Register (MCC-700 clause 18.3).

5.5 Methodology status SHALL be recorded only in the Methodology Status Register (control table 7), using the vocabulary CONCEPT, DRAFT, CONSULTATION, PILOT, APPROVED, WITHDRAWN/RETIRED; the public register SHALL display exactly its content.

5.6 FD-2026-09-03 item D6 sets methodologies M001–M010, M008 included, to the status CONCEPT (or DRAFT where a substantially complete text exists) until clause 5.4 is satisfied for each, and the methodology register still records MCC-M008 v1.1 as APPROVED; no project SHALL be registered, and no unit issued, under a methodology whose status does not permit it under the Methodology Status Register.

NOTE. The predecessor clause 0005 ("ten approved methodologies") is superseded; no approval record exists in the programme record for any of M001–M010 other than M008, whose approval FD-2026-08-24 item 1 records (D6: "M008 → APPROVED") and whose v1.1 text FD-2026-09-01 item D1 adopts, each recorded in the decision register as attested by the founder, with no executed copy filed (evidence gaps E14–E15).

5.7 The ghost-fishing-gear (GFS) pilot methodology SHALL be developed under family F03 and SHALL report its net greenhouse-gas result (MCC-CC, only where conservatively quantified and verified under an LCA/GHG boundary) and its marine conservation outcomes (MCC-MOU) in separate ledgers; no tonne SHALL be issued from gear mass alone.

5.8 Carbon crediting of kelp and coral activities is suspended; such activities SHALL proceed only as marine-outcome activities under family F05 unless and until a specific, peer-reviewed and conservatively tested carbon methodology passes independent expert review and is approved (MCC-001 clause 7.7).

NOTE — GENERATED CONTENT. Clauses 5.4 to 5.8 reproduce their single sources: the Methodology Status Register (canonical control table 7, adopted under FD-2026-09-03 item D6), MCC-001 clauses 7.3 to 7.7 and MCC-700 clause 18.3 — verbatim except that the operative tail of clause 5.6 ("no project SHALL be registered, and no unit issued, under a methodology whose status does not permit it under the Methodology Status Register") is an MCC-100-specific requirement of this Standard beyond MCC-001 clause 7.5. On any divergence in the reproduced content, the source prevails and this reproduction is corrected; no local variation is permitted.

5.9 Every project SHALL apply exactly one methodology of exactly one family per credited outcome; a project producing both a GHG outcome and a marine outcome (including under the GFS pilot) SHALL account for them in separate ledgers with no cross-crediting between them.

6. Project eligibility

6.1 Every project SHALL, before registration, demonstrate each of the following: (a) direct and material connection to a marine or coastal ecosystem (clause 1.4); (b) application of a methodology whose status permits registration (clause 5.6); (c) measurable, quantifiable outcomes under Sections 9 and 12; (d) domestic legality under Section 16; (e) additionality under Section 7; (f) safeguards conformity under Section 14; and (g) sustainable development assessment under Section 15. Each item SHALL be evidenced separately.

6.2 Every project SHALL define its project proponent, ownership of the environmental attribute claimed, and the legal right to that attribute, with documentary evidence.

6.3 A project SHALL declare every other environmental crediting programme, ecosystem-services payment scheme or attribute-generating arrangement in which the project activity or its boundary participates or has participated, per Section 17.

6.4 A project SHALL define a crediting period; the permitted crediting-period length and renewal limits per family SHALL be fixed in MCC-200, and renewal SHALL require baseline re-evaluation (clause 8.9) and additionality reassessment (clause 7.8).

6.5 Registration validity SHALL extend for the project's crediting period plus five years, to allow for late-submitted verification reports; renewal beyond that validity SHALL require a determination by the body designated in MCC-700 Annex A row 7.

7. Additionality

7.1 Every project SHALL demonstrate that the credited outcome would not occur in the baseline scenario without the incentive created by the credited activity, using the tests in clauses 7.2 to 7.7 as implemented by the applied methodology.

7.2 Regulatory surplus. The credited outcome SHALL NOT be required by any applicable law, regulation, permit condition, court order or binding enforcement action; outcomes achieved by complying with existing legal obligations SHALL NOT be credited.

7.2.1 Where a legal requirement exists but is demonstrably and systematically not enforced, a methodology MAY permit crediting only under documented suppressed-enforcement criteria, with a conservative discount, and subject to clause 8.8.

7.3 Common practice. The project SHALL demonstrate that the activity is not common practice in the relevant geography and sector, using a defined penetration metric and data sources specified by the methodology; where the activity is common practice, additionality SHALL be denied unless the methodology defines documented, verifiable distinguishing barriers.

7.4 Barrier and investment analysis. Where the methodology so requires, the project SHALL demonstrate at least one of: (a) an investment barrier, shown by a transparent financial analysis in which the activity is not the economically attractive course absent credit revenue; (b) a technological, institutional or capacity barrier; or (c) a documented social or ecological barrier — in each case with evidence capable of independent verification.

7.5 Prior consideration. The project SHALL evidence that the incentive of crediting was seriously considered in the decision to proceed, by documentation predating the project implementation decision; a project implemented before that documentation SHALL NOT be registered except under transition rules expressly defined in the methodology and disclosed at listing.

7.6 Perverse incentives. The project SHALL demonstrate that crediting does not create an incentive to cause, worsen or fabricate the problem being remediated (including the deposition of pollution or gear for later credited removal); every methodology SHALL define controls against such gaming, and evidence of gaming SHALL be grounds for refusal, suspension or revocation.

7.7 Continued additionality. Additionality SHALL be reassessed at every crediting-period renewal and upon any material change in law, market conditions or project circumstances notified under clause 12.10; crediting SHALL NOT continue where the outcome has become legally required or common practice, except to the extent of vested, already-verified outcomes.

7.8 The additionality demonstration, including all data, assumptions and calculations, SHALL be documented in the Project Design Document and assessed at validation; an AI system SHALL NOT make or determine any additionality assessment (clause 22.5).

8. Baselines

8.1 Every project SHALL define a baseline scenario representing the most plausible course of events in the absence of the project activity, established under the applied methodology.

8.2 The baseline SHALL be defined over an explicit spatial, temporal and gas/outcome boundary, stating every included source, sink, reservoir or outcome metric and justifying every exclusion; an exclusion SHALL be permitted only where it is conservative.

8.3 Baseline data SHALL follow a data hierarchy fixed by the methodology, preferring in order: (a) measured, project-site-specific data; (b) measured regional or national data; (c) peer-reviewed published data applicable to the site; (d) conservative default values published in the methodology. A lower tier SHALL be used only where every higher tier is demonstrably unavailable, with the unavailability documented.

8.4 Every baseline assumption, parameter and model SHALL be conservative: where a range of plausible values exists, the value selected SHALL be the one that yields the lower quantity of credited outcome.

8.5 Baseline emission factors, carbon stocks and outcome rates SHALL be justified by cited evidence; undocumented expert judgement SHALL NOT be a baseline data source.

8.6 The baseline SHALL account for documented trends and reasonably foreseeable policy effects in the baseline scenario; a static baseline MAY be used only where the methodology demonstrates it is conservative for the family and activity.

8.7 Baselines SHALL be re-evaluated and re-validated: (a) at every crediting-period renewal; (b) upon any material change in the applicable law, drivers of loss, or activity data underlying the baseline; and (c) at the maximum baseline validity interval fixed by the methodology, which SHALL NOT exceed ten years.

8.8 Suppressed activity. A baseline SHALL NOT assume levels of activity, demand or degradation above those evidenced historically ("suppressed demand" or projected-crisis baselines), unless the methodology defines the case with peer-reviewed justification and applies an explicit conservative cap.

8.9 A baseline update SHALL apply prospectively from the update; verified outcomes already issued against the prior validated baseline SHALL NOT be retrospectively invalidated by the update alone (without prejudice to Section 23 remedies for error or fraud).

9. Quantification, uncertainty and conservativeness

9.1 Every methodology SHALL quantify credited outcomes using explicitly stated equations, with every parameter defined by name, symbol, unit, data source, measurement method, measurement frequency and uncertainty treatment; a quantification that cannot be independently recomputed from the stated equations and recorded data SHALL NOT support issuance.

9.2 All quantification SHALL use metric units; GHG quantification SHALL use tonnes of CO2e computed with the global warming potential values fixed by MCC-200, applied suite-wide.

9.3 Quantified uncertainty SHALL be estimated for every material parameter and propagated to the final credited quantity using the method fixed by the methodology.

9.4 Where the combined uncertainty of the credited quantity exceeds the threshold fixed by the methodology, an uncertainty discount SHALL be applied that reduces the credited quantity, scaled to the excess uncertainty; uncertainty SHALL be addressed by such deductions and discounts before issuance and SHALL NOT be transferred to, or compensated from, the buffer pool.

9.5 Missing data. Where required monitoring data are missing or invalid for any part of a monitoring period, the methodology's missing-data procedure SHALL apply, and the substituted value SHALL be demonstrably conservative; missing data SHALL never increase the credited quantity, and where no conservative substitution is possible the affected quantity SHALL NOT be credited.

9.6 Materiality. Quantitative materiality thresholds for errors, omissions and misstatements SHALL be fixed by MCC-200 per assurance engagement type; the aggregate of uncorrected misstatements SHALL be below the applicable threshold before any verification statement supports issuance.

9.7 QA/QC. Every project SHALL implement a documented quality assurance and quality control procedure covering data collection, transcription, storage, calculation, review and correction, with named responsibilities; QA/QC records SHALL be available to the VVB and retained per the Record Retention Schedule.

9.8 Rounding. Every rounding step in quantification and issuance SHALL round down at the smallest permitted unit precision; commercial or nearest-value rounding SHALL NOT be used at any step that determines a credited quantity.

9.9 The ordered deduction sequence for any credited GHG quantity SHALL be: (a) conservative baseline and project quantification (Sections 8 and 9); (b) leakage deduction (Section 10); (c) uncertainty discount (clause 9.4); then (d) buffer-pool deduction (Section 11) applied only to stored-carbon reversal exposure; no step SHALL be reordered or netted against another.

9.10 No quantification step SHALL permit a negative deduction, a credit for an unmeasured outcome, or the crediting of an outcome outside the validated boundary.

10. Leakage

10.1 Every methodology SHALL identify each plausible leakage mechanism — activity-shifting, market leakage, ecological leakage and any family-specific mechanism — for its activity type and boundary.

10.2 Every project SHALL assess each identified leakage mechanism, quantify the expected leakage using the methodology's leakage-quantification procedure, and document mechanisms assessed as immaterial with reasons.

10.3 Quantified leakage SHALL be deducted in full from the credited quantity of the monitoring period in which it occurs or is projected to occur (clause 9.9 step (b)).

10.4 Leakage SHALL be monitored over the crediting period using indicators defined in the monitoring plan; monitored leakage exceeding the projection SHALL increase the deduction for the current and subsequent periods.

10.5 Leakage, and leakage uncertainty, SHALL NOT be covered by, transferred to or netted against the buffer pool.

10.6 Where leakage in a monitoring period exceeds the credited outcome of that period, no unit SHALL be issued for that period and the excess SHALL be carried forward as a deduction against future periods.

11. Permanence, durability and reversals

11.1 Every methodology crediting stored carbon (families F01 and F02, and any F03 stored-carbon component) SHALL assign each project a durability class from the classification fixed in the Tier 3 permanence and buffer standard, describing the expected longevity profile of the stored carbon.

11.2 Separately from the durability class, every such project SHALL define its enforceable commitment period: the period actually covered, in aggregate, by binding legal commitments, secured land/marine tenure or use rights, funded monitoring, and reversal-liability arrangements, each evidenced.

11.3 No permanence or durability claim, in any Programme document, registry field, certificate or communication, SHALL exceed the enforceable commitment period evidenced under clause 11.2; in particular, no 100-year or "permanent" claim SHALL be made absent contracts, tenure, monitoring funding, replenishment liability and wind-down protection covering that full period.

NOTE. The predecessor clause 0183.1 (100-year F01 permanence horizon against 30-year post-crediting monitoring, imported from MCC-200 clause 0031.1) is superseded and not carried (SYS-09; 200-05). Durability classes and their minimum enforceable-period requirements are defined once, in the rewritten Tier 3 permanence and buffer standard (MCC-BPM v2.0-draft, Schedule 1 — Durability Classification, put to consultation with this suite).

11.4 Post-crediting monitoring and reporting of stored carbon SHALL continue for the full enforceable commitment period, funded by arrangements evidenced before first issuance.

11.5 Reversal. A reversal is any loss or release that negates previously credited stored-carbon benefit, in any quantity; the predecessor's 10%/20% reversal thresholds are abolished, and no de minimis quantity of verified reversal SHALL be exempt from compensation.

11.6 Every verified reversal SHALL be compensated as MCC-700 clause 16.7 requires (equivalent cancellation or replenishment, regardless of cause, with pursuit of a responsible party a separate, non-deferring action); that clause is the single source of the compensation rule and is not restated here.

11.7 Suspected reversals SHALL be reported by the project proponent within thirty calendar days of discovery, assessed under the monitoring plan, and verified by a VVB before compensation is quantified; pending verification, issuance for the affected project SHALL be withheld.

11.8 Buffer pool scope. The buffer pool's exclusive scope — quantified stored-carbon reversal/non-permanence exposure, and nothing else — is fixed by MCC-700 clause 16.3, which is the single source of that rule and applies to every project under this Standard.

11.9 Flow-based outcomes (avoided emissions without a storage component, and all MCC-MOU outcomes) SHALL NOT contribute to, or draw on, the buffer pool.

11.10 Buffer-pool deduction rates SHALL be determined per project from a completed and verified non-permanence risk assessment under the rewritten Tier 3 buffer standard; no issuance SHALL occur for a stored-carbon project whose risk assessment is incomplete, and no default rate SHALL substitute for a completed assessment.

11.11 Buffer releases SHALL occur only under MCC-700 clause 16.5 (portfolio adequacy, independent assessment, and approval by the body there designated); no release SHALL occur solely because a project or vintage reaches a date.

11.12 Portfolio reversal-risk adequacy SHALL be assessed at least annually by an independent assessor, including concentration and correlated-event stress testing; the assessment SHALL be published.

12. Monitoring, reporting and verification data

12.1 Every project SHALL implement a monitoring plan, validated with the Project Design Document, that specifies every monitored parameter, measurement method, instrument, accuracy specification, sampling design, monitoring frequency, data owner and QA/QC control.

12.2 Monitoring instruments SHALL be calibrated and maintained per the manufacturer's specification or an applicable measurement standard, with calibration records retained and available to the VVB.

12.3 Sampling designs SHALL be statistical, with the confidence and precision targets fixed by the methodology, and SHALL be reproducible from the documented design.

12.4 Every monitored data point SHALL carry a documented chain of custody and data lineage from original observation (field measurement, sensor record, laboratory result or remote-sensing scene) to the value used in quantification, such that a verifier can trace every reported value to its origin.

12.5 Remote-sensing data MAY be used where the methodology defines the sensor classes, resolution, classification method, accuracy assessment and ground-truthing requirements; remote-sensing outputs SHALL be validated against field evidence at the frequency the methodology fixes.

12.6 Monitoring data SHALL be recorded in a form that preserves the original observation; corrections SHALL be logged, never overwritten.

12.7 Monitoring reports SHALL be submitted for each monitoring period at the frequency fixed by the methodology and SHALL include: monitored data and lineage, quantification per Section 9, leakage assessment per Section 10, permanence/reversal status per Section 11, safeguards monitoring per Section 14, and sustainable development reporting per Section 15.

12.8 A monitoring report SHALL be complete, internally consistent and reproducible before it is submitted for verification; a report failing these tests SHALL be returned by the Programme Secretariat without verification.

12.9 All monitoring data supporting an issuance SHALL be retained per the Record Retention Schedule and SHALL be available for re-verification for the full retention period.

12.10 The project proponent SHALL notify the Programme Secretariat in writing, within thirty calendar days, of any material change to the project design, boundary, ownership, legal status, tenure, applicable law or risk profile; material changes SHALL trigger the reassessments this Standard attaches to them.

13. Project lifecycle requirements

13.1 The project lifecycle — its states, transitions, owners, entry and exit criteria, service levels and appealability — is defined solely in MCC-700 Annex B; this Standard defines the programme requirements that SHALL be satisfied within each state and does not restate the state machine.

13.2 The lifecycle states are exactly those enumerated in MCC-700 Annex B rule B-2 (from DRAFT through REGISTERED, ACTIVE and the terminal states), which is their single source and is not reproduced here; no Programme document, screen or workflow SHALL introduce any other state or gate. Where this Standard names a state, the name is used as Annex B defines it.

13.3 The sequential-gate rule of MCC-700 clause 9.4 and Annex B applies to every project without relief: no gate SHALL be reordered, run concurrently or bypassed for any project, including pilot projects and any expedited handling.

NOTE. This cures the predecessor's contradiction (100-02) in which GOVERNANCE_REVIEW ran "concurrent with consultation" in the stage table while clause 0050 called the stages sequential.

13.4 Submission (DRAFT → SUBMITTED). A submission SHALL comprise the complete Project Design Document addressing every section required by the methodology, the safeguards screening form, the declarations under clause 6.3 and Section 17, the domestic-legality identification under clause 16.2, and payment of the listing fee per the published MCC Fee Schedule (MCC-700 Annex A row 33).

13.5 Completeness check. The Programme Secretariat SHALL check completeness against a published checklist within the Annex B service level; the completeness check is administrative and SHALL NOT assess substantive quality.

13.6 Safeguards screening. At SAFEGUARDS_SCREENING the requirements of clauses 14.3 to 14.6 SHALL be satisfied: risk category assigned with reasons, exclusion list screened, and the assessment instruments required for the category submitted or scheduled with dated commitments; safeguards screening is distinct from, and does not substitute for, the safeguards clearance required before issuance (clause 19.2(b)).

13.7 Technical review. At TECHNICAL_REVIEW the Programme Secretariat SHALL document its assessment of: methodology applicability and correct application; baseline conservatism (Section 8); additionality (Section 7); quantification and uncertainty treatment (Section 9); leakage assessment (Section 10); permanence and durability treatment (Section 11); monitoring plan feasibility (Section 12); and the validation report, which clause 18.2 requires for every project before TECHNICAL_REVIEW is passed.

13.8 Stakeholder consultation. A public consultation of no less than the period fixed in MCC-700 Annex B T5 SHALL be held, with the Project Design Document (redacted only per clause 20.7) publicly available, comments logged, and the proponent's responses to material comments published before the consultation record closes.

13.9 Governance review and registration. A project SHALL NOT pass GOVERNANCE_REVIEW unless: safeguards clearance for registration is confirmed; domestic-legality evidence is verified per clause 16.3; no unresolved exclusion, conflict-of-interest or double-counting flag remains; the methodology's status permits registration; and the consultation record is complete. The registration decision SHALL be issued in writing with reasons by the body designated in MCC-700 Annex A row 7.

13.10 Returns for revisions. Every return for revisions under a return transition of MCC-700 Annex B (row T15, or the completeness-stage return of row T2) SHALL: (a) be supported by written findings, each identifying the deficiency, its severity and the provision it relates to; (b) start a cure period of thirty calendar days from notification, extensible once by up to thirty calendar days on written request stating cause; (c) preserve the complete record of each prior submission and return; and (d) on resubmission, re-enter the machine at the point Annex B specifies without reopening any stage already lawfully passed.

NOTE. The general return-for-revisions transition (the substance of predecessor clauses 0053.1–0053.5) is carried by MCC-700 Annex B row T15, in the MCC-700 v4.0 draft put to consultation with this suite; this Standard attaches the due-process controls above to it and adds no transition of its own.

13.11 Once the stakeholder consultation has opened, a project SHALL NOT be returned to DRAFT; the competent body SHALL instead impose conditions, or refuse with reasons, under the Annex B gate rules.

13.12 A refusal MAY be issued at any pre-registration stage where the grounds are conclusively established, without advancing the project through remaining stages, with each ground stated separately (MCC-700 clause 10.5, Annex B T13).

13.13 A project developer MAY withdraw a project at any state per MCC-700 Annex B T14; withdrawal is terminal for the submission, and a fresh application starts a new lifecycle.

13.14 Queue neutrality. Submissions SHALL be taken up for each stage in the order in which they satisfied that stage's entry criteria; no AI-generated score, completeness flag or model output SHALL alter queue order, and no queue position SHALL relax any stage, consultation period, assessment or verification requirement.

NOTE. The predecessor's "prioritised sequencing" (clauses 0061.1–0061.3, inserted by Amendment 1) is abolished: an AI-derived queue preference structurally advantages well-resourced applicants (audit 850-06). Support pathways for small-scale and community developers are provided under clause 13.15 instead.

13.15 The Programme SHALL publish and operate a support pathway (guidance, pre-submission checks, template assistance) available to small-scale and community project developers without fee; use of the pathway SHALL confer no assessment advantage.

13.16 Every submission, return, withdrawal, rejection and stage advance SHALL be recorded in the registry audit trail with the deciding user or body, timestamp, prior and resulting state, and the reasons or findings relied on; lifecycle transitions SHALL be enforced programmatically against the Annex B machine, and any administrative override SHALL be recorded as a high-severity audit event and reported to the Programme Secretariat's compliance monitoring function.

13.17 A project whose methodology regresses in status SHALL be held at its current state with a dated hold annotation and written notice to the developer within five business days (MCC-700 clause 9.5).

13.18 The public register SHALL display every project from the SUBMITTED state onwards, with its current lifecycle state; "listed" is a description of that public visibility, is not a lifecycle state, and confers no registration, approval, validation, verification or issuance (MCC-001 clause 11.6).

14. Environmental and social safeguards

14.1 Environmental and social safeguards requirements — principles, exclusion list, assessment instruments, grievance mechanics and remedy — are defined in the Environmental & Social Safeguards Policy (Tier 3); this Section states the programme-level conditions that bind every project, and in case of conflict the safeguards taxonomy of that Policy prevails over any restatement.

14.2 Demonstrated safeguards conformity SHALL be a condition of registration and of every issuance (MCC-001 clause 10.2).

14.3 Every project SHALL be screened against the Programme exclusion list defined in the Environmental & Social Safeguards Policy before any risk categorisation; an excluded activity SHALL be refused.

14.4 Every project SHALL be assigned an environmental and social risk category — Category A (high risk), B (medium risk) or C (low risk) — with written reasons, applying the categorisation criteria of the Environmental & Social Safeguards Policy.

14.5 Category A projects SHALL complete a full Environmental and Social Impact Assessment by qualified independent experts, and an Environmental and Social Management Plan (ESMP); Category B projects SHALL complete a proportionate assessment and an ESMP; Category C projects SHALL complete the simplified conformity declaration defined in that Policy.

14.6 Every risk categorisation, including Category C, SHALL be independently validated before registration; self-declaration alone SHALL NOT establish a project's category.

14.7 Where Indigenous Peoples' rights, lands, waters, resources or cultural heritage may be affected, Free, Prior and Informed Consent (FPIC) SHALL be obtained and documented before registration, under the rights-holder identification and consent criteria of the Environmental & Social Safeguards Policy; meaningful consultation and lawful agreement SHALL be required wherever any community's rights or access are affected.

14.8 Every project SHALL address marine tenure, customary fishing and resource rights, access restrictions and livelihood impacts under the marine-rights requirements of the Environmental & Social Safeguards Policy, with documented benefit-sharing arrangements where access or use is restricted.

14.9 Every project SHALL establish and maintain a grievance mechanism that is free, accessible, confidential on request, culturally appropriate and non-retaliatory, with the acknowledgement, urgent-harm triage and escalation service levels fixed in the Environmental & Social Safeguards Policy; grievances disclosing risk of severe or ongoing harm SHALL be triaged immediately (MCC-700 clause 14.3).

14.10 Safeguards monitoring SHALL be conducted at least annually for Category A and B projects, and for every project (including Category C) at the minimum surveillance level fixed by the Environmental & Social Safeguards Policy; safeguards monitoring reports SHALL accompany every verification.

14.11 An urgent-harm stop-work or suspension MAY be ordered at any time under MCC-700 clause 14.3 and Annex A row 12a, without awaiting any cure period.

14.12 Remedy obligations arising from safeguards non-conformity or grievances SHALL survive the crediting period (MCC-700 clause 14.5).

14.13 A safeguards clearance, confirming that safeguards requirements are met or conditions resolved, SHALL be verified before every issuance (clause 19.2(b)).

15. Sustainable development contribution

15.1 Every project SHALL assess, measure and publicly report its sustainable development contributions under the Sustainable Development Contribution Framework (MCC-SDCF), subject to that framework's conformity review against FD-2026-09-03 items D1–D3 (the framework was outside the audited ten-file inventory). That review was completed on 3 September 2026 as CR-2026-001, which found MCC-SDCF v1.0 non-conforming; MCC-SDCF v2.0-draft is put to consultation with this suite, and the status of MCC-SDCF is reserved to the Governing Board (FD-2026-09-04 item 6).

15.2 Sustainable development indicators SHALL be methodology-relevant, selected and operationalised per MCC-SDCF, each with a baseline, measurement protocol, monitoring frequency, attribution rationale and assurance requirement; a sustainable development claim SHALL NOT be made without indicator-level evidence (MCC-001 clause 5.8).

15.3 Sustainable development performance SHALL be reported in every monitoring report and assessed in every verification.

15.4 No project or participant SHALL make a generic SDG badge claim, assert causality beyond what is verified, or claim a sustainable development contribution not substantiated by baseline data, monitoring data and third-party verification.

15.5 The qualifying criterion for the "MCC SD Gold" designation is not decided. Until one criterion is adopted — to be resolved in the rewritten MCC-SDCF (v2.0-draft, put to consultation with this suite, whose clause 8.3 proposes one), one rule suite-wide — no SD Gold designation SHALL be awarded, and this Standard states no criterion. (Consultation question 1.)

15.6 Aggregate sustainable development performance SHALL be published annually at programme level (MCC-001 clause 10.3).

16. Host-country requirements and Article 6 attributes

Domestic legality

16.1 Every project SHALL comply with the applicable law of its host country throughout its life; domestic legality is distinct from Article 6 authorization, and neither implies the other (MCC-700 clause 17.2).

16.2 Every project SHALL identify, at submission, every permit, licence, approval or other authorisation required under applicable host-country law to implement the project activity, or provide a reasoned legal confirmation that none is required.

16.3 Evidence of every instrument identified under clause 16.2 SHALL be submitted and verified before the project passes the GOVERNANCE_REVIEW gate; a project SHALL NOT be registered with outstanding required domestic instruments (MCC-700 clause 17.3; Annex B T6).

NOTE — resolution of MCC-700 OD-3. The corpus printed three incompatible domestic-permit gates (MCC-700 v3.1: before registration; MCC-100 v2.2: before issuance where required; MCC-HCA v1.0: optional). This Standard resolves the gate at registration (GOVERNANCE_REVIEW), confirming the interim rule of MCC-700 v4.0 clause 17.3 as the suite-wide rule, with continued-validity confirmation at every issuance under clause 16.4 preserving the protective substance of the predecessor's issuance-stage check. MCC-HCA v2.0-draft clause 3.2, put to consultation with this suite, states the gate at registration.

16.4 Continued validity of every required domestic instrument SHALL be confirmed in each monitoring report and verified before each issuance; where a required instrument lapses or is revoked, issuance SHALL be withheld and the project assessed for suspension under MCC-700 Annex B T9.

16.5 The evidential procedure for domestic-legality documentation SHALL be set in the Host Country Authorisation Procedure (Tier 5), which SHALL conform to this Section and to FD-2026-09-03 item D3.

16.6 Review of host-country instruments (issuer authority, signatures, conditions, currency) SHALL be performed by the Programme Secretariat and confirmed at the GOVERNANCE_REVIEW gate per MCC-700 clause 17.9.

NOTE. The predecessor's four host-country categories A–D (clauses 0106–0110), with per-category corresponding-adjustment "commitments", are abolished: they conflicted with MCC-HCA's three categories, embedded the superseded CA-commitment logic, and purported to classify sovereign states by promise rather than by evidence. No categorisation of host countries is normative under this Standard; each Article 6 fact is an evidence-backed attribute under clauses 16.8 to 16.14.

Article 6 attributes

16.7 The default status of every MCC unit SHALL be NOT AUTHORIZED FOR ARTICLE 6 / VOLUNTARY USE ONLY (FD-2026-09-03 item D3).

16.8 The registry SHALL record the Article 6 facts of each unit exclusively as the discrete evidence-backed attributes of the Article 6 Attribute/Status Matrix (control table 5): host-country project approval/non-objection; authorization purpose; authorization date/instrument; first-transfer definition; first-transfer event; corresponding-adjustment reporting evidence; withdrawal/revocation status; and scheme eligibility — each set only upon documentary evidence linked in the Evidence Register, mirrored to the registry record.

16.9 Article 6 authorization SHALL NOT be a precondition to listing, registration or issuance of any unit (MCC-700 clause 17.4).

16.10 Corresponding adjustments SHALL be treated under this Standard exactly as MCC-700 clause 17.6 provides (a Party's accounting action, evidenced but never performed, instructed or triggered by MCC, at retirement or otherwise); that clause and the Definitions Register are the single source of the corresponding-adjustment rule and definition, not restated here.

16.11 The status "CA evidence recorded" SHALL be applied only where the Party's documentary reporting evidence is linked in the Evidence Register, mirrored to the registry record; the label "CA-Confirmed" SHALL NOT be used, and no attribute SHALL be set on the basis of a stated intention or promise of future implementation.

16.12 No registry attribute, certificate or communication SHALL infer or assert compliance-market eligibility, Article 6.4 status or scheme eligibility from any host-country, authorization or corresponding-adjustment attribute; scheme eligibility SHALL be recorded only upon a scheme decision covering the exact programme, unit and vintage scope, linked in the Evidence Register.

16.13 No MCC unit SHALL be labelled, marketed or described as an A6.4ER or as any Article 6.4 unit.

NOTE — GENERATED CONTENT. Clauses 16.7 to 16.13 reproduce their single sources: the Article 6 Attribute/Status Matrix (canonical control table 5, adopted under FD-2026-09-03 item D3) and MCC-700 clauses 17.1 and 17.4 to 17.8, as restated in MCC-001 Section 8 — verbatim except that clause 16.8's evidence formulation "linked in the Evidence Register, mirrored to the registry record" deliberately extends MCC-700 clause 17.5 by applying to every attribute the linkage-and-mirroring test that MCC-700 clause 17.7 and control table 5 fix for the corresponding-adjustment attribute. On any divergence in the reproduced content, the source prevails and this reproduction is corrected; no local variation is permitted.

16.14 Changes to any recorded Article 6 attribute (including revocation or withdrawal by the Party) SHALL be recorded with the underlying instrument within ten business days of receipt, and affected unit holders notified.

NOTE. Predecessor clauses 0123–0124 ("credits with confirmed corresponding adjustment status shall be eligible for use in compliance carbon markets…") and 0211 (the CA-Confirmed/CA-Under Development/CA-Not Applicable/CA-Pending display statuses) asserted eligibility conclusions and promise-based statuses and are superseded in full (SYS-07; 100-03; FD-2026-09-03 item D3).

17. Double counting and finance stacking

17.1 No unit SHALL be issued where the same environmental outcome, for the same activity, boundary, period and outcome metric, has been or will be issued, used or claimed under any other programme or arrangement (MCC-001 clause 5.9).

17.2 The following SHALL be prevented and are prohibited: (a) double issuance — issuance of more than one unit, in any programme, for the same outcome; (b) double use — more than one use or retirement of the same unit; (c) double claiming — assertion of the same environmental benefit by more than one party, subject to the claim rules of MCC-600; and (d) double registration — registration of the same project activity and boundary for the same outcome in more than one crediting programme without cancellation or transition evidence.

17.3 Finance stacking. Receipt of grants, concessional finance, blended finance, philanthropic funding or non-credit payments for ecosystem services SHALL NOT of itself disqualify a project; such funding SHALL be disclosed at submission and in monitoring reports, and SHALL be prohibited only where it entails the sale, transfer or claiming of the same environmental attribute credited under the Programme.

NOTE. This replaces the predecessor's "double monetisation" prohibition, which as drafted risked banning legitimate blended finance rather than the duplicate monetisation of the same attribute (100-05). The additionality effect of non-credit funding is assessed under Section 7 (investment analysis), not by exclusion.

17.4 A project previously or concurrently registered under another programme SHALL be eligible only where the proponent evidences, for every overlapping outcome, boundary, period and metric: de-registration, cancellation or transition from the other programme, or that the outcomes credited are distinct; overlap SHALL be resolved by rights, boundary, registry and claim reconciliation before registration, and a baseline adjustment alone SHALL NOT be treated as resolving an overlap.

17.5 The proponent SHALL declare and certify, at submission and annually, every registration, application or credit issuance for the project activity in any other programme; a false or incomplete declaration is a material breach under Section 23.

17.6 The Programme SHALL operate risk-based cross-programme duplicate checks using public registry records and available interoperability arrangements, with manual escalation of suspected duplicates to the compliance monitoring function; confirmed double registration SHALL result in suspension or revocation and cancellation of affected units under Section 23.

17.7 The detailed double-counting controls, checks and Scope 3/value-chain claim rules SHALL be set in the Tier 3 double-counting standard and MCC-600, which SHALL conform to this Section.

18. Validation and verification

18.1 Every project SHALL be validated ex ante and verified ex post by an independent third-party VVB recognised under MCC-400 for the applicable scope (MCC-001 clause 5.3); VVB competence, impartiality, accreditation, insurance, rotation, cooling-off and oversight requirements are stated exclusively in MCC-400, and VVB decisions are governed by MCC-700 Annex A.

18.2 Validation SHALL be completed, and the validation report submitted, before the project passes TECHNICAL_REVIEW (MCC-700 Annex B T4); no project SHALL be registered without a positive validation conclusion.

NOTE. This fixes the predecessor's ambiguity (100-02) in which technical-review timing depended on a validation report whose place in the stages was undefined: validation is an entry input to the TECHNICAL_REVIEW exit criteria.

18.3 Validation SHALL assess, at minimum: project description, boundary and baseline determination (Section 8); methodology applicability and correct application; baseline conservatism; additionality (Section 7); quantification and uncertainty treatment (Section 9); leakage assessment (Section 10); permanence, durability class and enforceable commitment period (Section 11); monitoring plan feasibility and data quality (Section 12); safeguards conformity (Section 14); sustainable development assessment (Section 15); and stakeholder consultation adequacy.

18.4 Verification SHALL assess, for each monitoring period, at minimum: monitoring data completeness, accuracy and lineage (Section 12); quantification correctness and conservativeness, recomputed independently (Section 9); leakage deductions (Section 10); permanence status and any reversal (Section 11); safeguards implementation (Section 14); sustainable development indicators (Section 15); continued domestic-legality validity (clause 16.4); and buffer-pool contribution calculation (Section 11), to the assurance level fixed by MCC-400.

18.5 Where a project produces both GHG and marine-outcome results, the VVB SHALL apply separate assurance objectives and materiality to the GHG statement and to each marine-outcome statement, and SHALL issue separately identifiable conclusions for each.

18.6 The VVB SHALL determine its own evidence-gathering plan and sampling on a risk and materiality basis; no AI output, programme suggestion or confidence score SHALL reduce the VVB's minimum evidence, sampling or scrutiny (MCC-700 clause 20.4).

18.7 The VVB SHALL reach its validation and verification conclusions blind to any programme AI recommendation; AI outputs MAY be considered only after the VVB's draft conclusion, for discrepancy and quality review, per MCC-700 clause 15.5 and MCC-850.

18.8 Validation and verification reports SHALL follow the MCC templates and SHALL state: scope; procedures applied; findings per assessment area; the conclusion (positive, positive with conditions, or negative) with reasons; the VVB's identity, recognition scope and signature; and a statement of independence.

18.9 Site inspection SHALL be conducted where the methodology requires it and otherwise where the VVB's risk assessment requires it; the basis for omitting a site inspection SHALL be documented in the report.

18.10 The VVB SHALL have access to all project documentation, monitoring data, systems and sites necessary for its engagement; obstruction of access is a material breach under Section 23.

18.11 A negative validation or verification conclusion, and any conclusion later found to have been procured by misrepresentation, SHALL be reported to the Programme Secretariat and processed under Section 23.

19. Credit issuance

19.1 Units SHALL be issued only ex post, for outcomes verified for a completed monitoring period, and only upon satisfaction of every prerequisite in clause 19.2.

19.2 The issuance prerequisites are, in order: (a) a complete verification report with a positive verification statement per Section 18; (b) safeguards clearance confirmed per clause 14.13; (c) domestic-legality continued validity confirmed per clause 16.4; (d) Article 6 attributes recorded per clause 16.8; (e) the deduction sequence of clause 9.9 applied, with the buffer contribution determined per clause 11.10; (f) no unresolved material non-compliance, dispute or pending appeal on a decision relied on (MCC-700 clause 12.11); and (g) approval by the body designated in MCC-700 Annex A row 9, under the controls that row fixes.

19.3 Every prerequisite SHALL be satisfied and evidenced separately; no prerequisite SHALL be waived, netted or deemed satisfied.

19.4 The issued quantity SHALL equal the verified quantity after the clause 9.9 deduction sequence, rounded down to whole units (clause 4.11); no issuance SHALL exceed the verified quantity, and missing data or uncertainty SHALL never increase an issued quantity.

19.5 Serials SHALL be assigned to issued units in batches under the versioned serial specification (clause 4.12); no unit SHALL exist in the registry without a valid serial in an issued batch.

19.6 Buffer-pool contributions SHALL be issued to, and held in, the segregated buffer account under the rewritten Tier 3 buffer standard and MCC-800.

19.7 Every issuance SHALL be recorded and publicly disclosed in the registry within five business days, displaying the fields required by clause 20.4.

19.8 An issuance decision refusing or reducing a requested issuance SHALL be issued in writing with each ground stated separately, and carries the appeal rights of MCC-700 (Annex B T-I).

19.9 Issuance and serial assignment remain frozen until the Unit/Product Dictionary, the canonical Family–Methodology–Instrument Matrix and the versioned serial specification are adopted and implemented (MCC-001 clause 14.7); no issuance SHALL occur during the freeze.

20. Registry and transparency

20.1 The MCC Registry SHALL be the authoritative and exclusive record of every unit, label, holding, transfer, retirement and cancellation under the Programme; registry operations, data model, security, access control and reconciliation are governed by MCC-800.

20.2 The registry SHALL be publicly searchable, without login or fee, by at least: serial number or range, project, proponent, methodology, family, host country, vintage, unit status and Article 6 attributes.

20.3 The registry SHALL display for each project: unique identifier; title; location and host country; proponent; methodology and version; current lifecycle state (clause 13.18); registration date and crediting period where applicable; environmental and social risk category; safeguards status; sustainable development reporting; cumulative units issued, retired and cancelled by type; and buffer contributions.

20.4 The registry SHALL display for each unit or batch: serial range; instrument type (MCC-CC or MCC-MOU) and any MCC-CB labels; quantity; vintage; issuance date; project and methodology; host country; current status (issued, transferred, retired, cancelled); the Article 6 attributes per control table 5; and, where retired, the retirement date and retiring account holder.

20.5 All units, irrespective of status, SHALL remain permanently searchable, and retirement and cancellation records SHALL be permanent and public.

20.6 Machine-readable public data feeds and an API SHALL be provided per MCC-800 for the fields in clauses 20.3 and 20.4.

20.7 Public disclosure SHALL cover, at minimum, the integrity-critical data of this Section; personal data, commercially confidential information, legally privileged material, and information whose publication would endanger persons, reveal sensitive traditional knowledge or expose vulnerable locations MAY be redacted under the lawful redaction rules of the Tier 3 documents, and beneficiary or price information SHALL be published only where lawful and consented or required.

20.8 An annual programme transparency report SHALL be published covering issuances by methodology and vintage, retirements, project statistics, buffer status, and safeguards and sustainable development performance, and consolidating the four quarterly transparency reports published under MCC-700 clause 21.5. The annual report does not replace, and SHALL NOT delay, those quarterly reports.

20.9 Records SHALL be retained per the MCC Record Retention Schedule; this Standard sets no retention period locally, and until the Schedule is in force no record within this Standard's scope SHALL be destroyed.

NOTE. The predecessor's local retention figures (clause 0119: LoA documents seven years; clause 0157: VVB records ten years; clause 0266: AI audit trails seven years) are removed in favour of the single canonical Schedule (SYS-11; 100-06).

20.10 Registry availability, backup, disaster recovery and incident-disclosure requirements SHALL be fixed in MCC-800 and the Information Security Standard; this Standard states no technology stack, availability percentage or security parameter.

21. Retirement and claims

21.1 Retirement SHALL be the permanent, irreversible removal of a unit from circulation for a stated beneficiary and purpose; no mechanism SHALL exist to reverse a retirement, and a retired unit SHALL never be transferred, re-issued or recirculated.

21.2 Cancellation SHALL be the permanent removal of a unit for a reason other than a beneficiary claim (including buffer compensation, error correction or enforcement), recorded with its reason.

21.3 Retirement does not itself create, evidence or imply Article 6 authorization, a corresponding adjustment, or eligibility under any scheme.

21.4 No MCC unit SHALL be publicly marketed, sold or retired before the MCC Claims Code (MCC-600) is published and in force (MCC-001 clause 11.1); until then, retirement functionality for public claims SHALL remain disabled.

21.5 Until MCC-600 is in force, no offset, compensation, neutrality, compliance or alignment claim SHALL be made for any MCC unit by the Programme or, under their participation terms, by any participant.

21.6 Every public statement about a project, unit or label SHALL conform to the Claims Matrix (control table 6, adopted under FD-2026-09-03 item D7), matching the exact lifecycle state, unit type and authorization status, and SHALL be backed by a registry record.

21.7 A claim SHALL be made only on the basis of retired units, evidenced by the retirement record; no claim SHALL be asserted on owned but unretired units.

21.8 An MCC-MOU SHALL support contribution and outcome claims only; no offsetting, compensation, carbon-neutral, net-zero or tonne-equivalence language SHALL be applied to an MCC-MOU by any party.

21.9 The prohibited-wording list adopted with the Claims Matrix binds every Programme document, registry text, certificate and marketing material; in particular, no party SHALL state or imply that any MCC unit is compliance-eligible, CORSIA-eligible, ICVCM/CCP-approved, an A6.4ER, "designed to satisfy" or "aligned with" any scheme or regulation, absent the scheme-specific approval evidence linked in the Evidence Register.

NOTE. The predecessor's "permitted claims" (clause 0233), which scripted the phrases "Designed to satisfy international climate ambition" and "Structured for future assessment by [framework]", are superseded: both phrasings are on the decided prohibited-wording list (control table 6, item 7; SYS-08).

NOTE — GENERATED CONTENT. Clauses 21.4 to 21.9 reproduce verbatim their single sources: MCC-001 clauses 11.1 to 11.6 and the Claims Matrix with its prohibited-wording list (canonical control table 6, adopted under FD-2026-09-03 item D7). On any divergence, the source prevails and this reproduction is corrected; no local variation is permitted.

21.10 A retirement certificate SHALL be generated for each retirement, stating: serial range, instrument type and quantity, vintage, project and methodology, retirement date, retiring account holder, stated beneficiary and purpose where disclosed, certificate number, and the unit's Article 6 attributes stated factually per control table 5; the certificate template SHALL be governed by MCC-600 and MCC-800 and SHALL contain no eligibility conclusion.

21.11 Marketing materials referencing MCC units SHALL be reviewed against MCC-600 before publication, under the decision type in MCC-700 Annex A row 15.

21.12 Claims monitoring SHALL be performed by the Programme Secretariat's compliance monitoring function; violations SHALL be processed under Section 23, and corrections published.

22. Use of AI systems

22.1 AI systems MAY be used in Programme operations only for approved use cases, as assistive tools, under MCC-850; an AI system SHALL NOT make, and SHALL NOT be the deciding input to, any final decision on project approval, issuance, safeguards, VVB recognition, enforcement or any other material Programme matter (MCC-001 clause 5.4; MCC-700 clause 20.1).

22.2 The approved AI use cases are: (1) completeness-check support; (2) data-quality validation; (3) baseline-conservatism screening; (4) recomputation of quantification calculations; (5) cross-programme duplicate screening; (6) claims-wording monitoring; and (7) registry search and analysis. Any additional use case SHALL be approved under MCC-850 before deployment.

22.3 Every deployed AI use case SHALL carry a task-specific Review Confidence Index, validated for that use case with documented test data, published error and coverage metrics, and calibration evidence per MCC-850; a single generic confidence score SHALL NOT be applied across use cases, and no fixed global confidence band SHALL be used.

NOTE. The predecessor's global 85–99% confidence thresholds (clauses 0261–0262) had no task-specific statistical basis and are superseded (100-10; 850-03).

22.4 An AI output whose Review Confidence Index or validity conditions are not met SHALL NOT be used for any purpose other than flagging the matter for human assessment.

22.5 AI systems SHALL NOT be used for: additionality assessment; risk categorisation; registration decisions; issuance decisions; safeguards assessment; VVB recognition; enforcement or sanctions; or the determination of any person's rights.

22.6 Human assessments and VVB conclusions SHALL be formed blind to AI recommendations, with AI outputs consulted only afterwards for discrepancy and quality review (MCC-700 clauses 15.5 and 20.3); an AI output SHALL NOT reduce any minimum evidence, sampling or scrutiny (clause 18.6) and SHALL NOT affect queue order (clause 13.14).

22.7 Every AI application to a submission SHALL be disclosed to the affected participant, and any person affected by a decision supported by an AI system is entitled, on review or appeal, to human re-examination independent of the AI system and to human-readable reasons (MCC-700 clause 20.5).

22.8 A complete AI audit trail (inputs, model and version, parameters, outputs, indices, human reviewer identity and decision, divergences) SHALL be maintained per MCC-850 and retained per the Record Retention Schedule.

22.9 AI systems SHALL undergo independent validation at least annually per MCC-850, including bias testing; a system with documented bias or systematic error SHALL be suspended from use pending remediation.

23. Compliance and enforcement

23.1 Non-compliance is any material breach of this Standard or a related Programme document by a participant; monitoring and investigation of non-compliance SHALL be performed by the Programme Secretariat's compliance monitoring function, which has no decision authority (MCC-700 clause 4.11.3).

23.2 Enforcement measures SHALL be applied progressively and proportionately to severity, frequency and intent, from: written warning; conditional participation; temporary suspension (not exceeding twelve months per imposition); permanent suspension; cancellation of specifically affected units; to programme exclusion of the participant and related parties (entities under more than ten per cent common beneficial ownership or control).

23.3 Enforcement decisions SHALL be taken by the body designated for the decision type in MCC-700 Annex A, and every enforcement decision SHALL be issued in writing with each ground stated separately.

23.4 Before any measure other than a warning, the participant SHALL receive written notice of the alleged non-compliance and the supporting evidence, and no fewer than thirty calendar days to respond in writing and request a hearing; urgent-harm suspensions under clause 14.11 are excepted and reviewed per MCC-700 clause 14.6.

23.5 Cancellation of issued units SHALL occur only on a defect finding — error, fraud, misrepresentation, verified reversal (Section 11) or breach affecting the units' validity — with due process; a methodology revision or withdrawal SHALL NOT of itself cancel validly issued units.

23.6 Enforcement decisions SHALL carry the independent review and appeal rights of MCC-700 Sections 11 and 12; no appeal SHALL be decided by any person involved in the first-instance decision.

23.7 A suspended or excluded participant MAY apply for reinstatement on evidence of cure, under the decision type in MCC-700 Annex A; reinstatement SHALL require demonstrated remediation and a written compliance commitment.

23.8 Suspected fraud, falsification, deliberate double counting or corruption SHALL be referred to the competent national authorities where the evidence and applicable law warrant it, following due process; contractual sanctions SHALL be limited to participation in the MCC Programme.

23.9 Enforcement outcomes SHALL be recorded in the registry and published, with only the redactions permitted by clause 20.7.

24. Amendments

24.1 This Standard MAY be amended only by: a written proposal; a public consultation of no less than the minimum period MCC-001 clause 12.3 prescribes for Tier 2 amendments; a Standards Committee review and reasoned recommendation; and approval under the decision type in MCC-700 Annex A row 2.

24.2 Every amendment SHALL be published as a changelog entry and a clean consolidated text; amendment text SHALL NOT be published as a standalone bolded block within the consolidated document, and every consolidation SHALL state the instrument that creates the resulting version number.

24.3 No amendment SHALL take effect before its referenced normative dependencies exist (clause 1.6; MCC-001 clause 2.5).

24.4 Where a text of this Standard under public consultation is materially superseded during the consultation, MCC-001 clause 10.12 applies: the consultation SHALL be re-scoped by published notice or closed and restarted; no approval SHALL rest on a consultation conducted on a superseded text.

25. Transitional provisions

25.1 The Governing Board was constituted on 26 August 2026 with two members (GB-2026-001, recorded in the decision register as attested by the founder, with no executed copy filed); no other governance body of MCC-001 clause 9.1.1 has been constituted; every function this Standard assigns is exercised, until the relevant body is constituted, by the founder under MCC-700 Section 23, logged for ratification. Nothing in this Standard asserts that any other body currently exists or has decided anything.

25.2 Issuance and serial assignment are frozen per clause 19.9 and MCC-001 clause 14.7; no unit SHALL be issued, and no serial assigned, until the freeze is lifted by written decision recorded in the Evidence Register.

25.3 Any project submitted under a methodology whose status regressed under FD-2026-09-03 item D6 (including the two projects submitted under M008) SHALL be held at its current lifecycle state under clause 13.17, with written notice to the developer stating the hold, its reasons, the service level, and the available paths (completion of the methodology's approval chain, or transfer to the F03 GFS pilot under signed pilot terms with no crediting guarantee). Two projects exist, both SUBMITTED, both against M008: MCC-2026-0001 (Gulf of Gabès Ghost Gear Recovery) and MCC-DRAFT-7C51FD88 (Norwegian Ghost Gear Recovery); neither has passed the completeness check (Evidence Register ER-2026-001 §A3; registry counts of 1 October 2026). The platform has no fee-collection path, and the registry records no fee taken and no commitment made to any project developer (ER-2026-001 §A3; FD-2026-10-01 Schedule 1, Q14).

25.4 The entry into force of MCC-400 Addendum 1 v1.0 and MCC-850 Amendments 1 and 2 v1.0, each printed as taking effect on 17 September 2026, is stayed under FD-2026-09-03 item D8; no provision of this Standard SHALL be read as reviving them. MCC-BDR-2026-002, decision D-2026-08-02, states for MCC-850 Amendment 2 “Entry into force: 17 August 2026”; the 17 September 2026 date belongs to D-2026-08-10 (MCC-850 Amendment 1) and D-2026-08-11 (MCC-400 Addendum 1), which the same record expressly distinguishes: “Unlike D-2026-08-01 and D-2026-08-02, this Amendment does not enter into force on adoption.” On that record, Amendment 2 was to take effect on adoption. The stay under FD-2026-09-03 item D8 applies on either reading, and nothing is revived. MCC-BDR-2026-002 is unsigned, so the adoption it records is unevidenced (Evidence Register ER-2026-001 §§B1, B4).

25.5 Units, serials or registry records created under the superseded instrument codes (MCC-HYB, MCC-MCU) or the superseded family semantics SHALL be migrated under the versioned serial specification's migration rules before any further registry action on them; pending migration, they SHALL be flagged in the registry as legacy-format records.

25.6 Public consultations opened on methodology texts before this draft SHALL be handled per MCC-001 clause 10.12 (re-scope by published notice, or close and restart); no approval SHALL rest on a consultation conducted on a superseded text. At the date of this draft the consultation register held one open F01 consultation, "MCC-F01 Blue Carbon Sequestration — Methodologies M001 (Mangrove), M002 (Seagrass), M003 (Salt Marsh)", opened 31 August 2026 on 30 days' notice on the published text mcc-f01-methodologies-m001-m003-v0-1, and M001–M003 stood at v0.1, UNDER_REVIEW and unpublished. Its notice period ended on 30 September 2026, and it was closed on 1 October 2026 with its closing protocol published; no comment was received, and the text was not adopted as tabled (consultation register and its closing protocol).

25.7 Every point listed under Consultation questions in this Standard SHALL be resolved, and its resolution recorded in the Evidence Register or decision register, before this Standard may carry any status other than DRAFT — FOR CONSULTATION.

26. Entry into force

26.1 This Standard (MCC-100 version 3.0) SHALL enter into force upon approval under the decision type in MCC-700 Annex A row 2 — during the transitional period, upon a Founder Decision recorded and tabled for ratification under MCC-700 Section 23 — on a stated date, following the public consultation on this draft and completion of the acceptance tests in Section 9 of the independent audit dated 3 September 2026.

26.2 This draft is published with status DRAFT — FOR CONSULTATION and confers no rights and imposes no obligations until entry into force.

26.3 On entry into force, the predecessor MCC-100 texts (v2.0; v2.1; the circulated "v2.2" file) and MCC-100 Amendment 1 v1.0 SHALL be formally superseded and archived as uncontrolled historical records with superseded watermarks; their substance survives only as consolidated in this text.

26.4 Decisions validly taken under the predecessor texts before entry into force SHALL NOT be reopened by this Standard alone, except that any decision inconsistent with the prohibitions in clauses 16.10 to 16.13, 21.4 to 21.9 and 22.1 SHALL be reviewed and corrected.

---

End of MCC-100 version 3.0-draft. Status: DRAFT — FOR CONSULTATION. Not in force. Points the Programme has not decided, or on which it proposes a rule for comment, are listed under Consultation questions above and marked in the text.