Un número bajo en el sorteo de priorización puede mejorar la posición de una solicitud en varias etapas del programa de nuevos gTLD. No convierte la cadena solicitada en segura, ni garantiza que sus resultados lleguen antes. ICANN marca expresamente el límite: el número de prioridad determina el orden general de ciertos procesos, pero no el orden de la String Evaluation.
La diferencia no es semántica. Separa la gestión de una cola de expedientes del examen de la cadena que cada expediente propone.
El alcance real del número
ICANN atribuye al número de prioridad el orden general para avanzar por la resolución de contención, la Applicant Evaluation y la Application Evaluation, recibir sus resultados y, si la solicitud tiene éxito, dirigirse a la contratación.
Ese orden admite interrupciones. La propia organización enumera objeciones, apelaciones, asesoramiento por consenso del GAC, Extended Evaluation, resolución de contención, mecanismos de rendición de cuentas y solicitudes de cambio como motivos que pueden pausar un expediente. Mientras tanto, puede continuar el siguiente y retomar el anterior cuando desaparezca el bloqueo.
Por eso el número no es un pronóstico del orden final. Mucho menos es una calificación de la cadena.
Cinco evaluaciones en paralelo
La versión autoritativa de la Guía del Solicitante de 2026, V2-2026.04.24, limita la String Evaluation a las cadenas solicitadas y a sus variantes asignables. Su glosario define cinco elementos que se evaluarán de forma concurrente:
- String Similarity Evaluation, sobre similitud visual y sus posibles consecuencias.
- Name Collision Initial Assessment, sobre el riesgo inicial de colisión de nombres.
- Safeguard Assessment, relativo a los requisitos de salvaguarda.
- Geographic Names Identification, para identificar cadenas sujetas a las reglas de nombres geográficos.
- Singular/Plural Notifications Evaluation, sobre notificaciones de relaciones singular/plural entre cadenas.
Concurrente no significa simultáneo. La guía no promete que los cinco equipos comiencen, terminen o publiquen resultados en la misma fecha. Lo que descarta es una única cadena secuencial gobernada por el número del sorteo.
Así, una solicitud con número bajo puede seguir esperando una conclusión a nivel de cadena. También puede ocurrir que una comprobación de una solicitud con número más alto aparezca antes, sin que eso pruebe trato preferente. Y obtener pronto un resultado de cadena no significa haber superado la evaluación del solicitante, la evaluación de la solicitud, las objeciones, la contención o la contratación.
La transparencia necesita dos relojes
Una sola pantalla ordenada por número mezcla preguntas distintas. ¿Dónde está el expediente en la secuencia general? ¿Qué se ha determinado sobre la cadena? ¿Existe una pausa? ¿Qué elemento sigue abierto?
La rendición de cuentas mejoraría con dos registros enlazados. El primero mostraría el número, la etapa ordenada, las pausas, sus motivos y fechas. El segundo presentaría por separado los cinco elementos de String Evaluation, con estado, hitos, resultados y desafíos cuando correspondan.
Ese diseño impediría usar el número como sustituto de información que no contiene. Un número bajo no certifica la cadena; un resultado temprano no anuncia un contrato; una diferencia temporal no demuestra por sí sola una desviación de la cola.
La propuesta de dos relojes es una recomendación editorial de gobernanza, no una política vigente de ICANN. Su fundamento, sin embargo, sí está en los documentos oficiales: la organización ha definido qué procesos ordena la prioridad y ha excluido expresamente la String Evaluation. La información pública debería respetar esa misma frontera.