MCC-850 — AI Governance Standard

Document control

Field	Value
Document code	MCC-850
Title	AI Governance 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 25.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 at the next meeting of the Governing Board), in particular item D8 (stay of the entry into force of MCC-850 Amendments 1–2 and MCC-400 Addendum 1). FD-2026-09-03 is recorded in the decision register as attested by the founder on 7 September 2026; no executed copy has been filed (the register at /governance/decisions shows its status).
Supersedes	The circulated consolidated text carrying cover "MCC-850 v1.2 — Consolidated text / In force from 17 August 2026" over two document-control blocks each reading "Version 1.1 (consolidated)" — reclassified by FD-2026-09-03 item D5; the document register records v1.2 as in force until this version is adopted, when its withdrawal as a controlled copy is executed (FD-2026-09-07 item A8: scheduled, not executed; 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, control-table field names and platform enumeration values are quoted verbatim and retain their spelling (for example "AUTO_SUBMISSION", "GOVERNANCE_ASSIGNED").
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 and version-identity resolution

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

1. The circulated PDF displays "Version 1.2 — Consolidated text" on its cover, while its front document-control table and its end DOCUMENT METADATA block each read "Version 1.1 (consolidated)" (Phase 0 source inventory, confirmed; audit finding 850-01/SYS-06).
2. The document's own Appendix B.1 amendment history lists two rows both numbered "1.1" (one for Amendment 1, one for Amendment 2); no row and no instrument creates a version 1.2, and both amendments' editorial notes direct their incorporation "into MCC-850 v1.1".
3. Appendix B.4 of the predecessor cites "MCC-400 v1.2", which does not exist (the corpus MCC-400 is v1.1); MCC-400's own Appendix A.5 cites "MCC-850 v1.1" against the v1.2 cover. The two consolidations cross-cite phantom versions of each other (850-01 CONFIRMED).
4. The predecessor asserts "In force from 17 August 2026" while its Article 43 conditions effect on approval by an "MCC Board of Directors" — a body name appearing nowhere else in the suite — and a Board-designated implementation date, neither of which is evidenced (evidence gaps E24, E25, E38).

Resolution. This version 2.0-draft is declared the new baseline of MCC-850. It consolidates, where retained, the substance of MCC-850 v1.0 (23 March 2026) as amended by Amendment 2 v1.0 (recorded as adopted on 17 August 2026 in MCC-BDR-2026-002, which is recorded in the decision register as unsigned, and expressed to be in force on that date) and as amended by Amendment 1 v1.0 (recorded as adopted on 17 August 2026 in the same record; expressed to enter into force 17 September 2026; that entry into force is stayed by FD-2026-09-03 item D8 and Amendment 1's operative regime never took effect). What survives of each amendment, and what does not, is stated in the amendment-disposition note below. The un-instrumented "v1.2" designation is not adopted, perpetuated or legitimised; version 2.0 is used precisely so that no reader can mistake this text for either disputed predecessor identity. The predecessor, reclassified by FD-2026-09-03 item D5, is recorded in the document register as in force (as v1.2) until this version is adopted, when the withdrawal of its PDF as a controlled copy is executed (FD-2026-09-07 item A8: scheduled, not executed) and the PDF is archived as a superseded record with both printed identities noted.

Amendment disposition (honest attribution)

Instrument	Status at 3 September 2026	Disposition in this draft
Amendment 2 v1.0 (Automated Completeness Report, Applicant Disclosure and Degraded Mode)	Recorded as adopted 17 August 2026 in MCC-BDR-2026-002, which is recorded in the decision register as unsigned, and expressed in force on adoption: MCC-BDR-2026-002 decision D-2026-08-02 states “Entry into force: 17 August 2026”, while the 17 September 2026 date belongs to D-2026-08-10 (MCC-850 Amendment 1) and D-2026-08-11 (MCC-400 Addendum 1), which the same record expressly distinguishes (“Unlike D-2026-08-01 and D-2026-08-02, this Amendment does not enter into force on adoption.”). On that record Amendment 2 took effect on adoption; the stay under FD-2026-09-03 item D8 applies on either reading and nothing is revived; and the record is an unsigned draft, so the adoption itself is unevidenced (Evidence Register ER-2026-001 §§B1, B4); further effect stayed by FD-2026-09-03 item D8	Substantially carried forward, re-drafted: Automated Completeness Report (Section 10); communications boundary (clause 6.10–6.12); Degraded Mode (clauses 6.13–6.20); trigger-source labelling (Annex B); analysis-not-a-review-step rule (clause 12.4). Not carried: the Prioritised Sequencing Flag — abolished, because MCC-100 v3.0 clause 13.14 establishes queue neutrality and audit finding 850-06 identifies the fairness defect.
Amendment 1 v1.0 (Repeal and Replacement of Article 28 — structured AI visibility to VVBs on engagement assignment)	Recorded as adopted 17 August 2026 in MCC-BDR-2026-002, which is recorded in the decision register as unsigned; entry into force 17 September 2026 stayed by FD-2026-09-03 item D8; never in force	Core regime not carried: pre-conclusion AI visibility to VVBs is rejected (audit 850-05, 400-06; the v1.0 blind rule was the sounder design and is restored in strengthened form in Section 11). Surviving elements carried, re-enacted in blind-first-pass form: VVB access logging (clause 11.8); pre-submission visibility exclusion (clause 11.9); developer-visibility parity (clause 11.10); statistical engagement-pattern monitoring, reworked to outcome-based review per 850-07 (clause 17.9).

Change history

Version	Date	Change	Instrument
1.0	23 March 2026 (printed)	Base text, Articles 1–45 and confidence-tier decision matrix; printed "In force"	No approval record by the "MCC Board of Directors" named in the predecessor's Article 43 exists, and no body of that name appears anywhere in the governance architecture; evidence gap E25 stands (Evidence Register ER-2026-001 §§B1, B3).
1.1	17 August 2026 (printed)	Amendments 1 and 2 recorded as adopted and directed to be consolidated into v1.1; Amendment 2 expressed in force on adoption; Amendment 1 expressed to enter into force 17 September 2026	Printed as decisions D-2026-08-10 and D-2026-08-02, Governing Board, Article 5 procedure, record MCC-BDR-2026-002. MCC-BDR-2026-002 exists only as an unsigned draft with blank attendance, apologies, chair, quorum count and voting tallies; it records a Governing Board meeting of 17 August 2026 — nine days before the Board was constituted on 26 August 2026 — and states of itself that it is drafted from the resolutions as reported, so the adoption it is cited for is unevidenced (Evidence Register ER-2026-001 §B1).
"1.2"	—	Cover designation on the circulated consolidated file; no creating instrument exists; Appendix B.1 contains two rows both numbered 1.1	None known — identity defect resolved by the baseline declaration above. No such instrument exists: version designations across this corpus — MCC-100 “v2.2”, MCC-850 “v1.2”, MCC-800 “v1.1” and MCC-M008 “v1.1” — were advanced editorially without an adopting instrument; the pattern is systematic, not incidental, and this revision resets it: the instrument, not the file, sets the version (Evidence Register ER-2026-001 §B3 and Part C).
—	3 September 2026	Entry into force of Amendment 1 (and MCC-400 Addendum 1, and further effect of Amendment 2) stayed	FD-2026-09-03 item D8
2.0-draft	3 September 2026	Full rewrite against the independent audit of 3 September 2026 (findings 850-01 to 850-12 and SYS findings as applicable) and FD-2026-09-03 items D1–D8: decision-rights architecture cited from MCC-001/700/100; use-case register introduced; fixed generic confidence scores replaced by use-case-specific Review Confidence Indices with tier provenance; the unevidenced 50-PDD reference-dataset and 90%-concordance claims deleted and replaced by validation-evidence requirements; carbon-centric completeness rubric replaced by per-instrument/per-family schemas with the safeguards component regenerated from MCC-ESS SR1–SR12; VVB blind first pass restored and strengthened; prioritised sequencing abolished; data cards, privacy and lawful-basis requirements added; local retention periods and hard-coded security technology removed in favour of the Record Retention Schedule and Information Security Standard; alternative document hierarchy deleted	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, certification, dataset, test result, operational history or performance level 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 4.6 — Legacy recommendation field. Proposed: the legacy recommendation field is retained, sealed, and used solely for post-decision calibration comparison; it is not retired from the record schema at the next platform schema revision. Basis: FD-2026-10-01 Schedule 1 (Q21). Decided by: the Governing Board on adoption of the suite. Comments are invited on whether the sealed field should instead be retired, ending its calibration use.

2. Clause 8.9 — Bridging confidence cap. Proposed: MEDIUM for each currently deployed use case, as a bridge until validation evidence exists; it is not a validated threshold. Basis: FD-2026-10-01 Schedule 1 (Q17). Decided by: the Governing Board on adoption of the suite. Comments are invited on whether MEDIUM is the right ceiling while no calibration evidence exists.

3. Clause 8.11 — Recalibration thresholds. Proposed: no proposal is made — no threshold has a validated basis, so per-use-case thresholds are carried as open questions, not requirements; the predecessor's global figures, an override rate above 25% in two consecutive quarters and accuracy below 85%, are put only as candidates for comment. Basis: FD-2026-10-01 Schedule 1 (Q18). Decided by: the Governing Board on adoption of the suite. Comments are invited on which divergence-rate or error signals should trigger recalibration of each use case, and at what level.

4. Clause 15.9 — Controller, data protection officer and model providers. Proposed: no proposal is made on the controller's identity and particulars, on a data protection officer, or on the transfer mechanisms for model providers and sub-processors: each depends on the incorporation of the Programme's operating entity, which has not yet been incorporated and for which a Norwegian aksjeselskap (AS) is proposed (FD-2026-10-01 item 3 and Schedule 1, C1). Basis: FD-2026-10-01 item 3; FD-2026-09-04 item 6 (recorded in the decision register as attested by the founder, with no executed copy filed). Decided by: the Governing Board on adoption of the suite; the entity's name and jurisdiction, and whether applicant documentation may be transmitted to an external model provider, are reserved to the Board (FD-2026-09-04 item 6). Comments are invited on the arrangements the Programme should record once the entity exists.

5. Clause 17.3 — Accuracy and agreement targets. Proposed: targets for each use case are set with the first calibration report for that use case; no figure is proposed now, and the predecessor's agreement figure, which was never validated, is not carried forward. Basis: FD-2026-10-01 Schedule 1 (Q19). Decided by: the Governing Board on adoption of the suite. Comments are invited on how the targets should be set and published.

6. Clause 17.5 — Bias-test thresholds. Proposed: per-use-case disparity metrics and action thresholds, adopted with the first bias-test protocol; no threshold is asserted now, and no bias-test result exists. Basis: an open decision carried in the draft (FDP-2026-001 Part 3). Decided by: the Governing Board on adoption of the suite. Comments are invited on the metrics and thresholds the first protocol should use.

7. Clause 18.6 — Material and minor model changes. Proposed: the boundary between a material change, approved under MCC-700 Annex A row 34, and minor tuning that the Programme Secretariat may execute within pre-approved ranges is fixed per use case in the use-case register. Basis: an open decision carried in the draft (FDP-2026-001 Part 3). Decided by: the Governing Board on adoption of the suite. Comments are invited on where the boundary should lie.

8. Clause 25.3 and Annex A, A.2 — Use cases already deployed. Proposed: a use case deployed on the platform before this Standard enters into force, including UC-08 to UC-10, may run in advisory mode until the consultation on this Standard closes, and is then suspended unless approved. Basis: FD-2026-10-01 Schedule 1 (Q20). Decided by: the Governing Board on adoption of the suite. Comments are invited on whether advisory operation during the consultation is acceptable, and on the conditions it should carry.

9. Annex A, UC-08 to UC-10 — Proposed use cases. Proposed: UC-08 (methodology guidance grounded in register facts), UC-09 (PDD structuring support) and UC-10 (pre-submission draft precheck) are approved as register entries on the terms stated in each row. Basis: an open decision carried in the draft (FDP-2026-001 Part 3); under MCC-100 clause 22.2, use cases beyond those it lists are approved under this Standard (A.0). Decided by: the Governing Board on adoption of the suite. Comments are invited on each entry and its conditions.

Table of contents

1. Purpose, scope and application
2. Normative references, definitions and interpretation
3. Position in the document hierarchy and governance interface
4. Decision-rights architecture
5. AI use-case register
6. System architecture and operational boundaries
7. AI Assessment Records and logging
8. Calibration and Review Confidence Indices
9. Assessment schemas and the safeguards rubric
10. Applicant-facing outputs and disclosure
11. Interface with validation and verification: blind first pass
12. Queue neutrality, escalation and human review periods
13. Public transparency
14. Data governance, data cards and external data sources
15. Privacy and data protection
16. Security and retention
17. Performance and bias monitoring
18. Model change governance and validation
19. Incident management and model risk
20. Human review, reasons and appeals
21. Prohibited uses
22. Independent audit
23. Legal applicability assessment
24. Review and amendment
25. Entry into force and transitional provisions

Annex A — AI Use-Case Register (normative) Annex B — AI Assessment Record minimum schema (normative field semantics) Annex C — Safeguards rubric component (generated from MCC-ESS)

---

1. Purpose, scope and application

1.1 This Standard (MCC-850) SHALL govern every artificial-intelligence and machine-learning system, and every deterministic heuristic substituting for such a system, used in or for the MCC Programme, including systems operated by the Programme, by its contractors, or on the Programme's platform.

1.2 This Standard applies to MCC staff, the Programme Secretariat, every governance body, contracted Validation and Verification Bodies (VVBs), project applicants and developers using Programme-provided AI features, and every vendor or processor operating an in-scope system.

1.3 The objectives of this Standard are that: AI systems operate only within registered, bounded use cases; humans retain final decision authority on all substantive matters; AI outputs are auditable, logged and honestly labelled; confidence representations are calibrated per use case and never overstated; and affected persons can obtain human review and human-readable reasons.

1.4 An AI system, output or practice not expressly permitted by this Standard and registered under Section 5 SHALL NOT be deployed in the Programme.

1.5 Precedence is governed by MCC-001 Section 2.

NOTE. The predecessor's guiding slogan "AI-First, Human-Final" is not carried. The governing principle of this Standard is stated in clause 4.1 and derives from MCC-001 clause 5.4: AI systems are assistive tools; humans decide.

2. Normative references, definitions and interpretation

2.1 The following documents are normatively referenced: MCC-001 (Constitution of the Marine Conservation Credits Programme); MCC-100 (Programme Standard), in particular Sections 13, 18 and 22; MCC-700 (Governance and Appeals), in particular Section 20 and Annexes A and B; MCC-400 (Validation and Verification Body Standard), in particular its blind first-pass requirements; MCC-600 (Claims Code); the Environmental & Social Safeguards Policy (MCC-ESS), in particular clause 4.1 and Annex B; the MCC Record Retention Schedule; the MCC Information Security Standard; and the canonical control tables adopted under FD-2026-09-03.

2.2 Per MCC-001 clause 2.5, any requirement of this Standard that depends on a referenced instrument not yet published and listed in the Document Register — at this draft, the Record Retention Schedule, the Information Security Standard and MCC-400 v2.0 — is ineffective until that instrument is available.

2.3 For the purposes of this Standard:

2.3.1 AI system means a machine-based system that, for explicit or implicit objectives, infers from input how to generate output such as analysis, classifications, scores, flags, structured drafts or text, and includes the AI Engine;

2.3.2 AI Engine means the Programme's server-side analysis component that performs the registered use cases in Annex A;

2.3.3 AI Assessment Record means the complete stored output of an in-scope system for one invocation, with the minimum fields of Annex B;

2.3.4 Automated Completeness Report means the applicant-facing extract of an AI Assessment Record specified in clause 10.3;

2.3.5 use case means a registered, bounded application of an AI system defined by purpose, inputs, outputs, calibration requirement and human control, per Section 5;

2.3.6 Review Confidence Index (RCI) means the use-case-specific, evidence-calibrated index defined in Section 8; it replaces the predecessor's generic "Confidence Score";

2.3.7 confidence tier means the categorical tier (HIGH, MEDIUM, LOW, VERY_LOW) recorded on an AI Assessment Record under Section 8;

2.3.8 tier provenance means the recorded origin of a confidence tier: MODEL_REPORTED (asserted by the model within governed bounds) or GOVERNANCE_ASSIGNED (assigned or capped by a rule of this Standard or the use-case register);

2.3.9 recommendation-class output means any output that states or implies that a matter reserved to human decision should be approved, rejected, registered, issued or otherwise decided in a particular way, whether expressed as an enumerated value, score, paraphrase, colour, badge or any representation from which such a disposition may be inferred;

2.3.10 Degraded Mode means operation under clauses 6.13 to 6.20 in which a labelled deterministic heuristic substitutes for model analysis;

2.3.11 trigger source means the classification of an AI Assessment Record as machine-initiated (AUTO_SUBMISSION) or human-initiated (STAFF_REQUEST);

2.3.12 divergence means a human decision that departs from an AI flag, score or analysis, recorded under clause 7.7 (the predecessor's "Override");

2.3.13 data card means the documented description of a dataset required by clause 14.2;

2.3.14 validation set means a documented, versioned dataset used to calibrate or test a use case under Section 8 or Section 18; and

2.3.15 escalation level means the recorded level, path and review deadline attached to an AI Assessment Record under clause 12.5.

2.4 Other capitalised terms have the meanings in the MCC Definitions Register; a term defined there SHALL NOT be redefined here.

3. Position in the document hierarchy and governance interface

3.1 This Standard is a Tier 3 domain standard under the Document Hierarchy & Precedence Register adopted under FD-2026-09-03 item D5; the hierarchy is defined exclusively by that register and MCC-001 clause 12.1, and this Standard defines no hierarchy of its own.

NOTE. The predecessor's Article 3 hierarchy (Tier 1 "Board Strategic Direction" … Tier 5 "Guidance & FAQs"), which omitted the Constitution and contradicted MCC-001, is deleted (audit SYS-04).

3.2 Governance of the Programme — bodies, mandates, decision rights, delegated authority, appeals and complaints — is established exclusively by MCC-001 Section 9 and MCC-700; this Standard SHALL NOT create, name or empower any governance body, and every decision it references is owned by the body designated in MCC-700 Annex A.

NOTE. The predecessor's "Technical Committee", "AI Governance Committee", "MCC Board of Directors", "Governance Board" and "Programme Administrator" role assignments are not carried. In this Standard: administration of AI operations sits with the Programme Secretariat within delegated authority; standard and use-case approvals follow the RACI row for programme-standard adoption; independent AI audits are received and reviewed by the Registry Oversight Committee (MCC-700 clause 20.6); appeals lie to the Independent Appeals Panel.

3.3 Nothing in this Standard SHALL be read as qualifying, and every in-scope system SHALL comply with, MCC-001 clause 5.4, MCC-700 Section 20 and MCC-100 Section 22, which are cited and not restated.

4. Decision-rights architecture

4.1 An AI system SHALL NOT make, and SHALL NOT be the deciding input to, any decision on project approval or registration, credit issuance, retirement or cancellation, safeguards, methodology status, VVB recognition, enforcement, appeals, or any other matter affecting the rights or obligations of any person; every such decision SHALL be made by the human decision-maker with authority under MCC-700 Annex A (MCC-001 clause 5.4; MCC-700 clause 20.1; MCC-100 clause 22.1).

4.2 No output of an AI system SHALL be self-executing; no state transition in the project lifecycle, registry or any Programme workflow SHALL be initiated, executed or advanced by an AI system (MCC-700 Annex B rule B-6).

4.3 Every human decision on a matter analysed by an in-scope system SHALL be taken through the Programme's designated decision route, which SHALL enforce step-up authentication and separation of duties between the person requesting and the person deciding, and SHALL write the decision to the human-decision record of Annex B.

4.4 The service account under which any AI system operates SHALL hold no decision, write or state-transition permission other than the creation of AI Assessment Records, per clause 6.4.

4.5 An AI system SHALL NOT generate a recommendation-class output in any registered use case.

4.6 Where a deployed system's record schema retains a legacy recommendation-class field, that field SHALL be sealed: it SHALL NOT be displayed to any applicant, to any VVB, to the Independent Governing Board, or to any person before that person's first-instance assessment or draft conclusion on the matter is recorded; it SHALL NOT be an input to any decision; and it MAY be used solely for post-decision calibration comparison under Section 17. The field SHALL be retained, sealed, for that comparison. (Consultation question 1.)

4.7 An AI confidence tier, RCI value or any other AI output SHALL NOT reduce the minimum evidence, sampling, scrutiny, consultation or verification applied by any human reviewer or VVB (MCC-700 clause 20.4; MCC-100 clauses 18.6 and 22.6).

4.8 An AI output MAY add scrutiny — by raising flags, questions or escalation levels — and SHALL only ever operate in that direction; no AI output SHALL relax, shorten or waive any requirement, stage or period.

5. AI use-case register

5.1 The Programme SHALL maintain the AI Use-Case Register in Annex A as the single normative inventory of permitted AI use; every entry SHALL state the use case's purpose, permitted inputs, permitted outputs, calibration requirement and human control.

5.2 An AI capability SHALL NOT be deployed, and an existing capability SHALL NOT be materially extended, except under a register entry with status APPROVED, adopted through the amendment procedure of Section 24 (satisfying MCC-100 clause 22.2, which requires approval under this Standard for any use case beyond those it lists).

5.3 Each register entry SHALL bind the use case to the assessment schema (Section 9), RCI (Section 8) and disclosure rules (Sections 10 and 13) applicable to it.

5.4 A use case whose register entry lapses, is suspended under Section 19, or whose calibration conditions under clause 8.9 are not met, SHALL be limited to flagging matters for human assessment and SHALL produce no other operative output (MCC-100 clause 22.4).

5.5 The register, including each entry's status and calibration-evidence references, SHALL be published (clause 13.2).

6. System architecture and operational boundaries

6.1 Every in-scope system SHALL operate read-only against Programme data: it MAY read the records its register entry permits and SHALL write no record other than AI Assessment Records.

6.2 An AI system SHALL NOT send external communications, select notification recipients, compose notification content, or determine whether a notification is sent.

6.3 An AI system SHALL NOT access external services, registries, APIs or web content except an external source listed in the approved external-source register under clause 14.6.

6.4 The AI service account SHALL be configured with read-only database permissions plus write permission limited to AI Assessment Record creation, SHALL hold no decision permissions (clause 4.4), and SHALL be audited at least quarterly for unauthorised access attempts, with findings reported under Section 19 where material.

6.5 Model identity SHALL be pinned: every invocation SHALL run against a declared model identifier and version, and a change of model or version is a model change governed by Section 18.

6.6 Prompt templates SHALL be versioned artefacts under change control; every invocation SHALL record the versioned prompt template identifier used for its trigger source (Annex B).

6.7 Every input document or payload analysed SHALL be identified in the AI Assessment Record by a cryptographic hash (SHA-256) so that the exact analysed content is verifiable after the fact.

6.8 System availability targets, failover and disaster-recovery objectives are operational parameters and SHALL be set in a Tier 5 operational procedure, not in this Standard; the procedure SHALL NOT weaken any requirement of this Standard.

NOTE. The predecessor's hard-coded service levels (Article 8: <4 h, <2 h, <1 h), uptime figure (99.9%) and RTO are moved to the Tier 5 procedure per audit §6.3 (no operational parameters hard-coded in high-level policy). The predecessor's <1 h "final compliance check before credit issuance" trigger is not carried as a gate of any kind: no AI check is a precondition, substitute or accelerant for any issuance prerequisite (MCC-100 Section 19).

6.9 Where an analysis is executed within a submission request, its completion is not a review step, does not start or shorten any period allowed to a human reviewer, and does not advance the project (MCC-100 clause 13.14; clause 12.4).

Communications boundary

6.10 Notifications informing an applicant, a reviewer or a VVB that an analysis is available SHALL be generated only by the platform's deterministic, template-driven notification service, invoked by a recorded state change or record creation and never by an AI system.

6.11 No notification SHALL transmit any item withheld under clause 10.5 or Section 11.

6.12 Every notification derived from an AI Assessment Record SHALL carry the advisory label of clause 10.4 and SHALL be logged with recipient, template identifier, timestamp and source record.

Degraded Mode and honest unavailability

6.13 Where the model provider is unavailable, unauthenticated, rate-limited or fails to return a valid response within the configured timeout, the platform MAY produce a deterministic heuristic analysis in place of a model analysis, so that a submission is neither blocked nor silently unanalysed; such operation is Degraded Mode.

6.14 A Degraded Mode record SHALL carry a model-version identifier identifying it as heuristic output and a label sufficient to identify Degraded Mode on every surface on which the analysis appears, to staff and applicant alike.

6.15 A Degraded Mode record SHALL be assigned a confidence tier no higher than LOW, with tier provenance GOVERNANCE_ASSIGNED.

6.16 A Degraded Mode record SHALL NOT generate any recommendation-class output and SHALL NOT satisfy, relax or accelerate any requirement.

6.17 Degraded Mode records SHALL be excluded from calibration, accuracy, divergence-rate and bias metrics under Sections 8 and 17, and SHALL be counted and reported separately under Section 13.

6.18 Continuous Degraded Mode operation exceeding twenty-four hours SHALL be treated as an incident under Section 19.

6.19 On restoration of the provider, the Programme Secretariat MAY cause a submission analysed in Degraded Mode to be re-analysed; the Degraded Mode record SHALL be retained and the re-analysis recorded as a new record referencing its predecessor.

6.20 Where neither model analysis nor the heuristic can be produced, the platform SHALL return an honest service-unavailable response stating that analysis is unavailable; it SHALL NOT fabricate an analysis, return a placeholder styled as an analysis, or silently defer the submission.

7. AI Assessment Records and logging

7.1 Every invocation of an in-scope system SHALL produce an AI Assessment Record containing at minimum the fields of Annex B, including: model identifier and version; versioned prompt template identifier per trigger source; SHA-256 hash of every analysed input; analysis timestamps; confidence tier with tier provenance; escalation level, path and review deadline; and Degraded Mode status.

7.2 AI Assessment Records SHALL be stored in the immutable append-only audit store; no record SHALL be deleted or modified after creation, and corrections SHALL be recorded as new records referencing their predecessor.

7.3 AI Assessment Records SHALL be retained for the period the MCC Record Retention Schedule fixes for their record class; this Standard sets no retention period of its own.

NOTE. The predecessor's "Minimum 10 years; permanent retention recommended" (Article 20) and "version history retained permanently" (Article 11) are deleted (audit 850-10; SYS-11). Permanent retention of records containing personal data conflicts with data-minimisation obligations; the tension is resolved by the Record Retention Schedule, which fixes duration, lawful basis and deletion per record class, and to which clause 16.2 defers.

7.4 Every access to an AI Assessment Record by any user SHALL be logged with user identity, role, timestamp and the output viewed.

7.5 Every AI Assessment Record SHALL be linkable to the final human decision on the matter it analysed, held in the human-decision record.

7.6 Human decisions SHALL be written to a dedicated human-decision record through the decision route of clause 4.3, capturing decision, decider identity and role, timestamp, and the reasons relied on.

7.7 Where a human decision diverges from an AI flag, score or analysis, the divergence SHALL be recorded with the decision-maker's own reasons for the decision.

7.8 A divergence rationale documents the decision; it SHALL NOT be framed, reviewed or scored as a justification owed to the AI system, no minimum length applies, and no reason for divergence is inadmissible; divergence data SHALL be used for model calibration under Section 17 and SHALL NOT of itself ground any adverse assessment of the decision-maker.

NOTE. The predecessor's override protocol (50-word minimum; "unacceptable reasons" including disagreement with the AI; escalation of "inadequate" rationales) is not carried: it inverted the burden of proof against human judgement and institutionalised automation bias (audit 850-05, 850-07). Decision quality is monitored by sampled outcome review under clause 17.8.

8. Calibration and Review Confidence Indices

8.1 Confidence SHALL be expressed per use case through a Review Confidence Index (RCI) defined for that use case in the use-case register; a single generic confidence score SHALL NOT be applied across use cases, and no fixed global confidence band SHALL be used (MCC-100 clause 22.3).

NOTE. The predecessor's four-tier fixed bands (HIGH ≥85, MEDIUM 60–84, LOW 40–59, VERY_LOW <40), its additive score-derivation weights, its duplicated "Confidence Tier Decision Matrix" appendix, and every statement of the form "AI is 85%+ confident in recommendation" are deleted (audit 850-03; 100-10). No number in the predecessor's scoring model had a task-specific statistical basis.

8.2 Each RCI SHALL be defined by: the quantity it estimates; the evidence basis for its calibration (a documented validation set with a data card); its published error and coverage metrics; its validity conditions; and its mapping to confidence tiers.

8.3 An RCI value SHALL NOT be represented — internally, to applicants, to VVBs or publicly — as a probability of correctness, an accuracy statement or a performance claim unless that representation is supported by published calibration evidence for that use case.

8.4 No validation set, calibration study, or error and coverage measurement — the calibration evidence clause 8.2 requires — exists for any use case (Evidence Register ER-2026-001 §B5); the requirement stands unmet for every use case, and no reduction resting on it is available.

8.5 Confidence tiers (HIGH, MEDIUM, LOW, VERY_LOW) are retained as categorical labels only; the assignment of a tier for each use case SHALL be governed by that use case's register entry, and tier boundaries SHALL be justified by calibration evidence, not fixed globally.

8.6 Every recorded confidence tier SHALL carry a tier provenance value: MODEL_REPORTED where the tier derives from the model's own output within the register entry's governed bounds, or GOVERNANCE_ASSIGNED where a rule of this Standard, the register entry or a governance decision assigns or caps the tier.

8.7 Governance-assigned caps SHALL prevail over model-reported values; where both exist, the lower tier SHALL be recorded and displayed.

8.8 Numeric RCI values SHALL NOT be displayed to applicants (clause 10.5) and SHALL NOT be published at record level; tiers, with provenance, are the only confidence representation permitted on user-facing surfaces.

8.9 Until the calibration evidence required by clause 8.2 is linked in the Evidence Register for a use case: every confidence tier for that use case SHALL carry provenance GOVERNANCE_ASSIGNED; the tier SHALL be capped at the bridging maximum fixed in the register entry, which is MEDIUM for each currently deployed use case, as a bridge until validation exists and not as a validated threshold (Consultation question 2.); and every surface displaying the tier SHALL state that calibration evidence is pending.

8.10 A confidence tier, of any provenance, SHALL have no effect other than to add scrutiny per clause 4.8; in particular it SHALL NOT alter queue order, reduce evidence or sampling, or shorten any period.

8.11 Recalibration of a use case SHALL be triggered by: material model change (Section 18); adoption or material revision of a methodology the use case analyses; detected systematic bias (Section 17); or a divergence-rate or error signal exceeding the thresholds fixed in the register entry. No such threshold is yet fixed for any use case: the thresholds are open questions, not requirements. (Consultation question 3.)

9. Assessment schemas and the safeguards rubric

9.1 Every completeness or adequacy assessment SHALL be performed against an assessment schema specific to the instrument (MCC-CC or MCC-MOU), methodology family and methodology version of the submission, generated from the methodology's own requirements; one generic rubric SHALL NOT be applied across instruments or families.

NOTE. The predecessor's single carbon-centric rubric (Article 14: fixed weights of 20/20/15/20/15/10 across baseline, quantification, monitoring, additionality, permanence and safeguards) penalised legitimate non-carbon projects and is deleted (audit 850-04). Weights, where used, are schema parameters fixed per methodology under Section 18 change control.

9.2 A schema for an MCC-MOU submission SHALL assess the outcome-specific evidence its methodology requires and SHALL NOT score the submission against carbon-accounting components that do not apply to it.

9.3 Scoring SHALL be deterministic and reproducible for a given schema version, model version and input hash, and every score SHALL be accompanied by a per-section justification.

9.4 The safeguards component of every assessment schema SHALL be generated from the single safeguards taxonomy of MCC-ESS clause 4.1 (requirement areas SR1 to SR12) and the screening schema of MCC-ESS Annex B, as reproduced in Annex C; no other count, list or naming of safeguards principles SHALL appear in any rubric, prompt template or platform configuration (MCC-ESS clause 4.2; audit ESS-01).

9.5 The safeguards component SHALL assess only the presence, coverage and internal consistency of safeguards documentation; it SHALL NOT assess safeguards adequacy, assign or suggest a risk category, or evaluate FPIC — matters reserved to human assessment under MCC-100 clause 22.5 and the Environmental & Social Safeguards Policy.

9.6 Completeness thresholds attached to schema outputs SHALL have advisory effect only; no threshold SHALL create a fast-track, alter queue order or reduce any pathway requirement.

NOTE. The predecessor's threshold ladder (<80% "high-scrutiny pathway"; ≥95% "fast-track eligibility", later construed as the Prioritised Sequencing Flag) is deleted with the abolition of prioritised sequencing (clause 12.1).

9.7 Each schema SHALL be a versioned artefact; the schema version SHALL be recorded on every AI Assessment Record, and schema changes follow Section 18.

10. Applicant-facing outputs and disclosure

10.1 The permitted applicant-facing AI outputs are those of the applicant-facing use cases in Annex A: the Automated Completeness Report, register-fact methodology guidance, structuring assistance and pre-submission prechecks, each within its register entry.

10.2 Applicant-facing drafting or structuring assistance SHALL NOT fabricate content: where information needed for a section is not present in the applicant's own material, the system SHALL insert an explicit placeholder in substance "[INFORMATION NEEDED: …]" rather than generate substitute content, and SHALL NOT invent data, evidence, quantities or commitments.

10.3 Where an AI Assessment Record is generated on a project submission, the platform SHALL derive from it an Automated Completeness Report for the applicant containing, and limited to: (a) the completeness result under the applicable schema; (b) the per-section analysis (section, presence, adequacy classification, identified gaps); (c) the confidence tier, expressed categorically with its provenance and, where clause 8.9 applies, the calibration-pending statement; (d) risk flags as category and severity with a plain-language justification; and (e) suggested questions and clarifications expressed as actionable requests.

10.4 The Report, and every surface and notification referring to it, SHALL carry a label in substance: "This is an automated advisory report, not a review decision. All decisions affecting this project are made by a human reviewer." The Report SHALL state the analysis timestamp and model version and whether it was produced in Degraded Mode.

10.5 Applicants SHALL NOT have visibility to: (a) the AI Assessment Record in full, including numeric RCI values, cross-reference internals and internal analytic commentary; (b) any recommendation-class output or sealed legacy recommendation field, in any representation from which it could be inferred — only human decisions are communicated to applicants; (c) any queue, escalation or sequencing indicator; or (d) model internals, prompts, prompt templates, algorithm details or training data.

10.6 The applicant-facing surfaces of the platform SHALL be reviewed against this Section at each release affecting the project detail view, applicant notification templates or submission response payload; non-compliance is an incident under Section 19.

10.7 Every application of an AI system to a person's submission SHALL be disclosed to that person (MCC-100 clause 22.7), and Programme communications about AI SHALL comply with MCC-600.

11. Interface with validation and verification: blind first pass

11.1 A VVB SHALL reach its validation and verification conclusions blind to AI analysis: no AI Assessment Record, output, score, tier, flag or sealed recommendation field concerning the engagement SHALL be disclosed to the VVB before the VVB's independent draft conclusions have been recorded in accordance with the blind first-pass requirements of MCC-400 clauses 11.1–11.5 (First-Pass Record: MCC-400 clause 2.4 definition, clause 11.4 lock) (MCC-700 clauses 15.5 and 20.3; MCC-100 clause 18.7).

NOTE. This restores, in strengthened form, the rule of MCC-850 v1.0 Article 28. The structured pre-conclusion visibility regime of Amendment 1 (AI Analysis Sidebar on engagement assignment) never entered into force — its 17 September 2026 commencement is stayed by FD-2026-09-03 item D8 — and is not carried, because pre-conclusion disclosure creates anchoring the audit found indefensible (850-05; 400-06). The surviving Amendment 1 controls appear at clauses 11.8 to 11.10 and 17.9.

11.2 After the VVB's draft conclusions are recorded, the Programme MAY disclose the relevant AI analysis to the VVB solely for discrepancy and quality review, in the manner and sequence MCC-400 clauses 11.6–11.9 prescribe.

11.3 Post-draft disclosure SHALL NOT include any recommendation-class or sealed legacy recommendation output (the reciprocal of MCC-400 clause 11.6, whose reference to "MCC-850's non-disclosure rules" is to clauses 8.8, 10.5(b) and 21.3 of this Standard).

11.4 A discrepancy between AI analysis and VVB conclusions SHALL be resolved by the VVB's professional judgement on the evidence; the AI analysis SHALL NOT be treated as presumptively correct, and the VVB SHALL NOT be required to justify departure from it beyond its ordinary duty to reason its conclusions.

11.5 No AI output SHALL reduce the VVB's minimum evidence, sampling or scrutiny; the VVB determines its own risk- and materiality-based sampling plan (MCC-100 clause 18.6; MCC-400 clauses 10.1–10.3 and 11.8).

11.6 No sampling floor, evidence requirement or fee expectation SHALL be linked to any AI confidence tier (MCC-400 clauses 10.3 and 18.3).

NOTE. The stayed MCC-400 Addendum's confidence-tier sampling bands are a matter for MCC-400 v2.0, which is drafted under the blind first-pass regime; this Standard states the AI-side rule only and cites MCC-400 generically.

11.7 AI analysis of a VVB's submitted report (cross-checking findings against prior analyses) MAY be performed after the report is submitted, as a registered use case, with output to Programme staff only.

11.8 Every access by a VVB user to any AI output SHALL be logged in the immutable audit trail with user identity, timestamp and the output viewed; logs SHALL be available to the Programme Secretariat and to peer reviewers under MCC-400 clause 11.3.

11.9 No AI output generated against draft submissions, applicant working documents or pre-submission consultation SHALL be disclosed to a VVB at any time.

11.10 Nothing in this Section gives a VVB visibility to applicant-related AI output beyond what the project developer may see under Section 10, except the post-draft discrepancy material of clause 11.2.

12. Queue neutrality, escalation and human review periods

12.1 Submissions SHALL be taken up for review in the neutral queue order fixed by MCC-100 clause 13.14; no AI-generated score, completeness result, flag or tier SHALL alter queue order, and no prioritised-sequencing mechanism SHALL be created or operated.

NOTE. The Prioritised Sequencing Flag (Amendment 2; predecessor Article 19.1) and the Article 14 fast-track construction are abolished (audit 850-06). Support for small-scale and community developers is provided by the MCC-100 clause 13.15 support pathway, not by queue preference.

12.2 Any legacy prioritised-sequencing field in the platform data model SHALL be inert: not populated, not displayed and without effect.

12.3 Every AI Assessment Record SHALL record an escalation level with its escalation path and review deadline (Annex B); escalation levels SHALL be defined in the use-case register and mapped only to review owners holding authority under MCC-700 Annex A.

12.4 An escalation level MAY add review layers or refer a matter to a more senior owner; it SHALL NOT remove, shorten or substitute any review step, and completion of an automated analysis SHALL NOT start or shorten any period allowed to a human reviewer.

12.5 Review deadlines attached to escalation levels are service-level targets owned by the lifecycle state machine (MCC-700 Annex B) and the Tier 5 operational procedure; this Standard fixes none.

NOTE. The predecessor's escalation matrix (Article 23: PA 5 days / VVB 20 days / Technical Committee 30 days / Board 45 days) tied review authority to unvalidated confidence bands and to bodies outside the canonical governance architecture; it is deleted. Routing by confidence tier survives only as the ratchet-up principle of clauses 4.8 and 12.4.

13. Public transparency

13.1 The Programme SHALL publish, at least quarterly, an AI transparency report containing: analyses performed, by use case and trigger source; confidence-tier distribution, split by tier provenance; counts and durations of Degraded Mode operation and of honest-unavailability responses; divergence statistics at aggregate level; model identifiers and versions in use and changes in the period; and incident summaries at a level that does not disclose personal data or applicant-confidential material.

13.2 The Programme SHALL publish: the AI Use-Case Register with entry statuses and calibration-evidence references; a plain-language description of each deployed use case, its limitations and validated performance (MCC-700 clause 20.2); and this Standard.

13.3 Registry entries and certificates for any project whose review was AI-assisted SHALL disclose that fact.

13.4 The Programme SHALL NOT publish individual AI Assessment Records, model internals, prompts or training data; published aggregate statistics SHALL NOT be presented as accuracy or performance claims beyond what linked calibration evidence supports.

13.5 No public statement about AI performance, dataset size, testing or concordance SHALL be made unless the underlying record is linked in the Evidence Register (MCC-001 clause 11.3).

14. Data governance, data cards and external data sources

14.1 Every dataset used to train, tune, calibrate, test or ground an in-scope system SHALL be inventoried in the AI data inventory before use.

14.2 Each inventoried dataset SHALL have a data card recording: provenance and collection method; licensing and usage rights; contents and coverage; personal-data content and lawful basis; inclusion and exclusion criteria; splits; known gaps and representativeness limits; and version and custodian.

14.3 No reference dataset or validation set exists for any use case; the predecessor's claim of validation against 50 historical PDDs with minimum 90% concordance is unsupported, and the archived record holds 15 AI review records in total (Evidence Register ER-2026-001 §B5).

14.4 Applicant-submitted material SHALL be used only for the review purposes for which it was submitted; use for model training, tuning or evaluation SHALL occur only under a data card, a documented lawful basis, and the applicable consent or anonymisation requirements of Section 15.

14.5 Feedback of human decisions into model improvement MAY occur only as a registered use of data under a data card and Section 15; it SHALL NOT occur by default.

14.6 The Programme SHALL maintain an approved external-source register listing every external registry, database or service an in-scope system may access, with its terms of use, data flows, refresh cadence and the human-verification step required before any consequence attaches to externally sourced data.

NOTE. This resolves the predecessor's contradiction between "MCC-internal data only" and duplicate-registry checking that necessarily reads external registries (audit 850-08). Cross-programme duplicate screening (Annex A UC-05) operates on the sources in this register under MCC-100 clause 17.6, and a suspected duplicate is always verified by a human before any action.

14.7 Data lineage SHALL be maintained such that any AI output can be traced to its model version, prompt template version, schema version, input hashes and any dataset relied on.

15. Privacy and data protection

15.1 For each in-scope system, the Programme SHALL identify and record the controller and any processors of the personal data involved, and vendor and sub-processor arrangements SHALL be governed by written terms meeting this Section.

15.2 Every processing purpose SHALL have an identified lawful basis under applicable data-protection law, recorded in the processing record; a discretionary decision of any Programme body is not of itself a lawful basis.

15.3 A data protection impact assessment SHALL be completed and recorded before any in-scope system is deployed or materially changed, and reviewed on each Section 18 model change that alters data use.

15.4 The Programme SHALL operate documented procedures for data-subject rights (access, rectification, erasure, restriction, objection) applicable to personal data in AI inputs and outputs, consistent with the Record Retention Schedule and legal-hold rules.

15.5 International transfers of personal data processed by in-scope systems, including transfers to model providers, SHALL occur only under a recorded transfer mechanism valid in the relevant jurisdictions.

15.6 Personal-data breaches involving in-scope systems SHALL be handled under the incident process of Section 19 and notified to authorities and affected persons where applicable law requires.

15.7 Anonymised or aggregated use of applicant data for model improvement SHALL be preceded by a documented anonymisation assessment demonstrating that re-identification risk is remote.

15.8 Data residency obligations applicable in each operating jurisdiction SHALL be identified and implemented, and reviewed at least annually.

15.9 The controller's identity and registered particulars, the appointment of a data protection officer (or a documented finding that none is required), and the list of model providers and sub-processors with their transfer mechanisms are not yet settled, and none of them is evidenced in the programme record. The controller's identity depends on the incorporation of the Programme's operating entity, which has not yet been incorporated (FD-2026-10-01 item 3); whether applicant documentation may be transmitted to an external model provider is reserved to the Governing Board (FD-2026-09-04 item 6). (Consultation question 4.)

16. Security and retention

16.1 Security controls for in-scope systems — encryption in transit and at rest, key management, access control, vulnerability management, logging and monitoring — SHALL implement the MCC Information Security Standard; this Standard fixes no technology, protocol version or cipher.

NOTE. The predecessor's hard-coded TLS 1.3 / AES-256 / HSM clauses (Articles 20, 41) are moved to the Information Security Standard (audit SYS-11; §6.3 drafting rule). Until that Standard is published, the platform's existing configuration continues under clause 2.2 without normative restatement here.

16.2 Retention, deletion and legal hold for every AI record class — AI Assessment Records, human-decision records, data cards, validation sets, calibration reports, access logs and transparency reports — SHALL follow the MCC Record Retention Schedule; this Standard fixes no retention period and makes no permanent-retention recommendation.

16.3 Access to AI Assessment Records SHALL be role-based and limited to persons with a documented need, with all access logged per clause 7.4.

16.4 Internal and external auditors and, where legally required, regulators SHALL have access to AI records under documented procedures.

17. Performance and bias monitoring

17.1 For each deployed use case the Programme SHALL continuously track, at minimum: output volumes; error signals from sampled human re-assessment; divergence rates between AI flags and human decisions; Degraded Mode frequency; and processing-time distributions.

17.2 Accuracy SHALL be measured by periodic independent human re-assessment of a documented sample of AI outputs per use case; sampling design SHALL be recorded, and results SHALL be linked in the Evidence Register before being cited anywhere.

17.3 No accuracy, agreement or concordance figure SHALL be stated as a target met, or as an observed result, without a linked measurement record; numeric accuracy and agreement targets for each use case are set with the first calibration report for that use case, and none is set by this Standard. (Consultation question 5.)

17.4 Bias testing SHALL be performed for each use case before deployment and at least annually thereafter, across at minimum: geography and host-country grouping; project scale (including small-scale and community projects); instrument and methodology family; and submission language.

17.5 Bias test designs, metrics and thresholds SHALL be documented in advance; thresholds are per-use-case disparity metrics and action thresholds, to be adopted with the first bias-test protocol — no threshold is asserted here and no test result exists at this draft. (Consultation question 6.)

17.6 A use case with documented systematic bias or systematic error SHALL be suspended from use pending remediation (MCC-100 clause 22.9), and its suspension recorded in the use-case register.

17.7 Quarterly calibration reviews SHALL analyse the clause 17.1 metrics, assess drift, and recommend recalibration under clause 8.11; calibration review reports SHALL be published with the transparency report.

17.8 Human decision quality SHALL be monitored through sampled outcome review of decisions on their merits; deviation of a reviewer's decisions from AI outputs, from cohort medians, or fast turnaround SHALL NOT of itself be treated as a quality defect (audit 850-07).

17.9 The Programme SHALL monitor VVB engagement patterns for indicators of insufficient independent verification; indicators MAY inform the selection of engagements for enhanced peer review or witness assessment under MCC-400 clauses 13.3 and 14.5, and SHALL NOT of themselves ground a sanction, which requires merits review of the engagement's evidence.

18. Model change governance and validation

18.1 A model change — any change to model identity or version, prompt templates, schemas, thresholds, tier mappings, training data or heuristics of an in-scope system — SHALL follow this Section; no model change SHALL be deployed without the approvals it requires.

18.2 Every model change SHALL be documented in a technical specification stating what changes, why, and the expected impact per use case.

18.3 Before deployment, a model change SHALL be validated against the affected use cases' validation sets, with a regression comparison against the prior version and a bias assessment per clause 17.4; where no validation set yet exists for a use case (clause 8.4), the change record SHALL state that fact and the bridging rule of clause 8.9 SHALL apply to that use case.

18.4 Validation and bias results SHALL be recorded in a signed validation report linked in the Evidence Register; no result SHALL be asserted without such a report.

18.5 A tested rollback procedure to the prior version SHALL exist before deployment.

18.6 Material model changes SHALL be approved under MCC-700 Annex A row 34, on the Programme Secretariat's documented submission; minor tuning within ranges pre-approved in the use-case register MAY be executed by the Programme Secretariat and logged. The delegation boundary between material and minor changes is to be fixed in the use-case register per use case. (Consultation question 7.)

18.7 Stakeholders SHALL be notified of material model changes through the transparency report and the published register; changes affecting applicant-facing outputs SHALL be notified before deployment where practicable.

18.8 Model version comparisons across changes SHALL be retained for calibration continuity.

19. Incident management and model risk

19.1 An AI incident — including materially incorrect analysis, prohibited-output generation, disclosure of withheld items, unauthorised access, prolonged Degraded Mode (clause 6.18), or breach of this Standard by a system — SHALL be detected, documented and classified by severity when identified.

19.2 On a material incident, the affected use case SHALL be isolated or suspended where continued operation could affect any live matter.

19.3 Root-cause analysis SHALL be completed and recorded for every material incident, and affected analyses SHALL be identified, re-assessed and corrected by new records.

19.4 Material incidents SHALL be reported to the Programme Secretariat's compliance monitoring function within the timeline fixed in the Tier 5 procedure, and to the Registry Oversight Committee and the Independent Governing Board where live projects, decisions or personal data are affected.

19.5 The Programme SHALL maintain a model-risk register recording, per use case, its failure modes, the harm each could cause, the controls mitigating it and the residual-risk owner; the register SHALL be reviewed at each calibration review.

19.6 Incidents SHALL be summarised in the transparency report and reviewed in the annual AI governance report to the Independent Governing Board.

20. Human review, reasons and appeals

20.1 Any person affected by a decision supported by an AI system is entitled, on review or appeal, to human re-examination of the matter independent of the AI system, and to the reasons for the decision in human-readable form (MCC-700 clause 20.5; MCC-100 clause 22.7).

20.2 Reasons given for any decision SHALL be the human decision-maker's reasons; a decision notice SHALL NOT present an AI output as a reason, and SHALL disclose that AI assistance was used where it was.

20.3 A request for the human review of clause 20.1 SHALL be processed without any AI analysis of the request itself being an input to the re-examination.

20.4 Appeals follow MCC-700; nothing in this Standard limits any appeal right, and no AI output is admissible on appeal as evidence of the correctness of the decision under appeal.

21. Prohibited uses

21.1 No AI system SHALL approve, reject, register, suspend or revoke any project, methodology, VVB or participant, or decide any application.

21.2 No AI system SHALL issue, transfer, retire or cancel any unit, execute any registry operation, or initiate or advance any lifecycle state transition.

21.3 No AI system SHALL generate a recommendation-class output (clause 4.5), and no recommendation-class output SHALL be shown to any applicant, VVB, decision-maker before their recorded first-pass conclusion, or the Independent Governing Board.

21.4 No AI confidence tier, RCI value or score SHALL be used to reduce any evidence requirement, sampling, scrutiny, consultation period or verification step, or to alter queue order.

21.5 No AI system SHALL be used for: additionality assessment; safeguards adequacy assessment or risk categorisation; FPIC evaluation; VVB recognition; enforcement or sanctions; appeals; or the determination of any person's rights (MCC-100 clause 22.5).

21.6 No AI system SHALL fabricate content, evidence, data or citations in any output; applicant-facing assistance SHALL mark gaps per clause 10.2.

21.7 No AI output SHALL be represented, internally or publicly, as a probability, accuracy figure or performance result beyond what linked calibration evidence supports.

21.8 No AI system SHALL communicate with any person in a manner that represents or implies the communication is from a human.

21.9 No applicant data SHALL be used for model training, tuning or evaluation outside clauses 14.4 and 15.7.

21.10 Breach of this Section is an incident under Section 19 and a compliance matter under MCC-100 Section 23.

22. Independent audit

22.1 AI governance under this Standard SHALL be subject to independent audit at least annually, covering: compliance with each Section; the integrity and completeness of AI Assessment Records and logs; calibration and bias-test evidence; data cards and lawful-basis records; and the operation of the blind first-pass interface.

22.2 Audit reports SHALL be received and reviewed by the Registry Oversight Committee (MCC-700 clause 20.6) and reported to the Independent Governing Board, with a public summary in the transparency report.

22.3 Auditors SHALL be independent of the Programme Secretariat's AI operations and of every model vendor used.

22.4 Audit findings requiring remediation SHALL be tracked to closure in the compliance monitoring function.

23. Legal applicability assessment

23.1 The Programme SHALL complete and record a documented legal assessment of the applicability of AI-specific regulation — including the EU Artificial Intelligence Act and any other applicable AI, consumer-protection or data-protection regime — to each in-scope system, identifying for each jurisdiction the Programme's role (such as provider or deployer), the system's classification and the resulting obligations.

23.2 The assessment SHALL be completed before this Standard leaves consultation status, reviewed on every material model change and at least annually, and its conclusions SHALL be reflected in the use-case register. No such assessment exists (Evidence Register ER-2026-001 §B5).

23.3 No Programme communication SHALL claim compliance with, alignment to, or exemption from any AI regulation absent the clause 23.1 record (MCC-600).

24. Review and amendment

24.1 Amendments to this Standard SHALL follow the programme-standard amendment procedure of MCC-001 and MCC-700 (RACI row for programme-standard adoption/amendment), including public consultation; this Standard defines no separate amendment procedure.

24.2 Changes to Annex A register entries are amendments to this Standard, except immaterial corrections of record, which SHALL be logged and reported in the transparency report.

24.3 This Standard SHALL be reviewed at least annually against monitoring results, incident history, audit findings and regulatory developments.

25. Entry into force and transitional provisions

25.1 This document has no effect until approved by the body and threshold designated in MCC-700 Annex A, following public consultation; on approval, its status and effective date SHALL be recorded in the Document Register with the signed decision linked in the Evidence Register.

25.2 On entry into force, this Standard supersedes MCC-850 v1.0 as amended, together with the stayed Amendments 1 and 2 (whose disposition is recorded in the document-control block), and the predecessor texts SHALL be archived as superseded records.

25.3 A use case operating on the platform before entry into force MAY continue to operate only in advisory mode consistent with this Standard, and SHALL be brought under an Annex A register entry, with clause 8.9 bridging caps applied, within the transition period fixed at approval. The proposed transition is that a deployed use case may run in advisory mode until the consultation on this Standard closes, and is then suspended unless approved. (Consultation question 8.)

25.4 The Programme SHALL establish a go-live and evidence register recording, for each use case: the date of its first live operation; the certification, testing and approval records relied on for that operation; and every gap. As to the record of AI operation before this draft: the finding of fact recited for 17 August 2026 (15 AI review records, 44 snapshots, 17 projects) is corroborated as to AI records and projects — the archived demonstration cohort holds exactly 15 AI review records and 17 projects — but snapshots in the archive number 77, not the 44 recited; the live register holds 2 AI review records, both of 2 September 2026, and no snapshots (Evidence Register ER-2026-001 §§A1–A3). Five human decisions overriding an AI recommendation are recorded, all of 20 August 2026 and all on projects that are no longer in the register (human_decisions, measured 1 October 2026).

25.5 Records created under the predecessor schema SHALL be preserved unaltered; fields abolished by this Standard (the prioritised-sequencing flag; the legacy recommendation field, subject to clause 4.6) SHALL be handled as clauses 12.2 and 4.6 provide.

25.6 Decisions validly taken before entry into force are not reopened by this Standard alone, except that any live practice inconsistent with Sections 4, 10, 11, 12 or 21 SHALL be corrected with immediate effect on entry into force.

---

Annex A — AI Use-Case Register (normative)

A.0 The register below is the single inventory required by Section 5. Entries UC-01 to UC-07 carry the use cases MCC-100 v3.0-draft clause 22.2 lists as approved, a list that takes effect only on that Standard's adoption; entries UC-08 to UC-10 are PROPOSED entries describing applicant-facing assistive capabilities implemented on the platform, submitted for approval through this consultation (per MCC-100 clause 22.2, additional use cases are approved under this Standard). No entry asserts calibration evidence: clause 8.4 applies to every row, and every tier issued under any row is GOVERNANCE_ASSIGNED with the clause 8.9 cap until that evidence exists.

Id	Use case	Purpose	Permitted inputs	Permitted outputs	Human control	Calibration requirement	Status
UC-01	Completeness-check support	Advisory completeness review of submissions (section analysis, gaps, risk flags) against the Section 9 schema for the instrument/family/methodology	Submitted documents and structured fields of the submission; applicable schema	Automated Completeness Report content (clause 10.3); staff-facing section analysis and risk flags	Administrative completeness decision by Programme Secretariat per MCC-100 clause 13.5; blind to any sealed legacy field	Schema-level RCI per clause 8.2; validation set of human-assessed submissions — none exists (Evidence Register ER-2026-001 §B5)	Approved by MCC-100 22.2(1); conditions herein
UC-02	Data-quality validation	Flag internal inconsistencies, missing values, unit errors in submitted data	Submitted data and documents	Consistency flags with plain-language justification	Human reviewer assesses every flag; no auto-return	Per-check error/coverage measurement — none yet; the registry records no output of this use case, and measurement begins with its first production run (Evidence Register ER-2026-001 §A1)	Approved by MCC-100 22.2(2); conditions herein
UC-03	Baseline-conservatism screening	Flag baseline assumptions that appear non-conservative for human attention	PDD baseline sections; methodology parameters	Screening flags; suggested questions	Assessment of baselines remains wholly human/VVB (MCC-100 Sections 8, 18)	Use-case RCI with validation set — none yet; the registry records no output of this use case, and measurement begins with its first production run (Evidence Register ER-2026-001 §A1)	Approved by MCC-100 22.2(3); conditions herein
UC-04	Recomputation of quantification	Independently recompute stated calculations from stated equations and inputs	Equations, parameters and data in the submission	Match/mismatch results with computation trace	Human verifies mismatches; no issuance effect (clause 6.8 NOTE)	Deterministic; correctness tests per release — no validation or error measurement exists for any use case (Evidence Register ER-2026-001 §B5)	Approved by MCC-100 22.2(4); conditions herein
UC-05	Cross-programme duplicate screening	Risk-based screening for possible duplicate registration (MCC-100 clause 17.6)	Registry data; approved external sources per clause 14.6 only	Possible-duplicate flags for human verification	Every flag human-verified before any consequence	Precision/recall measurement on documented cases — none yet; the registry records no output of this use case, and measurement begins with its first production run (Evidence Register ER-2026-001 §A1)	Approved by MCC-100 22.2(5); conditions herein
UC-06	Claims-wording monitoring	Flag public or participant claim wording potentially non-conforming with MCC-600	Public communications; claim templates; registry records	Non-conformity flags to compliance monitoring	Compliance monitoring function decides all follow-up	Flag-quality sampling — none yet; the registry records no output of this use case, and measurement begins with its first production run (Evidence Register ER-2026-001 §A1)	Approved by MCC-100 22.2(6); conditions herein
UC-07	Registry search and analysis	Staff-facing search, retrieval and aggregate analysis over registry records	Registry records within the requester's own access rights	Search results and aggregations grounded in records	Read-only assistance; outputs carry record citations	Grounding-fidelity sampling — none yet; the registry records no output of this use case, and measurement begins with its first production run (Evidence Register ER-2026-001 §A1)	Approved by MCC-100 22.2(7); conditions herein
UC-08	Methodology guidance grounded in register facts	Answer applicant questions about methodologies using register facts stated by the server	Published methodology register facts supplied by the platform; the applicant's question	Guidance text quoting register facts; no eligibility or approval prediction	Advisory only; labelled per clause 10.4; register facts server-supplied, not model-recalled	Grounding-fidelity sampling — none yet; the registry records no output of this use case, and measurement begins with its first production run (Evidence Register ER-2026-001 §A1)	PROPOSED for approval through this consultation (Consultation question 9.)
UC-09	PDD structuring support	Help applicants structure their own material into the PDD template	The applicant's own uploaded material; the applicable template	Structured draft using only applicant material, with "[INFORMATION NEEDED: …]" placeholders per clause 10.2	Applicant owns and reviews all content; no submission auto-filed	Placeholder-discipline and fabrication-rate sampling — none yet; the registry records no output of this use case, and measurement begins with its first production run (Evidence Register ER-2026-001 §A1)	PROPOSED for approval through this consultation (Consultation question 9.)
UC-10	Pre-submission draft precheck	Advisory precheck of a draft before formal submission	The applicant's draft, at the applicant's request	UC-01-equivalent advisory output, marked pre-submission; never disclosed to VVBs (clause 11.9)	Advisory only; creates no record advancing the project; excluded from all queue and review processes	As UC-01	PROPOSED for approval through this consultation (Consultation question 9.)

A.1 The predecessor's trigger-point applications not carried into this register are recorded for transparency: AI screening of VVB applications is not registered (AI use in VVB recognition is prohibited, MCC-100 clause 22.5); the "final compliance check before credit issuance" is not registered as a distinct use case (UC-04 recomputation may be run on verified data, but no AI check is an issuance prerequisite or accelerant); AI cross-checking of validation/verification reports operates only post-submission under clause 11.7 within UC-01/UC-02 conditions.

A.2 It is proposed (FD-2026-10-01 Schedule 1, Q20) that UC-08 to UC-10, which are implemented on the platform, may continue operating during the consultation period under the advisory-mode conditions of clause 25.3, and are suspended when the consultation closes unless approved. (Consultation question 8.) Their historical approval basis is unevidenced: no instrument in the decision register approves the deployment of applicant-facing structuring, guidance or precheck features, and these use cases were deployed without a recorded approval basis (the register at /governance/decisions).

Annex B — AI Assessment Record minimum schema (normative field semantics)

GENERATED CONTENT. The field set below is reproduced from the platform's assessment and human-decision data model so that this Standard and the platform use one vocabulary; the platform SHALL implement at least these fields with these semantics, and any divergence found in implementation SHALL be reconciled to this Annex, not the reverse. Enumeration spellings are the platform's.

B-1 Every AI Assessment Record SHALL carry at minimum:

Field	Semantics	Fixed by
record id	Unique immutable identifier	Clause 7.2
subject reference	Project / submission / document analysed	Clause 7.1
use case id	Annex A entry invoked	Section 5
trigger source	AUTO_SUBMISSION | STAFF_REQUEST	Clause 2.3.11
model id + model version	Exact model identity pinned for the invocation	Clause 6.5
prompt template id + version	Versioned template used for this trigger source	Clause 6.6
input hash(es)	SHA-256 of every analysed input	Clause 6.7
schema id + version	Section 9 assessment schema applied (where applicable)	Clause 9.7
timestamps	Invocation and completion, ISO 8601	Clause 7.1
section analysis	Per-section presence, adequacy classification, findings, gaps	Clause 10.3
risk flags	Category, severity, plain-language justification	Clause 10.3
confidence tier	HIGH | MEDIUM | LOW | VERY_LOW	Section 8
tier provenance	MODEL_REPORTED | GOVERNANCE_ASSIGNED	Clauses 2.3.8, 8.6
escalation level, path, review deadline	Recorded escalation attributes	Clause 12.3
degraded mode flag	Whether produced under clauses 6.13–6.20	Clause 6.14
predecessor record reference	For corrections and re-analyses	Clauses 6.19, 7.2
legacy recommendation field (if present)	Sealed per clause 4.6; never displayed	Clause 4.6

B-2 Every human-decision record SHALL carry at minimum: decision; deciding user identity and role; authentication step-up evidence; timestamp; linked AI Assessment Record(s); reasons; and divergence marker with the clause 7.7 rationale where applicable.

B-3 Risk-flag categories SHALL be drawn from the applicable Section 9 schema (for GHG methodologies typically additionality, permanence, leakage, baseline, quantification, safeguards; for MCC-MOU methodologies the outcome-specific categories the methodology defines); no fixed global category list applies across instruments.

Annex C — Safeguards rubric component (generated from MCC-ESS)

GENERATED CONTENT. This Annex discharges MCC-ESS clause 4.2: the safeguards component of every assessment schema is regenerated here from the single safeguards taxonomy of MCC-ESS clause 4.1 (SR1–SR12) and the screening schema of MCC-ESS Annex B-4. The taxonomy is owned by MCC-ESS; on any divergence, MCC-ESS prevails and this Annex is corrected. The predecessor's "nine principles" rubric (v1.0 Article 14) is superseded (audit ESS-01).

C-1 The safeguards component of every assessment schema SHALL check, for each requirement area below, only: (a) whether the submission addresses the area or records a reasoned non-applicability determination; (b) whether the documents MCC-ESS requires for the project's risk category are present; and (c) internal consistency between the safeguards documentation and the rest of the submission. Adequacy, categorisation and FPIC evaluation are excluded (clause 9.5).

Code	Requirement area (MCC-ESS clause 4.1)
SR1	Impact assessment, mitigation hierarchy and do no harm
SR2	Labour and working conditions
SR3	Community health, safety and security personnel
SR4	Land and marine access restrictions, displacement and resettlement
SR5	Marine tenure, customary fishing rights and livelihoods
SR6	Indigenous Peoples and Free, Prior and Informed Consent
SR7	Biodiversity and critical habitat
SR8	Cultural heritage and chance finds
SR9	Gender equality and GBV/SEA/SH prevention and response
SR10	Stakeholder engagement and disclosure
SR11	Benefit sharing
SR12	Climate and disaster resilience

C-2 The screening questions applied per area SHALL be generated from MCC-ESS Annex B-4.1 and SHALL NOT be locally varied, extended or reworded in any prompt template or platform configuration.

C-3 Safeguards flags raised by the component SHALL be expressed as presence/coverage/consistency findings referencing the SR code, and SHALL route to human safeguards screening under MCC-ESS Section 6; they SHALL NOT state or imply a risk category, clearance outcome or FPIC status.

---

End of MCC-850 version 2.0-draft. DRAFT — FOR CONSULTATION. This document is not in force.