MCC-SDCF — Sustainable Development Contribution Framework

Document control

Field	Value
Document code	MCC-SDCF
Title	Sustainable Development Contribution Framework
Version	2.0-draft
Status	DRAFT — FOR CONSULTATION
Date of this draft	3 September 2026
Tier	Tier 5 (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 14.2.
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	Conformity Review CR-2026-001 of 3 September 2026, within the revision ordered by Founder Decision FD-2026-09-03. 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	MCC-SDCF v1.0 (March 2026), on entry into force.
Language convention	British English; RFC-style normative verbs (SHALL/MUST = mandatory; SHOULD = recommended, deviation to be documented; MAY = optional).
Classification	Public — consultation draft
Consultation period	30 days (FD-2026-10-01 Schedule 1, C4), from the opening recorded on the consultation register (FD-2026-09-04 item 2; FD-2026-10-01 item 5)

Why this is a rewrite and not an amendment

Conformity Review CR-2026-001 found MCC-SDCF v1.0 non-conforming against the revised normative suite, with five blocking findings. Amendment would have required rewriting Sections 1, 2, 6, 7, 8 and 9 of the predecessor — most of the document — because the defect that matters ran through all of them: the predecessor attached sustainable-development obligations to methodology codes, three of which (M007, M009, M010) have never existed, and used family names the programme does not use. A framework tied to a methodology portfolio breaks every time the portfolio changes. This version attaches obligations to families, which are stable.

Four further defects are corrected rather than carried:

• the predecessor asserted an issuance prerequisite (v1.0 cl. 0158–0159) that MCC-100 clause 0162 does not contain and the registry has never enforced. Section 10 states the position honestly;
• its flagship label could not be computed: three different tests existed for "MCC SD Gold" and two of them averaged different units. Section 8 states one test, once;
• it made claims about the market value of the programme's own credits — "premium pricing", "market recognition", a "registry ranking system" that does not exist. Every such statement is deleted; what the programme may say about credits issued under it is governed by the Claims and Use of Credits Policy v1.1 (adopted by FD-2026-08-24, recorded in the decision register as attested by the founder, with no executed copy filed) and, once it is made, by MCC-600 (the Claims Code);
• it created three governance bodies that are not among the seven. Section 12 assigns the functions to the Standards Committee.

Change history

Version	Date	Change	Instrument
1.0	March 2026	First text. Printed "Status: APPROVED". No signed approval instrument for MCC-SDCF v1.0 is in the programme record (document register: no adopting instrument recorded for MCC-SDCF v1.0).	None in the programme record
2.0-draft	3 September 2026	Full rewrite on the eight points of CR-2026-001. Family-level requirements; one label test; issuance position corrected; market-value claims removed; governance functions assigned to the Standards Committee, one of the seven bodies of MCC-700 v4.0-draft (not yet constituted); platform section reduced to obligations. Baseline discipline, causal-pathway test and ex-ante honesty requirements carried forward substantially as drafted.	CR-2026-001, under FD-2026-09-03

NOTE (non-normative). This document is issued for public consultation. Nothing in it asserts that any approval, accreditation, eligibility, registration, issuance, assessment, score or label exists unless a linked record is identified in the MCC Evidence Register. No sustainable- development assessment has ever been performed under this programme and no label has ever been awarded. 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 4.5 — the indicator library. Proposed: the library is built from the indicators of the first registered projects rather than written at adoption, because writing one now would fix indicators for ecosystems and geographies the Programme has never assessed; until it exists, clause 4.4 applies as a SHOULD and no project is prejudiced by the absence of a library. Basis: the drafting proposal under CR-2026-001; FDP-2026-001 Part 3; FD-2026-10-01 item 4. Decided by: the Governing Board on adoption of the suite. Comments are invited on whether a library should instead exist at adoption.

2. Clause 8.4 — the MCC SD Gold threshold. Proposed: the test at clause 8.3 — a score of 4 or higher on at least three indicators, spanning at least two Goals, with no indicator scoring below 3. The Board may prefer a stricter threshold, for example four indicators across three Goals, once the first assessments show what a realistic distribution looks like; no operational data exists on which to calibrate one today. Basis: the drafting proposal under CR-2026-001; FDP-2026-001 Part 3 (the SD Gold criterion); FD-2026-10-01 item 4. Decided by: the Governing Board on adoption of the suite. Comments are invited on whether the threshold is set at the right level.

3. Clause 10.4 — SD assessment as a registration condition. Proposed: not a condition for now: clause 10.2 applies at registration, and incompleteness is recorded and does not block registration, until the Programme has assessed enough projects to know what compliance costs a developer. An SD assessment is never an issuance condition (clause 10.1). Basis: the drafting proposal under CR-2026-001; FDP-2026-001 Part 3; FD-2026-10-01 item 4. Decided by: the Governing Board on adoption of the suite. Comments are invited on whether, and when, SD assessment should become a registration condition.

Table of contents

1. Purpose, scope and application
2. Normative references and definitions
3. Sustainable Development Goal alignment
4. Indicators
5. Baseline assessment and ex-ante estimation
6. Monitoring, reporting and verification
7. Scoring
8. Labels
9. Family requirements
10. Relationship to registration and issuance
11. Programme obligations
12. Governance, review and amendment
13. Transitional provisions
14. Entry into force

---

1. Purpose, scope and application

1.1 This Framework SHALL establish how a sustainable-development (SD) contribution is identified, measured, monitored, verified, scored and, where it qualifies, labelled.

1.2 This Framework is a Tier 5 instrument. Precedence is governed by MCC-001 Section 2, and nothing in this Framework SHALL be read as weakening a requirement of MCC-001, MCC-100, MCC-600 or MCC-700.

1.3 This Framework SHALL apply to every project registered under MCC-100, at every stage from project design to the end of the crediting period.

1.4 What an SD contribution is not. An SD contribution SHALL NOT change the quantity of units issued to a project. Units are issued on the quantified climate or conservation outcome under the applicable methodology; the SD assessment records what else the project does, and nothing about that assessment adds to, subtracts from, or conditions that quantity.

1.5 What this Framework does not do. This Framework makes no statement about the price, market value, marketability, buyer demand or comparative desirability of any unit, project or label. Any public statement concerning a unit is governed by MCC-600 (Claims Code) once it is made and, until then, by the Claims and Use of Credits Policy v1.1 (adopted, FD-2026-08-24); this Framework confers no permission to make one.

Drafting note (non-normative): the predecessor stated at cl. 0118, 0122, 0124 and 0034 that labels would enhance market recognition, be used in marketing materials, command premium pricing and feed a registry ranking system. A programme that certifies a credit and simultaneously promises that its certification raises the price of that credit has taken a position on the value of its own product. Clause 1.5 is the correction, and it sits in Section 1 rather than buried, because it changes what the whole document is for.

---

2. Normative references and definitions

2.1 This Framework SHALL be read with: MCC-001 (Charter and Constitution); MCC-100 (Programme Standard), in particular the registration workflow and the issuance prerequisites of clause 0162; MCC-200 (Methodology Framework) and the Methodology Template; MCC-400 (VVB Accreditation and Performance Standard); MCC-600 (Claims Code); MCC-700 (Governance and Appeals), in particular the Delegated Authority Matrix; and MCC-ESS (Environmental and Social Safeguards Policy).

2.2 Family means a methodology family F01 to F05 as defined in MCC-200 and adopted by FD-2026-09-03 item D2. Requirements in this Framework attach to families, not to individual methodologies.

2.3 Indicator means a quantified measure of a project outcome, with a defined unit, measurement method, baseline value and target value, capable of being verified from evidence.

2.4 SD contribution means an outcome of the project, additional to the outcome for which units are issued, that is measurable by one or more indicators and connected to project activities by a credible causal pathway.

2.5 Relationship to safeguards. A safeguard prevents harm; an SD contribution produces a benefit. Compliance with MCC-ESS is a condition of registration and SHALL NOT be counted, scored or labelled as an SD contribution under this Framework. Doing no harm is not a contribution.

Drafting note: the predecessor did not draw this line, and without it a project could score for meeting the safeguards floor that every project must meet.

---

3. Sustainable Development Goal alignment

3.1 SD contributions SHALL be expressed against the United Nations Sustainable Development Goals.

3.2 The Programme recognises three primary Goals across its portfolio: SDG 13 (Climate Action), SDG 14 (Life Below Water) and SDG 15 (Life on Land).

3.3 The Programme recognises six secondary Goals: SDG 1 (No Poverty), SDG 2 (Zero Hunger), SDG 5 (Gender Equality), SDG 6 (Clean Water and Sanitation), SDG 8 (Decent Work and Economic Growth) and SDG 11 (Sustainable Cities and Communities).

Drafting note: the predecessor announced eight secondary Goals at cl. 0013 and listed six. The list is corrected to what it was; adding two to reach the announced number would have been invention.

3.4 A project SHALL identify at least one primary Goal and at least two secondary Goals, and SHALL justify each by reference to its location, ecosystem, activity and beneficiaries.

3.5 A project MAY identify further Goals, each supported by indicators meeting Section 4.

3.6 A project SHALL NOT claim a contribution to a Goal without (a) at least one indicator meeting Section 4 and (b) a stated causal pathway from a project activity to the outcome the indicator measures.

3.7 A project SHALL NOT claim a contribution outside the geographic area of implementation or beyond the beneficiary population it identifies.

3.8 A project SHALL NOT claim a contribution that is required of it by MCC-ESS or by applicable law.

3.9 Where project scope, location or activity design changes materially, the project SHALL revise its Goal identification within 90 days and submit the revision with its next monitoring report.

---

4. Indicators

4.1 Each identified Goal SHALL carry at least one indicator.

4.2 An indicator SHALL state: its name; the outcome it measures; its unit; its measurement method; the frequency of measurement; its baseline value; its target value; and the party responsible for collecting it.

4.3 An indicator SHALL be capable of independent verification from evidence a third party can inspect. An indicator that can only be evidenced by the project's own assertion is not an indicator for the purposes of this Framework.

4.4 Indicators SHOULD be drawn from the Programme's indicator library where one covers the outcome, so that assessments are comparable across projects. Where a project defines its own indicator it SHALL state why no library indicator fits.

4.5 Whether the Programme maintains an indicator library at adoption, or builds it from the first registered projects' indicators, is not yet decided. This draft assumes the library is built from practice, because writing one now would fix indicators for ecosystems and geographies the Programme has never assessed. Interim rule until decided: clause 4.4 applies as a SHOULD and no project is prejudiced by the absence of a library. (Consultation question 1.)

4.6 Where an indicator measures a benefit to people, data SHALL be collected and reported disaggregated by gender.

---

5. Baseline assessment and ex-ante estimation

This Section is carried substantially from MCC-SDCF v1.0 clauses 0073 to 0084, which CR-2026-001 found sound and in places more demanding than comparable frameworks.

5.1 A project SHALL establish a baseline value for every indicator before project activities commence.

5.2 Where no data exists, the project SHALL establish a baseline by representative sampling or by a documented proxy, and SHALL state which it used and why.

5.3 Baseline data SHALL be collected within 12 months before commencement.

5.4 Baseline collection SHALL use the same measurement method the indicator will use for monitoring, so that later values are comparable.

5.5 A baseline report SHALL document: (a) the collection method and its quality assurance; (b) data sources; (c) limitations and confidence levels; (d) the names and qualifications of those who collected the data; and (e) the geographic and temporal scope of the data.

5.6 Community consultation SHALL be conducted during baseline assessment, and the indicators selected SHALL reflect what that consultation records as local priorities. Where a project selects an indicator the consultation did not support, it SHALL say so and why.

5.7 The baseline report SHALL form part of the Project Design Document and SHALL be available to the validation body.

5.8 A project SHALL submit ex-ante estimates of expected contribution for every indicator.

5.9 Ex-ante estimates SHALL be based on the activity design and timeline, credible reference data from comparable projects or scientific literature, an analysis of the beneficiary population, and stated context-specific assumptions.

5.10 Ex-ante estimates SHALL be conservative.

5.11 Ex-ante estimates SHALL be distinguished from aspirational or hypothetical benefits, and SHALL state confidence levels and uncertainty ranges.

5.12 A project SHALL document the basis of every assumption, including data sources, any expert judgement relied on, and sensitivity analysis where an estimate is sensitive to an assumption.

---

6. Monitoring, reporting and verification

6.1 A project SHALL measure every indicator at the frequency its indicator definition states, and at least annually.

6.2 SD monitoring data SHALL be submitted as part of the routine monitoring report, not as a separate submission.

6.3 Each submitted value SHALL carry: the date of collection, the source, the method used where it differs from the baseline method, and a confirmation that the project's quality assurance was applied.

6.4 Where a project cannot collect an indicator in a period, it SHALL report the gap and its cause rather than omit the indicator. An omitted indicator SHALL be treated as not achieved.

6.5 SD contributions SHALL be verified by an accredited validation and verification body.

6.6 The same body MAY verify both the climate or conservation outcome and the SD contribution, provided that SD assessment is within its accreditation scope under MCC-400. A body without that scope SHALL NOT verify an SD contribution, and MCC-400 SHALL record SD assessment as a scope that is applied for and granted separately.

Drafting note: the predecessor assigned both to the same body at cl. 0162 without asking whether the body was competent to do the second. The efficiency is real and is kept; the condition is new.

6.7 The verification body SHALL, for each indicator: confirm the measurement method was applied; inspect the underlying evidence; state whether the reported value is supported; and record its reasoning.

6.8 A verification opinion on an SD contribution SHALL be recorded as a typed value, in the same manner as a verification opinion under MCC-100.

---

7. Scoring

7.1 Each indicator SHALL be scored, on verification, on a scale of 1 to 5.

7.2 Scoring SHALL be against the target, as follows:

Score	Achievement against the ex-ante target
1	Less than 25%
2	25% to below 50%
3	50% to below 75%
4	75% to below 90%
5	90% or more

Drafting note: the predecessor defined each band twice — a change against baseline or an achievement against target — and the two diverge whenever a target is conservative or ambitious. Because clause 5.10 requires conservative estimates, the second limb mechanically rewarded the more conservative estimator. Scoring is now against the target only, and the conservatism of the target is assessed at validation, where it belongs.

7.3 A score SHALL be reduced by one band, to a minimum of 1, where the verification body finds that the target was set so low that its achievement does not represent a meaningful contribution. The body SHALL record its reasoning.

7.4 A score of 4 or 5 SHALL additionally require the verification body to confirm that the benefit is expected to persist beyond the crediting period, through an institutional arrangement, a contractual commitment or a self-sustaining mechanism. The durability classes of MCC-BPM apply to this assessment where the benefit is of a kind they cover.

7.5 Scores SHALL be assigned by the verification body, not by the project or the Programme, and SHALL be documented with the reasoning for each.

7.6 A score SHALL NOT be assigned for a period in which the indicator was not measured.

---

8. Labels

8.1 The Programme awards two labels, and no others.

8.2 MCC SD Verified. A project SHALL be awarded this label where every identified indicator has been verified and scored, and no indicator scores below 3.

8.3 MCC SD Gold. A project SHALL be awarded this label where it achieves a score of 4 or higher on at least three indicators, spanning at least two Goals, with no indicator scoring below 3.

Drafting note: this is the single most important correction in the document. The predecessor carried three different tests for the same label — its clause 0119 averaged across indicators, its clause 0120 averaged across Goals, and MCC-100's predecessor clause 0093 required a score of 4 or higher on five or more indicators. The three produce different answers on the same project, and two of them average different units. The test here is a floor rather than an average, because an average lets a strong indicator carry weak ones, which is exactly what a label should not permit. The competing statement is deleted from MCC-100 v3.0 by the change recorded in that document.

8.4 The Board may prefer a stricter Gold threshold — for example four indicators across three Goals — once the first assessments show what a realistic distribution looks like. No operational data exists on which to calibrate a threshold today. The test at clause 8.3 is the consultation proposal and is confirmed or varied on adoption. (Consultation question 2.)

8.5 A label SHALL be recorded against the project in the registry, with the verification that supports it and the date it was awarded.

8.6 A label SHALL be withdrawn where a subsequent verification finds the qualifying condition no longer met. The project SHALL have 12 months to remedy before withdrawal takes effect, unless the finding is that a previous claim was false, in which case withdrawal is immediate.

8.7 A false or unsubstantiated SD claim is a breach of MCC-600 and is dealt with under that Code and under the enforcement provisions of MCC-100, not under this Framework. Until MCC-600 is made, such a claim falls under the Claims and Use of Credits Policy v1.1 (adopted, FD-2026-08-24), which prohibits misleading co-benefit claims (Article 4.3).

8.8 The Programme SHALL verify, by sampling, at least one labelled project each year, or 10% of labelled projects, whichever is greater.

Drafting note: the predecessor required 10% and no floor, which rounds to nothing on a small portfolio.

8.9 A label states what a project achieved against its own targets. It is not a rating, a ranking, or a comparison between projects, and the Programme SHALL NOT publish one.

---

9. Family requirements

9.1 Each family SHALL have primary Goals and a minimum indicator set, stated in this Section. Requirements attach to families; a methodology SHALL NOT vary them.

9.2 A methodology MAY require additional indicators for its activity type, recorded in the methodology under the Methodology Template.

Family	Primary Goals	Minimum indicator set
F01 Blue Carbon Sequestration	SDG 13, SDG 14	(a) habitat area restored or protected; (b) a water-quality measure appropriate to the habitat; (c) one benefit-to-people indicator
F02 Ecosystem Restoration	SDG 13, SDG 14, SDG 15	(a) habitat area restored; (b) a biodiversity measure; (c) one benefit-to-people indicator
F03 (no methodology at the date of this draft)	SDG 14, SDG 15	To be stated when the family's first methodology is drafted
F04 Marine Gear and Pollution	SDG 14, SDG 6	(a) quantity of material removed or prevented from entering the marine environment; (b) an ecosystem-health measure appropriate to the activity; (c) one benefit-to-people indicator
F05 MPA Management	SDG 14, SDG 11	(a) area under effective management; (b) a biodiversity or stock measure; (c) one benefit-to-people indicator

9.3 The "benefit-to-people" indicator SHALL be selected by the project from its identified secondary Goals and SHALL be appropriate to its context.

Drafting note: the predecessor prescribed the benefit-to-people indicator per family — F04 projects were required to quantify "avoided health impacts through reduced water-borne disease incidence or air quality improvements" (v1.0 cl. 0146). Both live projects in F04 are ghost-gear recovery, and neither has a water-borne disease pathway; applied literally, the pilot could not satisfy its own mandatory indicators. The family now states the category and the project selects the measure.

9.4 F03 carries no indicator set because no methodology exists in that family. Nothing in this Framework SHALL be read as implying that F03 is open for registration.

9.5 The five families are recorded with a decision reference and an explicit boundary each, all under FD-2026-09-03 item D2. That reference epoch is not yet in force — the founder decision binds the programme now, while the rewritten suite expressing it is a consultation draft. If the MCC-200 consultation varies the names or boundaries, this table follows them.

---

10. Relationship to registration and issuance

10.1 An SD assessment is not a prerequisite to issuance. The prerequisites to issuance are those stated at MCC-100 clause 0162, and that list is exhaustive. Nothing in this Framework adds to it.

Drafting note: this is the correction of the predecessor's clauses 0158 and 0159, the second of which read "Projects shall not receive credits unless SD assessment documentation is complete and verified." MCC-100 clause 0162 has never contained an SD gate and the registry has never enforced one. A framework that states an issuance condition the programme does not apply misleads every reader who relies on it — in this case into believing that every issued unit carries a verified SD assessment.

10.2 A project SHALL submit its Goal identification, its indicators and its baseline as part of its Project Design Document at registration.

10.3 A project that has not completed an SD assessment SHALL NOT be awarded a label, and the registry SHALL show no label rather than a provisional or pending one.

10.4 Whether SD assessment should become a registration condition — not an issuance condition — once the Programme has assessed enough projects to know what it costs a developer to comply is not yet decided. Making it a condition today, with no completed assessment anywhere in the portfolio and no indicator library, would impose an untested burden. Interim rule until decided: clause 10.2 applies at registration; incompleteness is recorded and does not block registration. (Consultation question 3.)

---

11. Programme obligations

This Section states what the Programme must do. It does not specify how the platform is built: the predecessor's Section 8 named four database entities and five groups of API endpoints in "shall" language, of which roughly a third was ever built, so the framework was in breach of itself from the day it was printed.

11.1 The Programme SHALL record, for each project: its identified Goals; its indicators with their definitions, baselines and targets; each reported value with its date and source; each verified score; and each label with the verification supporting it.

11.2 The Programme SHALL publish, for each registered project: its identified Goals; its indicators and their current values against target; its label status; and the date and body of the most recent verification.

11.3 The Programme SHALL make the data at clause 11.2 available through its public interface, in the same manner as other registry data.

11.4 The Programme SHALL alert the responsible function where a project has not submitted SD monitoring data by its deadline.

11.5 The Programme SHALL retain SD assessment data for the period stated in the Record Retention Schedule.

11.6 The Programme SHALL publish annually, in aggregate: the number of projects assessed, the distribution of scores, and the number of labels awarded and withdrawn. It SHALL NOT publish an aggregate that implies a portfolio-level impact claim.

11.7 Where the Programme has assessed no project, clause 11.6 is satisfied by publishing that fact.

---

12. Governance, review and amendment

12.1 The Standards Committee SHALL be responsible for: this Framework and its review; the indicator library where one is maintained; and the award and withdrawal of labels.

12.2 A decision to award or withdraw a label SHALL be appealable to the Independent Appeals Panel under MCC-700.

Drafting note: the predecessor created three bodies — a "Sustainable Development Expert Panel" (cl. 0170), an "MCC Methodologies Panel" (cl. 0134) and a "methodology expert panel" (cl. 0025) — none of which is among the seven governance bodies, and two of which may have been the same body under different names. MCC-700 v4.0 clause 19.2 records the institutional home of SD certification as an open decision; this clause is the proposal that resolves it.

12.3 The Standards Committee MAY appoint external advisers to a review, and SHALL record who advised and on what.

12.4 This Framework SHALL be reviewed when the Programme has completed ten SD assessments, or after three years, whichever is sooner.

Drafting note: the predecessor required annual review, five-yearly comprehensive review, three- yearly third-party evaluation, annual stakeholder webinars and an annual standards document. For a programme with no completed assessment, that is a calendar of obligations no one will meet, and an unmet obligation in a standard is worse than none. Review is triggered by evidence instead.

12.5 A review SHALL consider: whether the indicators are measuring what they were chosen to measure; whether the scoring bands distribute sensibly across real projects; whether the label thresholds are set correctly; and what respondents and project developers report about the cost of compliance.

12.6 This Framework SHALL NOT state an obligation to align with, benchmark against, or be assessed under any external standard.

Drafting note: the predecessor committed the Programme at cl. 0009 to alignment with "the Gold Standard Frameworks and Verra SD VISta methodology" and at cl. 0177 to five-yearly benchmarking against them. That is a standing obligation to a third party's proprietary standard the Programme does not control and may lose access to, and alignment with a standard the Programme does not own is a claim it cannot verify. Where a provision here is drawn from an external source, the source is cited in the change log as a source, not as a commitment.

12.7 Amendment of this Framework follows the Tier 5 procedure under MCC-001 and the Rule Change and Public Consultation Procedure.

---

13. Transitional provisions

13.1 At the date of this draft: no SD assessment has been performed; no indicator has been defined for any project; no score has been assigned; and no label has been awarded. Nothing in this Framework is applied retrospectively, because there is nothing to apply it to.

13.2 MCC-SDCF v1.0 remains published as the superseded text with Conformity Review CR-2026-001 attached, so that a reader can see what changed and why.

13.3 No sustainable-development label SHALL be awarded, and no sustainable-development claim SHALL be made in any Programme communication, until this Framework enters into force.

13.4 A project registered before entry into force SHALL submit its Goal identification, indicators and baseline within 180 days of entry into force, or with its first monitoring report, whichever is later.

13.5 The registry holds no sustainable-development contribution record, no indicator and no label. The registry holds two project submissions, both at SUBMITTED, and neither has passed the completeness check (Evidence Register ER-2026-001 §A1, §A3).

---

14. Entry into force

14.1 This Framework is a draft for consultation and is not in force.

14.2 It enters into force on the date stated in the decision adopting it, following the Tier 5 notice period and the decision, on adoption, of every consultation question in this document.

14.3 On entry into force it supersedes MCC-SDCF v1.0 in its entirety.

---

End of MCC-SDCF version 2.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 and marked in the text.