Appendix 6 Predictability Framework

ICANN has established a Predictability Framework to manage operational processes for the New gTLD Program: 2026 Round, to ensure efficient and transparent handling of unexpected issues. When unanticipated matters arise, ICANN org will engage with the Standing Predictability Implementation Review Team (SPIRT)¹ based on the potential impact:

• For changes with material impact² on applicants, ICANN org and the SPIRT have to agree on a permanent solution.

• For changes with non-material impact on applicants, ICANN org will inform the SPIRT of such changes, but will not consult the SPIRT.³

Key limitations of this framework include:

• It is not a mechanism to develop policy.

• It does not restrict the ICANN Board’s ability to take Program-related actions or take action on any particular application.

• It does not take precedence over GNSO policy recommendations adopted by the ICANN Board.

• It does not impede the GNSO Council's policy development or guidance processes (see ICANN Bylaws Annexes A, A-1, A-2).⁴

• It does not limit advisory committees’ (including GAC) ability to provide advice in accordance with ICANN’s Bylaws Article 12.⁵

ICANN will document all changes (as described in A6.2 Description of Changes) to the Program in a publicly available change log. In addition, for non-minor operational changes, ICANN will inform all applicants directly.

A6.1 Parties Involved in the Framework

The following parties are involved in administering this framework, with roles and responsibilities specific to its implementation:

1. Applicants: All entities that applied for a new gTLD in the current Program round.

2. GNSO Council: The chartering entity of the SPIRT, consulted as described below.

3. ICANN org: Program operator committed to ensuring the continued and effective operation of the Program.

4. ICANN Board: Maintains its roles and responsibilities as detailed in the ICANN Bylaws.

5. SPIRT: Collaborates with ICANN org and GNSO Council to address and review non-minor operational changes, including potential policy modifications.

To facilitate ongoing communication and Program management, ICANN and the SPIRT will conduct regular standing calls as necessary to discuss potential Program changes and implementation challenges.

A6.2 Description of Changes

For the purpose of this framework, Program changes are classified in three distinct categories:

• A minor operational change refers to any modification during the ongoing round of the Program that can be implemented in alignment with the existing Board-approved policy recommendations and does not have a material impact on applicants.

• A non-minor operational change is a change during the ongoing round of the Program that can be implemented in alignment with the existing Board-approved policy recommendations and has a material impact on applicants.⁶ ICANN org and SPIRT have to agree on a permanent solution. If an agreement is not reached within 30 days, or more urgent action is necessary to the operation of the program, ICANN can implement a temporary solution to be replaced with the solution of ICANN and SPIRT once agreed.

• A policy change is a change during the ongoing round of the Program that cannot be implemented in alignment with the existing Board-approved policy recommendations.⁷ Policy changes for ongoing rounds would only occur in extraordinary circumstances where the Program’s continuation is at risk if the change were not executed. If a policy change is necessary, the Board, ICANN org, and the GNSO Council in consultation with the SPIRT will identify an appropriate solution that secures the Program’s continuation and establishes a suitable implementation process.⁸ Any collaboration between the Council and the SPIRT in this context is outside this Framework and is governed by the SPIRT Charter.

A6.3 Procedural Steps to Initiate and Execute a Change

The change request flow chart outlines the procedural steps the Advisory Committee (AC), GNSO Council, ICANN Board, and ICANN org take if they determine a change to the Program is required.

A6.3.1 Change Request

There are four paths that a change request can take:

• Path 1: ICANN org determines a change is required to the Program, ICANN org applies the Predictability Framework and proceeds with the steps outlined in the Change Execution flowchart.

• Path 2: The ICANN Board determines a change to the ongoing round of the Program is required. The ICANN Board directs ICANN org to implement the change. If implementation requires a change to the ongoing round of the Program, ICANN org applies the Predictability Framework and proceeds with the steps outlined in the Change Execution flowchart.

• Path 3: SPIRT determines a change to the ongoing round is required, the SPIRT collaborates with the GNSO Council to inform ICANN org. If ICANN org determines a change to the ongoing round is needed, ICANN org applies the Predictability Framework and proceeds with the steps outlined in the Change Execution flowchart. If ICANN org determines, contrary to the SPIRT, that no change is required to the ongoing round, the SPIRT confers with the GNSO Council. If the GNSO Council determines a change to the ongoing round is required, the GNSO Council engages with the ICANN Board. If the ICANN Board determines a change to the ongoing round is needed, the ICANN Board directs ICANN org to apply the Predictability Framework and proceeds with the steps outlined in the Change Execution flowchart.

• Path 4: GNSO Council or AC approve and submit guidance or advice to the ICANN Board, and the ICANN Board, after its consideration, adopts the guidance or advice. The ICANN Board directs ICANN org to implement the change. If implementation requires a change to the ongoing round of the Program, ICANN applies the Predictability Framework and proceeds with the steps outlined in the Change Execution flowchart.

Figure A6-1: Change Execution Flowchart 1⁹

A6.3.2 Change Execution

The Change Execution flow chart documents three primary scenarios for Program modifications:

1. When ICANN org determines that a required change can be implemented in alignment with the existing Board-approved policy recommendations and will not have a material impact on applicants,¹⁰ it is classified as a ‘minor operational change.’ In such cases, ICANN org will add the changes to the change log as soon as feasible, preferably before implementation.

2. For changes in alignment with the existing Board-approved policy recommendations that will have a material impact on applicants, ICANN classifies these as ‘non-minor operational changes.’ ICANN will inform SPIRT and follow the subsequent steps in the change execution flow chart. Once implemented, ICANN will notify applicants about any non-minor operational changes.

3. When ICANN org determines that the required change cannot be implemented in alignment with the existing Board-approved policy recommendations, ICANN org will inform the SPIRT. The SPIRT will then confer with the GNSO Council. Should the GNSO Council determine that an alternative change, which does not require a change of existing policy, cannot be found, the change is considered a ‘policy change’ and the subsequent steps in the change execution flow chart will be followed.¹¹

Figure A6-2: Change Execution Flowchart 2

A6.4 Change Log

ICANN org will document all changes to the Program in a publicly available change log and will set up a publicly archived mailing list for all parties that wish to be notified of Program changes. For non-minor operational changes, ICANN org will inform all applicants directly. Should a change relate to sensitive or security-related issues, information will be redacted as necessary.

ICANN org will add any minor operational changes to the Change Log within five business days after implementing it.

If, against the determination of ICANN org, a member of the SPIRT believes that a change that ICANN classified as a minor operational change, might have a material impact on applicants, the SPIRT will have the opportunity to raise this with ICANN org on the designated SPIRT mailing list or during one of the SPIRT-ICANN org standing calls. If ICANN org and the SPIRT determine that the change does have a material impact on applicants, the change will be treated as non-minor and ICANN and SPIRT will align on a mutually agreeable permanent solution; until such a solution is found, ICANN’s initial solution will remain in place.

A6.5 Definition of “Material Impact” for Predictability Framework

In the context of Predictability Framework, “material impact” refers to the implementation of new procedures or operations for the New gTLD Program: 2026 Round or changes to ICANN’s existing procedures or operations that will likely: (1) change the status of an application, (2) change the outcome of an evaluation of an application, (3) have a non-trivial monetary or operational impact on applicants, or (4) have a non-trivial impact on the timeline of application processing, up to the point of delegation.