MCC-CADCP — Corresponding Adjustment and Double Counting Prevention Policy

Document control

Field	Value
Document code	MCC-CADCP
Title	Corresponding Adjustment and Double Counting Prevention Policy
Version	2.0-draft
Status	DRAFT — FOR CONSULTATION
Date of this draft	3 September 2026
Tier	Tier 3 (Document Hierarchy & Precedence Register, per FD-2026-09-03 item D5 — the "Tier 3 double-counting standard" cited by MCC-001 clause 5.9 and MCC-100 clause 17.7)
Effective date	None. This document is not in force. It takes effect only on approval under clause 12.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; tabled for ratification by the Governing Board), item D3 in particular. 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 Corresponding Adjustment and Double Counting Prevention Policy v1.0 (printed "MCC-CADCP-v1.0", March 2026, status APPROVED) — reclassified by FD-2026-09-03 item D5; the document register records v1.0 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", "CA_EVIDENCE_RECORDED").
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)

Baseline declaration

1. The predecessor v1.0 was one of the seven corpus documents printed "APPROVED" with no document-control apparatus at all — no version table, owner, approval body, decision record or effective date (Phase 0 source inventory). No signed approval instrument for the predecessor is in the programme record (Evidence Register ER-2026-001 §B3).
2. The independent audit of 3 September 2026 assessed the predecessor as "the highest legal/accounting-risk policy in the suite" requiring "a substantive rewrite, not line editing" (audit §5.9), with critical findings CA-01 to CA-08 and its central role in SYS-07 (Article 6.2/6.4 conflation).
3. This version 2.0-draft is accordingly a substantive rewrite, not a line edit: the corresponding-adjustment model of v1.0 (a CA calculated by MCC, executed at retirement, and instructed to host countries) is replaced in full by the voluntary-first Article 6 attribute model of FD-2026-09-03 item D3 and canonical control table 5. The predecessor PDF is reclassified by FD-2026-09-03 item D5; its withdrawal as a controlled copy, and its archiving as a superseded record, are executed when this version is adopted (clause 12.3).

Change history

Version	Date	Change	Instrument
1.0	March 2026 (printed)	Base text; printed status APPROVED; no document-control table	No such instrument is in the programme record (Evidence Register ER-2026-001 §B3).
2.0-draft	3 September 2026	Substantive rewrite against audit findings SYS-07 and CA-01 to CA-08 and Founder Decisions FD-2026-09-03 D1–D8: correct Article 6 definitions; voluntary-first attribute model in place of the CA-at-retirement model; the four legacy CA-status models retired with a mapping (Annex A and the change log); transfer escrow abolished; overlap test replacing the absolute exclusive-registration ban; risk-based cross-programme checks replacing mandated external APIs; enforcement limited to Programme participation; technology stack and platform data-model clauses removed to MCC-800 and the Information Security Standard	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, transfer, retirement or operational history exists unless a linked record is identified in the MCC Evidence Register. The Consultation questions section below states how each point the drafting left open is answered.

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.

No point is listed for this draft. Each point its drafting left open is stated in the text with the programme record's answer and its source; for clause 12.7 the record answers only as to the registry (Evidence Register ER-2026-001 §A3). Comments on any part of the text are invited; the Governing Board decides on adoption of the suite.

Table of contents

1. Purpose, scope and application
2. Normative references, definitions and interpretation
3. Double-counting prohibitions
4. Registry-level controls
5. Programme-level controls against double issuance and double registration
6. Cross-programme integrity checks
7. Claiming and use rules per instrument
8. Corresponding adjustments and Article 6 attributes
9. Transparency and disclosure
10. Enforcement
11. Amendments
12. Transitional provisions and entry into force Annex A — Retired corresponding-adjustment status models and their migration (normative)

---

1. Purpose, scope and application

1.1 This Policy (MCC-CADCP) SHALL establish the Programme-wide framework for preventing double counting of MCC units and outcomes, and for recording Article 6 corresponding-adjustment evidence under the voluntary-first attribute model adopted by FD-2026-09-03 item D3.

1.2 This Policy SHALL apply to every project, unit, label, participant, registry operation and public communication of the MCC Programme, for every instrument (MCC-CC, MCC-MOU and MCC-CB label).

