MCC-800 — Registry Operations Standard

Document control

Field	Value
Document code	MCC-800
Title	Registry Operations Standard
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)
Effective date	None. This document is not in force. It takes effect only on approval under clause 27.1.
Document owner	Programme Administrator (transitional, until a Secretariat is staffed — FD-2026-10-01 Schedule 1, C3)
Approved by	Not approved. Prepared for public consultation.
Decision basis	Founder Decisions FD-2026-09-03, items D1–D8 (adopted 3 September 2026 in the programme working channel; to be tabled for ratification by the Governing Board), items D1, D2, D3 and D4 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-800 Registry Operations Standard, printed title "Version 1.1 — March 2026" over a control table and running headers reading "Version 1.0", status APPROVED, effective 2026-04-01 — reclassified by FD-2026-09-03 item D5; the document register records it as in force (as v1.1) until this version is adopted, when its withdrawal as a controlled copy is executed (FD-2026-09-07 item A8: scheduled, not executed; FD-2026-09-07 is recorded in the decision register as attested by the founder, with no executed copy filed). 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, pipeline state names and status labels are quoted verbatim from the adopted control tables and the platform data model and retain their spelling (for example "AUTHORIZED", "CA_EVIDENCE_RECORDED", "SERIAL_NUMBERS_GENERATED").
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's controlled identity cannot be determined from the document itself (audit finding 800-01; SYS-06, CONFIRMED in Phase 0): the title page prints "Version 1.1 — March 2026", while the document-control table and the running header on every page print "Version 1.0"; there is no changelog, and no instrument creating a v1.1 is in the programme record. Article 27 of the same text cites "FD-2026-08-24, item D13" and a "reissue note of 24 August 2026", yet the control table still reads v1.0 / effective 2026-04-01. Both exist and are served: FD-2026-08-24 item D13 settles the article 27 serial format, and the re-issue note of 24 August 2026, adopted under FD-2026-08-24, is published and entered in the document register (FD-2026-08-24 is recorded in the decision register as attested by the founder, with no executed copy filed). The residual absence is narrower: the note records what the v1.1 designation covers and does not itself create v1.1, and no instrument does (document register, entries for MCC-800 and its re-issue note; Evidence Register ER-2026-001 §B3).
2. Declared baseline. For the purposes of supersession and the change log, this rewrite treats the text served as MCC-800 v1.1 as the baseline and designates it "v1.0/v1.1 (indeterminate)". The controlled version per the control table and headers is v1.0; the title-page "v1.1" designation has no recorded creating instrument. This version 2.0-draft supersedes both designations and every text they could denote.
3. This version 2.0-draft is a substantive rewrite, not a line edit (audit §5.6: "legal, security and data-model controls are not production-ready"): the serial-number specification is replaced by a versioned, epoch-based specification (Schedule 1); the corresponding-adjustment tracking model of Articles 58–62 (including the Article 6.4 representation) is replaced by the Article 6 attribute model of FD-2026-09-03 item D3; customer due diligence, maker-checker, reconciliation, incident-response and wind-down controls are added; and technology-stack, protocol and performance parameters are removed to the Information Security Standard and the Registry Architecture Specification, the latter yet to be created. The predecessor is reclassified by FD-2026-09-03 item D5; the document register records it as in force (as v1.1) until this version is adopted, when the withdrawal of its PDF as a controlled copy, and its archiving as a superseded record, are executed (FD-2026-09-07 item A8: scheduled, not executed).

Change history

Version	Date	Change	Instrument
1.0/1.1 (indeterminate)	Printed March 2026, effective 2026-04-01, status APPROVED	Base text; title v1.1 over control-table and header v1.0; no changelog	No approval instrument for v1.0, and no instrument creating "v1.1", is in the programme record; the programme's document corpus was searched on 3 September 2026 (Evidence Register ER-2026-001 §B3), and the document register records MCC-800 v1.1 as in force with no adopting instrument.
2.0-draft	3 September 2026	Substantive rewrite against audit findings SYS-01, SYS-06, SYS-07, SYS-11, SYS-12 and 800-01 to 800-11 and Founder Decisions FD-2026-09-03 D1–D8: canonical instrument definitions (Art. 2 "Conservation Credits" corrected); versioned epoch-based serial specification with machine-readable tests and migration rules (Schedule 1); batches and immutable serial ranges; legal nature of units defined as contractual entitlements; risk-based KYC/KYB/UBO/sanctions controls and account recovery; maker-checker on issuance, transfer, retirement and cancellation; Articles 58–62 CA model retired and replaced by control table 5 attributes with the Schedule 2 migration; grandfathering of validly issued units; reconciliation regime; cross-registry transfers gated on bilateral protocol; retention delegated to the Record Retention Schedule; security delegated to the Information Security Standard; technology stack and performance figures moved to the Registry Architecture Specification (yet to be created); operational phase calendar and phased-compliance regime removed	FD-2026-09-03 items D1–D8

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

Consultation questions

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

1. Clause 3.3 — Governing law and dispute forum for registry entitlements. Proposed: Norwegian law, the UNCITRAL rules and a seat in London, stated in the Registry Terms of Use. The proposal depends on the jurisdiction of the Programme's operating entity, which has not yet been incorporated and for which a Norwegian aksjeselskap (AS) is proposed, and it is subject to the legal review required before adoption, which has not been obtained (Evidence Register ER-2026-001 §B5). The Registry Terms v1.1, which the document register records as in force (FD-2026-08-24), print the governing law as a "TBD by Board" placeholder carrying the same proposal (article 15). Basis: FD-2026-10-01 item 3 and Schedule 1 (C1, Q9); FDP-2026-001 C1 and Q9. Decided by: the Governing Board on adoption of the suite; the entity's name and jurisdiction are reserved to the Board (FD-2026-09-04 item 6, recorded in the decision register as attested by the founder, with no executed copy filed). Comments are invited on the proposed law, seat and rules, and on how registry entitlements should be governed until the entity is incorporated.

2. Clause 4.7 — Accountable owner of account onboarding, suspension and closure (MCC-700 Annex A rows 28 to 30). Proposed: the Programme Secretariat's registry function decides, under Registry Oversight Committee oversight and with maker-checker (two-person) approval, as drafted in rows 28 to 30; the Delegated Authority Matrix is put to consultation as drafted, as one proposal, with those rows confirmed as drafted. The Secretariat is not staffed and no Registry Oversight Committee is constituted: under the transitional appointments schedule also proposed (MCC-700 v4.0-draft cl. 4.5.5), the Programme Administrator would perform the Secretariat's functions until it is staffed and the Governing Board would exercise the Committee's until it is constituted, whereas clause 4.7 of this Standard, read with cl. 23.2 of that draft as it stands, places the functions of a body not yet constituted with the founder. Basis: FD-2026-10-01 Schedule 1 (C2, C5); FDP-2026-001 C2. Decided by: the Governing Board on adoption of the suite. Comments are invited on whether these determinations should rest with the Secretariat's registry function, and on who should take them until the Secretariat is staffed.

3. Clause 7.4 — Designation and adoption of the KYC and Account Procedure. Proposed: the Registry KYC and Account Opening Procedure v1.0 is designated under this Standard as the KYC and Account Procedure. It was put to consultation as a procedure under MCC-800 v1.1 and the Registry Terms v1.1; its notice period ended on 8 September 2026, and its closing protocol, published on 24 September 2026, recommends adoption, which rests on FD-2026-09-04 (recorded in the decision register as attested by the founder, with no executed copy filed). It is not entered in the document register as adopted, and whether a text may be adopted on an attested rather than a signed decision is referred to the Governing Board (MCC-CLS-2026-001 §B.1 and Part E item 4). Basis: FD-2026-10-01 Schedule 1 (Q12); FDP-2026-001 Q12. Decided by: the Governing Board on adoption of the suite, which also has before it the referral on adoption under an attested decision. Comments are invited on the designation, and on whether the procedure conforms to Section 7 of this Standard, as clause 7.4 requires.

