MCC-FORMS — Operational Forms Suite v1.0

Document control

Field	Value
Document code	MCC-FORMS (code assigned by the programme administration for this consultation; entered in the Document Register on adoption)
Title	Operational Forms Suite — MCC-FORM-001 to MCC-FORM-013
Version	1.0-draft
Status	DRAFT — FOR CONSULTATION
Date of this draft	3 September 2026
Tier	Tier 5 (operational templates)
Effective date	None. This document is not in force.
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	Audit finding SYS-05; MCC Programme Bible v2.0 §"Operational Templates" (a document retired by FD-2026-08-24 item D15, recorded in the decision register as attested by the founder, with no executed copy filed), which names ten forms; MIR-2026-001 rev 2 §3.1, where the series was verified against the Bible on 4 September 2026.
Supersedes	None (new document). No form in this suite has been issued as a document in any version; where the registry platform already collects a form's items, cl. 1.3 applies.
Language convention	British English; RFC-style normative verbs.
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)

NOTE (non-normative). The MCC Programme Bible v2.0 names ten operational forms and presents them as part of the programme's documentation. None of them has ever been issued as a document. Every gate in the credit lifecycle — application, listing, validation, verification, issuance, transfer, retirement — is named to a form that does not exist. This draft is the first text of all ten.

The Bible's numbering skips 009, 011 and 012 without explanation. This suite preserves the numbering as the Bible states it and does not invent the missing three; §12 records the gap rather than closing it.

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 9.9 — the country classification on MCC-FORM-008. Proposed: no separate proposal. MCC-HCA v2.0-draft, put to consultation with this suite, retires both the three country categories of MCC-HCA v1.0 and the four of MCC-100 v2.2 and makes no categorisation of host countries normative (its clause 7.1 and the NOTE following it); if it is adopted, the form carries no country category, and until then the field is specified and its permitted values are reserved. Basis: MCC-HCA v2.0-draft clause 7.1; FD-2026-10-01 item 4. Decided by: the Governing Board on adoption of the suite. Comments are invited on whether the form needs a country-category field at all.

2. Clause 12.3 — the gap at 009, 011 and 012. Proposed: no proposal is made — it is not established whether an earlier version of the form series populated those numbers, and the choice between renumbering the series contiguously and recording the gaps as deliberate and reserved turns on that. Basis: MCC Programme Bible v2.0 §"Operational Templates"; MIR-2026-001 rev 2 §3.1. Decided by: the Governing Board on adoption of the suite. Comments are invited from anyone who holds an earlier version of the series, and on which course the Board should take.

---

1. Purpose, scope and application

1.1 This suite specifies the minimum required content of each operational form. It does not specify layout, medium or field order; a form may be rendered as a web form in the registry platform, as a document, or both, provided every required item is captured and stored.

1.2 A form is the record of a request or a declaration, not a decision. Submitting a form creates no entitlement, and acceptance of a form is not acceptance of what it requests.

1.3 Where the registry platform implements a form, the platform's stored record IS the form for the purposes of this suite and of the Record Retention Schedule, and no separate document is required.

1.4 Every form SHALL capture, in addition to the items listed for it: the submitting person and organisation; the date and time of submission; the version of the form used; and a declaration of truthfulness signed or affirmed by a named individual with authority to bind the submitting organisation.

1.5 A form SHALL NOT request a datum the Programme has no stated purpose for. Where a listed item is not needed for a particular family or unit type, the form SHALL omit it rather than collect it unused (data minimisation).

1.6 Incompleteness. A form that omits a required item is not submitted. The Programme SHALL notify the submitter of the specific omissions within 10 working days and SHALL NOT begin any assessment period until the form is complete.

1.7 Every form is retained under the Record Retention Schedule; the applicable record class is stated in each section below.

---

2. MCC-FORM-001 — Project Application Form (PAF)

Gates: project application. Record class: R5 (project records). Submitted by: the project developer.

