Zusammenfassung

  • Laut endgültiger Datenübersicht führte der Experte für die chinesische Schrift nach der öffentlichen Konsultation eine zusätzliche KI-gestützte Untersuchung mit vier Methoden durch. Dabei wurden 1.612 Han-Ähnlichkeitsfälle identifiziert und nach weiterer Fachberatung in die chinesischen, japanischen und koreanischen SSE-Daten übernommen.
  • Diese Fälle erweitern eine Eingabeschicht. Das SSE-Werkzeug erzeugt mögliche Konfliktgruppen; das unabhängige Gremium darf sie ergänzen, entfernen oder verändern, muss seine Entscheidung zur vollständigen Zeichenkette begründen und kann nach einer binnen 21 Tagen geltend gemachten Sach-, Verfahrens- oder Systemstörung neu bewerten.

Eine größere Suchfläche ist nicht dasselbe wie eine größere Entscheidungsgewalt. Genau diese Trennlinie macht die Zahl 1.612 in ICANNs Veröffentlichung vom 30. Juli bedeutsam.

Die endgültige Übersicht beschreibt eine zusätzliche Untersuchung nach dem Ende der Konsultation. Der Experte für die chinesische Schrift nutzte dabei vier KI-gestützte Ansätze: konvolutionale neuronale Netze, Analyse der Strichstruktur, Zernike-Momente und Rasterhistogramme. ICANN zufolge ergaben sich daraus 1.612 weitere Ähnlichkeitsfälle in der Han-Schrift. Nach erneuter Beratung mit Schriftexperten wurden sie unter dem konservativen Grundsatz in die Daten für Chinesisch, Japanisch und Koreanisch aufgenommen.

Die Angabe betrifft keine Bewerbungen. Sie bezeichnet auch keine abgelehnten Zeichenketten, bestätigten Konflikte, Fehler oder Entscheidungen des Gremiums. Ein zusätzlicher Zusammenhang zwischen Codepunkten oder Folgen von Codepunkten kann dazu führen, dass das Werkzeug später mehr Zeichenketten zum Vergleich vorlegt. Ob eine solche Beziehung überhaupt eine beantragte Zeichenkette trifft, ist aus den geprüften Quellen noch nicht ersichtlich.

Die Daten weisen auf mögliche Prüfgegenstände hin. Sie verfügen nicht über die Befugnis, einer Bewerbung eine Folge zuzuweisen.

Von der kommentierten Fassung zur verbindlichen Eingabe

Im Oktober 2025 legte ICANN eine gemeinsame und 26 schriftspezifische Dateien zur Konsultation vor. Der Ansatz war bereits damals bewusst vorsichtig. Wenn die Ähnlichkeit zweier Elemente unklar blieb, konnten sie in die Menge aufgenommen werden, damit die spätere Prüfung sie nicht aufgrund eines engen Vorfilters übersah.

Auch Variantenbeziehungen und Transitivität konnten Elemente in derselben Menge zusammenführen, obwohl ein Experte das konkrete Paar nicht unmittelbar als verwechselbar eingestuft hatte. Kategorie und Begründungscode machten solche mechanisch entstandenen Beziehungen kenntlich. Die Dateien deckten das gesamte Repertoire der Root Zone Label Generation Rules ab.

Das SSE-Werkzeug sollte diese Daten nutzen, um eine durch Varianten stark anwachsende Vergleichsmenge zu bewältigen. Sein Bericht würde potenzielle Konfliktgruppen liefern. Schon die kommentierte Fassung stellte klar, dass diese Gruppen nicht endgültig sind und vom Gremium verändert werden dürfen.

Die Konsultation lief vom 16. Oktober bis 4. Dezember 2025 und erhielt elf Stellungnahmen. Sie enthielten konkrete Vorschläge zum Hinzufügen oder Entfernen von Paaren, Forderungen nach öffentlichem Zugang zum Werkzeug, Empfehlungen für spätere Pflege und den Wunsch nach vorsichtiger Einstufung bei Zweifeln. ICANN antwortete, es werde die technische und organisatorische Machbarkeit eines öffentlichen Zugangs prüfen. Die endgültige Fassung sollte für die Runde 2026 feststehen; spätere Hinweise würden für künftige Arbeiten gesammelt.

Die Juli-Fassung legt die Han-Erweiterung offen. Sie nennt Methoden, Umfang, betroffene Dateien und die zusätzliche Beratung. Daher wäre es falsch, von einer verborgenen Änderung zu sprechen.