4. Clause 12.4 — Destination of released buffer units. Proposed: this Standard states no preference between the two destinations — cancellation (BUFFER→CANCELLED), or re-activation and transfer (BUFFER→ACTIVE) — and the registry executes the destination stated in the release decision, refusing any release without a linked decision reference and an explicit destination. The choice between them is put to consultation in MCC-BPM v2.0-draft clause 11.6 (its question 7), as two options without a preference, and under that clause no release is made until it is decided. Basis: an open decision of this draft, put to consultation with its interim rule (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 the registry should support both destinations, and on which better protects the integrity of outstanding units.

5. Clause 18.1 — Privacy owner and applicable data protection law. Proposed: no proposal is made — the question is who should be the registry's responsible privacy owner, and which data protection law the registry should apply. No privacy owner has been designated, and FD-2026-10-01 makes no proposal for one. The applicable law depends on the jurisdiction of the Programme's operating entity, which has not yet been incorporated and for which a Norwegian aksjeselskap (AS) is proposed, and on where data subjects are located. The MCC Privacy Policy is put to consultation with this suite as MCC-PRIV v1.0-draft, which asks both points (its questions 1 and 9). Basis: FD-2026-10-01 item 3 and Schedule 1 (C1); FDP-2026-001 C1. Decided by: the Governing Board on adoption of the suite; the entity's name and jurisdiction are reserved to the Board (FD-2026-09-04 item 6). Comments are invited on who should hold the privacy-owner role, and on which data protection baseline the registry should apply until the entity is incorporated.

6. Clause 21.2 — Escrow agent and data-escrow agreement. Proposed: no proposal is made — the question is which independent escrow agent should hold the copy of the registry record, and under what data-escrow agreement and release triggers. No escrow agent has been appointed and no data-escrow agreement exists in the programme record; FD-2026-10-01 Schedule 1 (C6) makes no proposal for either, and none is made here. Basis: FD-2026-10-01 item 4 (a point asked without a proposal); FDP-2026-001 C6, which lists the escrow agent among the open money questions. Decided by: the Governing Board on adoption of the suite. Comments are invited on the criteria an escrow agent and agreement should meet.

7. Clause 21.4 — Funding of the registry's wind-down obligations. Proposed: no proposal is made — the question is by what dedicated reserve or equivalent secured arrangement the registry's wind-down obligations should be funded, and at what size. No funding mechanism is decided and no figure is proposed: FD-2026-10-01 Schedule 1 (C6) makes no proposal for this clause, and FDP-2026-001 C6 lists the funding of this clause among the open money questions without a figure. The arrangement interacts with the buffer standard's insolvency and wind-down protections, put to consultation in MCC-BPM v2.0-draft clauses 13.1 and 13.3 (its questions 11 and 12). Basis: FD-2026-10-01 Schedule 1 (C6); FDP-2026-001 C6. Decided by: the Governing Board on adoption of the suite; the arrangement's sizing and periodic review are then approved under MCC-700 Annex A row 31 (the Independent Governing Board, as drafted). Comments are invited on the form the arrangement should take and on how its size should be derived.

Table of contents

1. Purpose, scope and application
2. Normative references, definitions and interpretation
3. Legal nature of units, labels and registry entries
4. Registry governance and separation of duties
5. Registry data model and unit states
6. Serial numbers and batches
7. Account management and customer due diligence
8. Issuance operations
9. Transfer operations
10. Retirement operations and certificates
11. Cancellation
12. Buffer pool accounts
13. Article 6 attributes
14. Audit trail and data integrity
15. Reconciliation
16. Workflow engine and notifications
17. Public transparency and open data
18. Privacy and data protection
19. Information security
20. Service continuity, incident response and disaster recovery
21. Registry continuity and wind-down
22. Cross-registry interoperability
23. Change management and platform governance
24. Registry fees
25. Compliance monitoring
26. Amendments
27. Transitional provisions and entry into force Schedule 1 — Versioned Serial Number Specification (normative) Schedule 2 — Registry data migrations (normative)

---

1. Purpose, scope and application

1.1 This Standard (MCC-800) SHALL govern the operation of the MCC Registry: the data model, unit states, serial numbering, account lifecycle, customer due diligence, issuance, transfer, retirement, cancellation, buffer accounting interface, Article 6 attribute recording, audit trail, reconciliation, transparency, privacy, security, continuity and wind-down of the registry.

1.2 The MCC Registry is the authoritative and exclusive record of every unit, label, holding, transfer, retirement and cancellation under the Programme (MCC-100 clause 20.1); this Standard applies to the Registry Operator, every governance body and Programme function acting in the registry, every Account Holder and representative, and every person accessing registry data or interfaces.

1.3 This Standard is a Tier 3 instrument under the Document Hierarchy & Precedence Register; precedence is governed by MCC-001 Section 2, and this Standard implements — and SHALL NOT weaken — MCC-001 Sections 5 and 8, MCC-100 Sections 4, 19, 20 and 21, MCC-700 Sections 16 and 17 and Annexes A and B, and MCC-CADCP Section 4.

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

NOTE. The following instruments referenced in this Standard are not in force: MCC-600 (Claims Code), drafted as v1.0-draft (claims are governed meanwhile by the Claims Policy v1.1, adopted under FD-2026-08-24 and recorded in the document register as in force); the Record Retention Schedule (MCC-810) and the Information Security Standard (MCC-820), each put to consultation with this suite; the Registry Architecture Specification (Tier 5, to be created — it will carry the technology stack, protocol versions, availability and performance targets and capacity parameters removed from this Standard's predecessor); the registry data dictionary (clause 5.2), which does not yet exist; the KYC and Account Procedure (clause 7.4), for which the Registry KYC and Account Opening Procedure v1.0 is proposed — its consultation closed on 8 September 2026, and it is not entered in the document register as adopted; the reissued MCC-400 and MCC-850 (v2.0-drafts), each put to consultation with this suite; and the MCC Fee Schedule (MCC-FEES, 1.0-draft), no fee amount having been set (FD-2026-09-04 items 4 and 6). The Definitions Register is in force (clause 2.1). Each dependent requirement is deferred under clause 1.4, never silently effective.

1.5 This Standard states requirements and control objectives; it SHALL NOT be read as evidence that any control is implemented or tested. Implementation and test evidence SHALL be recorded in the Evidence Register per audit acceptance test QA-13 before issuance is enabled.

1.6 This Standard states no technology stack, database product, programming framework, protocol version, availability percentage, latency figure or capacity parameter; those choices SHALL be recorded in the Registry Architecture Specification, which SHALL conform to this Standard and to the Information Security Standard.

NOTE. The predecessor hard-coded PostgreSQL, Express/Node.js, React, TLS 1.3, AES-256, OWASP Top 10, 99.5% uptime, 500 ms / 2,000 ms response times, RPO 1 hour / RTO 4 hours and rate limits into the Standard itself (v1.x Arts. 14, 18–24, 78, 92; findings 800-10, SYS-11; audit §6.3 drafting rule). Requirements of that kind are either control objectives (now in the Information Security Standard, MCC-820 v1.0-draft) or architecture choices (for the Registry Architecture Specification, which is yet to be created).

2. Normative references, definitions and interpretation

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

2.2 The normative verb conventions of MCC-001 clause 3.1 SHALL apply throughout this Standard; each numbered clause states one testable requirement; text introduced by "NOTE" or "GUIDANCE" is non-normative.

2.3 The Programme instruments recorded in the registry are exactly those of the Unit/Product Dictionary (canonical control table 1, adopted under FD-2026-09-03 item D1): MCC-CC (Carbon Credit — exactly one tonne CO2e, ex-post verified), MCC-MOU (Marine Outcome Unit — a methodology-specific, quantified and verified physical marine outcome) and the MCC-CB label (a verified co-benefit statement attached to a specific MCC-CC or project record; not a unit and not separately transferable).

NOTE — GENERATED CONTENT. Clause 2.3 reproduces verbatim its single source, the Unit/Product Dictionary (canonical control table 1), as restated in MCC-001 clauses 6.1 to 6.5 and MCC-100 clauses 4.2 to 4.4. On any divergence, the source prevails and this reproduction is corrected; no local variation is permitted. This corrects the predecessor's Article 2, which expanded MCC-CC as "Conservation Credits" against the Programme Standard (finding 800-02; SYS-01), and retires the abolished instrument codes MCC-HYB and MCC-MCU (FD-2026-09-03 item D1; migration per Schedule 2).

2.4 In this Standard: Registry Account means a uniquely identified account in the MCC Registry held by a verified legal person or by the Programme; Account Holder means the legal person of record for a Registry Account; unit means an issued MCC-CC or MCC-MOU; batch means the set of units created by a single issuance decision, carrying one contiguous immutable serial range; serial range means a contiguous sequence of serial numbers within a batch; holder of record means the Account Holder recorded at serial-range level as owner of the units concerned (MCC-100 clause 4.14); registry transaction means any issuance, transfer, retirement, cancellation or administrative status change affecting a unit, batch or account; Vintage means the calendar year in which the verified emission reduction or removal (MCC-CC) or the verified outcome (MCC-MOU) occurred; epoch means the semantic era of a serial number under Schedule 1; maker-checker means the control under which no single person both initiates and approves the same action (MCC-700 clause 4.8.2).

2.5 Precedence is governed by MCC-001 Section 2. (This Standard implements, and SHALL NOT weaken, MCC-CADCP Section 4 by force of clause 1.3; no subject-matter precedence rule between same-tier instruments is stated here, and any such rule belongs in MCC-001 Section 2 by amendment.)

3. Legal nature of units, labels and registry entries

3.1 An MCC unit SHALL constitute a contractual entitlement against the Legal Entity, arising under the MCC Registry Terms of Use and the participation agreements, to the exclusive recording, transfer, retirement and claim rights this Standard and MCC-100 attach to that unit; the Programme documents SHALL NOT characterise a unit as a property right, security, financial instrument, commodity or currency in any jurisdiction, and any such characterisation under applicable law is a matter for that law, not for Programme text.

3.2 The registry entry SHALL be the authoritative record of the entitlement and of the holder of record; as between the Programme and Account Holders, and among Account Holders, the registry entry prevails over any certificate, confirmation, invoice or other derivative document (MCC-600 clause 6.4).

3.3 The Registry Terms of Use SHALL state the governing law and dispute forum for registry entitlements. The governing law and forum depend on the Legal Entity's jurisdiction of incorporation, and the Programme's operating entity has not yet been incorporated (FD-2026-10-01 item 3; MCC-001 v3.0-draft clause 1.4); the administration's proposal is put as a consultation question, subject to the legal review required before adoption, which has not been obtained. (Consultation question 1.)

3.4 Nothing in the registry, and no act of the Registry Operator, SHALL be represented as conferring, evidencing or implying regulatory, tax, accounting or financial-services treatment of any unit in any jurisdiction; participants SHALL take their own advice.

NOTE. The predecessor equated the registry entry with "legal title" without defining the asset's legal nature or governing law (finding 800-06). This Section defines the entitlement contractually and puts the unresolved jurisdictional question to consultation (clause 3.3) rather than asserting a property-law conclusion.

3.5 An MCC-CB label SHALL be recorded as an attribute of the specific MCC-CC batch or project record it attaches to; it SHALL NOT be recorded as a unit, SHALL NOT carry a serial number of its own, and SHALL NOT be transferable separately from the record it is attached to (MCC-100 clause 4.4).

4. Registry governance and separation of duties

4.1 Registry oversight — issuance control, registry risk, reconciliation and registry security — is vested in the Registry Oversight Committee under MCC-700 clause 4.8; decision ownership, thresholds, conflict rules and appeal routes for every registry-related Programme decision are fixed exclusively in MCC-700 Annex A, and this Standard states none.

4.2 Every issuance and every registry action within the Registry Oversight Committee's mandate SHALL be executed under maker-checker approval (MCC-700 clause 4.8.2); in this Standard that control applies, at minimum, to: issuance approval and execution; unit cancellation; buffer draws, cancellations and releases; account onboarding determinations; account suspension and closure; execution of any Schedule 2 migration step; and any manual correction of registry data.

4.3 The registry platform SHALL enforce separation of duties technically: for every action listed in clause 4.2 the platform SHALL evaluate, before execution, that the approving identity is distinct from the initiating identity and holds the required role, and SHALL block execution otherwise.

4.4 Any override of the separation-of-duties evaluation (including any launch-phase override facility) SHALL: (a) require a written justification captured at the moment of use; (b) be logged immutably in the audit trail; (c) be reported to the Registry Oversight Committee at its next meeting and reviewed; and (d) be technically disabled before the first issuance of any unit. The platform's issuance function carries such a facility: it refuses an approval by the person who requested the issuance unless a written justification of at least fifty words is supplied, and records any such override in the audit log, which holds no such entry. The check was added by migration 20260818161000; before it, each of the three issuance requests in the archived demonstration cohort, all of 10 August 2026 (two issued, one rejected), was decided by the person who had requested it. The platform's transfer and retirement routes carry the same override, usable only where it is switched on for the deployment, and record any use in the audit log, which holds no such entry either. No unit has been issued other than the demonstration units archived on 31 August 2026. The audit log separately records seven overrides of the status-transition guard, a different control, made between 10 and 17 August 2026 on demonstration and test records, none of which is in the live register. Distinct from all of these, five human decisions overriding an AI recommendation are recorded, all of 20 August 2026 and all under the Registry Manager role, on projects that are in neither the live register nor the archived demonstration cohort (Evidence Register ER-2026-001 §§A2–A3; audit log, issuance requests and human decisions measured 5 October 2026).

4.5 Registry roles and permissions SHALL be defined on a least-privilege basis in the Registry Architecture Specification under the access-control requirements of the Information Security Standard; no role SHALL combine, for the same transaction, the initiation and approval of that transaction, and no commercial or project-facing role SHALL hold registry write permissions.

4.6 Registry controls SHALL be subject to independent audit at least annually (MCC-700 clause 4.8.3); the audit scope SHALL include the controls of Sections 4, 6, 7, 8, 9, 10, 11, 14 and 15, and a summary of findings SHALL be published.

4.7 Day-to-day registry administration SHALL be performed by the Programme Secretariat's registry function within delegated authority (MCC-700 clause 4.11.1); the registry function SHALL have no authority to decide any matter reserved to a body by MCC-700 Annex A. Account onboarding determinations, account suspension and account closure are decided under MCC-700 Annex A rows 28, 29 and 30 respectively, added by the bundled conforming instrument of 3 September 2026. The accountable owner of each of those rows is proposed to be the Programme Secretariat's registry function under Registry Oversight Committee oversight, with maker-checker approval, as drafted there, the Delegated Authority Matrix being put to consultation as drafted, as one proposal (FD-2026-10-01 Schedule 1, C2). Until the owner is confirmed, these determinations are exercised under the transitional mechanics of MCC-700 Section 23 and logged for ratification. (Consultation question 2.)

NOTE. The predecessor's decision-holding roles "Registry Manager", "Programme Administrator" and "Governance Board" (v1.x Arts. 15, 33, 36, 51, 99, 112 and elsewhere) are not carried: they are not bodies of MCC-001 clause 9.1.1, and MCC-700 clause 8.2 voids decision-owner statements outside Annex A. Operational duties formerly assigned to the "Registry Manager" are carried by the Programme Secretariat's registry function, the Secretariat being not yet staffed (MCC-700 v4.0-draft clause 4.11.4); decisions are carried by the bodies MCC-700 Annex A designates.

5. Registry data model and unit states

5.1 The registry SHALL implement exactly the canonical data model of this Section; no screen, workflow, API response or document SHALL introduce a unit state, batch state, account state or pipeline state not defined here or in MCC-700 Annex B (project lifecycle).

5.2 A registry data dictionary SHALL be published as a Tier 5 controlled artefact recording, for every registry entity: its fields, types, enumeration values, validation rules and the canonical control table or clause each field implements; the data dictionary SHALL be generated from the canonical control tables and this Standard and SHALL NOT introduce semantics of its own.

5.3 Unit states. Every unit SHALL carry exactly one of the following states: ACTIVE (issued and available for transfer or retirement), RETIRED (permanently removed from circulation for a beneficiary claim), CANCELLED (permanently removed from circulation for a reason other than a beneficiary claim) and BUFFER (held in the Buffer Pool Account and unavailable for transfer, retirement or claim).

5.4 The permitted unit-state transitions SHALL be exactly: ACTIVE→RETIRED (retirement, Section 10); ACTIVE→CANCELLED (cancellation, Section 11); BUFFER→CANCELLED (buffer draw, Section 12); and BUFFER→ACTIVE (buffer release, Section 12, only under the Tier 3 buffer standard); RETIRED and CANCELLED are terminal, and no transition SHALL exist out of them.

5.5 Batch states. Every batch SHALL carry exactly one of: PENDING, APPROVED, ISSUED, PARTIALLY_RETIRED, FULLY_RETIRED; batch states are derived summaries of the batch's units and the issuance pipeline and SHALL never contradict unit-level states.

5.6 Account types and states. Every Registry Account SHALL carry exactly one type — GENERAL (participant accounts, including project developers and holders), BUFFER_POOL (the Programme-controlled buffer account) or PROGRAMME (Programme administrative accounts, including the cancellation account) — and exactly one state: ACTIVE, SUSPENDED or CLOSED.

NOTE. The predecessor's five account types (Project Developer, Holder, VVB, Programme, Public View — v1.x Art. 31) are consolidated to the three implemented types: developer and holder functions are GENERAL accounts distinguished by role and permission, VVB access is a role and not an account type holding units, and public read access is unauthenticated access to the public surfaces of Section 17, not an account.

5.7 Units under dispute, investigation, suspension, legal hold or pending migration SHALL be flagged; a flagged unit SHALL NOT be transferred or retired while the flag stands, flags SHALL be visible on the public record as a factual annotation, and flag decisions and their lifting follow MCC-700 Annex A (MCC-CADCP clause 4.5).

5.8 Every unit SHALL belong to exactly one batch; every batch SHALL belong to exactly one project, one methodology and version, one instrument type, one Vintage and one host country; and Article 6 attributes, MCC-CB labels and flags SHALL attach at unit or batch level per control table 5 and travel with the units through transfer.

5.9 For a split-ledger project (MCC-100 clause 5.9), the registry SHALL maintain the GHG ledger (MCC-CC batches) and each marine-outcome ledger (MCC-MOU batches) as separate batches with separate serial ranges; no registry operation SHALL merge, net or convert between the ledgers.

5.10 Quantities SHALL be recorded in whole units only (MCC-100 clauses 4.10 and 4.11); the registry SHALL NOT record, carry or display fractional unit quantities in any balance, transaction or export.

6. Serial numbers and batches

6.1 Every issued unit SHALL carry exactly one globally unique serial number, assigned at issuance under the Versioned Serial Number Specification in Schedule 1 (normative), and immutable for the life of the unit and beyond (MCC-100 clause 4.12; MCC-CADCP clause 4.2).

6.2 Serial numbers SHALL be assigned only in contiguous immutable serial ranges, one range per batch; splitting a holding (through partial transfer or partial retirement) SHALL preserve every unit's serial identity and the immutability of the original range, and merging of serial ranges SHALL NOT occur (MCC-100 clause 4.13).

6.3 No serial number SHALL ever be reused, reassigned or modified, including after retirement, cancellation, migration or voiding of a batch.

6.4 Serial numbers SHALL be generated automatically by the registry during the issuance pipeline step SERIAL_NUMBERS_GENERATED; manual assignment, reservation or alteration of serial numbers is prohibited.

6.5 The semantic meaning of every code embedded in a serial number (instrument code, family code) SHALL be resolvable only through the Family-Map Register for the serial's epoch, as Schedule 1 provides; no consumer of serial data SHALL interpret embedded codes by any other means.

6.6 Any change to the semantics of instrument or family codes SHALL be executed only as an epoch transition under Schedule 1 Part D; a semantic change without an epoch transition is prohibited.

6.7 The registry SHALL validate every serial number against the machine-readable tests of Schedule 1 Part E on creation, on import and on every transaction touching it, and SHALL reject any non-conforming serial.

6.8 The check-digit algorithm of Schedule 1 (Luhn, as specified there) SHALL be applied to every serial number, and public verification surfaces (Section 17) SHALL validate check digits on lookup.

NOTE. This Section and Schedule 1 remediate finding 800-03 (the predecessor's Article 27, its component table and its Article 28 example prescribed three mutually inconsistent formats and labelled the family code "Methodology") and finding 800-07 (no batches, serial ranges or split events). The one-serial-per-unit model is retained — the platform records units individually with Luhn-checked serials — but every serial now exists only inside an immutable batch range, and quantity precision is whole units (clause 5.10).

7. Account management and customer due diligence

Account opening

7.1 A Registry Account of type GENERAL SHALL be opened only for a verified legal person that has: (a) completed the customer due diligence of clauses 7.5 to 7.12 with a positive determination; (b) accepted the Registry Terms of Use; and (c) designated at least one verified authorised representative.

7.2 Account onboarding determinations SHALL record: the applicant's verified legal identity; the assigned risk tier; the KYC status; the determination and its maker and checker (co-signed under clause 4.2); and the due date of the next periodic refresh.

7.3 An application SHALL be processed within ten business days of a complete submission: approved, returned with a documented request for further information, or refused with written reasons; a refusal notice SHALL state the available review route.

7.4 The detailed evidential procedure (forms, acceptable documents, verification methods, screening lists and record content) SHALL be set in the KYC and Account Procedure (Tier 5), which SHALL conform to this Section. The Registry KYC and Account Opening Procedure v1.0 is proposed for designation as that procedure (FD-2026-10-01 Schedule 1, Q12). Its notice period ended on 8 September 2026, and its closing protocol, published on 24 September 2026, recommends adoption, which rests on FD-2026-09-04 (recorded in the decision register as attested by the founder, with no executed copy filed); it is not entered in the document register as adopted, and whether a text may be adopted on an attested rather than a signed decision is referred to the Governing Board (MCC-CLS-2026-001 §B.1 and Part E item 4). (Consultation question 3.)

Customer due diligence (KYC/KYB)

7.5 Customer due diligence SHALL be risk-based and SHALL establish and verify, before account approval: (a) the legal existence, name, form, registration number and registered office of the entity; (b) the identity and authority of each natural person acting as a representative; (c) the identity of each ultimate beneficial owner, at the ownership or control threshold set in the KYC and Account Procedure, which SHALL NOT be set above twenty-five per cent; and (d) the nature and purpose of the intended registry activity.

7.6 Each account SHALL be assigned a documented risk tier on defined criteria (including jurisdiction risk, ownership complexity, sector exposure, sanctions proximity and expected transaction profile); the risk tier SHALL determine the depth of due diligence and the refresh cadence of clause 7.10.

7.7 Sanctions screening. The Account Holder, its ultimate beneficial owners, its representatives and any disclosed controlling parties SHALL be screened against the sanctions and watch lists designated in the KYC and Account Procedure: before account approval; on every change notified under clause 7.11; on each periodic refresh; and on relevant list updates. Each screening, its lists, date, matches and disposition SHALL be recorded.

7.8 A confirmed sanctions match SHALL result in immediate account suspension, blocking of all outgoing transactions, escalation under clause 4.7's decision route, and reporting to competent authorities where applicable law requires; a potential match SHALL block approval or transaction execution until dispositioned by a second reviewer.

7.9 Politically exposed persons among beneficial owners or representatives SHALL trigger enhanced due diligence and a higher risk tier.

7.10 Due diligence SHALL be refreshed periodically per risk tier, at intervals set in the KYC and Account Procedure and not exceeding: one year (high risk), two years (medium risk), three years (low risk); an account whose refresh is overdue SHALL be restricted from initiating transfers and retirements until refreshed.

7.11 Account Holders SHALL notify the registry function within five business days of any change to legal status, ownership or control, beneficial owners, representatives or contact details; unnotified material changes discovered by the Programme are a breach of the Registry Terms of Use.

7.12 Suspicious activity — including transaction patterns indicating wash trading, circumvention of controls, or use of the registry in connection with fraud, money laundering or sanctions evasion — SHALL be escalated to the Programme Secretariat's compliance monitoring function, investigated, and reported to competent authorities where applicable law requires (Section 25).

Representatives and authentication

7.13 Each Account Holder SHALL designate at least one primary and MAY designate additional authorised representatives; each representative SHALL be individually identified, verified and bound to a named natural person; shared, generic or role-mailbox identities are prohibited.

7.14 Every representative identity SHALL meet the authentication and identity-assurance requirements of the Information Security Standard, including multi-factor authentication before any write function and step-up authentication on decision and transaction-approval routes.

Account recovery

7.15 Credential recovery for a representative SHALL require out-of-band verification of the natural person's identity per the Information Security Standard; knowledge-based answers alone SHALL NOT suffice, and recovery SHALL never disclose or reset another representative's credentials.

7.16 Where an Account Holder loses access to all its representatives, account control SHALL be re-established only by a fresh verification of the legal entity and of the authority of the persons claiming control, at the depth of the account's risk tier, executed under maker-checker; no transfer or retirement SHALL be executed from the account until control is re-established and a post-recovery review of pending transactions is completed.

7.17 Every recovery event SHALL be logged in the audit trail, notified to all registered representative contacts of the account, and reported to the Registry Oversight Committee where units were moved within thirty days after recovery.

Suspension and closure

7.18 An account SHALL be suspended (state SUSPENDED) where: a confirmed sanctions match exists (clause 7.8); there are documented reasonable grounds of fraud, misrepresentation or breach of the Registry Terms of Use; recovery integrity is in doubt (clause 7.16); or an enforcement measure under MCC-700 Annex A rows 20 to 26 so requires.

7.19 Suspension SHALL be communicated to the Account Holder within twenty-four hours with grounds and the remediation or review route; a suspended account SHALL NOT initiate transfers or retirements, and its holdings remain visible on the public record.

7.20 Account closure (state CLOSED) SHALL require a nil unit balance — transferred or retired first — and settlement of outstanding fees; closure SHALL NOT extinguish the audit trail, the account's historical transactions or its retention obligations, which follow the Record Retention Schedule.

NOTE. This Section remediates finding 800-05 (no adequate UBO, legal-authority, AML/sanctions, recovery or suspicious-activity controls in the predecessor). Field-level alignment: the onboarding determination record of clause 7.2 corresponds to the implemented organisation KYC fields (risk tier, KYC status, determinations with co-sign, refresh due date) and clause 7.7 to the implemented sanctions-screening records. The KYC and sanctions-screening structures exist in the platform schema. Six project-developer organisations are recorded, every one with KYC status NOT_STARTED; no KYC determination and no sanctions screening has been recorded (Evidence Register ER-2026-001 §§A1, A3; registry measurement of 5 October 2026).

8. Issuance operations

8.1 Units SHALL be issued only through the registry issuance pipeline, whose states are exactly: REQUESTED → VERIFICATION_CONFIRMED → BUFFER_CALCULATED → SERIAL_NUMBERS_GENERATED → GOVERNANCE_APPROVAL → ISSUED, with REJECTED as the sole terminal failure state; no issuance SHALL occur outside this pipeline.

8.2 The issuance prerequisites are exactly those of MCC-100 clause 19.2 (the authoritative list, incorporated by reference and not restated); the registry SHALL require documentary evidence of each prerequisite to be attached to the issuance record, and the pipeline SHALL NOT advance to GOVERNANCE_APPROVAL until every prerequisite is evidenced.

NOTE. The predecessor's issuance workflow (v1.x Art. 39) included a "corresponding adjustment confirmation" step. No such step exists: Article 6 authorization and corresponding-adjustment evidence are recorded attributes, never issuance preconditions (MCC-700 clause 17.4; MCC-CADCP clause 8.3). Safeguards clearance, domestic-legality validity and Article 6 attribute recording remain issuance prerequisites via MCC-100 clause 19.2(b)–(d), evidenced within the pipeline states above rather than as separate pipeline states.

8.3 VERIFICATION_CONFIRMED SHALL be reached only upon a positive verification statement of a recognised VVB for the monitoring period concerned, linked in the Evidence Register (MCC-700 clause 16.1).

8.4 BUFFER_CALCULATED SHALL apply the buffer-pool contribution determined under the Tier 3 buffer standard (MCC-100 clauses 11.10 and 19.2(e)); the registry SHALL record the calculation inputs, the rate applied and its assessment reference.

8.5 SERIAL_NUMBERS_GENERATED SHALL create the batch's contiguous serial range under Schedule 1 for the exact quantity computed per MCC-100 clause 19.4 (verified quantity after deductions, rounded down to whole units), split into a project-account range and a buffer range.

8.6 GOVERNANCE_APPROVAL SHALL record the approval of the body designated in MCC-700 Annex A row 9, under maker-checker control (MCC-700 clause 16.1; Annex B row T-I); the approving identities SHALL be distinct from every identity that prepared the issuance request.

8.7 On transition to ISSUED, the registry SHALL atomically and indivisibly: (a) create the unit records with state ACTIVE (project-account range) and BUFFER (buffer range); (b) bind the serial ranges to the batch; (c) credit the project account and the Buffer Pool Account respectively; (d) set the batch state to ISSUED; and (e) write the issuance to the audit trail with full provenance; failure of any step SHALL roll back all of them.

8.8 A rejected issuance request SHALL move to REJECTED with each ground stated separately in writing, and carries the appeal rights of MCC-700 Annex B row T-I; a rejected request SHALL NOT be modified in place, and any renewed request SHALL be a new pipeline instance.

8.9 Every issuance SHALL be publicly disclosed within five business days, displaying the fields of MCC-100 clause 20.4 (MCC-100 clause 19.7).

8.10 No unit SHALL be issued while the issuance and serial-assignment freeze of MCC-100 clause 19.9 and MCC-001 clause 14.7 stands, and no unit SHALL be issued under a methodology whose status in the Methodology Status Register is other than APPROVED, or PILOT within the pilot rules of MCC-200 Section 13.

9. Transfer operations

9.1 Transfers between Registry Accounts SHALL be executed only through the transfer pipeline, whose states are exactly: INITIATED → ACCOUNT_VALIDATED → CREDIT_VALIDATED → CONFIRMED → COMPLETED, with REJECTED and CANCELLED as the terminal failure states.

9.2 A transfer SHALL be initiated only by an authorised representative of the transferring account, and confirmed at CONFIRMED by an authorised representative under step-up authentication (clause 7.14); where the transferring account's risk tier or the KYC and Account Procedure so requires, the confirming representative SHALL be a different natural person from the initiator.

9.3 ACCOUNT_VALIDATED SHALL verify that: both accounts exist and are ACTIVE; neither is suspended, restricted under clause 7.10 or blocked under Section 25; and the receiving account's due diligence is current.

9.4 CREDIT_VALIDATED SHALL verify that: the transferring account is the holder of record of every unit in the specified serial ranges; every unit is ACTIVE; no unit is flagged under clause 5.7 or subject to a lock or encumbrance recorded in the registry; and the quantity is a whole number matching the serial ranges.

9.5 On COMPLETED, the registry SHALL atomically re-record the holder of record for the transferred serial ranges, preserving serial identity and batch linkage, and write the transfer to the audit trail with transferring account, receiving account, serial ranges, timestamp and transaction reference.

9.6 Transfers SHALL be visible on the public record at the level of MCC-100 clause 20.4; Article 6 attributes, labels and flags travel with the units unchanged (MCC-CADCP clause 8.13), and no transfer SHALL be escrowed, time-locked or held pending any sovereign action except as MCC-CADCP clause 8.13 provides.

9.7 The maximum units per transfer transaction and any batch-splitting mechanics SHALL be set in the Registry Architecture Specification; a limit SHALL exist and SHALL be published.

9.8 A failed or rejected transfer SHALL leave the holder of record unchanged for every affected unit; partial execution of a transfer is prohibited.

10. Retirement operations and certificates

10.1 Retirement SHALL be executed only through the retirement pipeline, whose states are exactly: REQUESTED → CREDITS_VALIDATED → CREDITS_LOCKED → CONFIRMED → CERTIFICATE_GENERATED, with REJECTED as the terminal failure state.

10.2 Retirement SHALL be initiated only by an authorised representative of the holding account, and confirmed under step-up authentication; the request SHALL state the serial ranges, and MAY state a beneficiary, purpose and beneficiary country, whose recording and display follow clause 10.9.

10.3 CREDITS_VALIDATED SHALL apply the validations of clause 9.4 to the units to be retired; CREDITS_LOCKED SHALL place a lock preventing any concurrent transfer, retirement or other transaction on the affected units until the pipeline reaches a terminal state.

10.4 Retirement execution SHALL be atomic over all affected units, under row-level locking or an equivalent concurrency control: the state change ACTIVE→RETIRED, the retirement record and the audit-trail entry SHALL be committed together or not at all, and the same serial SHALL be incapable of appearing in more than one retirement or cancellation event (MCC-CADCP clauses 4.4 and 4.7).

10.5 Batch retirements SHALL be validated for serial uniqueness across the entire request before execution (MCC-CADCP clause 4.7).

10.6 Retirement is permanent and irreversible; no mechanism SHALL exist in the registry to reverse, reactivate, transfer or re-retire a retired unit (MCC-100 clause 21.1).

10.7 On CERTIFICATE_GENERATED, a retirement certificate SHALL be generated on demand from the registry record, carrying a unique certificate number; the certificate is derivative of the registry record, which prevails on any divergence (MCC-600 clause 6.4), and certificate regeneration SHALL always reproduce the current registry record.

10.8 Certificate content SHALL comprise exactly the fields fixed by MCC-100 clause 21.10, the certificate template SHALL be the template pre-approved under MCC-600 Section 13, and a certificate SHALL contain no eligibility conclusion and SHALL state Article 6 attributes factually per control table 5 (MCC-600 clause 6.3; MCC-CADCP clause 9.3).

10.9 The retiring account holder, retirement date, quantity, serial ranges and stated purpose category SHALL be public; beneficiary identity, beneficiary country, price and intended-use narratives SHALL be recorded where supplied and published only where lawful and consented or required (MCC-100 clauses 20.4 and 20.7; finding 800-11).

10.10 Retirement functionality for public claims SHALL remain disabled until MCC-600 is in force (MCC-100 clause 21.4); the registry SHALL enforce the disablement technically, and buffer and enforcement cancellations under Sections 11 and 12 are not retirements and are unaffected.

11. Cancellation

11.1 Cancellation SHALL permanently remove units from circulation without generating a retirement certificate or supporting any environmental claim; cancelled units take state CANCELLED, are recorded with their reason code, and remain permanently on the public record (MCC-100 clause 21.2).

11.2 Cancellation SHALL occur only on the following grounds: (a) a defect finding — material error, fraud or misrepresentation affecting the issuance of the specific units — decided under MCC-700 Annex A row 24 with the due process of MCC-100 clauses 23.4 to 23.6; (b) buffer draw to compensate a verified reversal, under the Tier 3 buffer standard and MCC-700 Annex A row 11; (c) voluntary cancellation at the written request of the holder of record; or (d) an enforcement measure under MCC-700 Annex A rows 20 to 26.

11.3 Withdrawal, suspension, regression or revision of a methodology SHALL NOT of itself cancel, invalidate or impair units validly issued under that methodology while it was approved; such units remain valid unless and until a defect finding under clause 11.2(a) is made for those specific units.

NOTE. This clause grandfathers validly issued units and remediates finding 800-08: the predecessor (v1.x Art. 51(b)) allowed cancellation on "revocation of methodology approval" alone, exposing holders to retroactive cancellation without any defect in their units. Under FD-2026-09-03 item D6, methodology regression holds projects (MCC-200 clause 16.5); it does not touch issued units.

11.4 Every cancellation SHALL be executed under maker-checker (clause 4.2), atomically per clause 10.4 applied with the state change ACTIVE→CANCELLED or BUFFER→CANCELLED, and written to the audit trail with its ground, decision reference and quantity.

11.5 Affected holders SHALL be notified before a cancellation under clause 11.2(a) or (d) takes effect, with the decision, its grounds and the appeal route per MCC-700 Annex A row 24; urgent cancellation without prior notice SHALL occur only where the decision record states why delay would defeat the measure, with notice immediately after.

12. Buffer pool accounts

12.1 The Buffer Pool Account SHALL be a single Programme-controlled account of type BUFFER_POOL holding all buffer units in state BUFFER; buffer units SHALL NOT be transferred, retired, sold, encumbered or claimed (MCC-BPM Section 8).

12.2 The registry SHALL record for the buffer pool the full record content of MCC-BPM clause 15.1 (pool account and balance; each contribution with project, date, quantity, serial range, rate and assessment reference; each draw and cancellation with reversal reference, cause code, quantity and liability status; each release with decision reference, quantity and destination; and each risk assessment).

12.3 Buffer contributions SHALL be created at issuance per clause 8.7; buffer draws and cancellations SHALL be executed only under the Tier 3 buffer standard through the decision routes of MCC-700 Annex A rows 10 and 11, under maker-checker, and published.

12.4 A buffer release SHALL execute the destination stated in the release decision — either cancellation (BUFFER→CANCELLED) or re-activation and transfer (BUFFER→ACTIVE) — as the Tier 3 buffer standard provides; the registry SHALL enforce that no release executes without the linked release decision reference and an explicit stated destination. This Standard states no preference between destinations; the choice between them is put to consultation in MCC-BPM v2.0-draft clause 11.6. (Consultation question 4.)

12.5 This Standard sets no buffer rate, adequacy method, release trigger or release schedule; those rules are fixed exclusively in the Tier 3 buffer standard, and the registry SHALL implement them as recorded decisions, not as automated policy.

NOTE. The predecessor's buffer clauses (v1.x Arts. 54, 57) hard-coded a 10–40% rate range and a "sustained permanence over at least 10 years" release trigger, conflicting with both the Buffer Policy and MCC-100 (Phase 0 inventory item 7). All rate and release rules are placed in one instrument — MCC-BPM as rewritten (v2.0-draft, put to consultation with this suite) — and this Standard carries only the account mechanics.

13. Article 6 attributes

13.1 The registry SHALL record the Article 6 facts of each unit and batch 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 (MCC-100 clause 16.8).

13.2 The default of every attribute SHALL be its control-table-5 default, and the default status of every unit is NOT AUTHORIZED FOR ARTICLE 6 / VOLUNTARY USE ONLY (FD-2026-09-03 item D3); the registry SHALL apply the defaults automatically at issuance.

13.3 The corresponding-adjustment reporting evidence attribute SHALL take only the values NO_EVIDENCE (default) and CA_EVIDENCE_RECORDED, and the registry SHALL technically block setting CA_EVIDENCE_RECORDED unless an evidence-document reference is linked (MCC-CADCP clause 8.7).

13.4 Attribute values SHALL be set and changed only through the procedure of MCC-CADCP clause 8.6 and the Host Country Authorisation Procedure, under maker-checker, with the underlying instrument reference recorded; no registry workflow — including retirement — SHALL set, advance or modify any Article 6 attribute as a side effect.

13.5 The registry SHALL display Article 6 attributes factually, per attribute, in the display form of MCC-CADCP clause 9.1; no screen, API response, certificate or export SHALL aggregate attributes into a composite eligibility label, and the retired labels and models listed in MCC-CADCP Annex A SHALL NOT appear anywhere.

13.6 The legacy corresponding-adjustment status model of the predecessor's Articles 58 to 62 (NOT_APPLIED / REQUESTED / CONFIRMED / REJECTED / NOT_REQUIRED, the CA reference-number record, and the certificate representation that credits with confirmed CA "may support international transfer claims under Article 6.4") is retired in full; migration of every legacy field and value SHALL follow Schedule 2, which executes MCC-CADCP Annex A row 2.

NOTE. This Section remediates finding 800-04 and SYS-07 for this Standard: MCC issues no Article 6.4 unit, cannot convert any unit into one, and records a corresponding adjustment only as a Party's documented accounting act (MCC-700 clause 17.6). The certificate language of the predecessor's Article 61 is extinguished by this Standard (control table 5 migration row; MCC-600 clause 10.3); until this Standard is adopted, the predecessor, Article 61 included, is recorded in the document register as in force.

13.7 MCC MAY provide a Party with registry extracts concerning units linked to activities in its territory as a recorded transparency service per MCC-CADCP clause 8.14; the registry SHALL support extract generation with an immutable record of what was provided, to whom and when.

14. Audit trail and data integrity

14.1 The registry SHALL maintain a comprehensive, append-only audit trail recording every registry transaction, state change, attribute change, due-diligence determination, permission change, override, migration step and administrative action.

14.2 Each audit record SHALL capture at minimum: a unique audit record identifier; the action type from the enumeration defined in the registry data dictionary; the actor identity and role (and, for maker-checker actions, both identities); the timestamp in UTC; the affected entity type and identifier; the previous and new values; the linked decision or evidence reference where one exists; and the originating network address.

14.3 Audit records SHALL be immutable: no audit record SHALL be modified, deleted or overwritten after creation, enforced at both storage level and application level; corrections SHALL be made only by compensating entries that reference the record they correct.

14.4 Audit-trail integrity SHALL be verifiable by cryptographic means (hash chaining or an equivalent integrity scheme specified in the Registry Architecture Specification), and integrity SHALL be verified at least quarterly with the result recorded and reported to the Registry Oversight Committee.

14.5 Audit records SHALL be retained per the Record Retention Schedule; archived audit records SHALL remain searchable and retrievable within forty-eight hours of an authorised request.

14.6 Backups of registry data SHALL be maintained, protected and tested per the Information Security Standard and the continuity requirements of Section 20.

15. Reconciliation

15.1 The registry SHALL enforce, and SHALL verify by automated invariant checks at least daily, the following invariants: (a) every unit has exactly one serial in exactly one batch range, and no serial appears twice; (b) every unit has exactly one state and one holder of record; (c) account balances equal the sum of their recorded serial-range holdings; (d) batch quantities equal the sum of their units by state, and batch states are consistent with unit states; (e) the Buffer Pool Account balance equals recorded contributions minus draws, cancellations and releases; and (f) no retired or cancelled unit appears in any active balance or in more than one terminal event.

15.2 A full reconciliation run — covering the invariants of clause 15.1, the audit-trail integrity check linkage, and consistency between the registry, the public surfaces of Section 17 and any published exports — SHALL be executed on a defined schedule at least monthly, and each run SHALL be recorded with its scope, method, result and any discrepancies.

15.3 On any discrepancy: the affected units, batches or accounts SHALL be flagged under clause 5.7 immediately; the discrepancy SHALL be escalated to the Registry Oversight Committee within one business day; and no transaction SHALL execute on flagged records until the discrepancy is resolved by a documented root-cause finding and, where data changed, a compensating audit-trailed correction under maker-checker.

15.4 A duplicate-serial or duplicate-retirement finding SHALL additionally be processed under MCC-CADCP clause 4.6 and Section 25.

15.5 Reconciliation results SHALL be reported to the Registry Oversight Committee at each of its meetings, summarised in the annual programme transparency report, and included in the annual independent registry audit scope (clause 4.6).

16. Workflow engine and notifications

16.1 The registry SHALL enforce all multi-step registry processes through a state-machine workflow engine implementing only: the pipelines of Sections 8, 9 and 10, the project lifecycle of MCC-700 Annex B, and the administrative workflows defined in the registry data dictionary; no workflow SHALL introduce states, transitions or gates beyond its defining source (MCC-700 clause 9.2).

16.2 Each workflow SHALL define its states, permitted transitions, triggering events, guard conditions and authorised roles, and every transition SHALL be recorded in the audit trail and visible to participants with a role in the workflow.

16.3 The workflow engine SHALL enforce the service levels fixed in MCC-700 Annex B and in this Standard, with escalation notifications on breach; workflow deadlines SHALL be suspended during a declared registry outage (clause 20.5).

16.4 The registry SHALL notify participants of events affecting them — including issuance, transfer receipt, retirement confirmation, account status changes, flag placement, due-diligence refresh due dates and maintenance windows — via the platform notification centre and registered email, with webhook delivery where an integration is registered.

16.5 Critical notifications (account suspension, unit cancellation, flag placement, security incidents affecting the participant, recovery events) SHALL be dispatched within fifteen minutes of the triggering event; delivery status SHALL be logged and failed deliveries retried and escalated.

17. Public transparency and open data

17.1 The registry SHALL be publicly searchable without login or fee by at least: serial number or range, project, proponent, methodology, family, host country, vintage, unit status and Article 6 attributes (MCC-100 clause 20.2), and SHALL display the project-level and unit-level fields of MCC-100 clauses 20.3 and 20.4.

17.2 All units, irrespective of status, SHALL remain permanently publicly searchable, and retirement and cancellation records SHALL be permanent and public (MCC-100 clause 20.5).

17.3 A public, read-only API SHALL provide machine-readable access to the fields of MCC-100 clauses 20.3 and 20.4, retirement records, and aggregate statistics, without authentication, under published rate limits and a published, semantically versioned interface contract (clause 23.4).

17.4 A public dashboard SHALL display aggregate issuance, retirement and cancellation totals by instrument type, methodology, family, host country and vintage, updated on a published cadence.

17.5 Public verification surfaces SHALL allow any person, without authentication, to verify: (a) a serial number or range — its existence, validity under Schedule 1 Part E including the check digit, unit state, project, vintage and Article 6 attributes; and (b) a retirement certificate — its certificate number against the authoritative registry record, per clause 10.7.

17.6 Complete registry data extracts (unit register, project register, retirement register, issuance register), limited to the public fields, SHALL be published as downloadable machine-readable exports regenerated on a published cadence.

17.7 All public registry data SHALL be released under the Creative Commons Attribution 4.0 International (CC BY 4.0) licence, and the licence SHALL be stated on every public surface and export.

17.8 Public surfaces SHALL publish the integrity-critical minimum of MCC-100 Section 20 and SHALL NOT publish personal data, beneficiary identity, price or intended-use narratives except per MCC-100 clause 20.7 and clause 10.9; every public field SHALL be classified in the registry data dictionary as mandatory-public, optional-public (lawful-basis gated) or non-public.

17.9 No public surface, API response, export, certificate or dashboard SHALL display any composite eligibility label, any retired status model value, or any wording on the prohibited-wording list of control table 6 (MCC-600 clause 11.2).

18. Privacy and data protection

18.1 Personal data SHALL be processed in the registry only for defined purposes (account verification, security, transaction integrity, legal compliance and participant communication), on a lawful basis, minimised to what each purpose requires, and in accordance with applicable data protection law and the MCC Privacy Policy. The MCC Privacy Policy is put to consultation with this suite as MCC-PRIV v1.0-draft and is not in force; no responsible privacy owner has been designated; and the applicable law depends on the Legal Entity's jurisdiction — the Programme's operating entity has not yet been incorporated (FD-2026-10-01 item 3) — and on the location of data subjects. (Consultation question 5.)

18.2 Records SHALL be retained and disposed of exclusively per the Record Retention Schedule; this Standard sets no retention period locally, and until the Schedule is in force no registry record SHALL be destroyed.

NOTE. The predecessor's local retention table and clauses (v1.x Section 14: credit unit records permanent; audit trail minimum 20 years; account records 10 years post-closure; workflow records 10 years; notification records 5 years; API logs 2 years; Arts. 38, 67, 88–90) are to be superseded by the Record Retention Schedule (MCC-810 v1.0-draft, put to consultation with this suite), which resolves the suite-wide retention conflicts deliberately (SYS-11). The Schedule carries each of these classes with its resolved period and the reason.

18.3 Data-subject rights (access, rectification, erasure, restriction, objection) SHALL be honoured per applicable law; where an integrity-critical registry record must be retained under the Record Retention Schedule, erasure SHALL be effected by the minimisation and de-identification mechanics of that Schedule rather than by deletion of the registry record.

18.4 Personal data SHALL NOT be embedded in permanent public records: public records SHALL identify Account Holders by their legal-entity name and account identifier, and natural persons SHALL appear on public surfaces only where they are the Account Holder acting in a business capacity or have consented.

18.5 A data protection impact assessment SHALL be completed for the registry before issuance is enabled, and reviewed on material change. None has been completed; none existed on 3 September 2026 (Evidence Register ER-2026-001 §B5). DPIA-2026-001, a first assessment of the registry and the AI Analysis Layer, was drafted on 4 September 2026 as a v1.0 draft: it is a draft assessment in the proposal set, excluded from this consultation because it proposes no rule (FD-2026-09-04 item 2; FD-2026-10-01 item 5); it has not been reviewed by a qualified data protection adviser; and it records of itself that it cannot be completed, and that this clause is not satisfied, until the controller is identified and such an adviser has been instructed to review it. FD-2026-09-04 item 5 (recorded in the decision register as attested by the founder, with no executed copy filed) resolved that no credit is issued before DPIA-2026-001 has been reviewed by a qualified data protection adviser.

19. Information security

19.1 The registry SHALL be operated in conformity with the MCC Information Security Standard, which is the single canonical source of the Programme's security controls: classification, access control, identity assurance, cryptography, key management, secure development, vulnerability management, security testing, logging and monitoring, incident response, vendor and cloud controls, and personnel security.

19.2 This Standard states no encryption protocol, algorithm, key length, authentication technology or security parameter; every registry security control SHALL trace to a control objective of the Information Security Standard, with the concrete implementation recorded in the Registry Architecture Specification.

NOTE. This ends the duplicated, divergent security clauses the audit found across the suite (SYS-11; 800-10) — including the predecessor's hard-coded "TLS 1.3 or later" against the Buffer Policy's "TLS 1.2+". Cryptographic baselines are stated in the Information Security Standard as current-good-practice requirements, not fixed protocol versions.

19.3 Access to registry decision and transaction-approval routes SHALL require the step-up identity assurance the Information Security Standard fixes for high-impact actions; the separation-of-duties evaluation of clause 4.3 and the override governance of clause 4.4 are security controls within the annual independent audit scope.

19.4 Registry security testing SHALL follow the cadence of the Information Security Standard, including independent penetration testing at least annually and before issuance is first enabled; a summary of each independent security assessment SHALL be published. No independent penetration test or independent security assessment of the registry has been performed (Evidence Register ER-2026-001 §B5); the audit of 1 October 2026 lists the penetration test among the work that no decision can unlock (docs/AUDIT-2026-10-01.md §4D). No unit has been issued other than the demonstration units archived on 31 August 2026, and FD-2026-09-04 item 5 (recorded in the decision register as attested by the founder, with no executed copy filed) resolved that no credit is issued before an independent penetration test has been completed and its findings addressed.

19.5 Security incidents affecting the registry SHALL be handled under the incident-response requirements of the Information Security Standard and Section 20, including participant and authority notification where required.

20. Service continuity, incident response and disaster recovery

20.1 The Registry Operator SHALL define and publish service objectives for registry availability, maintenance windows and support response in the Registry Architecture Specification; scheduled maintenance SHALL be announced in advance through the notification system.

20.2 The Registry Operator SHALL maintain a documented and tested business continuity and disaster recovery plan meeting the recovery objectives fixed in the Registry Architecture Specification under the Information Security Standard; the plan SHALL be exercised at least annually and the exercise outcome recorded.

20.3 Registry data SHALL be backed up with integrity verification and geographic redundancy per the Information Security Standard; restoration SHALL be tested at least annually.

20.4 A registry incident-response procedure SHALL define severity classes, roles, escalation, communication and evidence preservation, consistent with the Information Security Standard; incidents affecting data integrity SHALL additionally trigger the reconciliation actions of clause 15.3.

20.5 On an unplanned outage exceeding the published threshold, the Registry Operator SHALL: notify Account Holders with the expected restoration time; publish a status notice; and suspend running workflow deadlines until service is restored.

20.6 After any unplanned outage or security incident, a post-incident review SHALL be completed within ten business days, with root cause, impact (including any data-integrity impact) and remediation actions recorded and a summary published; material incidents SHALL be reported to the Registry Oversight Committee immediately and to the annual independent audit.

21. Registry continuity and wind-down

21.1 The Registry Operator SHALL maintain a registry continuity and wind-down plan, approved under MCC-700 Annex A row 31 and reviewed annually, covering: operator failure or insolvency; planned cessation; and transfer of the registry to a successor operator.

21.2 A complete, restorable copy of the registry record (units, batches, serials, accounts, transactions, attributes, audit trail and the Family-Map Register) SHALL be lodged with an independent escrow agent under a data-escrow agreement, refreshed at least quarterly, releasable to the Programme or a successor on defined trigger events. No escrow agent has been appointed and no data-escrow agreement exists, and none is proposed. (Consultation question 6.)

21.3 The wind-down plan SHALL provide that, on cessation of the registry for any reason: (a) no further issuance, transfer or retirement occurs after the announced cut-off; (b) the unit register, retirement and cancellation records remain publicly accessible, or are transferred to a successor or independent host that keeps them publicly accessible, for the periods the Record Retention Schedule fixes; and (c) holders receive defined notice and a defined mechanism for the disposition of remaining ACTIVE units.

21.4 Wind-down obligations SHALL be funded by a dedicated reserve or equivalent secured arrangement, sized and reviewed under MCC-700 Annex A row 31. The funding mechanism and its size are not decided, and no figure is proposed (FD-2026-10-01 Schedule 1, C6); the arrangement interacts with the buffer standard's insolvency and wind-down protections (MCC-BPM Section 13). (Consultation question 7.)

21.5 The participation agreements and Registry Terms of Use SHALL bind the wind-down protections of this Section in favour of Account Holders, so that they survive the Legal Entity's insolvency to the extent the governing law permits.

22. Cross-registry interoperability

22.1 No cross-registry transfer — a transaction by which a unit issued under MCC comes to be held, mirrored or represented in an external registry, or vice versa — SHALL occur except under a bilateral interoperability agreement, approved under MCC-700 Annex A row 32, that fixes for both registries the legal and technical protocol of clause 22.2. No such agreement exists at the date of this draft, and cross-registry transfers are accordingly prohibited.

22.2 Every interoperability agreement SHALL define, at minimum: (a) the authoritative-record rule for each unit at every moment, such that exactly one registry is authoritative for a unit at any time; (b) lock semantics — the unit is locked against all transactions in the sending registry before the receiving registry acts; (c) completion semantics — the sending registry cancels (burns) or permanently immobilises the unit upon confirmed acceptance, so the unit is never live in two registries; (d) failure and rollback semantics — a failed or unconfirmed transfer leaves the unit live in exactly the sending registry; (e) atomic status reconciliation between the registries, on a defined schedule, with a discrepancy procedure; (f) duplicate-claim prevention, including how retirement in one registry is reflected in the other; and (g) the double-counting and Article 6 attribute treatment per MCC-CADCP.

22.3 Each executed cross-registry transfer SHALL additionally require verification that no double counting will result and confirmation of the units' Article 6 attribute states, recorded with the transaction.

22.4 The registry SHOULD implement standardised public-data interoperability (metadata export conforming to recognised open registry-data models) where technically feasible; such export is a transparency measure and SHALL NOT move, mirror or represent units.

NOTE. This Section remediates finding 800-09: the predecessor permitted cross-registry transfers on a bare "interoperability agreement" without lock, burn, rollback, reconciliation or duplicate-claim rules (v1.x Arts. 84–87).

23. Change management and platform governance

23.1 Every change to the registry platform SHALL follow a documented change-management process classifying changes (routine, significant, emergency) with proportionate review, testing, approval and rollback provisions, under the secure-development requirements of the Information Security Standard.

23.2 Significant changes — including any change touching serial generation, unit states, pipelines, balances, attributes or public data semantics — SHALL be tested against the machine-readable tests of Schedule 1 Part E and the invariants of clause 15.1 before deployment, with the test evidence retained.

23.3 Registry source code SHALL be maintained in version control with a complete history, and every production deployment SHALL be traceable to the exact reviewed change set.

23.4 The public API SHALL be semantically versioned; breaking changes SHALL be published with a deprecation period of no less than six months and notified to registered API consumers.

23.5 Emergency changes MAY be deployed immediately where a critical security or integrity defect so requires, and SHALL be documented and reviewed within two business days.

24. Registry fees

24.1 Registry fees SHALL be set in the registry part of the published MCC Fee Schedule (the single fee instrument, adopted under MCC-700 Annex A row 33), covering at most: account registration, account maintenance, issuance, transfer, retirement and above-limit API or export services.

24.2 Fees SHALL be set to recover the reasonable costs of registry operation, security, support and development, and reviewed at least annually; fee changes SHALL take effect no earlier than ninety days after publication.

24.3 Fee waivers or reductions MAY be granted under published criteria (including for least-developed-country proponents and academic use) under MCC-700 Annex A row 33; no waiver SHALL be granted ad hoc or unrecorded.

24.4 Access to the public surfaces of Section 17 SHALL always be free of charge within the published rate limits.

25. Compliance monitoring

25.1 The registry function SHALL monitor registry activity for anomalous patterns, including unusual transaction volumes, transfers between related parties indicative of wash trading, structuring to circumvent controls, attempts to circumvent buffer requirements, and unauthorised access attempts; monitoring rules SHALL be documented and reviewed annually.

25.2 A suspected breach of this Standard, of the Registry Terms of Use or of MCC-CADCP SHALL be escalated to the Programme Secretariat's compliance monitoring function and processed under MCC-100 Section 23 through the decision routes of MCC-700 Annex A rows 20 to 26; this Standard creates no separate sanction ladder.

25.3 Pending investigation, temporary account restrictions (blocking outgoing transfers, suspending retirement requests, requiring additional verification) MAY be imposed under the decision route of clause 4.7 (MCC-700 Annex A row 29), communicated to the Account Holder within twenty-four hours with grounds and the review route.

25.4 Confirmed breaches involving suspected criminal conduct SHALL be referred to competent national authorities where the evidence and applicable law warrant it, following due process (MCC-100 clause 23.8).

26. Amendments

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

26.2 Every amendment SHALL be published as a changelog entry and a clean consolidated text stating the instrument that creates the resulting version number; no version designation SHALL exist without its creating instrument recorded.

26.3 Amendments to Schedule 1 SHALL additionally satisfy Schedule 1 Part F (specification versioning); an emergency amendment addressing a critical security vulnerability MAY take immediate effect and SHALL be ratified through the clause 26.1 route within sixty days.

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

27. Transitional provisions and entry into force

27.1 This Standard (MCC-800 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.

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

27.3 On entry into force, the predecessor text (v1.0/v1.1, indeterminate — see the baseline declaration) SHALL be formally superseded and archived as an uncontrolled historical record with a superseded watermark.

27.4 Issuance and serial assignment remain frozen per MCC-100 clause 19.9 and MCC-001 clause 14.7; the freeze SHALL NOT be lifted before: the canonical control tables are baselined; Schedule 1 is implemented and its Part E tests pass on the platform; the Schedule 2 migrations are complete with their reports filed; the controls of Sections 4, 7, 14 and 15 are implemented and evidenced (QA-13); and the clause 19.4 security assessment is completed.

27.5 The data migrations of Schedule 2 (Article 6 attribute fields; instrument-code retyping; family-code epoch transition; legacy-record flagging) SHALL be executed before any further registry action on an affected record; pending migration, affected records SHALL be flagged as legacy-format per MCC-100 clause 25.5.

27.6 At 5 October 2026 the live register holds no unit, no batch and no serial, and no unit has been issued other than the demonstration units archived on 31 August 2026. The archived demonstration cohort (schema demo_archive_20260831) holds 28,769 units across 6 batches, every serial prefixed MCC-DEMO-. No corresponding-adjustment record exists, live or archived, but every archived unit carries a value in the predecessor's corresponding-adjustment status field: NOT_APPLIED (27,246 units), NOT_REQUIRED (1,508), CONFIRMED (14) or REQUESTED (1), by registry measurement of 5 October 2026, which corrects Evidence Register ER-2026-001 §A3 (it records that no corresponding-adjustment status value of any kind has ever been recorded). Schedule 2 has no live migration subject (Evidence Register ER-2026-001 §§A1–A3; registry measurement of 5 October 2026).

27.7 The predecessor's phased-compliance regime (v1.x Arts. 107–110: Pilot/Alpha/Beta phases with reduced availability targets and relaxed thresholds) is not carried; no control of Sections 4, 6, 7, 8, 9, 10, 11, 13, 14, 15, 18 and 19 SHALL be relaxed for any launch phase, and service objectives are set in the Registry Architecture Specification without a phase calendar (SYS-12).

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

---

Schedule 1 — Versioned Serial Number Specification (normative)

Specification identity: MCC-800-S1, version SSPEC-2.0-draft (versioned with this Standard; amendment per clause 26.3 and Part F). This Schedule is the "versioned serial specification" referenced across the rewritten suite (MCC-100 clauses 4.12 and 19.5; MCC-700 Annex B row T-I; MCC-CADCP clause 4.2; MCC-BPM clause 15.1).

Part A — Design principles

S1.1 The serial number is an identifier, not a self-contained semantic statement: every code embedded in a serial SHALL be interpreted only through the Family-Map Register (Part C) for the serial's epoch, and never by the reader's assumption of what a code "means".

S1.2 The epoch mechanism exists because family and instrument semantics have already changed once (FD-2026-09-03 items D1 and D2: the family remap including the ghost-gear move from old F04 to new F03, and the MCU→MOU rename): a serial's meaning SHALL survive every future semantic change, because its epoch pins it to the register version that defines its codes.

S1.3 No serial has been validly issued at the date of this draft (issuance frozen; MCC-100 clause 19.9); epoch 1 exists only to give any legacy, DEMO or test serials a defined home and a defined migration (Part D). At 5 October 2026 no serial exists in the live register; each of the 28,769 serials of the archived demonstration cohort carries the MCC-DEMO- prefix and none carries an epoch segment, and no serial without that prefix is recorded in the live register, the archive or the audit log (Evidence Register ER-2026-001 §§A1–A2; registry measurement of 5 October 2026).

Part B — Serial format (epoch 2, current)

S1.4 Every serial number assigned at issuance SHALL conform to:

MCC[-DEMO]-E<epoch>-<Instrument>-<Family>-<CountryProject>-<Vintage>-<Sequence>-<Check>

Segment	Format	Content
Prefix	MCC	Programme identifier, constant
Demonstration flag	DEMO (optional)	Present only on demonstration serials, which SHALL never be issued as units, never carry value and never appear in issuance, transfer or retirement records
Epoch	E + integer ≥ 2	The semantic era of the serial's codes (Part D); currently E2
Instrument	CC | MOU	Instrument code per the Family-Map Register for the epoch (epoch 2: MCC-CC and MCC-MOU; the MCC-CB label is not a unit and has no serial)
Family	F + 2 digits	Methodology family code per the Family-Map Register for the epoch (epoch 2: F01–F05 per canonical control table 2)
CountryProject	ISO 3166-1 alpha-3 + 4 digits	Host-country code followed by the zero-padded project number
Vintage	4 digits	The Vintage year (clause 2.4)
Sequence	8 digits	Zero-padded sequence within project and Vintage; assigned contiguously per batch serial range
Check	1 digit	Luhn check digit per S1.5

NOTE — resolution of finding 800-03. The predecessor prescribed, in one document, ISO alpha-3 + 4-digit project + 8-digit sequence (Art. 27 and the Art. 28 example) and simultaneously a 2-letter country code + 6-digit sequence with the family column labelled "Methodology" (the component table). This Schedule resolves in favour of the Art. 27/example form: alpha-3 is unambiguous across the full country set, and an 8-digit sequence accommodates large batches without format change. The "Methodology" label is corrected — the segment is the methodology family; the methodology and version are batch-level registry fields, not serial segments.

S1.5 Check digit. The check digit SHALL be the standard Luhn (mod-10) check digit computed over the decimal expansion of the serial body, where: the serial body is every character of the serial after the constant MCC- prefix (including the DEMO flag where present and the epoch segment) excluding hyphens and the check digit itself; and each character expands to its base-36 value written as two decimal digits (0→00 … 9→09, A→10 … Z→35).

S1.6 Every registry surface, import and API SHALL validate serials against Part E; a serial failing format, register-resolution or check-digit validation SHALL be rejected and logged.

S1.7 A serial SHALL be unique across all epochs, projects, vintages and instruments, including DEMO serials; uniqueness SHALL be enforced at storage level.

Part C — Family-Map Register

S1.8 The Family-Map Register is a versioned controlled register, published with the registry data dictionary, that defines for each epoch: the valid instrument codes and their canonical instruments (control table 1), and the valid family codes and their canonical families (control table 2); each register version SHALL be bound to exactly one epoch, and each epoch SHALL have exactly one current register version.

S1.9 The epoch-2 register content SHALL be generated verbatim from canonical control tables 1 and 2: instrument codes CC = MCC-CC (Carbon Credit) and MOU = MCC-MOU (Marine Outcome Unit); family codes F01 coastal blue-carbon removals/restoration, F02 coastal blue-carbon avoided loss/protection, F03 sustainable fisheries and fishing-gear interventions, F04 marine pollution prevention/removal, F05 marine habitat and biodiversity conservation.

NOTE — GENERATED CONTENT. S1.9 reproduces verbatim its single sources, the Unit/Product Dictionary (canonical control table 1) and the canonical Family–Methodology–Instrument Matrix (canonical control table 2), both adopted under FD-2026-09-03 items D1 and D2. On any divergence, the source prevails and this reproduction is corrected; no local variation is permitted.

S1.10 The epoch-1 register content is the legacy semantics of the superseded corpus: instrument codes CC, HYB, MCU and family codes F01–F05 as used by the predecessor documents and platform before FD-2026-09-03. Because the corpus itself carried at least five divergent family semantics (collisions register C2), the epoch-1 register SHALL record the legacy meaning per source document and per platform enumeration, as catalogued in canonical control table 2.2, and SHALL mark every epoch-1 code "RETIRED — NOT VALID FOR ISSUANCE".

S1.11 Adding a new code to an epoch's register (for example a new family adopted by amendment of control table 2) SHALL increment the register version without an epoch transition, provided no existing code's meaning changes; changing or removing the meaning of any existing code SHALL require an epoch transition under Part D.

Part D — Epochs and migration rules

S1.12 An epoch is the semantic era of a serial: all serials of one epoch resolve their codes against that epoch's register version(s), permanently. Epochs are numbered consecutively from 1.

S1.13 Epoch 1 (legacy). A serial without an epoch segment is, by construction, an epoch-1 serial: the legacy formats of the predecessor (with instrument codes CC/HYB/MCU and pre-D2 family semantics) never carried one. Epoch-1 serials SHALL never be issued, validated as current, or transacted; any epoch-1 serial found in the registry (including DEMO and pilot serials) SHALL be flagged as a legacy-format record (MCC-100 clause 25.5) and migrated under S1.15.

S1.14 Epoch transition. A new epoch SHALL be created only by amendment of this Schedule (clause 26.3), and only where the meaning of an existing instrument or family code changes; the transition instrument SHALL fix: the new epoch number; the new register version; the mapping from every old code to its successor (generated from the applicable control-table migration, per activity meaning and never per code label); and the migration procedure and completion criteria. Codes SHALL never be remapped within an epoch.

S1.15 Migration of serials across an epoch boundary. A serial is never edited: migration SHALL retire the old serial (permanently flagged MIGRATED, never reused, per clause 6.3) and issue a successor serial in the new epoch to the same holder for the same unit, with a bidirectional cross-reference recorded immutably in the audit trail and visible on the public record of both serials. The migration SHALL be executed under maker-checker, and a migration report (counts per code mapping, exceptions, evidence outcomes) SHALL be filed in the Evidence Register and published in summary.

S1.16 The instrument-code mapping for the epoch 1→2 boundary SHALL be: CC→CC; MCU→MOU (rename, FD-2026-09-03 item D1); HYB→ no successor code — the instrument is abolished, and any existing HYB record SHALL be dispositioned per the Unit/Product Dictionary's retired-codes table and the holder re-papering of collisions register C3 before any successor serial is issued. The family-code mapping SHALL follow canonical control table 2.2 via activity meaning (including old F04 ghost-gear activities → new F03).

S1.17 Consumers of registry data SHALL treat the epoch segment as opaque versioning: a serial's codes SHALL always be resolved through the register for its own epoch, so that the meaning of every historical serial remains stable forever, whatever later epochs define.

Part E — Machine-readable tests

S1.18 The registry SHALL implement, and SHALL run in continuous integration and at Part B validation points, at least the following tests; the authoritative test suite SHALL be published with the registry data dictionary and versioned with this Schedule.

E-1 Format test (epoch 2). A current serial SHALL match:

^MCC(-DEMO)?-E[2-9][0-9]*-(CC|MOU)-F[0-9]{2}-[A-Z]{3}[0-9]{4}-[0-9]{4}-[0-9]{8}-[0-9]$

E-2 Register-resolution test. The instrument code, family code and country code SHALL each resolve against the Family-Map Register version for the serial's epoch (and the ISO 3166-1 alpha-3 code list); an unresolvable code fails.

E-3 Check-digit test. The Luhn computation of S1.5 SHALL verify. Reference vectors (all country/project values illustrative only, asserting no real project):

Vector	Serial	Expected
V1	MCC-E2-CC-F01-PHL0001-2027-00000001-3	valid
V2	MCC-E2-MOU-F03-PHL0001-2027-00000001-0	valid
V3	MCC-E2-CC-F02-KEN0002-2026-00000042-5	valid
V4	MCC-E2-MOU-F04-IDN0003-2026-00001000-6	valid
V5	MCC-DEMO-E2-CC-F02-KEN0002-2026-00000042-3	valid (DEMO flag participates in the check digit)
V6	MCC-E2-CC-F02-PHL0001-2027-00000001-3	invalid (single-segment mutation of V1; correct digit for this body is 1)

E-4 Uniqueness test. No serial, and no serial range, SHALL collide with any existing serial or range across all epochs (S1.7); range arithmetic SHALL be verified (range length equals batch quantity; ranges within a project and Vintage do not overlap).

E-5 Legacy-rejection test. A serial matching any epoch-1 (legacy) pattern — including the predecessor's documented forms and its worked example MCC-MCU-F03-PHL0001-2026-00000001-5 — SHALL be rejected for issuance and transaction, and accepted only into the migration workflow of S1.15.

E-6 Immutability test. No update path SHALL exist that alters a stored serial string; migration produces a successor record (S1.15), never an edit.

Part F — Specification versioning

S1.19 This Schedule carries its own specification version (SSPEC-x.y); a change to format, algorithm, tests or register mechanics increments the specification version through clause 26.3, and an epoch transition additionally follows S1.14. The specification version history, the epoch table and the Family-Map Register versions SHALL be published together, and every serial SHALL be interpretable using only published versions of the three.

---

Schedule 2 — Registry data migrations (normative)

S2.1 The migrations of this Schedule SHALL be executed under maker-checker, before any further registry action on an affected record (clause 27.5), each producing a migration report (counts per legacy value or code, evidence outcomes, exceptions) filed in the Evidence Register and published in summary (MCC-CADCP Annex A-4).

S2.2 Migration M-1 — Article 6 attribute fields. The legacy corresponding-adjustment status fields and values (the predecessor's Articles 58–62 enumeration NOT_APPLIED/REQUESTED/CONFIRMED/REJECTED/NOT_REQUIRED, and the legacy host-country status fields) SHALL be replaced by the discrete attribute fields of control table 5; every legacy value SHALL be migrated exactly per MCC-CADCP Annex A (rows 2 and 4), only to what its linked documentary evidence supports, with defaults and an audit-trail note preserving the legacy value otherwise. No legacy value SHALL be migrated on the strength of its label alone.

S2.3 Migration M-2 — instrument codes. Registry records typed MCC_MCU SHALL be re-typed MOU; records typed MCC_HYB SHALL be dispositioned per S1.16 (no successor type; holder re-papering per collisions register C3); records typed MCC_CC carry forward as CC. The live register holds no unit of any type, and no MCC-MCU unit has ever existed, in the live register or the archive. The archived demonstration cohort holds 8,700 MCC-HYB units, all on MCC-DEMO- serials: the archive records 6,743 active units in a general account archived with the cohort, 1,954 buffer units against the Programme's buffer-pool account and 3 units as retired, and the live register holds none of them (Evidence Register ER-2026-001 §A3; the holdings by registry measurement of 5 October 2026, which corrects that section's statement that no unit was held outside the demonstration organisations).

S2.4 Migration M-3 — family semantics and serials. Every record carrying a family code SHALL be re-keyed to the canonical family by activity meaning per canonical control table 2.2 (never by code label), and every existing serial (including DEMO and pilot serials) SHALL be migrated across the epoch 1→2 boundary per S1.15; pending migration, affected records are flagged legacy-format (MCC-100 clause 25.5).

S2.5 Migration M-4 — certificates and public text. Any issued certificate, confirmation or public registry text displaying a legacy CA status, an "Article 6.4" representation or an eligibility conclusion SHALL be recalled and reissued in conforming form per MCC-CADCP clause 12.5. Five retirements reached the status CERTIFICATE_GENERATED, all of them demonstration retirements of 15 units in total on MCC-DEMO- serials, archived on 31 August 2026; four carry a certificate number, and the ten units those four retired carry the value CONFIRMED in the predecessor's corresponding-adjustment status field (clause 27.6). The live register holds no retirement, so no certificate has been issued against a live serial (Evidence Register ER-2026-001 §A3; registry measurement of 5 October 2026).

S2.6 Completion of M-1 to M-4 is a precondition to lifting the issuance freeze (clause 27.4).

---

End of MCC-800 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 above and marked in the text.