1.3 This Policy is a Tier 3 instrument under the Document Hierarchy & Precedence Register; precedence is governed by MCC-001 Section 2, and this Policy implements — and SHALL NOT weaken — MCC-001 clause 5.9, MCC-001 Section 8, MCC-100 Sections 16 and 17 and MCC-700 Section 17.

1.4 Where this Policy refers to another MCC document, form, tool or register, the reference SHALL be read against the Document Hierarchy & Precedence Register; a requirement of this Policy 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 Policy are not yet published under document control: MCC-600 (Claims Code), the rewritten MCC-800 (Registry Operations), the versioned serial specification, the Record Retention Schedule, the Information Security Standard, the registry data dictionary, and the conformed Host Country Authorisation Procedure (MCC-HCA v2.0-draft, put to consultation with this suite). Each dependent requirement is deferred under clause 1.4, never silently effective. The predecessor's "International Transfer Registry", "Host Country Classification Register" and "Enforcement Actions Registry" are not carried as instruments of this Policy (see the change log).

1.5 This Policy states control objectives and Programme rules; registry implementation (data model, fields, workflows, interfaces and security) is governed exclusively by MCC-800, the registry data dictionary and the Information Security Standard, and this Policy states no technology choice, database design, protocol, availability figure or security parameter.

2. Normative references, definitions and interpretation

2.1 Terms used with initial capitals in this Policy SHALL have the meanings assigned in the MCC Definitions Register, which is in force as MCC-100 Annex 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 Policy; each numbered clause states one testable requirement; text introduced by "NOTE" or "GUIDANCE" is non-normative.

2.3 The following Article 6 terms SHALL be used in this Policy and in every Programme document, registry text, certificate and communication only with the meanings below, which follow the authoritative UNFCCC terminology:

2.3.1 Authorization — a participating Party's formal authorization of mitigation outcomes for a stated Article 6 use or purpose under the applicable Article 6 rules.

2.3.2 Internationally transferred mitigation outcome (ITMO) — a mitigation outcome authorised by a participating Party for use towards Article 6.2 purposes and subject to the applicable first-transfer, reporting and accounting rules of the Article 6.2 guidance; a cross-border transfer of a unit is not, of itself, an ITMO.

2.3.3 First transfer — the event defined for the authorised mitigation outcome and use under the Article 6.2 guidance and the Party's authorization; the first-transfer trigger is selected and reported under the authorization framework by the participating Parties, never by MCC.

2.3.4 Corresponding adjustment (CA) — an accounting adjustment applied and reported by a participating Party under the Article 6 rules; MCC records evidence of it but does not perform it.

2.3.5 A6.4ER — an Article 6.4 emission reduction issued under the UNFCCC Article 6.4 mechanism; an MCC-issued unit is not an A6.4ER.

2.3.6 Retirement — permanent removal of a unit from circulation for a stated beneficiary and purpose; it does not itself create Article 6 authorization or a corresponding adjustment.

2.3.7 Cancellation — permanent removal of a unit for a reason other than the beneficiary claim, including buffer compensation, error correction or administrative action.

NOTE — GENERATED CONTENT. Clauses 2.3.1 to 2.3.7 reproduce their single sources: the canonical terminology adopted through FD-2026-09-03 (audit Appendix A) and the Article 6 drafting rules of audit §8, as restated in MCC-001 Section 8 and MCC-700 clause 17.6 — verbatim in substance, with clause 2.3.2's second limb ("a cross-border transfer of a unit is not, of itself, an ITMO") added as this Policy's express correction of the predecessor's definition (finding CA-01). On any divergence in the reproduced content, the source prevails and this reproduction is corrected; no local variation is permitted.

2.4 The predecessor's definitions of "Corresponding Adjustment" (a reduction in mitigation credits calculated within the MCC framework), "ITMO" (any cross-border transfer of credits) and "Buying Country" are retired and SHALL NOT be used in any Programme document (finding CA-01); Party accounting concepts and Programme registry metadata SHALL be kept separate in all drafting.

2.5 In this Policy, "external programme" means any environmental crediting programme, registry or attribute-generating scheme other than the MCC Programme, including the UNFCCC Article 6.4 mechanism registry, independent crediting programmes and national or regional compliance schemes.

3. Double-counting prohibitions

3.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.

3.2 The following SHALL be prevented and are prohibited:

3.2.1 double issuance — issuance of more than one unit, in any programme, for the same outcome;

3.2.2 double use — more than one use or retirement of the same unit;

