Summary

  • ICANN's FAQ says an applicant may challenge a String Similarity Evaluation outcome within 21 days after receiving notice; the 2026 Applicant Guidebook measures the period from transmission of the determination.
  • The challenge is not an unrestricted second evaluation. The Guidebook applies a clearly erroneous standard and identifies failures of procedure or handling of necessary material evidence or information as the exceptions to accepting the original panel determination.
  • The first-day record proposed here is a governance recommendation, not an ICANN-mandated form. Its purpose is to preserve the exact decision event, candidate error grounds, evidence provenance, deadline calculation and later filing as one auditable chain.

The clock starts before the argument is finished

An applicant may need days to decide whether an adverse String Similarity Evaluation, or SSE, outcome is genuinely challengeable. The record should not wait for that legal or technical judgment.

ICANN's public FAQ states that an applicant may file a challenge within 21 days after receiving notice of the evaluation outcome if it believes the panel made a factual, procedural or system error. Section 7.10.4 of the 2026 Applicant Guidebook uses a more operational formulation: the challenge can be made within 21 days from the date ICANN transmits the SSE determination.

Those statements establish the same short window while describing different observable events. The prudent response is not to decide informally which timestamp matters. It is to preserve both: when ICANN transmitted the determination and when the applicant's systems received or exposed the notice. The record should also retain the timezone, message identifier, delivery channel and the unaltered determination that accompanied the event.

This article does not claim that the later timestamp extends the deadline. It recommends keeping enough evidence to calculate the deadline conservatively and explain the calculation.

Preserve the decision before summarising it

A working team will quickly convert a long determination into a task list, slide, ticket or email. That is useful for coordination, but a summary should never become the evidentiary original.

The day-one package should preserve the exact bytes of the determination or report, its filename and retrieval path, a SHA-256 integrity hash, the evaluated string and any variant string, the result category, the date and time displayed by ICANN, and the version of the Applicant Guidebook used for the analysis. It should link these facts to a stable internal matter identifier without altering the original file.

Hashing does not prove that the determination was correct or that ICANN transmitted it at a particular time. It proves a narrower and still valuable point: the file reviewed later is the same file the applicant preserved. Transmission evidence must come from the message, portal or delivery record itself.

The challenge standard narrows the first review

The Guidebook says the challenge is assessed under a clearly erroneous standard. The Evaluation Challenge Service Provider must accept the original panel determination unless the panel failed to follow established evaluation procedures or failed to consider or solicit necessary material evidence or information. ICANN's FAQ also names factual, procedural and system error.

That framework should shape triage. The first internal review should not ask only whether the applicant dislikes the result or can present a more attractive similarity analysis. It should separate candidate grounds:

  1. What factual premise might be wrong?
  2. Which established procedure might not have been followed?
  3. What necessary material evidence or information may have been omitted or not solicited?
  4. What system behaviour may have affected the determination?

Each ground should point to the exact passage in the determination, the applicable rule or procedure, and the supporting source. A ground without a source is a hypothesis. A source without a mapped ground is an archive, not yet an argument.

Six linked objects make a challenge reconstructable

The minimum useful record contains six objects.

First is the transmission event: the sender, destination, channel, timestamp, timezone, message identifier and any portal event. Second is the received notice: when the applicant's controlled system accepted or exposed it and who first accessed it. Third is the authoritative determination: the unaltered file, its hash, result, evaluated string and stable reference.

Fourth is the rule snapshot: the Guidebook version, relevant section and any official FAQ relied on for the deadline or grounds. Fifth is the ground-and-evidence ledger: one row per alleged error, with the claim, cited decision passage, applicable rule, supporting material, provenance, owner and review status. Sixth is the deadline and filing record: the conservative deadline calculation, internal approvals, exact filed bytes, filing hash, submission timestamp and acknowledgment.

These objects should be linked, not merged into one editable document. The original notice and determination must remain immutable while analysis evolves around them.

A 30-day conclusion is a second clock, not a substitute for receipt

The Guidebook states that the SSE panel will communicate the conclusions from the challenge within 30 days after the applicant files it. That creates a second event chain. The filing record should therefore become the parent of the acknowledgment, the expected conclusion date, any procedural messages and the conclusion actually received.

If an error is found, the evaluation is reevaluated with the challenge findings taken into account. If no factual, procedural or system error is found, the original outcome stands. Neither branch makes the day-one evidence obsolete. The preserved record explains what was challenged, on what basis, and whether the later conclusion addressed the same grounds.

What the official sources do not establish

The official materials establish the window, review standard, conclusion timing and conditional consequence. They do not prescribe the record architecture proposed here. They do not provide a 2026 challenge success rate, reversal rate or completed application-level case from which outcomes can be forecast.

They also do not say that a hash, screenshot or internal approval makes a challenge timely or persuasive. Those controls preserve provenance and organisational memory; they do not replace the applicable filing rules or the applicant's professional advice.

The Heng Lu doctrine is relevant only as a normative lens. Its emphasis on stable identity, provenance and traceable state transitions supports preservation of the decision chain. It is not evidence of what ICANN did, what the rules require, or how a panel will decide.

The governance test is whether the record survives personnel change

Twenty-one days is long enough for several people to touch the matter and short enough for responsibility to fragment. A reliable record lets a new decision-maker answer five questions without relying on memory: what arrived, when it arrived, which rule governed, what error was alleged, and exactly what was filed.

That is the real purpose of day-one preservation. It does not prejudge a challenge. It keeps the option to make an informed, source-bound decision from being lost to missing timestamps, overwritten files or unsupported recollection.

Sources