#	Required item
1.1	Project name, and the developer's legal name, registered address and company number
1.2	Named project contact, with a second contact for continuity
1.3	Host country or countries, and the political subdivision
1.4	Project boundary as machine-readable geospatial data, with the coordinate reference system stated
1.5	Methodology family (F01–F05) and methodology code applied for
1.6	Credit type applied for, and the reason it is the correct type under MCC-100
1.7	Crediting period sought, with start date and duration
1.8	Baseline study, or a statement of when it will be supplied and by whom
1.9	Additionality justification against the applicable methodology's test
1.10	Estimated annual and lifetime volume, with the calculation method
1.11	Land or sea tenure, and the legal basis on which the developer may act in the project area
1.12	Rights holders and affected communities identified, and the engagement undertaken to date
1.13	Prior or concurrent registration of the same activity with any other crediting programme, or a statement that there is none
1.14	Host-country authorisation status, cross-referring to MCC-FORM-008 where applicable
1.15	Declared conflicts of interest between the developer and any prospective VVB
1.16	Declaration under cl. 1.4

2.1 Item 1.13 is not optional and its omission is a ground to refuse the application. Double registration is the defect the corresponding-adjustment machinery exists to prevent, and the register cannot detect it if the applicant is not asked.

2.2 Item 1.4 is the trigger for satellite monitoring. No project in the register currently carries a boundary, which is why no monitoring has run for either project in the register.

---

3. MCC-FORM-002 — Project Listing Intake Checklist (PLIC)

Gates: listing. Record class: R5. Completed by: the Programme Administrator.

3.1 The PLIC is an internal completeness check, not an assessment of merit. It records, item by item against MCC-FORM-001, whether each required item was supplied, and the date each gap was notified and closed.

3.2 The PLIC SHALL record: the reviewer's name; the date of each review pass; each item marked complete, incomplete or not applicable with a reason; and the resulting decision to list, to refuse, or to hold pending information.

3.3 A listing decision SHALL be published on the public register with its date. Listing confers no entitlement and SHALL NOT be described, by the Programme or the developer, as approval, registration, validation, or any form of endorsement.

---

4. MCC-FORM-003 — Validation Request Form (VRF)

Gates: validation. Record class: R5. Submitted by: the project developer.

#	Required item
4.1	Project reference on the register
4.2	The complete PDD, at a stated version and file hash
4.3	The VVB engaged, with its accreditation reference and the scope of that accreditation
4.4	Independence declaration by the VVB against MCC-400, and the developer's confirmation of no undisclosed relationship
4.5	Confirmation that the VVB's professional indemnity cover meets the requirement in force, with the insurer, policy number and expiry
4.6	The period the validation is expected to take, and the date by which the opinion is expected
4.7	Any AI-augmented method the VVB intends to use, disclosed under MCC-850 and MCC-400 Addendum 1
4.8	Declaration under cl. 1.4

4.9 Item 4.5: the professional indemnity figure is USD 2 million per occurrence and USD 5 million in aggregate, the amounts FD-2026-08-24 item D7 fixed (recorded in the decision register as attested by the founder, with no executed copy filed), which prints the first limit per claim, and that MCC-400 v2.0-draft clause 4.6 carries per occurrence (FD-2026-10-01 Schedule 1, C6; MCC-400 v2.0-draft consultation question 1). The form SHALL cite the figure in force at the date of submission rather than reproduce a number, so that it cannot go stale.

---

5. MCC-FORM-004 — Verification Request Form (VEF)

Gates: verification. Record class: R5. Submitted by: the project developer.

#	Required item
5.1	Project reference and registration date
5.2	Monitoring period covered, with exact start and end dates
5.3	The monitoring report at a stated version and file hash (MCC-100 Annex B)
5.4	The VVB engaged, with accreditation reference, scope, independence declaration and cover as at cl. 4.3–4.5
5.5	Whether the same VVB conducted the validation, and if so the rotation position under MCC-400
5.6	Any reversal, incident or non-conformity arising in the period, cross-referring to MCC-FORM-010
5.7	Any change to the project boundary, tenure, ownership or methodology version since the last verification
5.8	Declaration under cl. 1.4

5.9 Item 5.7 is material: a boundary or ownership change between monitoring periods can move a project outside the methodology it was registered under, and the register cannot detect it unless it is declared.

---

6. MCC-FORM-005 — Issuance Request Form (IRF)

Gates: issuance. Record class: R1 (permanent). Submitted by: the project developer; decided by the Programme under MCC-100 cl. 0162.

