An applicant draws a low Priority Number and immediately gains a story to tell: its application is near the front of ICANN’s processing queue. That story is useful, but incomplete. The number does not place every part of the application near the front of every line. ICANN’s own 2026 Round materials make one exception explicit: Priority Numbers do not determine the order in which applications move through String Evaluation.
That distinction matters because String Evaluation is where ICANN examines the proposed label itself and its allocatable variants. A low number may improve the general scheduling position for later application processing, but it is not a string-level verdict, a promise of early clearance, or a shortcut around the five checks that ICANN says are assessed concurrently.
What the number orders
ICANN describes the Prioritization Draw as the mechanism that assigns a Priority Number to every new gTLD application. The number sets the general order in which applications move through contention resolution, Applicant Evaluation and Application Evaluation, receive those evaluation results and, if successful, proceed toward contracting.
“General” is doing real work in that description. A separate ICANN FAQ says an application can pause because of objections, appeals, Governmental Advisory Committee Consensus Advice, Extended Evaluation, contention resolution, accountability mechanisms or change requests. ICANN may then process the next application and resume the paused one after the issue is resolved.
The queue is therefore an ordering device, not a guaranteed finish order. And even that qualified ordering role stops at the boundary of String Evaluation.
Five checks on a different clock
The authoritative 2026 Applicant Guidebook, V2-2026.04.24, defines String Evaluation as an examination focused on applied-for strings and their allocatable variant strings. Its glossary identifies five elements:
- String Similarity Evaluation asks whether applied-for strings and relevant comparison strings are visually similar in ways that can affect outcomes or contention.
- Name Collision Initial Assessment examines potential collision risk associated with a proposed string and its allocatable variants.
- Safeguard Assessment considers the safeguard requirements attached to the proposed string.
- Geographic Names Identification determines whether a proposed string falls within the Guidebook’s geographic-name rules.
- Singular/Plural Notifications Evaluation addresses notifications asserting a singular or plural relationship between applied-for strings.
ICANN says these five elements will be assessed concurrently. That does not mean every panel starts at the same instant, completes on the same date or publishes one synchronized result. It means the Guidebook does not describe them as a single ranked relay in which one must finish before the next begins.
This is why an applicant’s Priority Number cannot be used as a proxy for the state of its string. A low-ranked application can still be waiting on a string-level finding while an application with a higher number has different elements moving on different timelines. Conversely, an early string finding does not mean the application has cleared Applicant Evaluation, Application Evaluation, objections, contention or contracting.
One rank, two operational views
ICANN’s public reporting should resist the temptation to compress all progress into a single rank-shaped status. Applicants, communities and potential objectors need to see at least two distinct operational views.
The first is the priority-ordered application view: Priority Number, current ordered stage, any pause, the reason for that pause, the date it began and the date processing resumed. The second is the String Evaluation view: the status and key dates for each of the five string-level elements, with clear labels for results, challenges and pending dependencies.
Those views answer different questions. The first asks where an application generally sits in ICANN’s processing sequence. The second asks what ICANN has learned about the proposed string. Combining them invites false conclusions: that a low number means a string is safe, that an early string result means contracting is near, or that a later-numbered application has been improperly accelerated whenever one of its string checks appears first.
The accountability test is legibility
The Priority Number is valuable precisely because it creates a visible scheduling rule. Its legitimacy, however, depends on publishing the boundaries of that rule as clearly as the number itself. ICANN has already stated the central boundary: String Evaluation is not ordered by Priority Number.
The next step is operational transparency. A public two-clock ledger should show the ordered application queue alongside the five-element String Evaluation record. It should distinguish official results from work in progress, disclose material pauses without exposing protected application data, and preserve dates so observers can compare expected and actual movement.
That proposal is an accountability recommendation, not a claim that ICANN has already adopted such a dashboard. But it follows directly from the process ICANN has described. If one number governs only part of the journey, the public record must show where the number ends and the separate evaluation clock begins.