Community Priority Evaluation is a highly consequential mechanism because it determines whether a community-based application should receive priority in a contention set. The integrity of this process is therefore critical not only for applicants, but also for the credibility of ICANN’s multistakeholder model, the predictability of the 2026 Round, and the protection of genuine communities within the DNS ecosystem.

The draft guide is a positive operational step. It provides clearer direction for the selected CPE vendor, outlines the roles of the evaluator, vendor, and ICANN org, and reinforces important principles such as objectivity, consistency, transparency, confidentiality, and accountability. I also support the guide’s recognition that CPE is limited to Community Applications and that the guide is intended to complement, not replace or supersede, the Applicant Guidebook.

However, given the importance of CPE in resolving contention, I recommend that ICANN org and the CPE provider strengthen the guide in the following areas before final publication.

1. Clarify the hierarchy between the Applicant Guidebook and the Evaluation Guide

The final guide should include an explicit “order of authority” provision. While the public comment materials state that the guide does not replace or supersede the Applicant Guidebook, this should be stated clearly within the guide itself.

Suggested wording:

“In the event of any inconsistency between this Evaluation Guide and the Applicant Guidebook, the Applicant Guidebook shall prevail. This guide is intended to operationalize the CPE criteria and guidelines and shall not create additional substantive criteria, thresholds, or evidentiary burdens beyond those set out in the Applicant Guidebook.”

This clarification will reduce interpretive uncertainty and help prevent operational guidance from being treated as new policy.

2. Strengthen safeguards for limited independent research

The draft guide permits evaluators to conduct limited independent research where necessary. This is appropriate, but the final guide should provide a clearer workflow to ensure such research remains objective, proportionate, and focused on verification.

For each instance of independent research, the panel should document the reason the research was necessary, the source consulted, the date accessed, the criterion affected, whether the research confirms or contradicts the applicant’s evidence, and how the applicant’s response was considered where applicable.

This is particularly important for localized, linguistic, Indigenous, professional, cultural, and Global South communities, where credible evidence may not always be widely available online or in English. Independent research should support fair evaluation, not introduce unintended bias.

3. Avoid over-formalizing community evidence

The CPE process should not disadvantage legitimate communities simply because their structures are informal, decentralized, traditional, non-Western, or not highly visible online. The final guide should make clear that community legitimacy can be demonstrated through different forms of evidence, including charters, membership records, historical records, community programs, local endorsements, professional networks, linguistic associations, public-interest initiatives, or credible expert verification.

A community should not be penalized merely because it does not mirror the structure of a formal corporation, trade association, or globally visible institution. The New gTLD Program should remain accessible to communities across regions, languages, cultures, and governance traditions.

4. Improve the treatment of support and opposition

The guide should make clear that evaluation of support and opposition is not a numerical popularity contest. Letters of support and opposition should be assessed based on relevance, legitimacy, substance, representativeness, and connection to the identified community, not simply by volume.

A small but highly relevant community institution may carry more weight than a large organization with only a loose connection to the community. Similarly, mass-generated or generic opposition should not outweigh authentic and well-supported endorsements from recognized community bodies.

The final guide should also require evaluators to explain how support and opposition were weighed, especially where the applied-for string has multiple meanings or where the applicant defines a narrower community than the broader public meaning of the string.

5. Reinforce the “no double-counting” principle

The final guide should include a clear quality assurance checkpoint confirming that negative findings are not counted repeatedly across multiple criteria unless there is a distinct and justified basis for doing so.

For example, a weakness identified under Community Establishment should not automatically reduce scoring under Nexus, Registration Policies, or Community Endorsement unless the evaluator explains how the same fact independently affects each criterion. This will improve consistency, transparency, and fairness.

6. Increase transparency in final reports

The reporting requirements in the draft guide are useful and should be strengthened further. Final reports should include sub-score breakdowns, concise reasoning for each score, public sources relied upon, a summary of independent research, a summary of any expert consultation where appropriate, and confirmation that the applicant had an opportunity to respond to adverse research where required.

The final report should be detailed enough for applicants and the wider ICANN community to understand how the determination was reached, while still protecting confidential applicant information. This will improve trust and reduce the likelihood of avoidable disputes.

7. Clarify the Evaluation Challenge process

The draft guide refers to Evaluation Challenges and states that a different set of panelists will form the Challenge Panel. This is welcome, but the final guide should provide more practical detail.

It should include a standalone section explaining the scope of a challenge, timelines, standing, standard of review, possible remedies, independence safeguards, and how factual, procedural, or system errors will be identified and corrected. It should also clarify whether system errors include platform, document-handling, transmission, or publication errors.

A clearer challenge framework will improve procedural fairness and reduce unnecessary escalation into broader accountability mechanisms.

8. Strengthen calibration and quality assurance

The vendor’s responsibility to facilitate calibration sessions and cooperate with quality assurance is important. However, the final guide should require documented calibration protocols before live evaluations begin.

These should include evaluator training, mock scoring exercises, consistency testing, conflict-of-interest refreshers, and training on cultural, linguistic, and regional diversity. This is necessary because CPE decisions must be consistent across different applications, communities, languages, and contexts.

ICANN does not need to publish confidential deliberations, but it should be able to confirm that evaluators were properly trained, calibrated, conflict-screened, and quality-assured before determinations were issued.

9. Improve timeline predictability

The draft guide anticipates that CPE may take approximately 90 to 180 days, depending on complexity. This is reasonable, but applicants need more granular visibility.

The final guide should include indicative milestone targets for assignment, conflict screening, clarification questions, independent research disclosure, applicant response, quality assurance, final report submission, and publication. Where delays occur, ICANN should provide applicants with a reasoned update and revised timeline.

Predictability should not only apply to the final outcome; it should apply across the evaluation lifecycle.

I support the publication of ICANN org’s Draft Community Priority Evaluation (CPE) Vendor Evaluation Guide for the New gTLD Program: 2026 Round. The guide provides a strong operational foundation by outlining evaluator, vendor, and ICANN roles, and by reinforcing key principles such as objectivity, consistency, transparency, confidentiality, and accountability.

My submission recommends targeted improvements to strengthen fairness, predictability, and trust in the CPE process. In particular, the final guide should clearly state that the Applicant Guidebook prevails in the event of any inconsistency, and that the Evaluation Guide should not create new substantive criteria or evidentiary burdens.

I also recommend clearer safeguards for limited independent research, including documentation of sources, rationale, relevance to scoring, and applicant response opportunities. The guide should avoid over-formalizing community evidence so that legitimate communities with informal, decentralized, traditional, linguistic, regional, or Global South structures are not disadvantaged.

The submission further recommends that support and opposition be assessed based on relevance, legitimacy, substance, and representativeness rather than volume alone. It also calls for a stronger “no double-counting” quality assurance checkpoint, greater transparency in final reports, clearer procedures for Evaluation Challenges, documented evaluator calibration, and more granular milestone timelines.

Overall, I believe these refinements will help ensure that CPE outcomes are evidence-based, globally inclusive, procedurally fair, and trusted by applicants, affected communities, and the wider ICANN ecosystem.