#	Required item
6.1	Project reference; monitoring period; verification report version and hash
6.2	The verification opinion, as a typed value. Only POSITIVE permits issuance.
6.3	Volume requested, by unit type and vintage year
6.4	The buffer contribution to be withheld, with the rate applied and the instrument that sets it
6.5	Net volume to be issued to the developer's account, and the account reference
6.6	Open non-conformities: each listed with severity. An open major blocks issuance absolutely. An open minor blocks issuance unless deferred with reasons and a named decision-maker.
6.7	Open grievances: each listed. An unresolved grievance blocks issuance.
6.8	Host-country authorisation position, and whether a corresponding adjustment applies, cross-referring to MCC-FORM-008
6.9	Where authorisation is not required: the determination to that effect, with its stated reason and named decision-maker. A silent absence is not a determination.
6.10	Declaration under cl. 1.4

6.11 Items 6.2, 6.6, 6.7 and 6.9 restate the determinations recorded at D-2026-08-09 in MCC-BDR-2026-002, recorded in the decision register as unsigned; their retaking was proposed to the Governing Board in the board pack of 23 September 2026 (draft resolution 2.4). No record of a Governing Board meeting on 23 September 2026 has been filed. They are already implemented and verified gate by gate in the registry platform.

6.12 No issuance has ever occurred. The live registry holds no units of any type. This form has therefore never been needed, and is written before it is, rather than after.

---

7. MCC-FORM-006 — Transfer Instruction Form (TIF)

Gates: transfer. Record class: R1. Submitted by: the holder of record.

#	Required item
7.1	Transferor account, and the identity of the natural person instructing, with their authority
7.2	Transferee account, and confirmation that it is open and in good standing
7.3	Unit serial numbers or serial ranges
7.4	Whether the transfer is a sale, a gift, an intra-group movement or other, stated
7.5	Confirmation that the transferee is not a person the Programme is prohibited from dealing with
7.6	The fee applicable, cited to the Fee Schedule in force rather than reproduced
7.7	Declaration under cl. 1.4

7.8 A transfer instruction SHALL be executed on a maker-checker basis: the person who records the instruction SHALL NOT be the person who releases it.

---

8. MCC-FORM-007 — Retirement Request Form (RRF)

Gates: retirement. Record class: R1. Submitted by: the holder of record.

#	Required item
8.1	Account and unit serial numbers or ranges
8.2	The claim the retirement supports, in the exact words to be published
8.3	The beneficiary of the claim, where not the holder
8.4	The reporting year or period the claim relates to
8.5	Confirmation that the claim conforms to the Claims Policy in force, and that no other claim is or will be made on the same units
8.6	Declaration under cl. 1.4

8.7 Retirement is irreversible. The form SHALL state this on its face and SHALL require positive acknowledgement before submission.

8.8 Item 8.2 is the point at which the Programme's claims discipline is either enforced or lost. The claim text SHALL be checked against the Claims Policy before the units are retired, not after, because there is no reversing it.

8.9 Retirement is free of charge (Definitions Register v1.0 §4, carrying FD-2026-08-24 item D9; proposed to the Governing Board under FD-2026-10-01 Schedule 1, C6, which is asked whether the amount is already decided — MCC Fee Schedule 1.0-draft, clause 2.1). The form SHALL NOT present a fee field.

8.10 Cancellation — permanent removal without a claim, including for error correction — is a distinct operation and SHALL NOT be recorded on this form. It requires a separate instruction with a stated reason and a named authoriser.

---

9. MCC-FORM-008 — Host Country Authorization Record (HCAR)

Gates: Article 6 authorisation. Record class: R1. Completed by: the Programme Administrator from the host country's instrument.

#	Required item
9.1	Host country, and the authorising ministry or agency with the name and office of the signatory
9.2	The authorising instrument itself, attached, with its date and reference
9.3	The activities, project references and vintages authorised
9.4	Whether a corresponding adjustment is committed, and in what terms
9.5	The authorised use: which claim purposes the units may serve
9.6	Conditions, reservations and expiry
9.7	The retroactive-notification position where an authorised use changes after issuance

9.8 Where authorisation is not required, this form records the determination to that effect under cl. 6.9, with its reason and decision-maker, rather than being left unfiled.

