Кратко

  • Руководство заявителя ICANN 2026 года даёт 21 день на оспаривание решения String Similarity Evaluation и предусматривает сообщение выводов в течение 30 дней после подачи.
  • При подтверждении фактической, процедурной или системной ошибки SSE переоценивается с учётом выводов по оспариванию; само подтверждение не гарантирует положительного результата.

Представим, что заявитель получает вывод о подтверждённой ошибке в первоначальной String Similarity Evaluation — оценке сходства строк, или SSE. Формулировка может показаться отменой первого решения. По опубликованной процедуре ICANN она лишь открывает отдельный следующий этап.

Вывод по оспариванию отвечает на вопрос, была ли первая оценка затронута ошибкой, соответствующей установленному стандарту. Переоценка отвечает, каким должен быть правильный результат SSE после учёта этого вывода. Вопросы связаны, но не совпадают.

Если первоначальное решение, вывод по оспариванию и новый результат хранятся как три изолированных документа, сложно проверить, была ли ошибка действительно исправлена. Явная цепочка решений позволяет проследить изменение и не принять подтверждение ошибки за автоматическое прохождение.

Последовательность решений, а не единичная апелляция

Раздел 7.10.4 Руководства 2026 года чётко ограничивает оспаривание. Заявитель может подать его в течение 21 дня после передачи ICANN решения панели. Поставщик услуги по оспариванию применяет стандарт «явной ошибки». Он должен принять решение панели, если только панель не нарушила установленные процедуры оценки либо не рассмотрела или не запросила необходимые существенные доказательства или информацию.

Руководство устанавливает и второй срок: панель должна сообщить выводы в течение 30 дней после подачи оспаривания.

Публичный FAQ ICANN короче описывает основания как фактическую, процедурную или системную ошибку. Источники совпадают в отношении последствия: при подтверждении ошибки SSE проводится заново. Руководство уточняет, что переоценка должна учитывать выводы оспаривания.

Таким образом, цепочка включает пять отдельных событий:

  1. ICANN передаёт первоначальное решение SSE.
  2. Заявитель в течение 21 дня подаёт оспаривание на основании предполагаемой фактической, процедурной или системной ошибки.
  3. Процедура формирует выводы, обычно в течение 30 дней после подачи.
  4. Если ошибка подтверждена, SSE переоценивается с учётом этих выводов.
  5. Переоценка создаёт новое решение по существу.

Четвёртый и пятый этапы нельзя объединять. Подтверждение ошибки открывает повторное рассмотрение. Изученные официальные источники не говорят, что оно автоматически превращает отрицательный результат в положительный, распускает группу конкуренции или заранее определяет другой итог.

Стандарт явной ошибки сохраняет точность вопроса

Оспаривание не становится неограниченной второй оценкой. Условия Руководства сосредоточены на соблюдении процедуры и работе с необходимыми существенными доказательствами или информацией. FAQ прямо добавляет фактические и системные ошибки.

Это ограничение требует от заявителя указать дефект, оправдывающий повторное открытие оценки, а не просто попросить другого принимающего решение предпочесть иную профессиональную оценку.

Запись должна сохранять ту же точность. Оспаривание должно устойчиво ссылаться на исходное решение, отдельно перечислять каждую предполагаемую ошибку и связывать её с доказательством. Вывод должен показывать, какие основания подтверждены, а какие отклонены. Запись о переоценке должна затем показать, что подтверждённые выводы вошли в её исходные данные.

Это рекомендация по управлению, а не утверждение о текущем формате публикации ICANN. Официальные материалы устанавливают процедурную связь, но не предписывают предложенную здесь публичную схему.

Подтверждение ошибки и новое решение — разные действия

Вывод по оспариванию спрашивает, повлияла ли допустимая ошибка на первую оценку. Новое решение спрашивает, каков правильный результат после учёта этого вывода.