3.2.3 double claiming — assertion of the same environmental benefit by more than one party, subject to the claim rules of MCC-600; and

3.2.4 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.

NOTE — GENERATED CONTENT. Clauses 3.1 and 3.2 reproduce verbatim their single sources, MCC-001 clause 5.9 and MCC-100 clauses 17.1 and 17.2; MCC-100 Section 17 is the Tier 2 statement of these prohibitions and this Policy is their Tier 3 operative control framework (MCC-100 clause 17.7). On any divergence, the source prevails and this reproduction is corrected; no local variation is permitted.

3.3 The controls of this Policy SHALL be applied so that each prohibited form in clause 3.2 is addressed by at least one registry-level control (Section 4), one programme-level control (Section 5 or 7) and one detection mechanism (Section 6), as mapped in the table in clause 3.4.

3.4 The control mapping is:

Prohibited form	Primary preventive control	Primary claim/accounting control	Detection
Double issuance	Unique project identification and overlap test (clauses 5.1–5.6)	Ex-post issuance only against verified outcomes (MCC-100 Section 19)	Cross-programme checks (Section 6)
Double use	Serial uniqueness, single ownership and retirement finality (Section 4)	Retirement-based claims only (clause 7.2)	Registry reconciliation and audit (clause 4.6)
Double claiming	Article 6 attribute recording (Section 8)	Claims Matrix and MCC-600 rules per instrument (Section 7)	Claims monitoring (MCC-100 clause 21.12)
Double registration	Participation declarations and overlap reconciliation (clauses 5.3–5.6)	Registration refusal absent cancellation/transition evidence (clause 5.5)	Cross-programme checks (Section 6)

4. Registry-level controls

4.1 The registry-level double-counting controls SHALL be implemented in the MCC Registry under MCC-800; this Section states the control objectives those controls MUST satisfy and does not restate their implementation.

4.2 Serial uniqueness. Every issued unit SHALL carry exactly one serial, assigned in an immutable batch serial range under the versioned serial specification made under MCC-800; no serial SHALL ever be reassigned or reused, including after retirement or cancellation (MCC-100 clauses 4.12 and 19.5).

4.3 Single ownership. Every unit SHALL have, at all times, exactly one account holder of record, recorded at serial-range level (MCC-100 clause 4.14); no transfer SHALL be executed except from the recorded holder's account under the transfer controls of MCC-800.

4.4 Retirement finality. Retirement SHALL be permanent and irreversible, and a retired unit SHALL never be transferred, re-issued or recirculated (MCC-100 clause 21.1); cancellation SHALL be equally permanent and recorded with its reason (MCC-100 clause 21.2).

4.5 Status integrity. A unit under dispute, investigation, suspension or legal hold SHALL be flagged in the registry and SHALL NOT be transferred or retired while the flag stands; flag decisions and their lifting follow the decision rights of MCC-700 Annex A.

4.6 Audit trail and reconciliation. Every unit status change SHALL be captured in the immutable registry audit trail, and registry reconciliation and independent audit SHALL be performed as MCC-800 and MCC-700 clauses 4.8.2 to 4.8.3 require; a duplicate-retirement or duplicate-serial finding SHALL be escalated to the Registry Oversight Committee and processed under Section 10.

4.7 No mechanism SHALL exist in the registry by which the same serial appears in more than one retirement or cancellation event; batch retirements SHALL be validated for serial uniqueness before execution under MCC-800.

NOTE. The predecessor's implementation prescriptions — distributed-ledger serial generation, blockchain ledger, cryptographic hashing schemes, multi-signature authorisation, OAuth 2.0, recovery-time objectives and annual penetration-test scheduling (v1.0 clauses 0030–0055, 0126–0145) — are removed from this Policy: technology choices belong to the registry architecture under MCC-800 and the Information Security Standard, not to a Tier 3 policy (audit §6.3; finding CA-06 noted the blockchain language contradicted the actual database design). The control objectives above are preserved; their implementation evidence is an obligation on MCC-800.

5. Programme-level controls against double issuance and double registration

5.1 Every project SHALL receive, at first submission, a unique project identifier that SHALL be retained unchanged for the life of the project and used in every registry record, serial and public display concerning it.

5.2 The project boundary, activity, crediting period and credited outcome metrics recorded at registration SHALL be the reference data against which every overlap assessment under this Section is performed.