9.9 MCC-HCA v1.0 makes host-country authorisation optional (cl. 0006, 0040) against the mandatory gates of MCC-001 cl. 0034, MCC-100 cl. 0102–0115 and MCC-700 cl. 8.1.1.2; and MCC-HCA uses three country categories against MCC-100's four. MCC-HCA v2.0-draft, put to consultation with this suite, resolves the category conflict by retiring both models and making no categorisation of host countries normative (its clause 7.1), and the optionality conflict by making domestic-legality evidence mandatory and Article 6 authorisation optional (its Section 3); if it is adopted, this form carries no country category. The field is specified; its permitted values are reserved. (Consultation question 1.)

---

10. MCC-FORM-010 — Reversal / Buffer Pool Incident Form (RPIF)

Gates: reversal handling. Record class: R1. Submitted by: the project developer, or raised by the Programme.

#	Required item
10.1	Project reference and the units affected
10.2	Date the reversal occurred and the date it was detected, both, with the reason for any gap
10.3	Cause, and whether it is classified as avoidable or unavoidable, with the reason for that classification
10.4	Quantified loss, with the method used to quantify it
10.5	Buffer units to be cancelled in compensation, and the calculation
10.6	Remediation proposed, with dates
10.7	Whether the reversal affects the project's continued eligibility
10.8	Declaration under cl. 1.4

10.9 Item 10.2: the interval between occurrence and detection is the measure of whether the monitoring regime works, and it is not recoverable after the fact. It SHALL be captured at the time.

10.10 A reversal SHALL be notified within the period the Buffer Pool Management Policy in force requires, and the form SHALL be capable of submission before every item is known, marked provisional, rather than delaying notification until it is complete.

---

11. MCC-FORM-013 — Conflict of Interest Declaration (COI)

Gates: governance. Record class: R6 (governance records). Submitted by: every member of every governance body, every person exercising a delegated authority, and every VVB engagement lead.

#	Required item
11.1	Declarant's name, role and the body or function concerned
11.2	Financial interests in any participant, VVB, developer or buyer
11.3	Employment, directorship, consultancy or advisory relationship, current or within the look-back period
11.4	Family and close personal relationships engaging the same interests
11.5	Any interest of an entity the declarant controls or is controlled by
11.6	Where an interest is declared: the mitigation proposed — recusal, screening, or divestment — and who decided it
11.7	Declaration under cl. 1.4

11.8 The look-back period is 36 months (proposed: FD-2026-10-01 Schedule 1, Q7; MCC-ROI v1.0-draft cl. 6.6).

11.9 Declarations SHALL be made on appointment, annually, and on the arising of any new interest within 14 days. An annual-only regime does not catch the interest that arises the week before a decision.

11.10 Declarations are recorded in the Register of Interests. The Register is proposed in MCC-ROI v1.0-draft, put to consultation with this suite; the platform's interest_disclosures store already holds one declaration (MCC-ROI v1.0-draft cl. 14.3–14.4).

---

12. The gap at 009, 011 and 012

12.1 The Programme Bible's form series runs 001, 002, 003, 004, 005, 006, 007, 008, 010, 013. Numbers 009, 011 and 012 are absent without explanation.

12.2 This suite does not invent them. Either three forms were dropped from an earlier list without a record, or the series was transcribed from a longer one. Both are document-control defects and both are recorded here rather than papered over.

12.3 Whether an earlier version of the form series exists in which 009, 011 and 012 are populated is not established. If none exists, the Board should either renumber the series contiguously or record that the gaps are deliberate and reserved. (Consultation question 2.)

---

13. Maintenance

13.1 A form is amended by the procedure for a Tier 5 instrument. The version of the form used SHALL be recorded on every submission (cl. 1.4), so that a submission can always be read against the form as it then stood.

13.2 A change to a form that alters what a submitter must declare is a substantive change and requires consultation. A change to layout, wording or help text is not.

13.3 Where an instrument at a higher tier changes a requirement a form captures — a fee, a threshold, an insurance figure — the form is amended by the document owner without consultation, because the form is citing rather than setting the requirement. Every such amendment is published with its reason.

---

Prepared 3 September 2026 for public consultation. Ten forms, none of which has been issued as a document before, specified for the first time. Evidence: MCC Programme Bible v2.0 §"Operational Templates", verified line by line on 4 September 2026; MIR-2026-001 rev 2 §3.1; MCC-100 cl. 0162 and the issuance gates already implemented in the registry platform. No decision in this draft has been taken.