Ebenso wenig belegt eine Änderung nach Konsultationsschluss, dass die Konsultation umgangen wurde. Kommentare können erst nach Fristende ausgewertet und in eine Schlussfassung eingearbeitet werden. Die geprüften Unterlagen enthalten keine Pflicht, bei jeder fachlichen Korrektur oder Erweiterung eine neue Konsultation zu eröffnen. Die engere Kontrollfrage lautet: Lässt sich eine wesentliche Änderung erkennen, begründen und später mit einer konkreten Folge verbinden?

Die öffentlichen Materialien bieten keine zeilenweise, maschinenlesbare Differenzdatei, die alle 1.612 Ergänzungen samt früherem Zustand, Herkunftsklasse und fachlicher Behandlung isoliert. Sie zeigen auch noch nicht, welche Beziehung eine reale Bewerbung berühren wird. Diese Sichtbarkeitsgrenze beweist weder das Fehlen interner Änderungsunterlagen noch eine fehlende Prüfung.

Eine feste Version ist kein festes Urteil

Die endgültigen Daten und Leitlinien tragen jeweils die Version 1.0 und das Datum 23. Juli 2026. Die Leitlinien bestimmen sie als anwendbare Fassungen für die Runde 2026. Weitere Hinweise können eingereicht, protokolliert und mit den zuständigen Experten erörtert werden, ändern aber die gemeinsame Grundlage dieser Runde nicht.

Das schafft zeitliche Gleichbehandlung. Bewerbungen derselben Runde sollten nicht anhand still wechselnder Zuordnungen beurteilt werden. Eine bezeichnete Fassung macht den Ausgangspunkt reproduzierbar und verhindert, dass ein späterer Dateistand rückwirkend als damalige Grundlage erscheint.

Festgeschrieben ist die Eingabe, nicht das Ergebnis. Das SSE-Werkzeug erstellt einen Vorscreening-Bericht mit potenziellen Konfliktgruppen. Das Gremium nutzt ihn als einen von mehreren Inputs und kann zusätzliche Analysen berücksichtigen. Es darf Gruppen anpassen, ergänzen oder entfernen und trägt die Verantwortung für die endgültige Feststellung.

Zudem wechselt der Prüfgegenstand. Die Daten bewerten Codepunkte oder Codepunktfolgen; das Gremium beurteilt vollständige Zeichenketten. Position, Schriftart, Großschreibung, Zusammensetzung und die Wahrnehmung in der jeweiligen Schrift können das Gesamtbild verändern. Die Leitlinien verlangen deshalb Mitwirkung von Personen mit muttersprachlicher Lesefähigkeit und eine Begründung der Ergebnisse. Abweichungen vom Werkzeug sind ausdrücklich zu erläutern.

Bei schwer entscheidbaren Fällen soll der konservative Weg erwogen und die Ähnlichkeit bejaht werden. Diese veröffentlichte Tendenz ist überprüfbar, sagt aber nicht das Ergebnis eines noch ungeprüften Falls voraus.

Vier Zustände dürfen nicht ineinanderfallen:

  1. Ein Ähnlichkeitsfall befindet sich in einer Schriftdatei.
  2. Das Werkzeug schlägt auf Basis der festen Daten eine potenzielle Konfliktgruppe vor.
  3. Das Gremium entscheidet über vollständige Zeichenketten und nennt Gründe.
  4. Eine fristgerechte Beanstandung prüft einen Sach-, Verfahrens- oder Systemfehler und führt zur Bestätigung oder Neubewertung.

Wer den ersten Zustand bereits als dritten beschreibt, macht ein Register zur Autorität. Wer den zweiten als unantastbare technische Wahrheit behandelt, macht eine Arbeitserleichterung zum Mandat.

Erst die Gremienentscheidung löst Folgen aus

Der Applicant Guidebook ordnet den Ergebnissen konkrete Wirkungen zu. Je nach Vergleichsgegenstand kann visuelle Ähnlichkeit eine Bewerbung am Fortgang hindern, sie zurückstellen oder mit einer anderen Bewerbung in eine Konfliktgruppe bringen. Das maßgebliche Ergebnis gilt für die zugehörige Variantenmenge. ICANN will Ergebnisse und Begründungen auf der Seite mit den Evaluation Results veröffentlichen.

Damit ist die Rollenverteilung materiell. Die Daten halten mögliche Beziehungen fest. Das Werkzeug macht den Suchraum beherrschbar. Das Gremium entscheidet, ob vollständige Zeichenketten so ähnlich sind, dass ihre gemeinsame Delegation eine Verwechslungswahrscheinlichkeit schafft. ICANN vollzieht anschließend die im Programm vorgesehene Konsequenz.