5.3 Participation declaration. The project proponent SHALL declare, at submission and annually thereafter, every registration, application, credit issuance or attribute-generating arrangement for the project activity or its boundary in any external programme, including arrangements that have ended (MCC-100 clauses 6.3 and 17.5).

5.4 A false or incomplete participation declaration SHALL be a material breach processed under Section 10; the declaration SHALL be certified by the proponent and updated within thirty calendar days of any change.

5.5 Overlap test. A project with any prior or concurrent external-programme participation SHALL be eligible for registration only where the proponent evidences, for every overlapping outcome, boundary, period and metric, one of: (a) de-registration, cancellation or transition from the external programme; or (b) that the outcomes credited under each programme are distinct in activity, boundary, period or outcome metric; 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 (MCC-100 clause 17.4).

NOTE. This replaces the predecessor's absolute exclusive-registration model (v1.0 clauses 0026–0029 and 0040: a bar on any project that "previously generated" credits anywhere, an exclusivity affidavit and a single-programme declaration binding for the project lifetime). That model was overbroad (finding CA-05): it barred legitimate programme transitions and attribute stacking on distinct outcomes, while the real integrity test is same activity, same boundary, same period, same outcome metric. Legitimate finance stacking is governed by MCC-100 clause 17.3 and is not a double-counting event.

5.6 A transition from an external programme SHALL be evidenced by the external programme's own records (de-registration confirmation, cancellation statement or equivalent documentary evidence), linked in the Evidence Register; the proponent's assertion alone SHALL NOT suffice.

5.7 Issuance for any monitoring period SHALL be refused to the extent the same outcome for that period has been issued in an external programme, irrespective of the registration position.

5.8 Where a credited activity could plausibly be claimed within another party's inventory, product claim or value chain, the methodology and the Project Design Document SHALL identify the exposure, and the claim-side treatment SHALL follow Section 7 and MCC-600.

6. Cross-programme integrity checks

6.1 The Programme SHALL operate risk-based cross-programme duplicate checks for every project: at registration, at least annually thereafter, and before the first issuance of each monitoring period.

6.2 Cross-programme checks SHALL use, in order of availability: (a) the public registries and published project lists of external programmes; (b) documentary evidence supplied under clauses 5.3 to 5.6; and (c) data received under any interoperability arrangement in force under clause 6.4.

6.3 A check SHALL compare, at minimum: project location and boundary; activity type; proponent and related parties; crediting or monitoring period; and claimed outcome metrics.

6.4 MCC MAY enter into bilateral data-sharing or interoperability arrangements with external programme operators; such arrangements SHALL be recorded in the Document Register, and no clause of this Policy SHALL be read as imposing any obligation on an external programme or registry.

NOTE. The predecessor mandated nightly automated API checks against named external registries, subscription to "all external programme registries", monthly coordination calls, and joint determinations binding on other programmes (v1.0 clauses 0037–0038, 0106–0124). MCC cannot unilaterally mandate the conduct of external registries or operators (finding CA-06); this Section substitutes risk-based checks on public records, voluntary bilateral arrangements, and the escalation procedure below.

6.5 A suspected duplicate SHALL be escalated to the Programme Secretariat's compliance monitoring function, which SHALL open an investigation record, place an issuance hold on the affected project or units, and notify the proponent, within five business days of the flag.

6.6 The investigation SHALL be completed within sixty calendar days where the evidence permits; where cooperation of an external programme operator is sought, MCC SHALL invite it and record the response, and the investigation deadline MAY be extended with reasons notified to the proponent.

6.7 A confirmed double registration or double issuance SHALL be processed under Section 10, including cancellation of affected units on a defect finding under MCC-100 clause 23.5.

6.8 The cross-programme check performed for each project, its date, sources consulted and outcome SHALL be recorded and retained per the Record Retention Schedule, and the current outcome SHALL be displayed on the public project record as a factual statement (checked date and result; no warranty of absence of duplication).

7. Claiming and use rules per instrument

7.1 Every public claim concerning an MCC unit or label SHALL conform to the Claims Matrix (canonical control table 6) and, once in force, MCC-600; this Section states the double-counting constraints per instrument and creates no claim wording.

7.2 MCC-CC. A use claim on an MCC-CC 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, and no unit SHALL support more than one beneficiary claim (MCC-100 clauses 21.7 and 21.1).

