Summary

  • ICANN's 2026 Applicant Guidebook gives an applicant 21 days to challenge a String Similarity Evaluation determination and calls for challenge conclusions within 30 days of filing.
  • A confirmed factual, procedural, or system error triggers re-evaluation that takes the challenge findings into account. It does not, by itself, guarantee a passing result.

Suppose an applicant receives a challenge conclusion that confirms an error in its String Similarity Evaluation. That sounds like a reversal. It is not yet one.

The official sequence contains a separate next step: re-evaluation. The challenge conclusion answers whether a qualifying error occurred. The later evaluation still has to decide the application's substantive result after taking that conclusion into account.

That distinction is small in wording and large in operation. If the original determination, the challenge conclusion and the re-evaluated determination are treated as three unrelated documents, the transition becomes difficult to audit. If they are treated as a connected decision chain, an applicant and the wider community can see what changed without assuming that an error finding dictated the final answer.

The rule creates a sequence, not a single appeal event

Section 7.10.4 of the 2026 Applicant Guidebook describes the challenge in a deliberately bounded way. An applicant may file within 21 days after ICANN transmits the panel determination. The Evaluation Challenge Service Provider assesses the challenge under a “clearly erroneous” standard. The Guidebook says the provider must accept the panel determination unless the panel failed to follow the established evaluation procedures or failed to consider or solicit necessary material evidence or information.

The Guidebook then sets a second clock. The panel is to communicate its conclusions within 30 days of the challenge filing.

ICANN's public FAQ expresses the grounds more compactly: the applicant may challenge if it believes the panel made a factual, procedural or system error. The FAQ and the Guidebook converge on the operational consequence. If an error is confirmed, the String Similarity Evaluation is re-evaluated. The Guidebook adds the important connective language: the re-evaluation takes the challenge findings into account.

The sequence is therefore:

  1. ICANN transmits the original SSE determination.
  2. The applicant files a challenge within 21 days on the basis of an alleged factual, procedural or system error.
  3. The challenge process reaches a conclusion, ordinarily within the Guidebook's 30-day period.
  4. If the conclusion finds a qualifying error, the SSE is re-evaluated using the challenge findings.
  5. The re-evaluation produces the new substantive determination.

The fourth and fifth steps should not be collapsed. A confirmed error is the gateway to reconsideration. The sources reviewed for this article do not say that it automatically turns a failed evaluation into a pass, dissolves a contention set, or determines any other substantive outcome.

“Clearly erroneous” narrows the challenge question

The Guidebook's standard matters because it keeps the challenge from becoming an unbounded second evaluation. The listed conditions focus on procedure and the handling of material evidence or information. ICANN's FAQ also names factual and system errors.

That does not make the challenge trivial. It makes the question more precise. The applicant is not merely asking a second decision-maker to prefer a different judgement. It is identifying a defect that could justify reopening the evaluation.

This precision should carry through to the record. At minimum, the challenge needs a stable reference to the original determination, a clear statement of each asserted error, and the evidence offered for it. The challenge conclusion then needs to identify which asserted errors were confirmed or rejected. The re-evaluation record needs to show that the confirmed findings were part of its input.

Those are governance recommendations, not a claim about ICANN's current publication schema. The official material establishes the procedural connection. It does not prescribe the public data model proposed here.

A confirmed error and a new determination answer different questions

The challenge conclusion asks: did a qualifying error affect the first evaluation?

The re-evaluated determination asks: what is the correct SSE result after taking the challenge findings into account?

Keeping those questions separate avoids two opposite mistakes.

The first mistake is to treat the error finding as an automatic substantive win. That overstates what the sources promise. The second is to publish a new determination without a visible connection to the finding that caused re-evaluation. That makes it hard to test whether the error was actually remedied.

A well-linked record can preserve both propositions at once:

  • the challenge succeeded on one or more error grounds; and
  • the re-evaluation remained responsible for the substantive SSE outcome.

The result is a decision chain rather than a replacement document.

The no-error path shows why outcome labels need context

The Guidebook is explicit about what happens when the panel finds no factual, procedural or system error. The original SSE outcome remains in place.

But “remains in place” can lead to different operational states. For the specified similarity or Blocked Name findings covered by the no-error rule, the application does not proceed. If the finding concerns similarity to another applied-for string, the application remains in its contention set.

This split is a useful warning against status fields that say only “challenge denied.” The denial explains why the original determination persists. It does not by itself tell an operator whether the application stops or remains active in contention. That information comes from the original determination and its rule-specific consequence.

The same discipline should apply after a confirmed error. “Challenge upheld” is a transition state, not the final application state.

Five links would make the re-evaluation traceable

For an applicant, evaluator or independent observer, the smallest useful transition record would connect five objects:

  1. Original determination. A stable identifier, transmission time, evaluated string and outcome basis.
  2. Challenge filing. Filing time, asserted error grounds, cited procedure and submitted evidence.
  3. Challenge conclusion. A stable identifier and a ground-by-ground conclusion showing what was confirmed or rejected.
  4. Re-evaluation input record. A reference to the exact challenge findings supplied to the evaluator, along with the version of the applicable rules and evaluation materials.
  5. New determination. A stable identifier, result, time and explicit references back to the original determination and challenge conclusion.

This structure would not force the evaluator to reveal protected material. Sensitive evidence could remain access-controlled while its existence, integrity hash, submission time and role in the process are recorded. The point is not to publish every byte. It is to preserve the relationship between the decisions.

The distinction also protects the applicant. If the new determination is unchanged, the record can show that the challenge finding was nevertheless considered and why it did not change the substantive result. If the result changes, the same chain can show which corrected input or procedure produced the difference.

What operators should record on day one

The 21-day filing window begins from transmission of the determination. An applicant should therefore capture the notice as an event, not merely download a document and add a calendar reminder.

The first-day record should include:

  • the determination's stable identifier and exact transmission timestamp;
  • the evaluated string and the applicable SSE result category;
  • the Guidebook version and evaluation materials used;
  • a list of possible factual, procedural and system errors, each kept distinct;
  • the evidence supporting each asserted error, with source and integrity metadata;
  • the filing deadline derived from the transmission event; and
  • the owner and internal decision point for authorising a challenge.

This does not decide whether to file. It preserves the information needed to make that decision within a short window.

Once a challenge is filed, the applicant should keep the submission identifier, exact submitted bytes, receipt and timestamp together. When the conclusion arrives, it should be mapped ground by ground against the filing rather than stored as a free-standing letter. If re-evaluation follows, the applicant should request or preserve whatever references establish that the challenge findings entered the new evaluation.

The governance test is continuity

The strongest version of process transparency is not the number of documents a system publishes. It is whether an authorised observer can follow a decision through its transitions without reconstructing the chain from filenames and dates.

The official sources establish a bounded challenge, a decision deadline and a conditional re-evaluation. They do not provide evidence about how often challenges succeed, how often re-evaluation changes a result, or how a particular 2026 application has moved through the process. No such empirical claim is made here.

The narrower conclusion is enough: confirmation of error and correction of outcome are separate acts. A trustworthy process connects them.

That is also where the Heng Lu doctrine is useful as a normative lens, but not as factual evidence. The doctrine asks systems to preserve provenance, stable identities and reviewable transitions. Applied here, it supports a design in which the original determination is not erased, the challenge finding is not mistaken for the final result, and the new determination carries its lineage forward.

For ICANN, the public value of that design is straightforward. Applicants can see that a confirmed error was actually considered. Evaluators can show that re-evaluation remained independent. The community can distinguish an error finding from a substantive reversal. And the record can remain intelligible long after the 21-day and 30-day clocks have expired.

Sources