Eine Bewerbung kann binnen 21 Tagen nach Erhalt des Ergebnisses eine Evaluation Challenge einreichen. Zulässig sind behauptete Sach-, Verfahrens- oder Systemfehler. Wird ein Fehler bestätigt, findet unter Berücksichtigung dieser Feststellung eine Neubewertung statt. Andernfalls bleibt das ursprüngliche Ergebnis bestehen. Der Weg ist keine unbegrenzte zweite Sachprüfung und erlaubt keine wesentliche Veränderung der Bewerbung als Ersatz für den Fehlernachweis.

Diese Architektur begrenzt Macht besser als ein vollautomatisches Ergebnis. Sie bleibt aber nur nachvollziehbar, wenn die Schichten verbunden sind. Ein Ergebnis ohne die genaue Datenversion lässt sich nicht reproduzieren. Eine Begründung, die nur die Werkzeugausgabe wiederholt, verleiht dem Vorschlag Entscheidungskraft. Eine Korrektur ohne Ablösungshistorie lässt die alte Erklärung weiterleben, obwohl sie nicht mehr gilt.

Ein Beleg vom Datenwechsel bis zur Entscheidung

Öffentliche Kontrolle verlangt weder vorzeitige Offenlegung geschützter Bewerbungen noch die Veröffentlichung vertraulicher Beratungen oder personenbezogener Angaben. Sie verlangt eine belastbare Verbindung zwischen einer wesentlichen Datenänderung und einer später öffentlich wirksamen Entscheidung.

Daniel Kades vorgeschlagener Änderungs-Entscheidungs-Beleg beginnt mit der Datenversion und den Fingerabdrücken der betroffenen Dateien. Für jede erhebliche Ergänzung, Entfernung oder Neueinstufung zwischen Konsultations- und Endfassung hält er Codepunkt oder Folge, Zustand davor und danach sowie eine Herkunftsklasse fest: Reaktion auf öffentliche Stellungnahmen, Expertenkorrektur, fachliche Erweiterung, KI-gestützter Kandidat, Transitivitätseinfügung oder mechanische Transformation.

Hinzu kommen Eingangsdatum, Methode, Begründung, betroffene Schriften und Stand der Expertenberatung. Der Beleg trennt Beziehungen, die in die Berechnung eingehen, von solchen, die nur dokumentiert werden. Eine Beratung darf nicht als Einstimmigkeit dargestellt werden, wenn die Quelle diese nicht nachweist.

Trägt eine Beziehung später zu einer potenziellen Konfliktgruppe bei, verbindet der geschützte Teil diesen Beitrag mit der Werkzeugversion. Sobald das Programm die Veröffentlichung zulässt, verknüpft der öffentliche Teil die Entscheidung zur vollständigen Zeichenkette, die angewandte Leitlinie und den Grund für Übernahme, Ergänzung, Entfernung oder Übersteuerung. Beanstandung, bestätigter Fehler, Neubewertung, Korrektur und Ablösung bleiben Teil derselben Geschichte.

ICANN hat einen solchen Beleg nicht angekündigt; er ist Daniel Kades Vorschlag. Die endgültigen Daten stehen bereits in HTML und XML bereit. Eine maschinenlesbare Differenz zwischen kommentierter und endgültiger Fassung sowie aggregierte Zahlen nach Schrift und Herkunft würden die Transparenz vertiefen, ohne Bewerbungsinformationen verfrüht zu veröffentlichen.

Die 1.612 Fälle sind weder ein Argument gegen Automatisierung noch ein Freibrief für maschinelle Entscheidung. Größe verlangt Vorscreening, Schrift verlangt Fachkenntnis, Folgen verlangen zurechenbares Urteil und Fehler verlangen einen begrenzten Korrekturweg. Governance entsteht aus diesen Grenzen.

Quellen

  1. ICANN — Ankündigung der SSE-Daten und Leitlinien, 30. Juli 2026
  2. ICANN — endgültige Übersicht der SSE-Daten, Version 1.0
  3. ICANN — endgültige SSE-Leitlinien, Version 1.0
  4. ICANN — Ressourcenseite zur String Similarity Evaluation
  5. ICANN — öffentliche Konsultation zu den SSE-Daten
  6. ICANN — Zusammenfassungsbericht zur Konsultation der SSE-Daten
  7. ICANN — zur Konsultation gestellte Übersicht der SSE-Daten
  8. ICANN — Applicant Guidebook für die neue gTLD-Runde 2026
  9. ICANN — FAQ zur Beanstandung von SSE-Ergebnissen