7.3 MCC-MOU. An MCC-MOU SHALL support contribution and outcome claims only; no offsetting, compensation, carbon-neutral, net-zero or tonne-equivalence claim SHALL be made on an MCC-MOU by any party, and an MCC-MOU outcome SHALL NOT be counted towards any GHG quantity (MCC-100 clause 21.8).

7.4 MCC-CB label. An MCC-CB label SHALL be claimed only together with, and within the scope of, the specific MCC-CC or project record it is attached to; a label SHALL NOT be claimed, transferred or marketed separately, and the verified co-benefit SHALL NOT additionally be claimed as a standalone outcome.

7.5 Split-ledger projects. Where a project produces both a GHG result and a marine-outcome result in separate ledgers (MCC-100 clause 5.9), a claim on one ledger's units SHALL NOT assert or imply the other ledger's outcome; the same physical intervention SHALL NOT be claimed twice through its two ledgers.

7.6 Host-country accounting overlap. For a unit whose Article 6 authorization attribute is NOT_AUTHORIZED, the Programme SHALL disclose on the registry record and retirement certificate that the underlying mitigation outcome remains within the host country's national accounting; buyer-side claim wording for this situation SHALL be governed by MCC-600, and no Programme text SHALL describe such a unit as conveying an emission reduction "outside" or "adjusted out of" the host country's inventory.

7.7 Value-chain and Scope 3 claims. MCC-600 SHALL define the rules under which value-chain (Scope 3) and product-level claims referencing MCC units are permitted, including the disclosure and no-overstatement conditions that prevent the same benefit being claimed by more than one entity in a value chain; until MCC-600 is in force, no such claim SHALL be made (MCC-100 clause 21.5).

7.8 Buyers SHALL receive, before completing a transfer or retirement, the factual Article 6 attribute statement of the units concerned per Section 8; a buyer acknowledgement SHALL be recorded for retirements once retirement functionality is enabled under MCC-100 clause 21.4.

7.9 No claim, in any jurisdiction or scheme, SHALL be represented by MCC as satisfying a regulatory obligation of the claimant; the eligibility of a unit under any external scheme SHALL be stated only per clause 8.10.

8. Corresponding adjustments and Article 6 attributes

The attribute model

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