Разделение предотвращает две противоположные ошибки. Первая — объявить автоматическую победу по существу сразу после подтверждения ошибки, чего источники не обещают. Вторая — опубликовать новый результат без видимой связи с выводом, вызвавшим переоценку, и тем самым затруднить проверку исправления.

Связанная запись может одновременно сохранить два факта: оспаривание было успешным по одному или нескольким основаниям, а переоценка осталась ответственной за окончательный результат SSE.

Путь без ошибки показывает, почему одного статуса мало

Руководство гласит: если фактическая, процедурная или системная ошибка не обнаружена, первоначальный результат остаётся в силе.

Но это может означать разные операционные состояния. При выводах о сходстве или Blocked Name, охватываемых правилом для случая без ошибки, заявка дальше не проходит. При сходстве с другой поданной строкой она остаётся в своей группе конкуренции.

Поэтому статус «оспаривание отклонено» сам по себе не сообщает, остановлена ли заявка или остаётся активной в конкуренции. Нужно сохранять связь с первоначальным решением и правилом, определяющим его эффект.

Так же и «оспаривание удовлетворено» после подтверждения ошибки является переходным состоянием, а не окончательным статусом заявки.

Пять связей для проверяемой переоценки

Минимальная полезная цепочка связывает пять объектов:

  1. Первоначальное решение: устойчивый идентификатор, время передачи, оцениваемая строка и основание результата.
  2. Подача оспаривания: время, основания, указанная процедура и доказательства.
  3. Вывод по оспариванию: устойчивый идентификатор и решение по каждому основанию.
  4. Входные данные переоценки: выводы, переданные оценщику, версия правил и оценочные материалы.
  5. Новое решение: идентификатор, результат, время и явные ссылки на предыдущие этапы.

Для этого не нужно публиковать все защищённые материалы. Чувствительные доказательства могут оставаться под контролем доступа, а их наличие, хеш целостности, время подачи и роль в процедуре — фиксироваться. Цель не в публикации каждого байта, а в сохранении отношений между решениями.

Если результат не изменился, цепочка может показать, что вывод был учтён, и объяснить, почему исправление не повлияло на существо. Если результат изменился, можно определить, какие исправленные данные или процедура создали разницу.

Что заявителю фиксировать в первый день

Срок 21 день начинается с передачи решения. Уведомление следует регистрировать как событие с точным временем, а не просто как загруженный файл и напоминание в календаре.

Первичная запись должна включать идентификатор решения и точное время передачи, оцениваемую строку, категорию результата SSE, версию Руководства и применимые материалы, раздельный перечень возможных ошибок, происхождение и целостность каждого доказательства, рассчитанный срок и внутреннего ответственного за разрешение подачи.

Эти данные не принимают решение автоматически. Они сохраняют основу для информированного выбора в коротком временном окне.

После подачи идентификатор, точные отправленные байты, квитанция и время должны храниться вместе. Вывод следует сопоставить с каждым основанием, а не архивировать как отдельное письмо. При начале переоценки нужно сохранить ссылки, показывающие, что выводы вошли в новое рассмотрение.

Проверка управления — это непрерывность

Прозрачность измеряется не числом опубликованных документов, а возможностью проследить переходы без восстановления отношений по именам файлов и датам.

Официальные источники подтверждают ограниченное оспаривание, заданные сроки и условную переоценку. Они не дают показателя успешности, частоты изменения результатов после переоценки или эмпирического случая заявки 2026 года. Эта статья таких утверждений не делает.

Подтверждённый вывод уже и важнее: подтвердить ошибку и исправить результат — два разных действия. Надёжный процесс связывает их.

Доктрина Heng Lu может служить нормативной рамкой, но не фактическим доказательством. Её акцент на происхождении, устойчивых идентичностях и проверяемых переходах поддерживает сохранение первого решения, отказ от подмены окончательного результата выводом по оспариванию и перенос истории в новое решение.

Источники