8.2 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 (canonical 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.

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

8.4 A corresponding adjustment is an accounting action performed and reported by a participating Party under the Article 6 rules (MCC-700 clause 17.6, the single source of this rule); MCC SHALL NOT perform, calculate, instruct, trigger, require or purport to bind any Party's corresponding adjustment or reporting, at retirement or otherwise.

NOTE. This extinguishes the predecessor's core model: v1.0 clauses 0056–0064 placed the corresponding adjustment "at the point of credit retirement", had MCC "record the corresponding adjustment", required host countries to "implement corresponding adjustments … and report … to the UNFCCC on an annual basis", and had MCC supply sovereign states with implementation templates (findings SYS-07, CA-01, CA-02). None of that follows the Article 6 architecture, in which the adjustment is the Party's own accounting act under the Party-selected and Party-reported first-transfer trigger.

The evidence-recording procedure

8.5 The evidential intake and verification steps for host-country and Article 6 instruments SHALL follow the Host Country Authorisation Procedure (Tier 5), which SHALL conform to this Section, to MCC-100 Section 16 and to control table 5.

8.6 An Article 6 attribute SHALL be set or changed only by the following procedure, in order: (a) receipt of the documentary instrument or extract; (b) authenticity and scope verification under the Host Country Authorisation Procedure; (c) linkage of the document in the Evidence Register; (d) mirroring of the attribute value and document reference to the registry record of the affected units or batches; and (e) notification to affected holders where MCC-100 clause 16.14 requires it.

8.7 The corresponding-adjustment reporting evidence attribute SHALL take only the values NO_EVIDENCE (default) and CA_EVIDENCE_RECORDED; it SHALL be set to CA_EVIDENCE_RECORDED only where the Party's Article 6 reporting extract, or equivalent documentary evidence of the Party's reported adjustment, is linked in the Evidence Register, mirrored to the registry record, with the document reference and reporting round stated.

8.8 The label "CA-Confirmed", and any attribute setting on the basis of a stated intention, promise, category, classification or expectation of future implementation, SHALL NOT be used (MCC-700 clause 17.7).

8.9 The first-transfer definition applicable to authorised units SHALL be recorded verbatim as the Party has selected and reported it under the cooperative approach; the first-transfer event SHALL be recorded as OCCURRED only upon a registry transaction matching that recorded definition, with the date and transaction reference; MCC SHALL NOT select, construe beyond its text, or apply by analogy any first-transfer definition.

8.10 Scheme eligibility (including CORSIA) SHALL be recorded only upon a scheme decision covering the exact programme, unit and vintage scope, linked in the Evidence Register; no eligibility SHALL be inferred from any host-country, authorization or corresponding-adjustment attribute (MCC-100 clause 16.12).

8.11 No MCC unit SHALL be labelled, marketed or described as an A6.4ER or as any Article 6.4 unit, and no Programme text SHALL describe any MCC process as conferring, converting into, or providing a pathway to Article 6.4 status (MCC-100 clause 16.13).

8.12 Changes to any recorded Article 6 attribute, including a Party's revocation or withdrawal of an authorization, SHALL be recorded with the underlying instrument within ten business days of receipt, and affected unit holders notified (MCC-100 clause 16.14).

NOTE — GENERATED CONTENT. Clauses 8.1 to 8.4 and 8.7 to 8.12 reproduce their single sources: the Article 6 Attribute/Status Matrix (canonical control table 5, adopted under FD-2026-09-03 item D3), MCC-700 clauses 17.1 and 17.4 to 17.8, and MCC-100 clauses 16.7 to 16.14 — verbatim in substance, except that clauses 8.6 and 8.9 state the operative recording procedure this Policy adds as the Tier 3 owner of the corresponding-adjustment control (steps (a)–(e), and the verbatim-recording and event-matching rules). On any divergence in the reproduced content, the source prevails and this reproduction is corrected; no local variation is permitted.

Transfers and sovereign action

8.13 Host-country and Article 6 attributes SHALL attach at unit or batch level and travel with the units through transfer; an ordinary account-to-account transfer SHALL NOT require any host-country confirmation, notification precondition or sovereign action, and no transfer SHALL be escrowed, time-locked or held pending a state's response, unless the Party's authorization instrument itself expressly conditions transfers of the authorised units, in which case the recorded condition SHALL be enforced as written.

NOTE. This abolishes the predecessor's escrow mechanism (v1.0 clauses 0048–0050 and 0077: every transferred credit held in restricted status for a minimum of 30 days pending "signed corresponding adjustment confirmation from the host country", with host-country confirmation "a binding condition for credit transfer finality"). Conditioning every private transfer on sovereign action was unworkable and wrong in law (finding CA-04): authorization status is a recorded attribute of the units, not a per-transaction sovereign approval.

8.14 MCC MAY, on request or under an arrangement with a Party, provide that Party with registry extracts concerning units linked to activities in its territory; such provision is a transparency service, SHALL be recorded, and SHALL NOT be represented as notification triggering, or evidence of, any accounting action.

8.15 A dispute between Parties concerning authorization, first transfer or corresponding adjustments SHALL NOT be adjudicated by MCC; MCC SHALL record the existence of the dispute against the affected units, flag them under clause 4.5 where integrity so requires, and otherwise await the Parties' resolution.

NOTE. The predecessor's inter-state dispute mechanism (v1.0 clauses 0078–0080: MCC decisions "binding on both parties" within 60 days) exceeded any authority a private programme can hold over sovereign states (findings CA-02, CA-07) and is not carried.

9. Transparency and disclosure

9.1 The registry SHALL display for every unit and batch the factual Article 6 attributes per control table 5, in the display form fixed by MCC-800 and MCC-100 clause 20.4; the display SHALL be factual per attribute and SHALL NOT aggregate attributes into any composite eligibility label.

9.2 The retired display labels "With CA", "Without CA" and "CA Pending", and every other legacy composite CA status listed in Annex A, SHALL NOT appear in any registry display, marketplace text, certificate or communication.

9.3 Retirement certificates SHALL state the unit's Article 6 attributes factually per MCC-100 clause 21.10 and SHALL contain no eligibility conclusion.

9.4 Public disclosure SHALL cover the integrity-critical minimum data of MCC-100 Section 20; buyer identity, price and intended use SHALL be published only where lawful and consented or required (MCC-100 clause 20.7), and no clause of this Policy SHALL be read as mandating their publication.

NOTE. The predecessor's automatic publication of buyer identity, location and intended use, its mandatory intended-use disclosure regime and its separate price-display mandate (v1.0 clauses 0099–0105) are removed (finding CA-08): they may be unlawful or unavailable in many jurisdictions and are not integrity-critical. The integrity-critical minimum — serials, status, project, vintage, attributes, retirement records — is already mandated by MCC-100 Section 20.

9.5 Aggregate statistics on issuance, retirement and the distribution of Article 6 attributes SHALL be published in the annual programme transparency report (MCC-100 clause 20.8); no per-country reporting SHALL present MCC data as a Party's accounting position.

9.6 Intermediaries, brokers and marketplaces presenting MCC units SHALL, under their participation terms, present the attribute data of clause 9.1 unaltered and unabridged; misrepresentation or omission of attribute data SHALL be a material breach processed under Section 10.

10. Enforcement

10.1 Violations of this Policy SHALL be investigated by the Programme Secretariat's compliance monitoring function and decided under MCC-100 Section 23 by the bodies designated in MCC-700 Annex A (rows 20 to 26); this Policy creates no separate enforcement machinery, sanction ladder or registry of its own.

10.2 Enforcement measures for violations of this Policy SHALL be limited to participation in the MCC Programme (warning, conditional participation, suspension, unit cancellation on a defect finding, exclusion, per MCC-100 clause 23.2); MCC SHALL NOT purport to bar any person from any external programme, and SHALL NOT purport to direct the conduct of any state or external registry.

NOTE. The predecessor's permanent cross-programme blacklisting ("permanently ineligible to register projects in any programme", v1.0 clauses 0118–0122, 0158) exceeded MCC's authority (finding CA-07) and is not carried. MCC MAY share confirmed integrity findings with external programme operators under clause 10.4.

10.3 Confirmed intentional double issuance, fraudulent verification or systematic misrepresentation of Article 6 attributes SHALL be referred to the competent national authorities where the evidence and applicable law warrant it, following due process (MCC-100 clause 23.8).

10.4 MCC MAY notify an external programme operator of a confirmed duplicate registration or issuance affecting that programme, limited to the facts found and following the due-process protections of MCC-100 clauses 23.4 and 23.6; the notification SHALL be recorded.

10.5 Every enforcement decision under this Policy SHALL carry the review and appeal rights of MCC-700 Sections 11 and 12, and enforcement outcomes SHALL be recorded and published per MCC-100 clause 23.9.

11. Amendments

11.1 This Policy 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 3 amendments; a Standards Committee review and reasoned recommendation; and approval under the decision type in MCC-700 Annex A row 2.

11.2 Every amendment SHALL be published as a changelog entry and a clean consolidated text stating the instrument that creates the resulting version number.

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

12. Transitional provisions and entry into force

12.1 This Policy (MCC-CADCP version 2.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.

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

12.3 On entry into force, the predecessor MCC-CADCP v1.0 SHALL be formally superseded and archived as an uncontrolled historical record with a superseded watermark.

12.4 The four legacy corresponding-adjustment status models enumerated in Annex A are retired; every registry field, certificate template, marketplace display, API response and document text carrying a legacy value SHALL be migrated under Annex A and the MCC-800 migration rules before any further registry action displays a CA-related value. No corresponding-adjustment record exists, live or archived, and no live unit exists, so no live record carries a corresponding-adjustment status value and the migration has no live subject (registry measurement of 5 October 2026). The 28,769 demonstration units archived on 31 August 2026 do each carry one — 27,246 NOT_APPLIED, 1,508 NOT_REQUIRED, 14 CONFIRMED and 1 REQUESTED — which Evidence Register ER-2026-001 §A3 missed in stating that no status value of any kind had been recorded; the archive is served nowhere.

12.5 Any retirement certificate, confirmation or public text already issued displaying a legacy CA status, an Article 6.4 reference or an eligibility conclusion SHALL be recalled and reissued in conforming form. No certificate or confirmation has been issued against a live serial: the registry holds no credit units, batches, issuance requests, retirements, transfers or corresponding adjustments, and the five retirement certificates generated in the demonstration cohort concern MCC-DEMO- serials only and were archived on 31 August 2026 (Evidence Register ER-2026-001 §A1–§A3). Among live records, this clause has no subject at entry into force.

12.6 Any standing notification, template, commitment or communication sent to a host country under the predecessor's clauses 0058 to 0072 (transfer notifications, CA implementation templates, quarterly CA reports) SHALL be withdrawn by written notice explaining the corrected model. The programme record shows no such communication: no register of corresponding-adjustment communications exists, and no corresponding-adjustment record of any kind exists (Evidence Register ER-2026-001 §A1, §B5).

12.7 Exclusivity affidavits or declarations taken under the predecessor's clauses 0040 and 0113 to 0115 SHALL be replaced, at the proponent's next declaration date, by the participation declaration of clause 5.3; the stricter obligations of the superseded affidavits SHALL NOT be enforced beyond the scope of this Policy. The registry records no fee taken and no commitment made to any project developer (Evidence Register ER-2026-001 §A3; FD-2026-10-01 Schedule 1, Q14).

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

---

Annex A — Retired corresponding-adjustment status models and their migration (normative)

A-1 The programme record carried four incompatible corresponding-adjustment status models (Phase 0 source inventory; audit SYS-07). All four are retired. The sole status model is the Article 6 Attribute/Status Matrix (canonical control table 5); this Annex is the translation key from each legacy model into it.

A-2 Migration principle: a legacy value SHALL be migrated only to what its underlying documentary evidence supports; where no linked document exists, the affected attributes revert to their control-table-5 defaults (NOT_AUTHORIZED / NO_EVIDENCE / NONE_RECORDED) with an audit-trail note preserving the legacy value for the record. No legacy value SHALL be migrated on the strength of the label alone.

A-3 The four retired models and their migration:

#	Legacy model (source)	Legacy values	Migration under control table 5
1	MCC-100 v2.2 clause 0211 (public display statuses)	CA-Confirmed / CA-Under Development / CA-Pending / CA-Not Applicable	CA-Confirmed → attributes set only per linked evidence, else defaults + audit note; CA-Under Development and CA-Pending → defaults (a promise or process is not an attribute); CA-Not Applicable → defaults with voluntary-use annotation
2	MCC-800 v1.1 Article 59 (registry enumeration)	NOT_APPLIED / REQUESTED / CONFIRMED / REJECTED / NOT_REQUIRED	Per the migration row of control table 5: NOT_APPLIED → defaults; REQUESTED → host-country field per the underlying instrument, authorization NOT_AUTHORIZED; CONFIRMED (no record in the registry carries a corresponding-adjustment status of any value, so this branch has no subject to migrate and is retained for completeness — Evidence Register ER-2026-001 §A3) → reclassified into authorization and/or CA-evidence attributes only where documents exist, else defaults + audit note; REJECTED → REFUSED / NOT_AUTHORIZED as applicable; NOT_REQUIRED → defaults with voluntary-use annotation. Article 61 certificate language ("Article 6.4") is retired
3	MCC-CADCP v1.0 clauses 0084 table and 0086 (policy statuses and labels)	CA Required / CA Pending / CA Confirmed / CA Not Applicable; display labels "With CA" / "Without CA" / "CA Pending"	CA Required and CA Pending → defaults (the "requirement" derived from the abolished CA-at-retirement model); CA Confirmed → as model 2 CONFIRMED; CA Not Applicable and "Without CA" → defaults with voluntary-use annotation; all three display labels retired (clause 9.2)
4	MCC-HCA v1.0 clauses 0077 and 0153 (correspondingAdjustmentStatus enumeration)	NOT_APPLICABLE / PENDING / AUTHORISED / CONFIRMED	NOT_APPLICABLE → defaults; PENDING → defaults (submission-in-verification is workflow state, not an attribute); AUTHORISED → authorization attributes set per the verified instrument (purpose, date, instrument), CA evidence NO_EVIDENCE; CONFIRMED → CA_EVIDENCE_RECORDED only where the Party's reporting extract is linked, else AUTHORISED-equivalent attributes or defaults per evidence

A-4 The migration SHALL be executed under the MCC-800 migration rules with maker-checker control, and the completed migration report (counts per legacy value, evidence outcomes, exceptions) SHALL be filed in the Evidence Register and published in summary.

NOTE — GENERATED CONTENT. Annex A row 2 reproduces the migration row of the Article 6 Attribute/Status Matrix (canonical control table 5) verbatim in substance; rows 1, 3 and 4 extend the same principle to the other legacy models as this Policy's own normative content. On any divergence with control table 5, the control table prevails.

---

End of MCC-CADCP version 2.0-draft. Status: DRAFT — FOR CONSULTATION. Not in force. The Consultation questions section above states how each point the drafting left open is answered.