Synchrone Wellen und NOMOS-Erfassung

Kapitelgrenze

Die ersten elf Kapitel legen die Grundlagen der Messung fest: Eine einzelne Antwort ist kein GEO-Score; Repräsentation ist eine Verteilung über Nutzer und Systembedingungen; die geprüfte Entität muss definiert werden, bevor Ergebnisse beobachtet werden; offizielle Repräsentation und verifizierte Entitätsrealität müssen getrennt bleiben; jedes KI-Produkt benötigt seine eigene berechtigte Nutzerpopulation; Teilnehmer müssen durch eine populationsbasierte, versionierte und ergebnisunabhängige Methode ausgewählt werden; kleinere Länder und Sprachen mit geringeren Ressourcen müssen durch spezielle Beobachtungsgremien sichtbar bleiben; das KI-Produkt, der Plan, die Nutzeroberfläche und die Systemkonfiguration müssen in einem Register verknüpft werden; Aufforderungen müssen die gleiche Nutzerabsicht über Sprachen hinweg bewahren und nicht die gleichen Wörter; und kontrollierte, saubere und natürliche Nutzerpanels müssen unterschiedliche Realitäten messen. Diese Elemente müssen nun in einem einzigen Messevent zusammengeführt werden:

Wann werden die Teilnehmer die Prompt einreichen, wie werden sie die anfängliche Ausgabe erfassen und wie werden sie nachweisen, dass jede Beobachtung danach nicht verändert wurde?

Ihre Gründungsidee war klar: Menschen in verschiedenen Ländern der Welt sollten denselben Prompt gleichzeitig an dasselbe KI-Produkt senden und dies mit einem Screenshot nachweisen. Diese Idee ist der experimentelle Kern von GEO-1000. Allerdings ist der Ausdruck „zur gleichen Zeit“ allein nicht ausreichend. Wenn alle Teilnehmer versuchen, zur gleichen Sekunde einzureichen:

• verändern sich die Verbindungsgeschwindigkeiten,
• tauen die Uhren der Geräte voneinander ab,
• einige Nutzer sind gezwungen, um Mitternacht zu arbeiten,
• es kann einen plötzlichen Lastanstieg auf dem KI-Produkt geben,
• der Anbieter kann Geschwindigkeits- oder Nutzungslimits anwenden,
• einige Antworten können in zwei Sekunden, andere in zwei Minuten fertiggestellt werden,
• das Produkt kann während der Messung aktualisiert werden,

Ein Teilnehmer kann die Antwort sofort hochladen, ein anderer Stunden später. Ein Klick im gleichen Moment garantiert nicht, dass wir denselben Systemzustand perfekt messen. Ebenso ist das bloße Sammeln eines Screenshots nicht ausreichend. Ein Screenshot:

• kann zugeschnitten sein,
• kann die Prompt nicht zeigen,
• kann nicht beweisen, ob die Antwort anfänglich oder aktualisiert ist,
• kann Produkt- und Planinformationen nicht zeigen,
• kann an einem anderen Tag aufgenommen worden sein,
• kann von einem anderen Nutzer kopiert worden sein,

Es kann später bearbeitet worden sein. Aus diesem Grund muss GEO-1000 zwei separate Systeme zusammen installieren:

Synchronisierte Messwelle

und:

NOMOS Aufnahme-Kette von Evidenzmitteln

Die synchronisierte Welle beantwortet die folgende Frage:

Wurden die Beobachtungen innerhalb einer vergleichbaren Systemzeit und in einer vordefinierten Einreichungsreihenfolge erzeugt?

NOMOS Capture fragt andererseits:

Können wir zeigen, dass der gesendete Prompt, die resultierende erste Ausgabe, die Produktbedingungen und die Zeitinformationen ohne Änderungen erhalten geblieben sind?

Die vorherige Audit-Architektur stellte fest, dass jede Prüfung Modell oder Produkt, Datum, Land, Sprache, Abfragesatz, Wiederholungsanzahl und Messdatensatz als zwingende Messlogik enthalten muss. Diese Anforderung ist nicht nur eine technische Vorschrift. Denn unsichtbare Anweisungen, gefälschte Nachweise und als unabhängig dargestellte Inhalte können letztlich die Repräsentation verzerren, die von echten Menschen übernommen wird. Dieser Abschnitt:

• Messwelle,
• Synchronisationsfenster,
• UTC Zeitstandard,
• Versandfenster,
• Abschluss- und Erfassungszeiten,
• Erstkontaktergebnis und erste Inhaltsausgabe,
• technische Wiederholungsregeln,
• Produktänderungen innerhalb der Welle,
• Externe Ereignis- und Nachrichteneffekte,
• NOMOS Evidenzpaket erfassen,
• Die Beziehung von Screenshot, Rohantwort und Metadaten,
• Zeitvalidierung,
• Dateiintegrität,
• Hash und digitale Signatur,
• Evidenzkette,
• Datenschutz und Schwärzung,
• Öffentliches Evidenzverzeichnis,
• Qualitäts- und Gültigkeitsstatus der Welle

definiert. Dieses Kapitel behandelt noch nicht:

• Welche Realität die atomaren Aussagen in KI-Antworten aufzeichnet, wird bewertet,
• Wie Schiedsrichter Antworten kodieren werden,
• Übergangs- und kritische Fehlergrenzen,
• Legt die endgültigen NOMOS Punkformeln nicht fest

Die Hauptfrage von Kapitel 12 lautet:

Wie verknüpfen wir Tausende von echten Nutzerbeobachtungen mit demselben Messereignis und verwandeln jede in eine unveränderliche, prüfbare, die Privatsphäre schützende Beweiseinheit?

NOMOS Herausforderung

Sie geben denselben Prompt an tausend Personen. Sie sagen: „Schicken Sie es heute Mittag.“ Ein Nutzer schickt es in Istanbul um 12:03 Uhr nachmittags. Ein anderer Nutzer schickt es in London um deren lokale Mittagszeit. Ein weiterer Nutzer sieht die Aufgabe abends in Tokio und erledigt sie acht Stunden später.

Ein Nutzer hatte die Geräteuhr falsch eingestellt. Die Internetverbindung eines anderen Nutzers war unterbrochen. Jemand anderes mochte die Antwort nicht und drückte den „Regenerate“-Button. Dann lud er einen Screenshot der längsten und positivsten Antwort hoch. Ein Nutzer hat nur die Mitte der Antwort zugeschnitten, der Prompt ist nicht sichtbar. Der Name des KI-Produkts ist nicht sichtbar.

Eine andere Person schickte denselben Screenshot mit zwei verschiedenen Panel-Konten. Ein Nutzer erledigte die Aufgabe korrekt, lud den Screenshot jedoch zwei Tage später hoch. In der Zwischenzeit haben sie die Datei zugeschnitten und ihre persönlichen Informationen gelöscht. Der ursprüngliche Zustand der Datei wurde nicht bewahrt. Ein anderer Nutzer in der ersten Antwort der KI:

Es erhielt das Ergebnis „Ich kann diese Frage nicht beantworten.“ Der Forscher sagte: „Es muss ein technischer Fehler vorgelegen haben“ und bat darum, es erneut zu versuchen. Die zweite Antwort war korrekt, und nur die zweite Antwort wurde im Bericht aufgenommen. Ein anderer Nutzer erlebte einen echten Verbindungsfehler. Die Prompt wurde gesendet, aber das System erzeugte keinen Inhalt.

Diesmal erlaubte der Forscher kein erneutes Ausprobieren. Dasselbe Protokoll wurde auf zwei Nutzer unterschiedlich angewendet. Nun, mitten in der Messwelle, der KI-Anbieter:

• Websuchverhalten,
• Zitationssystem,
• die verwendete Modellanleitung

ändert alle drei. Die ersten 500 Personen sehen den alten Systemzustand; die nächsten 500 sehen den neuen. Der Bericht sagt dann: ‚1,000 Personen haben das gleiche KI-System zur gleichen Zeit getestet.‘ Diese Aussage ist falsch. Es gibt tausend Nutzer, aber nicht unbedingt eine einzige kohärente Messwelle.

Nun wendet ihr einen Hash auf alle Bildschirmaufnahmen an. Ihr sagt, dies beweist, dass alle Beobachtungen real sind. Was beweist ein Hash? Er stärkt die Sicherheit, dass die Datei nach der Erstellung des Hashes nicht verändert wurde. Allein beweist er nicht:

• Dass das Bild von einem realen KI-Produkt stammt
• Dass es die erste Antwort war
• Dass es zur richtigen Zeit erhalten wurde
• Dass es nicht von einem anderen Nutzer kopiert wurde
• Dass der Prompt korrekt war
• Dass das Bild vor dem Hashen nicht bearbeitet wurde

Die erste Prämisse dieses Abschnitts lautet:

Zur gleichen Zeit messen ist nicht dasselbe wie in derselben Sekunde klicken.

Ihre zweite Bestimmung lautet:

Ein Screenshot ist Teil des Evidenzpakets; er ist nicht das gesamte Evidenzpaket.

Seine dritte Bestimmung besagt:

Die erste falsche Antwort ist kein Datenfehler. Wenn sie nach dem Protokoll erzeugt wird, ist sie das Ergebnis der Messung.

Seine vierte Bestimmung besagt:

Hash stärkt die Integrität; er schafft nicht von selbst die Realität der Beobachtung.

Seine fünfte Vorschrift lautet:

Wenn sich das System in einer Welle wesentlich ändert, können tausend Antworten ohne Zeitstempel nicht als zum selben System gehörig betrachtet werden.

Seine sechste Bestimmung lautet:

Die Evidenzkette wird nicht erstellt, um das Ergebnis gut aussehen zu lassen, sondern um später nachvollziehen zu können, wie das Ergebnis erzeugt wurde.

1. ZWECK DES KAPITELS

Der Zweck dieses Abschnitts besteht darin, GEO-1000 Nutzerbeobachtungen in vergleichbaren Zeitfenstern zu erzeugen und jede Beobachtung mit einer vollständigen digitalen Evidenzkette zu sichern. Der Abschnitt standardisiert die folgenden Unterscheidungen:

• Messfenster synchronisiert auf die gleiche Sekunde
• Lokale Zeit versus UTC Zeit
• Welle versus Unterwelle
• Übertragungszeit versus Antwortabschlusszeit
• Aufzeichnungszeit versus Upload-Zeit
• Geplanter Slot versus tatsächliche Übertragung
• Erster Systemkontakt versus erste Inhaltsantwort
• Technischer Fehler versus Systemablehnung
• Technischer Wiederholversuch versus Antwortaktualisierung
• Die bestausgewählte Ausgabe mit der ersten passenden Ausgabe
• Sichtbarkeit auf dem Bildschirm mit Abschluss der Antwort
• Rohantwort mit Screenshot
• Screenshot versus vollständiges Evidenzpaket
• Beobachtungsoriginalität mit Dateiintegrität
• Zeitstempel mit Hash
• Zuverlässige Zeitquelle mit lokaler Gerätezeit
• Server-Akzeptanzzeit mit Teilnehmer-Upload
• Schwärzte öffentliche Kopie mit Rohbeweis
• Teilnehmeridentität mit Beobachtungs-ID
• Antwortgenauigkeit mit Erfassungsvalidität
• Natürliche Ausgabenvarianz mit Produktaktualisierung
• KI-Produktänderung mit externem Nachrichtenereignis
• Wellenbeendigung mit Ausschluss nach Ergebnis
• Automatische Bot-Messung mit Erfassung durch menschlichen Nutzer
• API-Protokoll mit Nutzeroberflächenaufzeichnung
• Anbieter-Telemetrie mit unabhängiger Erfassung
• Zugriff auf Nachweise für alle durch Speichern der Nachweise
• Unwiderruflicher Datensatz mit unveränderlichem Datensatz
• Versionierte Korrektur einer falschen Entscheidung mit Rohdatenschutz

Am Ende dieses Abschnitts sollte jedes GEO-1000-Audit in der Lage sein, die folgenden Fragen zu beantworten:

Zu welcher Welle gehört diese Beobachtung?

Zu welcher UTC-Zeit wurde die Aufforderung gesendet?

Was war das ursprüngliche Systemergebnis?

Wann wurde die Antwort abgeschlossen und wann wurde sie erfasst?

Wenn ein technischer Wiederholungsversuch durchgeführt wurde, was war der Grund und wo war der vorherige Versuch?

Zeigt die Screenshot-Prompt das Produkt und die vollständige Antwort?

Bestätigen die Rohantwort und die visuelle Darstellung einander?

Wann wurden der Hash und der Zeitstempel der Dateien erstellt?

Wenn das Evidenzmaterial später geändert wurde, ist die Änderungshistorie sichtbar?

Kann ein unabhängiger Prüfer die Rohbeweise überprüfen, während die Privatsphäre der Teilnehmer gewahrt bleibt?

2. ZENTRALE NORMATIVE BESTIMMUNG

Jede GEO-1000-Beobachtung muss vor der Datenerfassung mit einer festgeschriebenen Messungswelle verknüpft sein; alle relevanten Zeiten vom Senden der Prompt bis zum ersten Systemergebnis, vom Abschluss der Antwort bis zur Aufnahme und zum Hochladen; Bedingungen des KI-Produkts; die vollständige gesendete Prompt; die erste geeignete Ausgabe und alle Integritätsaufzeichnungen müssen in einem versionierten NOMOS-Capture-Evidence-Paket aufbewahrt werden. Eine GEO-1000-Beobachtung allein:

• Screenshot,
• kopierter Antworttext,
• Teilnehmererklärung,
• Datei-Hash

kann nicht für sich allein als gültig betrachtet werden. Das Hauptbeweispaket muss, soweit relevant, Folgendes enthalten:

• Wave-ID
• Anonyme Beobachtungs-ID des Teilnehmers
• KI-Systemregistereintrag
• Panelstatus
• Prompt-ID und Version
• Zugewiesene Prompt
• Gesendete Prompt
• Übermittlungszeit
• Erste Systemkontaktaufnahme
• Antwortabschlusszeit
• Erfassungszeit
• Hochladezeit
• Vollständige Rohantwort
• Vollbild- oder sequenzielle Screenshots
• Referenz- und Quelldatensätze
• Technischer Fehler- und Wiederholungsprotokoll
• Produkteinstellungen
• Datei-Hashes
• Paket-Hash
• Zeitüberprüfungsaufzeichnung
• Erfassungswerkzeug-Version
• Gültigkeitsentscheidung
• Datenschutz- und Schwärzungsstatus
• Eigentümer der Evidenzkette

3. WAS IST EINE MESSWELLE?

Eine Messwelle ist ein umfassendes Datenerhebungsereignis, das unter vordefinierten Bedingungen durchgeführt wird:

• KI-Produkten,
• Zielpopulation,
• Aufforderungsversionen,
• Nutzerpanels,
• Zeitfenster,
• Stichprobenverteilung,
• Erfassungsprotokoll,
• Referenzaufzeichnungen

Eine Welle:

Wk=(A,U,P,F,T,C,R,G)

kann repräsentiert werden als. Hier:

• A: Beispiele für KI-Produkte
• U: Zielnutzerpopulation und Stichprobe
• P: Aufforderungssatz
• F: Panelzustände
• T: Zeit- und Abgabestruktur
• C: Erfassungsprotokoll
• R: Referenzrealitätsversion
• G: Governance und Hauptaufzeichnung

Wenn sich eines dieser Felder wesentlich ändert, kann eine neue Welle oder Unterwelle erforderlich sein.

4. ARTEN VON WELLEN

MW-1— HAUPT-SYNCHRONISIERTE WELLE

Es ist die Hauptmessung der GEO-1000-Population. Standardmäßig zielt sie auf mindestens 1,000 gültige Beobachtungen des Population Panels für jedes KI-Produkt ab.

MW-2— BESTÄTIGUNGSWELLE

Sie wird durchgeführt, um das Ergebnis der ersten Welle zu wiederholen, einen spezifischen Fehler zu bestätigen oder die statistische Stabilität zu testen. Sie wird nicht verwendet, um die niedrige oder hohe Punktzahl der ersten Welle zu ändern. Sie liefert ein separates Ergebnis.

MW-3— INCIDENT-WELLE

Sie wird nach einem kritischen oder signifikanten Beobachterereignis für gezielte und schnelle Überprüfung durchgeführt. Sie ist keine globale Hauptwelle.

MW-4— TRENDÜBERWACHUNGSWELLE

Überwacht Zeitänderungen im Verhalten von Produkt, Einheit, Ressource oder Sprache.

MW-5— KORREKTUR-NACHTEST-WELLE

Erzeugt neue Ergebnisse nach einer Korrektur oder Intervention. Die vorherige Welle wird nicht gelöscht.

MW-6— LOKALZEIT-AUSGEWOGENE WELLE

Zielt darauf ab, Teilnehmer unter ähnlichen lokalen Zeitzuständen zu messen. Es wird nicht ein einzelner globaler Systemmoment gemessen.

MW-7— KONTROLLIERTE LABORATORIUMSWELLE

Ein eingefrorenes Modell ist eine kontrollierte Studie, die mit API- oder Standard-Testkonten durchgeführt wird. Es ist kein Panel echter Nutzerpopulation.

5. WAS BEDEUTET „GLEICHE ZEIT“?

In GEO-1000 bedeutet Gleichzeitigkeit:

Es bedeutet nicht, dass alle Nutzer zur gleichen Millisekunde klicken

Die funktionale Definition ist:

Beobachtungen werden innerhalb eines vorbestimmten UTC-Messfensters erzeugt, entsprechend aufgezeichneter und ergebnisunabhängiger Einreichungszeitfenster.

Dieser Ansatz balanciert drei Ziele aus:

• Den Produktstatus zeitlich nahe zu halten
• Plötzliche künstliche Last für den Anbieter zu reduzieren
• Teilnehmer-Einreichungen auf reproduzierbare Weise zu verteilen

6. ZEITSTRUKTUR

Jede Welle muss mindestens vier Zeitschichten enthalten.

6.1. Wellenfenster

Es ist der Bereich UTC, in dem alle Haupt-Einreichungen vorgenommen werden müssen. Beispiel:

12:00–13:00 UTC

6.2. Mikro-Zeitfenster

Dies ist das kürzere Zeitintervall, das dem Teilnehmer zugewiesen wird, um die Aufforderung zu senden. Beispiel:

12:15–12:20 UTC

6.3. Zusätzliche Zeit für die Fertigstellung

Wenn die Eingabe innerhalb des Slots gesendet wird, ist die vordefinierte Zeit für die Fertigstellung der Antwort.

6.4. Zeit für das Erfassen und Hochladen

Die Zeit, die für das Erstellen des Nachweises und dessen Hochladen in ein sicheres System nach Abschluss der Antwort erlaubt ist.

7. GRUNDREGEL FÜR SYNCHRONISIERTE WELLE DES KANDIDATEN

GRUNDREGEL FÜR KANDIDATEN — GRUNDLEGENDES PRINZIP FÜR KANDIDATEN

Für allgemeine Verbraucher-Chat-Produkte kann die folgende Struktur als Hauptkandidat für synchronisierte Wellen verwendet werden:

• Einreichungsfenster: 60 Minuten
• Mikro-Slots: 12× 5 Minuten
• Teilnehmer-Einreichung: innerhalb des ihnen zugewiesenen Mikro-Zeitfenster
• Zusätzliche Zeit für die Fertigstellung der Antwort: bis zu 20 Minuten nach der Einreichung
• Erzeugung des Capture-Hashes: vorzugsweise innerhalb von 5 Minuten nach Abschluss der Antwort
• Nachweis-Upload: spätestens innerhalb von 60 Minuten nach der Aufnahme
• Meldung technischer Probleme: innerhalb derselben Welle

Diese Zeiträume sind universell und nicht endgültig. Sie können sich unter den folgenden Bedingungen ändern:

• Antwortzeit des KI-Produkts
• Mobile Verbindung
• Infrastruktur des Landes
• Langantwortformat
• Barrierefreiheitsanforderung
• Nutzungslimit des Produkts

Die verwendeten Zeiten sollten vor der Datenerfassung festgelegt werden.

8. WARUM MIKRO-SLOTS?

Gleichzeitige Einreichung durch tausend Teilnehmer:

• Außergewöhnliche Belastung des KI-Produkts,
• Geschwindigkeitsbegrenzung,
• Warteschlange,
• technischer Fehler,
• Anstieg der Antwortzeit

kann erstellt werden. In diesem Fall kann das Audit das normale Verhalten des Produkts nicht messen, aber:

kann das vom Audit erzeugte künstliche Lastereignis messen

Mikro-Slots:

• verteilen die Last,
• halten die gleiche gesamte Systemzeit bei,
• machen die Einreichungsreihenfolge unabhängig vom Ergebnis,

ermöglichen die Modellierung des Zeiteffekts.

9. SLOT-ZUWEISUNG

Teilnehmer sollten Slots zugewiesen werden:

• Land,
• Sprache,
• KI-Produkt,
• Plan,
• auf ausgewogene und vorab zufällig bestimmte Weise in Bezug auf:

Panel-Status. Ein Mikro-Zeitfenster allein sollte nicht ausgefüllt werden mit:

• bestimmtem Land,
• bestimmter Sprache,
• bestimmtem Produkt

Nutzern. Andernfalls wird der Zeiteffekt mit dem Gruppeneffekt verfälscht.

10. FAIRE LOKALE ZEIT

Ein einzelnes UTC-Fenster kann für einige Teilnehmer sein:

• Nacht,
• Arbeitszeiten,
• Gebets- oder Ruhezeit,
• schwer erreichbare Stunden

Diese Situation:

• Teilnahmerate,
• Verbindungsbedingungen,
• Aufmerksamkeit der Nutzer,
• Gerätetyp

kann beeinflusst werden. Es können zwei ergänzende Methoden verwendet werden.

10.1. Rotierende globale Wellen

Hauptwellen werden zu verschiedenen UTC-Zeiten durchgeführt. Beispiel:

• Welle 1: 12:00 UTC
• Welle 2: 20:00 UTC
• Welle 3: 04:00 UTC

So trägt dieselbe Region nicht bei jeder Welle die gleiche lokale Zeitbelastung.

10.2. Lokalzeit-ausgeglichene Unterwelle

Teilnehmer werden in einem ähnlichen Zeitband in ihrer Ortszeit gemessen. Diese Studie:

• Nutzermüdigkeit,
• ist wertvoll für

tägliches Nutzungsverhalten. Sie ist nicht das Ergebnis eines einzelnen globalen Systemmoments.

11. DREI-WELLEN-STABILITÄTSARCHITEKTUR

KANDIDATEN-ARCHITEKTUR — KANDIDATEN-ARCHITEKTUR

Für die vollständige Implementierung von GEO-1000 können mindestens drei Hauptwellen vorgeschlagen werden:

W1 — Anfangswelle

Erzeugt die anfängliche Populationsschätzung.

W2 — Kurzzeit-Wiederholung

Testet die kurzfristige Stabilität des Produkts und der Messung. Kandidatenintervall: 24–72 Stunden nach W1

W3 — Mittelfristige Stabilität

Misst, ob die Repräsentation des Produkts und der Entität über einen langen Zeitraum hinweg erhalten bleibt. Kandidatenintervall: 14–30 Tage nach W1. Bestimmte Intervalle müssen vor der Datenerhebung festgelegt werden. Falls es aufgrund einer Produktaktualisierung oder eines Ereignisses geändert wird, ist ein neuer Versionsdatensatz erforderlich.

12. 30,000 BEOBACHTETER GRÜNDER ENTWURF

Für KI-Produkte, 1,000 Hauptbeobachtungen pro Produkt und für drei Hauptwellen:

10×1,000×3=30,000

Gültige Hauptpopulation-Panelbeobachtungen werden angestrebt. Ergänzend:

• Land Beobachter
• Sprachliche Fairness
• Barrierefreiheit
• Ereignis
• Nachtest

Panels können oberhalb dieser Zahl hinzugefügt werden. 30,000:

• ist nicht die Anzahl der Einladungen,
• ist nicht die Anzahl der Dateien,

ist nicht die Anzahl der Screenshots. Es ist das gültige Hauptprodukt-Beobachtungsziel.

13. ZEITVEKTOR DER BEOBACHTUNG

Für jede Beobachtung kann der Zeitvektor als Kandidat wie folgt definiert werden:

T_i= (t_i^assign, t_i^open, t_i^submit, t_i^first, t_i^complete, t_i^capture, t_i^upload, t_i^validate)

Hier:

• tiassign: die Zeit, zu der die Aufgabe dem Nutzer zugewiesen wird
• tiopen: die Zeit, zu der die Aufgabe geöffnet wird
• tisubmit: die Zeit, zu der die Eingabe gesendet wird
• tifirst: die Zeit, zu der das erste sichtbare Systemergebnis beginnt
• ticomplete: die Zeit, zu der die Antwort abgeschlossen ist
• ticapture: die Zeit, zu der der Nachweis erfasst wird
• tiupload: die Zeit, zu der das Paket das sichere System erreicht
• tivalidate: die Zeit, zu der die Gültigkeit der Erfassung überprüft wird

All diese Zeiten sind möglicherweise nicht direkt auf jeder Nutzeroberfläche beobachtbar. Unbekannte Felder sollten UNBEKANNT bleiben.

14. GRUNDLEGENDE ZEITMETRIKEN

Antwortverzögerung:

L_i= t_i^complete− t_i^submit

Erfassungsverzögerung:

C_i= t_i^capture− t_i^complete

Upload-Verzögerung:

U_i= t_i^upload− t_i^capture

Slot-Abweichung:

D_i= t_i^submit− t_i^{slot-midpoint}

kann wie folgt berechnet werden. Diese Metriken sind:

• Systemlast,
• Teilnehmerverzögerung,
• Beweissicherheit,
• Wellenintegrität

im Hinblick auf die Bewertung.

15. KANN NICHT NACH VERZÖGERUNG VERWALTET WERDEN

Eine über einen langen Zeitraum abgeschlossene Antwort:

• in die Kategorien gezwungen werden von wahr,
• falsch,
• lang,
• kann zitiert werden.

Aufgrund der Verzögerung gilt die Ausschlussregel:

• vor der Datensammlung,
• unabhängig vom Inhalt der Antwort

muss definiert werden. Folgendes Verhalten ist untersagt: eine negative Antwort auszuschließen, weil sie verspätet eingereicht wurde; eine positive Antwort zu schützen, wenn sie mit derselben Verzögerung eingereicht wurde.

16. WAVE STATUS STATUSES

WS-0— GEPLANT

Die Welle ist geplant. Sie wurde noch nicht festgeschrieben.

WS-1— festgeschrieben

Proben-, Aufforderungs-, Produkt-, Zeit- und Erfassungsregeln sind festgeschrieben.

WS-2— OFFEN

Das Einreichungsfenster hat begonnen.

WS-3— GESCHLOSSEN

Die Annahme neuer Einreichungen ist beendet. Fristen für Fertigstellung und Hochladen können weiterhin bestehen.

WS-4— ABGESCHLOSSEN

Feld- und erste Erfassungsüberprüfungen wurden abgeschlossen.

WS-5— GETEILT

Es wurde aufgrund von Materialsystem- oder Protokolländerungen in Unterwellen aufgeteilt.

WS-6— PAUSIERT

Vorübergehend gestoppt aufgrund von Sicherheits-, Produkt- oder Infrastrukturproblemen.

WS-7— ABGEBROCHEN

Vor Abschluss der Welle beendet. Ergebnisse können begrenzt oder unbrauchbar sein.

WS-8— INVALIDIERT

Ungültig für die Hauptprognose aufgrund eines zuvor definierten schwerwiegenden Protokollfehlers. Rohdaten werden nicht gelöscht.

WS-9— ARCHIVIERT

Version wurde geschlossen und die Evidenzkette archiviert.

17. WAVE-HEALTH-KLASSEN

WH-0— NICHT BEWERTET

Gesundheit der Welle wurde nicht bewertet.

WH-1— KOMPROMITTIERT

Es liegt eine Änderung des Materialsystems, der Zeit oder ein Erfassungsfehler vor. Möglicherweise nicht für das Hauptergebnis verwendbar.

WH-2— TEILWEISE

Einige Schichten oder Slots sind unzureichend. Ein reduziertes Ergebnis kann erzeugt werden.

WH-3— AKZEPTABEL

Hauptzeit, System- und Erfassungsbedingungen sind ausreichend erhalten.

WH-4— STARK

Hohe Erfassungszuverlässigkeit, ausgewogene Slot-Abdeckung und geringer Protokollverlust sind vorhanden.

WH-5— REPLIZIERT

Ähnliche Wellengesundheit wurde mehrfach und auf unabhängigen Panels wiederholt. Die Wellengesundheit hängt nicht davon ab, ob der KI-Score hoch oder niedrig ist.

18. PRODUKTÄNDERUNGEN INNERHALB DER WELLE

Das KI-Produkt kann sich innerhalb des Messfensters wesentlich ändern. Signale:

• Modellkennzeichenänderung
• Schnittstellenänderung
• Aktivierung oder Deaktivierung der Webfunktion
• Änderung des Zitationsformats
• Plötzlicher Bruch in der Antwortstruktur
• Ankündigung des Anbieters
• Unterschiedliches Systemverhalten gleichzeitig bei vielen Nutzern
• Produktunterbrechung oder Neustart

In diesem Fall: Die Zeit der Änderung wird geschätzt. Systemkonfigurations-Fingerabdrücke werden verglichen. Welle WS-5 kann in den SPLIT-Status versetzt werden. Vorherige und nachfolgende Beobachtungen werden separate Unterwellen sein. Wenn ein einzelner Wert erstellt werden soll, wird der Systemstatus als separater Faktor modelliert. Materielle Unsicherheit wird im öffentlichen Bericht dokumentiert.

19. EXTERNES EREIGNISPROTOKOLL

Die Welt kann sich ändern, auch wenn sich das KI-Produkt nicht ändert. Während der Messung:

• Unternehmensübernahme,
• Produkteinführung,
• wichtige Nachrichten,
• rechtliche Entscheidung,
• Krise,
• Finanzmitteilung,
• virale Inhalte

kann auftreten. Dieses Ereignis:

• Webressourcen,
• Abruf-Ergebnisse,
• Nutzerkommentar zur Prompt,
• KI-Antwort

kann geändert werden. Jede Welle, soweit sie relevant ist:

Externe Ereignisregistrierung

Muss tragen.

20. WIE WERDEN ERGEBNISSE EXTERNER EREIGNISSE VERWALTET?

Ein externes Ereignis:

• wenn es vor der Welle bekannt ist, wird das Referenzpaket aktualisiert,
• wenn es während der Welle eintritt, wird es mit einem Zeitstempel markiert,

wenn es nach der Welle bemerkt wird, wird ein retrospektiver Ereigniseintrag hinzugefügt. Folgendes Verhalten ist verboten: Beobachtungen aufgrund von Nachrichten auszuschließen, die den Score senken; sie zu bewahren, wenn es Nachrichten sind, die den Score erhöhen. Das Ereignis selbst kann Teil des realen Systemzustands sein. Falls notwendig, wird eine sub-wellen- oder ereignisangepasste Analyse durchgeführt.

21. ERGEBNIS DES ERSTEN KONTAKTS

Das erste Systemergebnis, das der Nutzer nach dem Senden der Prompt erhält:

Ergebnis des Erstkontakts

wird genannt. Das Ergebnis des Erstkontakts:

• Vollständige Antwort
• Ablehnung
• Technischer Fehler
• Nutzungslimit
• Verbindungsunterbrechung
• Endloses Laden
• Klärungsfrage
• Kein Ergebnis

möglich. Dieses Ereignis ist Teil der tatsächlichen Nutzererfahrung. Es kann nicht stillschweigend gelöscht werden.

22. ERSTE ZULÄSSIGE INHALTSAUSGABE

Die erste materielle Antwort, die im zuvor erlaubten erneuten Versuch nach einem technischen Fehler generiert wurde:

Kann als Erste Zulässige Inhalt Ausgabe bezeichnet werden

Diese Ausgabe: ersetzt nicht das anfängliche Kontaktergebnis, sie wird zusammen damit aufgezeichnet. Beispiel:

• Erstkontakt: Geschwindigkeitsbegrenzung
• Fünf Minuten später, zuvor erlaubter technischer erneuter Versuch
• Erste Inhaltsantwort

Der Bericht sollte Folgendes zusammenfassen:

• Erste Nutzererfahrung: Geschwindigkeitsbegrenzung
• Erste Inhaltsrepräsentation: spezifische Antwort

23. ERSTE GEEIGNETE AUSGABEREGEL

Wenn ein KI-Produkt eine signifikante Antwort auf den ersten Prompt liefert:

• selbst wenn es falsch ist,
• selbst wenn es kurz ist,
• selbst wenn sie eine Ablehnung beinhaltet,
• selbst wenn keine Referenzen angegeben werden,
• selbst wenn die Marke falsch identifiziert wird

eine Reproduktion kann nicht hergestellt werden. Die Hauptbeobachtung ist der erste Ausgang. Der Nutzer:

• Kann keine neue Antwort auswählen, indem durch:
• regenerieren,
• Umschreiben,
• Versuchen Sie es nochmal,
• Eine weitere Antwort,

Weitermachen

24. TECHNISCHER WIEDERHOLUNGSVERSUCH

Ein technischer Wiederholungsversuch kann nur unter zuvor definierten technischen Bedingungen verwendet werden. Zulässige Gründe des Kandidaten:

• Verbindungsunterbrechung, bevor die Antwort beginnt
• Serverfehlercode
• Schnittstelle sendet die Aufforderung nicht
• Anwendungsabsturz
• Überprüfter vorübergehender Systemausfall

Kann kein Grund für einen technischen Wiederholungsversuch sein:

• Falsche Antwort
• Ablehnung
• Kurze Antwort
• Fehlende Quellenangabe
• Marke nicht erwähnt
• Kritischer Fehler
• Die geprüfte Institution mag die Antwort nicht

25. WIEDERHOLUNG BEI TEILANTWORT

Wenn das System einen Teil des Inhalts erstellt hat und dann gestoppt wurde:

• Teilweise Ausgabe wird gespeichert,
• gespeichert als TRUNCATED_RESPONSE

wenn ein erneuter Versuch unternommen werden soll, wird ein neuer und verknüpfter Versuch erstellt. Er kann nicht gelöscht werden, als ob keine teilweise Antwort vorhanden wäre.

26. VERSUCHSKETTE

Eine Beobachtungszuweisung kann mehrere technische Versuche enthalten:

A_i→ (Attempt_{i,1}, Attempt_{i,2}, …)

Jeder Versuch:

• Zeit,
• trägt den Produktstatus,
• den Prompt-Hash,
• das Systemergebnis,
• den technischen Fehlgrund

Es wird nicht durch einen anderen Versuch überschrieben.

27. WAS IST NOMOS CAPTURE?

NOMOS Capture ist ein offener Daten- und Verfahrensstandard, der die Integrität der Beobachtung vom dem an den Nutzer gegebenen Prompt bis zur Archivierung des Evidenzpakets bewahrt. NOMOS Capture:

• ist nicht nur eine Screenshot-Anwendung,
• muss keine proprietäre Software sein, die nur NobleJackal gehört,

ist nicht nur auf eine einzelne Browser-Erweiterung angewiesen. Eine kompatible NOMOS Capture-Anwendung:

• verwendet ein offenes Datenschema,
• folgt Zeit- und Integritätsregeln,
• achtet Datenschutzgrenzen,
• bewahrt die Evidenzkette

muss eingehalten werden. Unabhängige Forscher sollten in der Lage sein, ihre eigenen kompatiblen Werkzeuge zu entwickeln. Wenn der Standard nur mit der Software des Gründers implementiert werden kann, schwächt unabhängige Replikation.

28. VIER FUNKTIONEN DER NOMOS CAPTURE

28.1. Aufgabe ausführen

Richtig:

• Nutzer,
• Prompt,
• KI-Produkt,
• Slot

stellt Übereinstimmung sicher.

28.2. Beobachtung erfassen

Protokolliert die Prompt, das anfängliche Systemergebnis, die Antwort und die zugehörige Nutzeroberfläche.

28.3. Integrität wahren

Erstellt den Dateihash, Zeitstempel und Paketbeziehung.

28.4. Nachweise transportieren

Verknüpft Roh-, eingeschränkte und öffentlich verfügbare Evidenzschichten miteinander.

29. ERFASSUNGSMETHODEN

CM-1— GELEITETE MANUELLE ERFASSUNG

Der Teilnehmer stellt einen Screenshot und den rohen Antworttext gemäß den Anweisungen bereit. Dies verursacht eine geringe technische Belastung. Es ist anfällig für menschliche Fehler.

CM-2— UNTERSTÜTZTE ERFASSUNGSANWENDUNG

Anwendung:

• Prompts kopieren,
• Zeitprotokollierung,
• Datei-Upload,
• Hash-Generierung

Funktionen werden unterstützt. Es beeinträchtigt das KI-Produkt nicht.

CM-3— INSTRUMENTIERTE NUTZEROBERFLÄCHENAUFNAHME

Browser- oder Anwendungsintegration:

• das gesendete Prompt,
• die Produktmetadaten,
• den Antworttext,
• die Zeiten

werden direkt erfasst. Bietet hohe Integrität. Nutzungsbedingungen und Datenschutz sollten bewertet werden.

CM-4— ANBIETER EXPORT ODER TELEMETRIE-AUFNAHME

Die Sitzungsexporte des Anbieters oder überprüfte Telemetrie werden verwendet. Kann die unabhängige Erfassung stark unterstützen. Kann allein keine Unabhängigkeit bieten.

CM-5— KONTROLLIERTE API- ODER LABORAUFNAHME

API- oder gefrorene Systemprotokolle werden verwendet. Es handelt sich nicht um eine Live-Beobachtung der Nutzeroberfläche. Gehört zu einem separaten Laborpanel.

30. GRENZE DER AUTOMATISIERUNG

Automatisierung:

• Prompt-Einreichung,
• Zeitprotokollierung,
• Hash-Erzeugung,
• Dateiintegrität

kann verwendet werden. Anstelle des Teilnehmers:

• Bot-Konto,
• automatisierte Massenabfrage,
• Nicht-Nutzersitzung

Erzeugung erstellt kein echtes Human Population Panel. Die Prüfung durch automatisierte Systeme ist separat:

CONTROLLED_AUTOMATION_PANEL

muss aufgezeichnet werden als.

31. ERFASSUNG DER ZUVERLÄSSIGKEITSSTUFEN

NCL-0— KEINE ÜBERPRÜFBARE ERFASSUNG

Es gibt nur die Aussage des Teilnehmers. Kann nicht als das Haupt-GEO-1000-Ergebnis einbezogen werden.

NCL-1— TEILWEISE NACHWEISE

Es gibt einen Antworttext oder einen eingeschränkten Screenshot. Der Prompt oder der Systemzustand können nicht vollständig überprüft werden.

NCL-2— SCREEN-BEWEIS

Der Prompt, die Antwort und die Hauptoberfläche des Produkts wurden mit einem Screenshot überprüft. Metadaten und Zeitvertrauen können eingeschränkt sein.

NCL-3— KOMPLETTES EVIDENZPAKET

Vollständige Antwort, Prompt, Produktaufzeichnung, Zeiten, Screenshot und Hash sind verfügbar. Mindeststufe für die Hauptanalyse ist ein Kandidat.

NCL-4— INSTRUMENTIERTE UND SIGNIERTE AUFNAHME

Das Aufnahmetool hat die Prompt, Antwort, Zeit und Metadaten direkt aufgezeichnet; das Paket ist digital signiert.

NCL-5— UNABHÄNGIG ÜBERPRÜFTE MEHRQUELLEN-AUFZEICHNUNG

Aufnahmepaket:

• unabhängige Validierung,
• Anbieterexport,
• zweite Evidenzquelle

wurde unterstützt. Haupt-GEO-1000-Echtbenutzerbeobachtungen mindestens:

NCL-3

sollte dieses Niveau anstreben.

32. NOMOS Evidenzpaket ERFASSEN

Für jede Beobachtung enthält das Paket die folgenden Komponenten als Kandidaten:

32.1. Beobachtungsmanifest

Enthält alle Identitäts- und Statusfelder der Beobachtung.

32.2. Prompt-Artefakt

Der vollständige zugewiesene und gesendete Prompt-Text, die Version und dessen Hash.

32.3. Rohantwort-Artefakt

Die vollständige rohe Antwort des KI-Produkts.

32.4. Visuelles Nachweis-Artefakt

Zeigt Bilder oder aufeinanderfolgende Bilder von Prompt, Antwort und Produktoberfläche.

32.5. Systemzustands-Artefakt

Zeigt Plan, Oberfläche, Modellbezeichnung, Speicher, Web und andere materielle Systemzustände.

32.6. Zeitbeweis-Artefakt

Trägt die Einreichungs-, Abschluss-, Erfassungs- und Hochladezeiten.

32.7. Versuchsprotokoll

Zeigt die Kette technischer Fehler und Wiederholungen.

32.8. Integritätsmanifest

Enthält Hashes und Größen aller Dateien.

32.9. Datenschutzmanifest

Zeigt den Status von Schwärzung, Zugriff und Aufbewahrung.

32.10. Validierungsprotokoll

Gibt an, wer und wann die Gültigkeit der Erfassung bewertet wurde.

33. MINIMALE INHALTE DES SCREENSHOTS

Soweit relevant, sollte der visuelle Nachweis Folgendes zeigen:

• KI-Produkt oder Oberflächenidentität
• Völliger Prompt
• Beginn der Antwort
• Ende der Antwort
• Referenzfelder
• Ablehnungs- oder Fehlermeldung
• Offensichtliches Modelllabel
• Nachweis, dass die Sitzung neu oder in einem relevanten Zustand ist
• Materialsystemeinstellung
• Schnittstellenstatus, der anzeigt, dass die Antwort nicht abgeschnitten wurde

34. LANGE ANTWORTEN

Wenn die Antwort nicht auf eine einzelne Bildschirmseite passt:

• Vollseitenscreenshot,
• scrollbarer Screenshot,
• überlappende aufeinanderfolgende Screenshots,
• Bildschirmaufnahme,
• direkter Textexport

können verwendet werden. Aufeinanderfolgende Darstellungen:

• sollten keine Lücken lassen,
• sollten sich überlappen,

sollten fortlaufende Nummerierungen tragen. Nur der positive oder relevante Abschnitt darf nicht beschnitten werden.

35. BILDSCHIRM-AUFNAHME

Bildschirmaufnahme:

• Prompt-Einreichung,
• Streaming-Antwort,
• Fertigstellungsstatus,
• kein Aktualisierungsvorgang durchgeführt

kann angezeigt werden. Allerdings:

• mehr persönliche Informationen,
• Benachrichtigung,
• private Anwendung,
• Konten-ID

können erfasst werden. Daher Bildschirmaufnahme:

• muss möglicherweise nicht standardmäßig erfolgen,
• kann in Hochrisiko- oder Verifizierungs-Teilmustern verwendet werden,

erfordert Datenschutzvorbereitung vor der Aufzeichnung.

36. ROHES ANTWORTTEXT

Zusätzlich zum Screenshot sollte der vollständige Antworttext separat gespeichert werden. Bevorzugte Reihenfolge:

• Offizieller Export oder Kopierfunktion des Produkts
• Direkte Texterfassung durch das Erfassungstool
• Barrierefreiheitsbaum oder DOM-basierte Extraktion
• Vom Nutzer kopierter Text
• OCR und menschliche Überprüfung

OCR sollte nur die letzte Option sein. Wenn ein wesentlicher Unterschied zwischen der automatischen Extraktion und der visuellen Darstellung besteht, ist eine Überprüfung erforderlich.

37. DYNAMISCHE ANTWORTEN

Einige Produkte können nach Abschluss der Antwort:

• eine Quelle hinzufügen,
• eine Quellenkarte laden,
• den Text umformatieren,

eine Sicherheitswarnung hinzufügen. Es können zwei Erfassungsmomente verwendet werden:

• Erste Abschluss-Erfassung
• Erfassung nach kurzer Render-Stabilität

Wenn ein wesentlicher Unterschied besteht, werden beide Versionen beibehalten. Die erste Nutzeranzeige wird nicht gelöscht.

38. WIE MAN VERSTEHT, DASS DIE ANTWORT ABGESCHLOSSEN IST?

Indikatoren für den Abschluss eines Kandidaten:

• Streaming stoppt
• Ladeanzeige schließt
• Schaltfläche "Regenerieren" oder ähnliches erscheint
• Produktsignale der Fertigstellung
• Vordefinierte Ruhezeit
• API-Fertigstellungsaufzeichnung

Produktorientierte Fertigstellungsregeln müssen im KI-Systemregister gefunden werden.

39. WENN DER NUTZER DIE ANTWORT GESTOPPT HAT

Der Nutzer könnte versehentlich oder absichtlich:

• stoppen,
• abbrechen,
• die Anwendung beenden

Durchgeführt haben. Diese Situation wird aufgezeichnet als:

BENUTZER_UNTERBROCHEN

VERSEHENTLICHE_UNTERBRECHUNG

UNBEKANNTE UNTERBRECHUNG

Eine vom Nutzer gestoppte Antwort kann nicht als vollständige Systemausgabe betrachtet werden. Die Regel für Teilnehmerersatz oder Wiederholung muss im Voraus definiert werden.

40. DAS PROMPT UND DIE ANTWORT SIND IN GETRENNTEN DATEIEN

Wenn das Prompt und die Antwort in separaten Bildern vorliegen:

• sie müssen mit derselben Sitzung verknüpft sein,
• mit derselben Beobachtungs-ID,
• und mit einer ununterbrochenen Zeitkette

Andernfalls ist es möglicherweise nicht möglich zu überprüfen, dass die Prompt und die Antwort tatsächlich zu derselben Unterhaltung gehören.

41. DATEI-INTEGRITÄT

Für jede Datei muss ein kryptografischer Hashwert erzeugt werden. [K25] Kandidat:

h_j= H(file_j)

Paket-Hash:

h_bundle= H(JCS(manifest(file_id, Reihenfolge, Größe, Algorithmus, h_j))) [K14; K25]

kann erstellt werden. Hierbei ist H ein veröffentlichter und als sicher geltender Hash-Algorithmus. Der Algorithmus:

• versioniert,
• offen,
• kann in Zukunft bei Bedarf geändert werden.

muss sein.

42. WAS BEWEIST EIN HASH?

Wenn der aufgezeichnete Hash-Wert zuverlässig gespeichert wird, hilft das erneute Hashen derselben Datei mit demselben Algorithmus, Änderungen in der Byte-Sequenz [K25] zu erkennen. Dieser Vergleich unterstützt die Behauptung, dass die Datei nach der Generierung des Referenz-Hash die gleiche Byte-Sequenz beibehalten hat; er beweist jedoch nicht die Quelle der Datei, dass sie zur richtigen Zeit erzeugt wurde oder ihre Authentizität vor dem Hashen. Ein Hash allein beweist nicht:

• Dass die Datei vom echten KI-Produkt stammt
• Dass sie dem richtigen Nutzer gehört
• Dass sie zur richtigen Zeit erzeugt wurde
• Dass sie vor dem Hashen nicht organisiert wurde
• Dass es die erste Ausgabe ist
• Dass der Prompt korrekt war

Daher, Hash:

Es ist ein Nachweis der Integrität.

Allein:

Es ist kein Nachweis der Originalität.

43. DIGITALE SIGNATUR

Erfassungstool oder autorisierter Prüfer:

• das Beobachtungspaket,
• Zeitaufzeichnung,
• Fahrzeugversion

kann digital signieren. Unterschrift:

• welches Fahrzeug oder welche Institution das Paket erzeugt hat,
• dass es nach der Unterschrift nicht verändert wurde

stärkt. Der Unterschrifteninhaber könnte falsche oder gefälschte Daten unterschrieben haben. Daher garantiert die Unterschrift allein nicht die Authentizität.

44. ZUVERLÄSSIGE ZEIT [K26]

Lokale Geräteeinstellung der Uhr:

• falsch konfiguriert,
• manuell geändert,
• außer Synchronisation

kann auftreten. Ein starker Zeitstempel sollte mehrere Signale tragen:

• Aufnahmezeitpunkt der Serverakzeptanz
• Zuverlässiger UTC Zeitdienst
• Gerätezeit und Abweichungsaufzeichnung
• Sichtbare Zeit im KI-Produkt, falls vorhanden
• Dateierstellungszeit
• Digitale Zeitstempel

45. ZEITABWEICHUNG

Die Differenz zwischen der Gerätezeit des Teilnehmers und der zuverlässigen UTC-Zeit:

O_i^clock= t_i^device− t_i^reference

kann aufgezeichnet werden. Wenn eine wesentliche Abweichung besteht:

• dieser Zeit wird die Serverzeit als Hauptreferenz verwendet,
• die Gerätezeit wird als korrigierter Eintrag beibehalten,

Unsicherheit wird markiert. Dem Teilnehmer sollte nicht aufgefordert werden, die Geräteuhr manuell zu ändern.

46. UPLOAD-ZEIT IST NICHT DIE AUFNAHMEZEIT

Das Hochladen einer Datei auf den Server bei 14:00 beweist nicht, dass der Screenshot bei 14:00 erstellt wurde. Daher:

• Aufnahmezeit,
• Hash-Erstellungszeit,
• Upload-Zeit

sollte getrennt aufgezeichnet werden. Lange Upload-Verzögerungen können das Vertrauen in die Erfassung verringern. Der Datensatz muss nicht automatisch ungültig sein.

47. VERZÖGERTER UPLOAD

Aufgrund von Verbindungsproblemen kann es sein, dass der Nutzer die Nachweise nicht sofort hochladen kann. Wenn ein verspäteter Upload akzeptiert wird:

• lokaler Hash zum Zeitpunkt der Erfassung,
• vertrauenswürdige Gerätezeit,
• offline signierter Datensatz,
• Grund für die Upload-Verzögerung

können erforderlich sein. Nur die Aussage des Nutzers: „Ich habe dieses Bild gestern gemacht.“ ist für die Hauptstufe NCL-3 nicht ausreichend.

48. Evidenzkette

Die Evidenzkette einer Beobachtung als Kandidat besteht aus den folgenden Phasen:

• Aufgabenzuweisung
• Festschreibung des Prompts
• Nutzer- und Produkttauglichkeit
• Slot-Öffnung
• Prompt-Einreichung
• Ergebnis des Erstkontakts
• Abschluss der Antwort
• Erfassung
• Lokaler Integritätsdatensatz
• Sicheres Hochladen
• Server-Akzeptanzzeit
• Paket-Hash
• Protokollüberprüfung
• Bearbeitung
• Beurteilung
• Archiv
• Öffentliches Manifest

Jede Phase muss mit der vorherigen Phase verbunden sein.

49. ZERREIßEN DER KETTE

Die Evidenzkette kann in folgenden Situationen unterbrochen werden:

• Kein Aufforderungsprotokoll
• Die anfängliche Ausgabe kann nicht überprüft werden
• Die Antwort stimmt nicht mit der visuellen Darstellung überein
• Erfassungszeit ist unbekannt
• Datei wurde später geändert
• Doppelte Teilnehmer-ID
• Produkt und Plan sind unbekannt
• Die Beobachtung liegt außerhalb der Welle
• Der Hash stimmt nicht mit der Datei überein
• Bearbeitung hat die Rohdatei überschrieben
• Es ist unbekannt, wer es überprüft hat

Die Art der Unterbrechung bestimmt den Gültigkeitsstatus.

50. ROHDATEN KÖNNEN NICHT GEÄNDERT WERDEN; DIE ENTSCHEIDUNG KANN SICH ÄNDERN

Rohdatenpaket:

• soll nicht überschrieben werden,
• soll nicht stillschweigend korrigiert werden,

soll nicht gelöscht und durch ein neues ersetzt werden. Bezüglich der Beobachtung jedoch:

• Gültigkeit,
• tscheidung,
• Klassifikation,
• Compliance

die Entscheidung kann sich ändern. Die neue Entscheidung:

• neue Version,
• Begründung,
• Datum,
• Entscheidungsträger

sollte tragen. Diese Unterscheidung ist eine grundlegende Governance-Regel:

Nachweise können unverändert bleiben; die Interpretation kann sich mit den Nachweisen weiterentwickeln.

51. SCHWARZUNG

Die folgenden Felder können in der öffentlichen oder der Schiedskopie geschwärzt werden:

• Name und Nachname
• E-Mail
• Profilbild
• Konten-ID
• Private Gespräche
• Benachrichtigungen
• Unternehmensfeld
• Sensibler Dateiname
• Exakter Standort

Schwärzung:

• sollte nicht an der Rohdatei durchgeführt werden,
• sollte eine neue abgeleitete Datei erstellen,
• sollte einen eigenen Hash tragen,

sollte aufzeichnen, welches Feld geschwärzt wurde und warum.

52. DREI EBENEN VON NACHWEISEN

52.1. Roh eingeschränktes Evidenzmaterial

Es handelt sich um vollständige Rohdaten als Evidenzmaterial. Nur autorisierte Prüfer und erforderliche Forschungsrollen können darauf zugreifen.

52.2. Audit-Evidenzschicht

Enthält die Nachweise, die für unabhängige Schiedsrichter und Reproduktionsteams notwendig sind. Persönliche Bereiche werden minimiert.

52.3. Öffentliches Evidenzmittel-Manifest

Für die Öffentlichkeit:

• Beobachter-ID,
• Land- und Sprachzelle,
• KI-Produkt,
• Zeit,
• Nachweis-Hash,
• Gültigkeitsstatus,
• Schwärzungsstatus

werden dargestellt. Rohes privates Material wird nicht unbedingt veröffentlicht.

53. ÖFFENTLICHES EVIDENZ-MANIFEST

Für jede Welle kann das öffentliche Manifest die folgenden Felder enthalten:

• Wave-ID
• Protokollversion
• Anzahl der Produkte
• Ziel- und gültige Beobachtungsanzahl
• Abdeckung von Ländern und Sprachen
• Slot-Abdeckung
• Erfassungs-Sicherheitsgrade
• Technische Fehler- und Ablehnungsraten
• Anzahl der ungültigen Beobachtungen
• Hashwerte des Beobachtungspakets
• Wellenintegritäts-Wurzel
• Änderungsereignisse
• Öffentlich redigierte Beispiele
• Unabhängiges Zugriffsverfahren
• Status der Evidenzerhaltung

54. WELLE INTEGRITÄTS-WURZEL

KANDIDATENKONZEPT

Sei der Hash jedes Beobachtungspakets hi. Daraus kann die Wurzel der Welle mit einem Merkle-Baum oder einer gleichwertigen Struktur gebildet werden:

RW

kann erzeugt werden. Die Wellenwurzel kann nach Abschluss der Messung veröffentlicht werden. Diese Methode:

• erhöht die Sichtbarkeit von späteren stillen Änderungen der Beobachtungsliste in der Welle,
• Hinzufügen einer neuen Beobachtung,
• Ändern einer bestehenden Beobachtung

macht sie sichtbarer. Merkle-Wurzel:

• beweist allein nicht, dass die Beobachtungen real sind,
• oder dass die Entscheidung der Schiedsinstanz korrekt ist

Es stärkt die Integrität der Liste.

55. HINZUFÜGEN UND ENTFERNEN VON BEOBACHTUNGEN

Nachdem die Welle geschlossen ist:

• Hinzufügen einer neuen Beobachtung,
• eine bestehende Beobachtung entfernen,
• die Datei ändern

erfordert eine neue Manifestversion. Die alte Integritätswurzel wird beibehalten. Für die zu entfernende Beobachtung:

• Grund,
• Datum,
• Entscheidungsträger
• Auswirkung auf alten und neuen Score

aufgezeichnet.

56. ANTRAG AUF TEILNEHMER-RÜCKZUG

Forschungsethik oder der Datenschutzrahmen können es dem Teilnehmer erlauben, seine Daten zurückzuziehen. In diesem Fall:

• kann Rohdatenmaterial sicher gelöscht oder unzugänglich gemacht werden,
• ein leerer WITHDRAWN-Eintrag kann im öffentlichen Manifest beibehalten werden,
• kann der Welle-Score mit der neuen Version neu berechnet werden,

Das alte Ergebnis und der Grund für die Änderung werden beibehalten. Unveränderlichkeit bedeutet nicht, die Menschenrechte abzuschaffen.

57. GÜLTIGKEITSSTATUSSE DER BEOBACHTUNGSERFASSUNG

CV-0— NICHT ÜBERPRÜFT

Die Erfassung wurde noch nicht bewertet.

CV-1— GÜLTIG

Erfüllt alle obligatorischen Erfassungs- und Zeitbedingungen.

CV-2— BEDINGT GÜLTIG

Es besteht ein begrenzter Mangel. Es wird angegeben, in welchen Analysen es verwendet werden kann.

CV-3— TEILBEWEIS

Die Beobachtung kann als Ereignis verwendet werden. Sie darf nicht in die Hauptpopulationswertung einfließen.

CV-4— AUSSERHALB DER WELLE

Die Prompt wurde außerhalb der erlaubten Zeitstruktur gesendet.

CV-5— ÜBEREINSTIMMUNG VON EINGABE ODER AUSGABE NICHT ERREICHT

Es gibt eine wesentliche Diskrepanz zwischen dem zugewiesenen Prompt, dem eingereichten Prompt oder der aufgezeichneten Antwort.

CV-6— DOPPELT

Die gleiche Beobachtung oder Nutzeraufzeichnung wurde wiederholt.

CV-7— MANIPULATION VERDACHT

Es besteht ein ungelöstes Zweifel an der Integrität der Datei oder der Metadaten.

CV-8— ERFUNDEN ODER MANIPULIERT

Die Beobachtung ist keine echte Nutzererfahrung oder wurde absichtlich verändert.

CV-9— ZURÜCKGEZOGEN

Sie wurde aufgrund von Teilnehmer- oder ethischen Prozessen von der Analyse ausgeschlossen.

58. DIE GÜLTIGKEIT DER AUFZEICHNUNG SOLLTE VON DER SEMANTISCHEN GENAUIGKEIT GETRENNT WERDEN

Eine Beobachtung:

• vollständig gültig in Bezug auf die Aufzeichnung,
• stark falsch in Bezug auf den Inhalt

kann sein. Eine weitere Beobachtung:

• korrekte Antwort,
• kann fehlende oder manipulierte Nachweise enthalten

Daher gibt es zwei getrennte Entscheidungen:

• Erfassungsvalidität
• Semantische Beurteilung

Der Erfassungsvalidator sollte so wenig wie möglich über den Erfolgspunktwert der Antwort wissen.

59. ROLLE DES ERFASSUNGSVALIDATORS

Der Erfassungsvalidator überprüft:

• Prompt-Abgleich
• Erhebungswelle und Zeitfenster
• Produktidentität
• Erste Ausgaberegel
• Bildschirmintegrität
• Rohtext-Konsistenz
• Technisches Wiederholen
• Hash und Zeit
• Datenschutz

Entscheidet sich nicht für: Wurde das Unternehmen korrekt beschrieben? Unterstützt die Zitation die Behauptung? Gibt es einen kritischen Fehler? Geht die Antwort durch? Dies sind die Aufgaben der nächsten Überprüfungsebene.

60. WIEDERHOLTES BILDSCHIRMBILD

Das gleiche Bild:

• versehentlich zweimal hochgeladen,
• von mehreren Nutzern genutzt,
• Wiederholt unter den Panelanbietern

kann passieren. Prüfungen:

• Datei-Hash
• Visuelle Ähnlichkeit
• Rohantworttext
• Zeit- und Sitzungsmetadaten
• Nutzereinzigartigkeit

Das ist möglich. Dasselbe KI-Produkt kann einigen Nutzern exakt dieselbe Antwort Wort für Wort geben. Der gleiche Text allein ist kein Nachweis für Betrug. Die gleiche Datei oder dieselbe visuelle Spur ist ein stärkeres Signal.

61. DATEIÄHNLICHKEIT UND FALSCH-POSITIV

Gleiches Gerät und gleiche Schnittstelle:

• ähnliche Visuals,
• gleiche Bildschirmgröße,
• gleiche Kompression

kann erzeugen. Der Algorithmus zur visuellen Ähnlichkeit sollte keine automatische Ausschlussfunktion ausführen. Mehrere Signale und menschliche Überprüfung sind erforderlich.

62. PROVIDER-TELEMETRIE

KI-Anbieter:

• Sitzungszeit,
• Modell,
• Prompt,
• Antwort,
• Werkzeugnutzung

kann zuverlässige Protokolle dazu bereitstellen. Dieser Eintrag stärkt die unabhängige Erfassung. Allerdings kann der Anbieter:

• gemessene Partei,
• Systembesitzer,
• Begünstigter

sein. Anbieter-Telemetrie: sollte zusammen mit, nicht als Ersatz für, unabhängige Nutzerbeweise verwendet werden.

63. FALLS KEINE ANBIETERBEWEISE VORLIEGEN

Der Zugriff auf Anbieterprotokolle ist in den meisten Live-Consumer-Produkten möglicherweise nicht verfügbar. Dies macht GEO-1000 jedoch nicht unmöglich. Die folgende Zusammensetzung kann verwendet werden:

• Instrumentierte Nutzererfassung
• Server-Zeitstempel
• Nachweis des Vollbilds
• Rohantwort
• Systemeinstellung
• Hash und Signatur
• Unabhängige Verifikations-Subprobe

Der Vertrauensgrad des Nachweises wird entsprechend angegeben.

64. ERFASSUNG IN Panel unter natürlichen Nutzungsbedingungen

Erfassungstool im Naturpanel:

• Inhalt der speziellen Anweisung,
• vorherige Gespräche,
• Kontenidentität

sollte nicht unnötig erfasst werden. Bevorzugter Ablauf: Der Nutzer öffnet einen neuen Natural-Account-Chat. Capture zeichnet nur das Aufgabenfenster auf. Der Personalisierungsstatus wird separat als hochrangige Metadaten erfasst. Private Historie bleibt außerhalb der Erfassung. Öffentliche Kopie wird bearbeitet.

65. NATÜRLICHE KONVERSATION-STATUS-ERFASSUNG

Wenn der aktuelle Gesprächskontext gemessen wird:

• nur der notwendige vorangegangene Gesprächsbereich,
• explizite Zustimmung,
• starke Schwärzung,
• Zugriffsbeschränkung

ist erforderlich. Alle privaten Chat-Historien dürfen standardmäßig nicht gesammelt werden.

66. MOBILE ERFASSUNG

Auf mobilen Geräten:

• Vollbild-Erfassung,
• scrollbarer Screenshot,
• Anwendungsversion,
• Systemzeitprotokoll

kann anders funktionieren. Mobiles Protokoll:

• iOS,
• Android,
• andere Systeme

können separate technische Anleitungen enthalten. Mobile Nutzer können nicht ausgeschlossen werden, da das Erfassen auf Desktop-Geräten schwierig ist. Das Erfassungstool muss sich an die Nutzerpopulation anpassen.

67. ZUGÄNGLICHKEIT UND ERFASSUNG

Für Teilnehmer, die Screenreader, Spracheingabe oder motorische Hilfsmittel verwenden, kann eine standardmäßige visuelle Erfassung allein nicht ausreichen. Alternative Nachweise:

• Export des Barrierefreiheitsbaums
• Aufzeichnung der Sprachsitzung
• Anwendungs-Transkript
• Protokoll der assistiven Technologie
• Aufgabenbeobachtungsprotokoll

können auftreten. Diese Beobachtungen sollten nicht als wenig zuverlässig angesehen werden. Ein gleichwertiger Nachweisstandard sollte entwickelt werden.

68. BEOBACHTUNG DES ERFASSUNGSTOOLS BEI VERÄNDERUNG DES VERHALTENS

Browser-Erweiterung oder Instrumentierung:

• Seitenlade,
• Schnittstellenverhalten,
• Sicherheitssystem,
• Produkterkennung

kann beeinträchtigt werden. Die Auswirkungen des Erfassungswerkzeugs sollten im Piloten getestet werden. Wenn Sitzungen mit und ohne Werkzeug sich unterschiedlich verhalten: wird die Bedingung des Werkzeugs zu einem experimentellen Faktor, das Erfassungswerkzeug kann nicht als stillschweigend neutral angenommen werden.

69. ERFASSUNGSWERKZEUG VERSIONIERUNG

Jedes Erfassungspaket:

• Werkzeugname,
• Version,
• Konfiguration,
• Betriebsumgebung,
• bekannte Fehler

muss enthalten. Wenn sich das Erfassungswerkzeug während der Messung ändert:

• neue Werkzeugversion,
• Subwelle,
• Kompatibilitätsprüfung

kann erforderlich sein.

70. ERFASSUNGSWERKZEUGFEHLER

Werkzeug:

• kann die Prompt möglicherweise falsch kopieren.
• kann das Ende der Antwort abschneiden,
• kann die Zeit falsch aufzeichnen,
• kann keinen Hash erzeugen,

kann die Datei komprimieren. Fehler des Tools:

• kann nicht in das KI-Produkt geladen werden,
• oder der Nutzer

Separat:

CAPTURE_TOOL_FEHLER

muss aufgezeichnet werden als.

71. SYNTHETISCHER DREI-WELLEN-FALL GEO-1000

DEMONSTRATION DER SYNTHETISCHEN METHODOLOGIE / Die folgenden Produkte, Daten, Zahlen und Ergebnisse sind vollständig fiktiv. Zehn synthetische KI-Produkte:

A1–A10

sollen in drei Hauptwellen gemessen werden.

71.1. Wellenkalender

Für jedes Produkt in jeder Welle: 1,000 gültige Hauptbeobachtungen sind angestrebt. Gesamtziel:

10×1,000×3=30,000

71.2. Slot-Struktur

Jede Welle:

• 12 Mikro-Slots
• mit Teilnehmern pro Slot nach Produkt und Land ausgeglichen

Der Slot des Teilnehmers: wird vor der Datenerhebung zufällig zugewiesen.

71.3. W1 Ergebnis

Ziel: 10,000 gültige Hauptbeobachtungen Feld:

• 13,240 Einladungen
• 10,870 abgeschlossene Aufgaben
• 10,106 gültige Beobachtungen in Bezug auf Erfassung
• Hauptanalysebeobachtungen von 10,000 gemäß zuvor festgeschriebener Haupt-/Backup-Reihenfolge

Verbleibende gültige Datensätze von 106:

• Backup,
• Empfindlichkeit,
• Erfassung Qualitätskontrolle

sind reserviert für.

71.4. Technische Ereignisse

118 Nutzungslimit 42 Verbindungsfehler 31 Systemablehnung 17 Nutzertrennung 9 Aufforderungsabweichung 6 Wiederholung Screenshot Alle Ergebnisse des Erstkontakts wurden gespeichert. Nur vordefinierte echte technische Fehler wurden erneut versucht.

71.5. Produktänderung während W2

A7-Produkt bei 20.32 UTC:

• automatische Webnutzung,
• neue Referenzansicht

lass es gewinnen. Beobachtungen von A7:

W2A: 20.00–20.31

W2B: 20.32–21.00

werden wie folgt getrennt. Ein einziger fester W2-Wert für A7 wird ohne Erklärung nicht veröffentlicht.

71.6. Externes Ereignis in W3

Eine wichtige rechtliche Entscheidung sollte am 04.22 UTC über das geprüfte synthetische Unternehmen veröffentlicht werden. Es sollte beobachtet werden, dass sich die Antworten in webbasierten Produkten nach 04.25 geändert haben. Ereignis: Es wird in das Register für externe Ereignisse aufgenommen. Ergebnisse vor und nach dem Ereignis werden als separate diagnostische Zellen gezeigt. Beobachtungen werden nicht gelöscht, da sie den Wert verringern oder erhöhen.

71.7. Wave Health Card

Alle drei Wellen können verwendet werden. A7- und externe Ereignis-Kommentare sind ebenfalls eingeschränkt.

72. SYNTHETISCHER EINZELBEOBACHTUNGSERFASSUNGSFALL

SYNTHETISCHES BEISPIEL

Teilnehmer:

• Türkei
• Türkisch
• Orion AI Web kostenpflichtiger Plan
• Kontrolliertes Panel unter bereinigten Bedingungen

W1

Slot 12.15–12.20 UTC Zugewiesene Aufforderung: „Mit welchem Mutterunternehmen ist Apple.com verbunden und was sind die Haupttätigkeiten dieses Unternehmens?“

72.1. Zeiten

Aufgabeneröffnung: 12.14.20 Eingabebestätigung: 12.16.08 Erstes Token: 12.16.10 Antwortabschluss: 12.16.24 Erfassung: 12.16.39 Hash-Erzeugung: 12.16.41 Hochladen: 12.17.12 Serverannahme: 12.17.13

72.2. Nachweis

Prompt-Hash stimmt überein Vollständiger Antworttext verfügbar Zwei sich überlappende Screenshots verfügbar Produkt-, Plan- und Modellkennzeichnung sichtbar Speicher- und spezielle Anweisungen aus Webnutzung aktiviert Zitation nicht angezeigt Keine Reproduktion Kein vorheriges Gespräch Dateihashes und Paket-Signatur verfügbar Erfassungsebene:

NCL-4

Gültigkeit:

CV-1

Es wurde noch nicht entschieden, ob die Antwort korrekt oder inkorrekt ist.

73. SYNTHETISCHER TECHNISCHER WIEDERHOLUNGSFALL

Beim ersten Versuch:

• Prompt korrekt gesendet
• Produkt zeigte "Netzwerkfehler"
• Sachliche Antwort nicht begonnen
• Fehler-Screenshot gemacht
• Zeit und Hash wurden aufgezeichnet

Gemäß der vordefinierten Regel wurde innerhalb von fünf Minuten ein zweiter Versuch unternommen. Beim zweiten Versuch erfolgte eine Antwort. Korrekte Aufzeichnung:

• Ergebnis des ersten Kontakts: VORÜBERGEHENDER_TECHNISCHER_FEHLER
• Erste gültige Inhaltsausgabe: zweiter Versuch
• Beide Versuche sind im Paket enthalten
• Erster Vorfall ist in der technischen Fehlerquote enthalten
• Die zweite Antwort wird in die Inhaltsbewertung einbezogen, wenn die Methode dies im Voraus vorhersagt.

Falscher Eintrag: Der erste Fehler wird gelöscht und es wird so behandelt, als ob nur die zweite Antwort existierte.

74. SYNTHETISCHES UNRichtiges RETRY-FALL

Erste Antwort: „Apple ist ein lokales Unternehmen, das nur Handys verkauft.“ Dem Teilnehmer gefällt die Antwort nicht. Er gibt sie erneut ein. Die zweite Antwort stellt sich als korrekt heraus. Der Teilnehmer reicht nur die zweite Antwort ein. Das Systemprotokoll oder die Aufzeichnungsdatei zeigt die Wiederholung. Korrekt-Status:

CV-8— MANIPULIERTE BEOBACHTUNG

Die Beobachtung wird nicht gespeichert, nur weil die zweite Antwort korrekt ist. Wenn die erste Antwort zusätzlich wiederhergestellt werden kann, kann sie in der Vorfalluntersuchung bewahrt werden. Der Hauptteilnehmerdatensatz ist ungültig.

75. WELLE ABSCHLUSSBERICHT

Am Ende jeder Welle sollte der folgende Datensatz erstellt werden:

• Wave-ID
• Öffnungs- und Schließzeit
• Zielanzahl der Beobachtungen
• Eingeladene Person
• Abgeschlossene Aufgabe
• Gültige Erfassung
• Beobachtung, die in die Hauptanalyse eingeht
• Backup gültige Beobachtung
• Technischer Fehler
• Ablehnung
• Nutzungslimit
• Prompt-Abweichung
• Erfassungsabweichung
• Verspäteter Upload
• Duplikat
• Vermutete Manipulation
• Teilnehmer-Rückzug
• Produktänderungen
• Externe Ereignisse
• Slot-Abdeckung
• Abdeckung von Ländern und Sprachen
• Erfassungs-Sicherheitsgrade
• Gesundheitsstatus der Welle
• Integritätswurzel
• Verantwortliche menschliche Genehmigung

76. VERPFLICHTENDE NORMATIVE BESTIMMUNGEN

CH12-N01

Jede GEO-1000-Beobachtung muss mit einer vorab festgeschriebenen Messwelle verknüpft sein.

CH12-N02

Der Begriff "gleiche Zeit" kann nicht ohne das vollständige UTC-Fenster, Mikro-Zeitfenster und die Abschlussregeln verwendet werden.

CH12-N03

Ortszeit kann nicht allein als Wellzeit verwendet werden; der Hauptzeitstandard muss UTC sein.

CH12-N04

Das Übertragungsfenster, Mikro-Slots, Fertigstellungszeit und Ladezeit müssen bestimmt werden, bevor KI-Antworten angezeigt werden.

CH12-N05

Die Slot-Zuweisung muss so erfolgen, dass Länder, Sprachen, Produkte und Panelgruppen zeitlich nicht unausgewogen bleiben.

CH12-N06

Teilnehmer dürfen nicht basierend auf ihren Ergebnissen auf frühere oder spätere Slots verschoben werden.

CH12-N07

Der lokale Zeitversatz des einzelnen UTC-Fensters muss im öffentlichen Methodenprotokoll dokumentiert werden.

CH12-N08

Zurückkehrende globale Wellen oder lokal zeitlich ausgeglichene Operationen müssen als separate Zeitresultate geführt werden.

CH12-N09

Jede Beobachtungsaufforderung muss, soweit relevant, Einreichungs-, Erstkontakt-, Abschluss-, Erfassungs- und Upload-Zeiten enthalten.

CH12-N10

Unbekannte Zeitfelder können nicht als geschätzte tatsächliche Zeiten dargestellt werden.

CH12-N11

Die Gerätuhr allein kann nicht als zuverlässiger UTC Zeitnachweis betrachtet werden.

CH12-N12

Erfassungszeit und Hochladezeit müssen getrennt aufgezeichnet werden.

CH12-N13

Beobachtungen, die außerhalb der Welle gesendet wurden, dürfen nicht ohne Erklärung in die Hauptwelle aufgenommen werden.

CH12-N14

Ausschlussregeln für Verzögerung oder Slot-Abweichung müssen unabhängig vom Inhalts der Antwort sein.

CH12-N15

Als Ergebnis des ersten Kontakts muss es getrennt von der ersten Inhaltserstellung aufbewahrt werden.

CH12-N16

Ablehnung, Nutzungslimit, technischer Fehler, Klärung und Unklarheit dürfen nicht in dieselbe Kategorie eingeordnet werden.

CH12-N17

Falsche, negative, referenzlose oder kritische KI-Antwort kann kein Grund für einen erneuten Versuch sein.

CH12-N18

Technischer erneuter Versuch kann nur unter vordefinierten technischen Bedingungen durchgeführt werden.

CH12-N19

Wenn ein technischer erneuter Versuch durchgeführt wird, müssen alle Versuche und das Ergebnis des ersten Kontakts erhalten bleiben.

CH12-N20

Teilweise oder unvollständige Antworten dürfen nicht ignoriert und durch eine neue Antwort ersetzt werden.

CH12-N21

Die erste geeignete Ausgabe kann nicht erneuert, ausgewählt oder manuell verbessert werden.

CH12-N22

Jede Beobachtung muss mindestens auf NCL-3 oder einem gerechtfertigten gleichwertigen Erfassungs-Sicherheitsniveau abzielen.

CH12-N23

Ein Screenshot allein kann nicht als vollständiges Evidenzpaket betrachtet werden.

CH12-N24

Die visuelle Evidenzaufforderung sollte die gesamte Antwort und die Oberfläche des physischen Produkts zeigen.

CH12-N25

Lange Antworten müssen vollständig und in der richtigen Reihenfolge mittels der Erfassungsmethode aufbewahrt werden.

CH12-N26

Wenn es einen materiellen Unterschied zwischen dem Rohtext der Antwort und dem visuellen Nachweis gibt, sollte eine Untersuchung durchgeführt werden.

CH12-N27

OCR kann als Hilfsmethode verwendet werden, wenn eine direkte Texterfassung nicht möglich ist; ohne Verifizierung kann es nicht als endgültige Textquelle betrachtet werden.

CH12-N28

Die anfängliche Fertigstellung und die nachfolgenden materiellen Versionen dynamisch sich ändernder Antworten müssen separat aufbewahrt werden.

CH12-N29

Der Teilnehmer, der die Antwort stoppt oder die Schnittstelle schließt, muss als separates Ereignis protokolliert werden.

CH12-N30

Wenn das Prompt und die Antwort in getrennten Dateien vorliegen, müssen sie mit derselben Sitzung und Zeitschiene verknüpft werden.

CH12-N31

Jede Evidenzdatei und jedes Evidenzpaket muss einen Integritätshash tragen.

CH12-N32

Der Hash allein kann nicht als Beweis für die Realität der Beobachtung vorgelegt werden.

CH12-N33

Digitale Signatur und Zeitstempel sind nicht die Gesamtheit der Authentizität der Beobachtung; sie sind Komponenten der Evidenzkette.

CH12-N34

Keine Schwärzung oder Korrektur darf über die Rohbeweisdatei geschrieben werden.

CH12-N35

Jedes bearbeitete Derivat muss seine eigene Datei-ID und seinen eigenen Hash tragen.

CH12-N36

Der Zugriff auf Rohbeweise kann eingeschränkt sein; das öffentliche Manifest muss die Integrität der Beobachtung nachweisen, ohne Identitäten preiszugeben.

CH12-N37

Der Name des Teilnehmers, die E-Mail, das Passwort, private Gespräche oder unnötige persönliche Informationen dürfen nicht zu den öffentlichen Evidenzmitteln hinzugefügt werden.

CH12-N38

Das Risiko der Re-Identifizierung für kleine Länder und Nutzer seltener Untergruppen sollte ebenfalls bewertet werden.

CH12-N39

Die Panel unter natürlichen Nutzungsbedingungen-Erfassung sollte standardmäßig keine speziellen Anweisungen und Inhalte vergangener Gespräche sammeln.

CH12-N40

Äquivalente alternative Erfassungsmethoden sollten für Nutzer mit Zugänglichkeitsbedürfnissen bereitgestellt werden.

CH12-N41

Wenn das Erfassungstool die Nutzererfahrung wesentlich verändert, sollte diese Auswirkung separat gemessen werden.

CH12-N42

Das Erfassungstool und seine Version sollten in jeder Beobachtung aufgezeichnet werden.

CH12-N43

Wenn das Erfassungstool während einer Erhebungsphase wesentlich verändert wird, sollte eine Unterscheidung für Unterphase oder Tool-Version vorgenommen werden.

CH12-N44

Der Fehler des Erfassungstools kann weder als ein KI-Produkt noch als ein Fehler des Teilnehmers klassifiziert werden.

CH12-N45

Die Telemetrie des Anbieters kann die unabhängige Erfassung von Nutzern unterstützen; sie kann diese nicht ohne Erklärung ersetzen.

CH12-N46

Wenn während der Welle eine wesentliche Änderung eines KI-Produkts auftritt, können Beobachtungen nicht zu einem einzigen festen Produktzustand zusammengeführt werden.

CH12-N47

Produktänderungen erfordern Wellentrennung, Neustart, explizite Modellierung oder eine Warnung vor gemischtem Zustand.

CH12-N48

Das Fehlen einer Anbieter-Update-Ankündigung ist kein endgültiger Beweis dafür, dass sich das System nicht geändert hat.

CH12-N49

Wesentliche externe Ereignisse sollten mit Zeitstempel und Umfang im Register für externe Ereignisse hinzugefügt werden.

CH12-N50

Externe Ereignisse können nach der Veröffentlichung der Ergebnisse nicht als Grund für einen Ausschluss dienen, nur weil sie die Bewertung erhöht oder gesenkt haben.

CH12-N51

Die Gültigkeit der Erfassung sollte so blind wie möglich bewertet werden, bevor die semantische Korrektheit der Antwort beurteilt wird.

CH12-N52

Eine korrekte KI-Antwort kann eine fehlende oder manipulierte Erfassung nicht validieren.

CH12-N53

Eine falsche KI-Antwort kann eine protokollkonforme Erfassung nicht entwerten.

CH12-N54

Duplikat- und Manipulationsentscheidungen sollten mehrere Signale und menschliche Überprüfung beinhalten.

CH12-N55

Der gleiche Antworttext allein kann nicht als Beweis für Duplikation oder Betrug betrachtet werden.

CH12-N56

Das Hinzufügen, Entfernen oder Ändern von Beobachtungen nach dem Abschluss einer Welle erfordert ein neues Manifest und eine neue Analyseversion.

CH12-N57

Das alte Wellenmanifest und die Integritätswurzel müssen erhalten bleiben.

CH12-N58

Rohbeweise können unverändert aufbewahrt werden; Validitäts- und Schiedsentscheidungen dürfen nur in versionierter Form geändert werden.

CH12-N59

Das Recht der Teilnehmer auf Rückzug und die Forschungsethik müssen über dem Anspruch der Unveränderlichkeit stehen.

CH12-N60

Die Integrität der Welle sollte unabhängig vom KI-Score bewertet werden.

CH12-N61

Der Bericht zum Wellenabschluss sollte Ziel, tatsächliche Werte, Ungültigmachungen, technische Ereignisse, Produktänderungen und Evidenzintegrität zeigen.

CH12-N62

NOMOS Die Einhaltung der Erfassung kann nicht ausschließlich an die Verwendung von Software gebunden werden, die von NobleJackal entwickelt wurde; gleichwertige Open-Source-Anwendungen sollten möglich sein.

CH12-N63

Das Erfassungsschema, die Validierungsentscheidungen und Wellenaufzeichnungen sollten in einem maschinenlesbaren Format versioniert werden.

CH12-N64

Jede Welle und Evidenzkette sollte einen verantwortlichen menschlichen oder institutionellen Eigentümer haben.

77. FORMEN DES VERSAGENS

CH12-F01— DER GLEICHE ZWEITE FEHLER

Alle Teilnehmer gleichzeitig senden zu lassen, wird als die einzige Bedingung für Gleichzeitigkeit betrachtet.

CH12-F02— „HEUTE“ ALS SYNCHRONISIERTE WELLE ZU ZÄHLEN

Ortszeit und Zeitzonen werden verwechselt.

CH12-F03— ORTSZEIT WIE UTC VERWENDEN

Beobachtungen werden in die falsche chronologische Reihenfolge gebracht.

CH12-F04— ZUORDNUNG DER ZEITSLOTS BASIEREND AUF ERGEBNISSEN ÄNDERN

Nutzer mit niedriger Punktzahl werden in eine andere Zeitzelle verschoben.

CH12-F05— EIN LAND IN EINEN SLOT PACKEN

Zeiteffekt wird mit Ländereffekt vermischt.

CH12-F06— KÜNSTLICHE LAST ERZEUGEN

Tausende Nutzer senden gleichzeitig, wodurch das abnormale Fehlverhalten des Produkts ausgelöst wird.

CH12-F07— NACHTTEILNAHME VERSTECKEN

Müdigkeit und Teilnahmeverlust werden in bestimmten Bereichen nicht gemeldet.

CH12-F08— HINZUFÜGEN VON OFF-WAVE-BEOBACHTUNG ZUR WELLE

Eine Antwort, die Stunden oder Tage später erhalten wird, wird so verwendet, als gehöre sie zum Hauptfenster.

CH12-F09— LADEZEIT ALS AUFNAHMZEIT ZÄHLEN

Es kann nicht nachgewiesen werden, wann die Datei erzeugt wurde.

CH12-F10— BLINDES VERTRAUEN AUF DIE GERÄTEUHR

Manuell geänderte oder falsche Zeit wird zum Hauptzeitaufzeichnungseintrag.

CH12-F11— AUSSCHLIEßLICH VERZÖGERTES NEGATIVES ANTWORTEN

Die Zeitregel wird abhängig vom Ergebnis angewendet.

CH12-F12— LÖSCHEN DES ERSTEN KONTAKTERGEBNISSES

Die Geschwindigkeitsbegrenzung, der Fehler oder die Ablehnung wird beim zweiten Versuch unsichtbar gemacht.

CH12-F13— ZÄHLUNG VON ABLEHNUNGEN ALS TECHNISCHER FEHLER

Das tatsächliche Systemverhalten wird erneut versucht.

CH12-F14— ZÄHLUNG FALSCHER ANTWORTEN ALS TECHNISCHER FEHLER

Regeneration wird durchgeführt, bis das gewünschte Ergebnis erreicht wird.

CH12-F15— TEILWEISE ANTWORT IGNORIEREN

Selbst wenn das System unterbrochen wird, wird nur die nachfolgende vollständige Antwort gespeichert.

CH12-F16— AUSWAHL DER BESTEN ANTWORT

Unter mehreren Antworten wird die positivste oder längste gemeldet.

CH12-F17— NUR SCREENSHOT

Die Visualisierung wird ohne Prompt, Produkt, Zeit und Metadaten als ausreichend betrachtet.

CH12-F18— ZUGESCHNITTENE ERFOLGSVISUALISIERUNG

Falsche oder einschränkende Teile bleiben unsichtbar.

CH12-F19— AUFNAHME ZEIGT DIE EINGABE NICHT

Es kann nicht nachgewiesen werden, zu welcher Frage die Antwort gehört.

CH12-F20— AM ENDE DER ANTWORT ABBRECHEN

Materialeinschränkung oder abgelehnter Teil wird unsichtbar.

CH12-F21— LÜCKE IN AUFEINANDERFOLGENDEN VISUALS

Einige Teile der Antwort gehen verloren.

CH12-F22— OCR-TEXT ALS ROHE ANTWORT ZÄHLEN

Erkennungsfehler ändern Materialangaben.

CH12-F23— NUR DIE NEUESTE VERSION DER DYNAMISCHEN ANTWORT ALS ECHT BETRACHTEN

Die anfängliche Nutzerdarstellung wird gelöscht.

CH12-F24— NUTZERUNTERBRECHUNG ALS VOLLSTÄNDIGE ANTWORT BETRACHTEN

Die Systemausgabe ist aufgrund einer Nutzerintervention unvollständig.

CH12-F25— SEPARATE EINGABE UND ANTWORT FALSCH ZUORDNEN

Dateien aus verschiedenen Chats werden derselben Beobachtung zugeordnet.

CH12-F26— HASH-VEREHRUNG

Jede Datei mit einem Hash wird als echt und original angesehen.

CH12-F27— PRE-HASH-BEARBEITUNG IGNORIEREN

Gekürzte oder bearbeitete Dateien werden durch Hashing legitimiert.

CH12-F28— DIE SIGNATUR ALS GÜLTIG BETRACHTEN

Signierter, aber falscher Datensatz wird ohne Streit akzeptiert.

CH12-F29— BEARBEITUNG DER ROHDATENDATEI

Originalbeweise werden unwiderruflich verändert.

CH12-F30— DAS BEARBEITETE DERIVAT ALS ROHBEWEIS BETRACHTEN

Die öffentliche Kopie wird wie die Originaldatei verwendet.

CH12-F31— PRIVATSPHÄRE FÜR NACHWEISE ENTFERNEN

Name, Konto und privater Chat des Teilnehmers werden veröffentlicht.

CH12-F32— EINEN TEILNEHMER AUS EINEM KLEINEN LAND AUFDECKEN

Zeit-, Geräte- und Planinformationen machen eine Person rückidentifizierbar.

CH12-F33— SPEZIELLE GESCHICHTE IM NATÜRLICHEN PANEL SAMMELN

Irrelevante Gespräche werden in die Aufnahme aufgenommen.

CH12-F34— NACHWEISE ZUR BARIERREFREIHEIT UNGÜLTIG MACHEN

Der echte Nutzer wird ausgeschlossen, weil kein Standard-Visuell erzeugt werden kann.

CH12-F35— ANNEHMEN, DASS DAS AUFZEICHNUNGSWERKZEUG NEUTRAL IST

Das Werkzeug verändert das Produktverhalten, wird aber nicht getestet.

CH12-F36— VERSTECKEN DER ERFASSUNGSVERSION

Verschiedene Werkzeugversionen werden als eine einzelne Messmethode dargestellt.

CH12-F37— BETRACHTUNG DES ERFASSUNGSWERKZEUGFEHLERS ALS KI-FEHLER

Die zugeschnittene Antwort wird auf das Produkt hochgeladen.

CH12-F38— ZÄHLEN DES API-LOGS AUF DEM NUTZERBILDschirm

Die reale Nutzeroberfläche wird unsichtbar.

CH12-F39— ZÄHLEN DES PROVIDER-LOGS ALS UNABHÄNGIGES EVIDENZMATERIAL

Die Aufzeichnung der gemessenen Partei wird zu einem einzigen Evidenzstück.

CH12-F40— VERSTECKEN DES PRODUKTUPDATES

Zustände zweier Systeme innerhalb der Verzweigung verschmelzen zu einer einzigen Bewertung.

CH12-F41— IGNORIEREN VON ÄNDERUNGEN, WENN KEINE ANKÜNDIGUNG

Der beobachtete Systemabbruch wird nicht untersucht.

CH12-F42— AUSSCHLUSS EXTERNER EREIGNISSE BASIEREND AUF DEM ERGEBNIS

Antworten mit negativen Nachrichten werden entfernt; Antworten mit positiven Nachrichten werden beibehalten.

CH12-F43— VERKNÜPFUNG DER WELLENGESUNDHEIT MIT DEM SCORE

Fehlerhafte Wellen mit hohen Werten sind gültig, starke Wellen mit niedrigen Werten gelten als verdächtig.

CH12-F44— ZÄHLEN DER RICHTIGEN ANTWORT ALS GÜLTIGE AUFNAHME

Der Evidenzfehler wird durch semantischen Erfolg vertuscht.

CH12-F45— ZÄHLEN DER FALSCHEN ANTWORT ALS UNGÜLTIGE AUFNAHME

Das Messergebnis wird in einen Datenfehler umgewandelt.

CH12-F46— ZÄHLEN DES GLEICHEN TEXTES ALS BOT-NACHWEIS

Deterministische oder ähnliche KI-Antworten werden versehentlich zu Duplikaten.

CH12-F47— EINZELNE SIGNALMANIPULATION ENTSCHEIDUNG

Dateigröße oder Zeitunterschied erzeugen automatisch einen Ausschluss.

CH12-F48— BEOBACHTUNG NACH WELLE HINZUFÜGEN

Neue Datensätze werden stillschweigend hinzugefügt, um die gewünschte Stichprobengröße zu erreichen.

CH12-F49— NIEDRIG BEWERTETE BEOBACHTUNG NACH DER WELLE ENTFERNEN

Manifest und Ergebnis werden nachträglich geändert.

CH12-F50— ALTES MANIFEST LÖSCHEN

Versionshistorie wird zerstört.

CH12-F51— ROHDATEN KORRIGIEREN

Dateiinhalte werden geändert, um Fehlklassifizierungen zu korrigieren.

CH12-F52— WIDERSPRUCHSRECHT VERWEIGERN

Unveränderlichkeit wird über Menschenrechte gestellt.

CH12-F53— GESCHLOSSENES EIGENTÜMERISCHES ERFASSUNGSMONOPOLE

Nur mit dem Tool des Gründers erzeugte Nachweise werden als gültig betrachtet.

CH12-F54— DAS ERFASSUNGSSCHEMA NICHT VERÖFFENTLICHEN

Ein unabhängiges Team kann nicht dieselbe Evidenzkette herstellen.

CH12-F55— DIE WELLENWURZEL ALS NACHWEIS DER REALITÄT BETRACHTEN

Die Merkle- oder Hash-Wurzel wird dargestellt, als würde sie die Inhaltsgenauigkeit beweisen.

CH12-F56— ANSPRACHE AUF „1,000 SCREENSHOTS“ OHNE EINE Evidenzpaket

Die Anzahl der Dateien wird wie die Anzahl gültiger Beobachtungen verwendet.

78. PRÜFUNGSVERFAHREN

Schritt 1— Bestimmen des Forschungszwecks der Welle

Haupt-, bestätigend, Vorfall-, Drift- oder Retest-Typ wird ausgewählt.

Schritt 2— KI-Produkt- und Systemzustände festschreiben

Es verbindet sich mit der Wellenversion des KI-Systemregisters in Abschnitt 9.

Schritt 3— Population-, Stichproben- und Panelzustände festschreiben

Aufzeichnungen aus den Abschnitten 5–8 und Abschnitt 11 werden verwendet.

Schritt 4— Prompt-Register festschreiben

Die Prompt-Versionen in Abschnitt 10 sind mit der Erhebungswelle verknüpft.

Schritt 5— UTC Wellenfenster einstellen

Start-, Schluss- und zusätzliche Zeitdauern werden geschrieben.

Schritt 6— Mikroslots erstellen

Teilnehmer werden ausgewogen in Bezug auf Produkt, Land und Sprache Slots zugewiesen.

Schritt 7— Zeitquelle definieren

Server, Gerät und vertrauenswürdige UTC Aufzeichnungen werden bestimmt.

Schritt 8— Erste Kontakt- und Wiederholungsregeln festschreiben

Technische und semantische Zustände werden getrennt.

Schritt 9— Aufnahmemethoden bestimmen

Web-, Mobil-, Barrierefreiheits- und natürliche Panel-Pfade werden definiert.

Schritt 10— NCL-Ziel bestimmen

Der für die Hauptanalyse erforderliche Aufnahme-Confidence-Level wird aufgezeichnet.

Schritt 11— Evidenzpaket-Schema festschreiben

Manifest, Dateien, Hash und Metadatenfelder sind definiert.

Schritt 12— Datenschutz- und Schwärzungsregeln festschreiben

Roh-, Prüfungs- und öffentliche Ebenen sind getrennt.

Schritt 13— Erfassen Sie Ihr Fahrzeug mit dem Piloten

Ändert das Fahrzeug das Produktverhalten? Sind Zeit- und Textaufzeichnungen korrekt?

Schritt 14— Externes Ereignisregister öffnen

Ein Prozess zur Überwachung von Produkt- und Entitätsereignissen ist eingerichtet.

Schritt 15— Wave Lock bestätigen

Der Status WS-1 — FESTGESCHRIEBEN wird vergeben.

Schritt 16— Slots öffnen

Teilnehmer dürfen nur in ihren eigenen Slots einreichen.

Schritt 17— Erstkontakt-Ergebnis aufzeichnen

Antwort, Ablehnung, Fehler oder Limit ist getrennt.

Schritt 18— Erfassen der ersten geeigneten Ausgabe

Die vollständige Antwort wird ohne Erneuerung aufbewahrt.

Schritt 19— Erstellen von Rohbeweisen und Metadaten

Screenshots, Rohtexte, Systemstatus und Zeitstempel werden aufgezeichnet.

Schritt 20— Lokalen Hash ausführen und sicher hochladen

Dateien erhalten vor dem Hochladen einen Integritätsdatensatz.

Schritt 21— Serverakzeptanz und Erstellen eines Paket-Hashes

Die Evidenzkette wird mit Serverzeit und Paket-ID geschlossen.

Schritt 22— Blindprüfung der Gültigkeit der Erfassung

Der CV-Status wird vergeben, ohne den semantischen Erfolg zu kennen.

Schritt 23— Duplikat- und Manipulationsüberprüfung durchführen

Mehrere Signale und menschliche Überprüfung werden verwendet.

Schritt 24— Untersuchung des Systems innerhalb der Welle und externer Ereignisse

Bestimmen Sie, ob ein Teil-Welle- oder Mischzustand erforderlich ist.

Schritt 25— Wellen-Gesundheit zuweisen

Der Status wird zwischen WH-0 und WH-5 zugewiesen.

Schritt 26— Wellenmanifest und Integritätsstamm erstellen

Die Beobachtungsliste wird versioniert.

Schritt 27— Öffentliches Nachweis-Manifest veröffentlichen

Umfang und Integrität werden ohne persönliche Daten sichtbar gemacht.

Schritt 28— Wellenabschlussbericht genehmigen

Ziele, Vorkommnisse, Mängel, Ereignisse und Änderungen werden mit menschlicher Zustimmung abgeschlossen.

79. NOTWENDIGE NACHWEISE

Wellen-ID Wellentyp Protokollversion KI-System Registrierungsversion Populationsrahmen Probe-Sperre Panel-Status-Sperre Prompt Registrierungs-Version Referenzpaketversion UTC Start- und Endzeit Mikro-Zeitfenster-Liste Teilnehmer–Slot-Zuordnung Zeitquelle Geräteuhrabweichungen Übertragungszeiten Erste-Kontakt-Zeiten Abschlusszeiten Erfassungszeiten Hash-Zeiten Upload-Zeiten Server-Akzeptanzzeiten Erste-Kontakt-Ergebnisse Erste passende Inhaltsausgaben Technische Wiederholungsaufzeichnungen Teilantwortaufzeichnungen Ablehnungen und Nutzungsgrenzen Volle Rohantworten Volle Screenshots Sequenzielle visuelle Manifeste Bildschirmaufzeichnungen falls vorhanden Zitations- und Quellenaufzeichnungen Systemeinstellungen Nachweis Erfassungstool und Version Erfassungsmethode NCL-Stufe Dateihashes Paket-Hash

Digitale Signatur Zeitstempel Duplikatsprüfungen Manipulationsprüfungen Erfassungs-Gültigkeitsentscheidungen Schwärzungsdateien Roh-zu-geschwärzten Links Datenschutzmanifest Rücknahmeaufzeichnungen Produktänderungsereignisse Externes Ereignisregister Wellenunterteilungen Slotbereich Länder- und Sprachbereich Technische Fehlerraten Erfassungs-Gültigkeitsrate Wellen-Status Wellenintegritätswurzel Öffentliches Evidenzmanifest Wellenabschlussbericht Änderungsprotokoll Verantwortliche Person oder Institution

80. PRÜFLISTE FÜR AUDITS

Ist der Typ und Zweck der Welle klar? Wurden KI-Produkte und Systemstatus festgeschrieben? Sind die Bevölkerung, Stichprobe und Panel-Versionen bestimmt? Wurde der Prompt-Satz vor den Ergebnissen festgeschrieben? Ist das Wellenfenster UTC geöffnet? Wurden Mikro-Slots vorab zugewiesen? Wurden Länder und Sprachen gleichmäßig auf Slots verteilt? Haben Teilnehmer die Slots basierend auf ihren Ergebnissen gewechselt? Wurde die lokale Zeitbelastung bewertet? Gibt es rotierende Wellenstunden? Sind die zusätzlichen Zeiten für Einreichung und Abschluss klar? Wurde die Geräteuhr mit einer zuverlässigen UTC-Quelle verglichen? Wurden Einreichungs-, Abschluss-, Erfassungs- und Hochladezeiten getrennt? Wurden Beobachtungen außerhalb der Welle in die Hauptbewertung einbezogen? Wurde das Ergebnis des ersten Kontakts aufgezeichnet? Wurde ein technischer Fehler von einer Ablehnung unterschieden?

Wurde aufgrund einer falschen Antwort ein erneuter Versuch unternommen? Wurde der erste Versuch im technischen Retry beibehalten? Wurden Teilergebnisse gelöscht? Ist die erste geeignete Ausgabe wirklich die erste Ausgabe? Wurde „Regenerate“ oder eine Folge-/Nachricht verwendet? Wird die visuelle Prompt und die gesamte Antwort angezeigt? Gibt es bei langen Antworten eine Erfassung ohne Leerzeichen? Entspricht der Rohtext der visuellen Darstellung? Falls OCR verwendet wurde, gab es eine menschliche Überprüfung? Wurden dynamische Antwortversionen beibehalten? Hat der Nutzer die Antwort gestoppt? Sind die Prompt und die Antwort mit derselben Sitzung verknüpft? Wurde das Erfassungstool und die Version protokolliert? Hat das Erfassungstool das Nutzerverhalten verändert? Wurde der NCL-Level angegeben? Gibt es Beobachtungen unterhalb von NCL-3 in der Hauptanalyse? Hat jede Datei einen Hash? Ist klar, was der Hash nicht beweist?

Gibt es eine digitale Signatur oder Serverzeit? Ist die Aufnahmezeit von der Upload-Zeit getrennt? Gibt es einen Grund für den späten Upload und ein lokales Integritätsprotokoll? Wurde die Bearbeitung an den Rohbeweisen durchgeführt? Haben die bearbeiteten Derivate separate Hashes? Enthüllt das öffentliche Manifest die Identität des Teilnehmers? Kann ein Nutzer aus einem kleinen Land wieder identifiziert werden? Wurden private Gespräche unnötigerweise im natürlichen Panel erfasst? Wurde ein alternativer Evidenzweg für Nutzer mit Zugriffshilfen bereitgestellt? Wurde die Duplikatentscheidung nur auf demselben Text basierend getroffen? Trägt die Manipulationsentscheidung mehrere Signale? Kennt der Erfassungsvalidierer die semantische Punktzahl? Deckt die richtige Antwort den Evidenzfehler ab? Wurde die falsche Antwort für ungültig erklärt? Hat sich das Produkt während der Welle geändert?

Wurde die Produktänderung als Unterwelle oder Mischzustand verarbeitet? Wurden externe Ereignisse aufgezeichnet? Haben externe Ereignisse laut Ergebnis zu einer Ausschlusswertung geführt? Ist der Wellengesundheitsstatus unabhängig von der Bewertung? Wurden nach dem Schließen der Welle Beobachtungen hinzugefügt oder entfernt? Werden das alte Manifest und die Integritätswurzel aufbewahrt? Wie wurden Teilnehmer-Rücktrittsanfragen behandelt? Gibt es ein öffentliches Beweismanifest? Gibt es einen eindeutig verantwortlichen Eigentümer des Wellenabschlussberichts?

81. EINWÄNDE UND ANTWORTEN

Einwand 1— „Wenn nicht alle Nutzer genau im selben Moment ihre Eingaben machen, wird keine echte Gleichzeitigkeit erreicht.“

Eine Ein-Sekunden-Übermittlung kann künstliche Last-, Verbindungs- und Warteschlangeneffekte erzeugen. Ein vordefiniertes kurzes UTC-Fenster und zufällige Mikro-Slots können denselben Systemzeitraum zuverlässiger messen.

Einwand 2— "Das Produkt kann sich innerhalb eines Ein-Stunden-Zeitrahmens ändern."

Es kann sich ändern. Daher sind Systemaufzeichnungen, Konfigurations-Fingerabdruck und Produktänderungsverfolgung erforderlich. Im Falle einer wesentlichen Änderung wird die Welle getrennt.

Einwand 3— "Warum reicht nicht einfach ein Screenshot?"

Screenshot:

• Zeit,
• anfängliche Ausgabe,
• Prompt-Version,
• Systemeinstellung,
• Kopieren

Diese Themen nicht immer anzeigen. Ein vollständiges Evidenzpaket ist erforderlich.

Einwand 4— „Ist es nicht zu aufwendig, tausend Screenshots einzeln zu überprüfen?“

Es ist aufwendig. Automatische Integritätsprüfungen, stichprobenartige menschliche Überprüfungen und risikobasierte Verifikationen können verwendet werden. Kritische oder verdächtige Aufzeichnungen werden genauer untersucht.

Einwand 5— „Wenn es einen Hash gibt, warum können wir dann nicht sagen, dass die Datei echt ist?“

Ein Hash zeigt nur, dass die Datei nach der Erstellung des Hashes unverändert geblieben ist. Er zeigt nicht, wie die Datei vor der Erstellung des Hashes entstanden ist.

Einwand 6— „Wenn der Nutzer persönliche Informationen kürzen muss, wie wird dann die Rohdatei geschützt?“

Wenn möglich, sollte das Capture-Tool von Anfang an keine persönlichen Informationen erfassen. Falls unvermeidbar, wird die Rohdatei in einem eingeschränkten und verschlüsselten Repository aufbewahrt, und eine öffentliche Kopie wird als separat redigierte Version bereitgehalten.

Einwand 7— „Wenn die Antwort falsch ist, warum versuchen wir es dann nicht noch einmal?“

Weil eine falsche Antwort eine Frage der Messung ist. Ein erneuter Versuch ist nur bei einem tatsächlichen technischen Fehler vorgesehen.

Einwand 8— „Wenn das System ablehnt, kann der Nutzer tatsächlich noch einmal versuchen?“

Richtig. Das Haupt-First-Contact-Panel speichert die Ablehnung. Ein separat vorhandener Natural Interaction Track kann das Nachverhalten des Nutzers messen.

Einwand 9— „Wenn ein technischer Fehler ein Problem der Nutzererfahrung ist, warum erlauben wir dann einen erneuten Versuch?“

Der technische Fehler wird als Ergebnis des ersten Kontakts beibehalten. Ein vordefinierter technischer Wiederholungsversuch kann durchgeführt werden, um zusätzlich den repräsentativen Inhalt zu untersuchen. Die beiden Ergebnisse ersetzen einander nicht.

Einwand 10— „Ist nicht das eigene Protokoll des Anbieters der stärkste Nachweis?“

Technisch kann es sehr stark sein. Der Anbieter ist der Eigentümer des gemessenen Systems. Es ist zuverlässiger, wenn es zusammen mit einer unabhängigen Nutzeraufnahme verwendet wird.

Einwand 11— „Wird NOMOS Capture eine verpflichtende NobleJackal-Software sein?“

Nr. NOMOS Capture ist ein offenes Evidenzprotokoll. Unabhängige Werkzeuge, die die äquivalenten Schema- und Integritätsbedingungen erfüllen, können kompatibel sein.

Einwand 12— „Wenn wir nicht alle Nachweise öffentlich machen, wie wird dann eine unabhängige Überprüfung durchgeführt?“

Das öffentliche Manifest zeigt Integrität und Umfang. Autorisierte unabhängige Prüfer können auf geschwärzte oder eingeschränkte Rohbeweise zugreifen. Datenschutz und Überprüfung können zusammen gestaltet werden.

Einwand 13— „Würde nicht die gesamte Arbeit gestört, wenn wichtige Nachrichten während der Welle auftauchen?“

Nicht immer. Der Bericht ist Teil der realen Systemumgebung. Er kann mit einem Zeitstempel vor und nach dem Ereignis getrennt werden. Der Umfang der Bewertung wird entsprechend erklärt.

Einwand 14— „Ist es nicht einfacher, alte Antworten zu verwerfen und mit dem neuen System fortzufahren, wenn ein Produkt aktualisiert wird?“

Alte Antworten sind am Messdatum real. Sie können nicht gelöscht werden. Alte und neue Systemstatus müssen als separate Wellen oder Unterwellen beibehalten werden.

Einwand 15— „Wenn das Erfassungstool das Produktverhalten beeinflusst, schlägt die ganze Methode fehl?“

Nein. Der Fahrzeugeffekt wird mit dem Piloten gemessen. Falls notwendig, wird ein leichteres Fahrzeug, manuelle Erfassung oder eine Methode gewählt, die den Fahrzeugeffekt als separaten Faktor verwendet.

Einwand 16— „Wenn der Teilnehmer seine Daten zurückzieht, wäre dann die Integritätswurzel nicht gefährdet?“

Eine neue Manifestversion und eine neue Wurzel werden erstellt. Der alte Eintrag kann eine inhaltslose ZURÜCKGEZOGENE Spur behalten. Er wird auf der Architektur für Nachweise der Menschenrechte aufrechterhalten.

ALLGEMEINES URTEIL DES ABSCHNITTS 85

Am Ende einer GEO-1000-Studie könnten Sie 30,000 Screenshots haben. Diese Zahl allein ist kein Nachweis. Sie müssen Folgendes wissen: In welcher Welle wurden sie erstellt? Zu welchem Systemzustand gehörten sie? Wurde tatsächlich derselbe Prompt gesendet? War es die erste Ausgabe? Wurde die Antwort aktualisiert? Hat sich das Produkt während der Welle verändert? Wann wurde die Datei erfasst? Wann wurde der Hash erstellt? Wurde die Teilnehmer-ID wiederholt? Zeigt die Visualisierung die gesamte Antwort? Entspricht der rohe Text der Visualisierung? Wenn die Nachweise später bearbeitet wurden, wo ist das Original? Wurde die Erfassungsprüfung vor der semantischen Bewertung durchgeführt? Sie können innerhalb derselben Sekunde tausendmal klicken. Trotzdem:

• geräteinterne Uhren,
• Verbindungen,
• Warteschlangen,
• Produktzustände

Es kann unterschiedlich sein. Daher ist Gleichzeitigkeit keine Marketingshow. Es ist eine vordefinierte Zeitarchitektur. Wenn ein Nutzer eine falsche Antwort erhält: 'Versuchen Sie es noch einmal.' zu sagen, ist verlockend. Aber diese falsche Antwort ist die Realität, die Sie zu messen versuchen. Wenn Sie sie löschen, beheben Sie das System nicht. Sie verfälschen die Nachweise. Wenn ein Nutzer einen echten Verbindungsfehler erlebt, kann ein technischer Wiederholungsversuch durchgeführt werden. Aber das Ergebnis des ersten Kontakts sollte dennoch erhalten bleiben. Denn der Nutzer ist zuerst auf den Fehler gestoßen. Der Hash ist wertvoll. Die digitale Signatur ist wertvoll. Der Zeitstempel ist wertvoll. Der Screenshot ist wertvoll. Keines davon allein enthält die ganze Wahrheit. Vertrauen:

• Prompt,
• Zeit,
• Produkt,
• Nutzer,
• Datei,
• Initiative,
• Verifizierung

Es entsteht aus der gemeinsamen Erhaltung seiner Kette. Ein Standard: Wenn es heißt: „Nur Nachweise, die mit meiner Software erstellt wurden, sind gültig“, stellt es das eigene Interesse über die unabhängige Reproduzierbarkeit. Aus diesem Grund ist NOMOS Capture keine Werkzeugmarke, sondern eine offene Beweisarchitektur. Unabhängige Universitäten, Forscher oder Prüfinstitutionen sollten in der Lage sein, dieselben Regeln anzuwenden. Daher lautet das zwölfte Messgesetz von NOMOS wie folgt:

Nebenläufigkeit ist beobachtbare Reproduzierbarkeit innerhalb desselben definierten Systemzeitpunkts, nicht derselben Sekunde.

Das dreizehnte Gesetz lautet wie folgt:

Die erste Ausgabe ist kein Entwurf, der erneuert werden kann, bis einem das Ergebnis gefällt.

Das vierzehnte Gesetz lautet wie folgt:

Hash bewahrt den Beweis; er erstellt keinen Beweis.

Das fünfzehnte Gesetz lautet wie folgt:

Erfassungsvalidität und Reaktionsgenauigkeit sind unabhängig voneinander.

Sechzehntes Gesetz lautet wie folgt:

Die Evidenzkette sollte die Integrität der Beobachtung sichtbar machen, nicht die Identität der Person.

Sein siebzehntes Gesetz lautet:

Wenn sich das System während der Welle verändert, kann es nicht so tun, als hätte sich die Messhistorie nicht verändert.

Sein achtzehntes Messgesetz besagt:

Auf Rohbeweise wird nichts geschrieben; Entscheidungen werden durch Versionierung korrigiert.

Sein neunzehntes Messgesetz besagt:

Eine Erfassungsmethode, die nicht unabhängig angewendet werden kann, kann kein Weltstandard sein.

Bestellung von Abschnitt 12 von NOMOS

Sag mir nicht „wir haben zur gleichen Zeit gefragt.“ / Zeige, in welchem UTC-Fenster, in welchem Slot und in welchem Systemzustand du gefragt hast.

Stapele nicht tausend Personen in dieselbe Sekunde, um einen künstlichen Fehler zu erzeugen. / Verteile die Zeit, aber halte das System in derselben Welle.

Mische keine Ortszeiten miteinander. / Mache die Gerätesteuerung nicht zur absoluten Wahrheit.

Speichere nicht das Ergebnis des ersten Kontakts. / Speichere das Nutzungslimit, Wiederholungen, Fehler und Klärungen separat.

Regeneriere nicht, wenn du eine falsche Antwort bekommst. / Diese falsche Antwort ist mein tatsächliches Verhalten.

Du kannst es erneut versuchen, wenn ein technischer Fehler auftritt. / Lösche aber nicht den ersten Fehler.

Bringen Sie mir nicht nur einen Screenshot. / Bringen Sie den Prompt, die vollständige Antwort, das Produkt, die Zeit, die Einstellung, die Interferenzkette und die Datei-Integrität.

Schneiden Sie den guten Teil Ihrer Antwort nicht ab. / Lassen Sie das Ende, die Grenze und den Fehler sichtbar.

Erklären Sie den Hash nicht als Realität. / Beweisen Sie auch, was vor dem Hash war.

Schwärzen Sie die Rohdatei selbst nicht. / Bewahren Sie das Original und erstellen Sie eine separate öffentliche Kopie.

Veröffentlichen Sie keinen Namen einer Person, kein Konto oder private Unterhaltung als Nachweis.

Machen Sie den einzigen Teilnehmer in einem kleinen Land nicht identifizierbar.

Erklären Sie Ihr Erfassungstool nicht als neutral, ohne zu testen, ob es mich verändert hat.

Wenn sich das System in der Mitte der Welle geändert hat, dürfen alte und neue Antworten nicht zusammengeführt werden, als gehörten sie zu einem einzigen Produkt.

Wenn ein externes Ereignis die Änderung verursacht hat, zeichnen Sie das Ereignis auf. / Löschen Sie die Beobachtung nicht, nur weil Ihnen die Bewertung nicht gefällt.

Halten Sie das Evidenzmaterial unverändert. / Wenn die Entscheidung falsch ist, korrigieren Sie sie mit einer neuen Version.

Binden Sie den Erfassungsstandard nicht an die geschlossene Software eines einzelnen Unternehmens. / Lassen Sie andere in der Lage sein, dieselbe Evidenzkette herzustellen.

Zuerst die Welle festschreiben. / Dann die Zeit verteilen. / Dann den ersten Output erfassen. / Dann hashen. / Dann sicher hochladen. / Dann die Erfassung überprüfen, ohne die Genauigkeit zu prüfen. / Und erst danach entscheiden, was Ihre Antwort aussagt.

Der abschließende Satz des Kapitels

Eine Antwort in GEO-1000 wird erst dann zu einer echten Maßeinheit, wenn gezeigt werden kann, unter welchem Systemzustand, zu welchem Zeitpunkt, von welchem Prompt und innerhalb welcher unveränderlichen Evidenzkette sie entstanden ist.

Normativer Kern

Jede GEO-1000-Beobachtung MUSS mit einer vorher deklarieren und versionierten Messwelle verknüpft sein, die Folgendes definiert: - KI-Produktzustände, - Populationen und Stichprobenrahmen, - Panelzustände, - Prompt-Versionen, - UTC-Übertragungsfenster, - randomisierte Mikro-Slots, - Abschluss- und Erfassungsfristen, - technische Wiederholungsregeln, - Erfassungsschema, - Referenzdatensatzversionen und - Governance-Zuordnung. Synchronisation MUSS Beobachtung innerhalb eines deklarierten UTC-Systemzustandsfensters und zugewiesener Slot-Struktur bedeuten. Sie DARF NICHT als perfekte Millisekunden-Simultanität repräsentiert werden. Jede Beobachtung MUSS folgende Angaben so weit wie möglich beibehalten: - Zuweisungszeit, - Prompt-Einreichungszeit, - erstes Systemereignis, - Abschlusszeit der Antwort, - Erfassungszeit, - Hash-Erstellungszeit, - Upload-Zeit, - und Server-Akzeptanzzeit. Das Ergebnis des ersten Kontakts MUSS sichtbar bleiben. Ein technischer Wiederholungsversuch DARF nur unter zuvor angekündigten Infrastruktur-Ausfallbedingungen verwendet werden und MUSS jeden vorherigen Versuch beibehalten. Falsche, ungünstige, abgelehnte, nicht zitierte, gekürzte oder kritische Ausgaben DARF NICHT einfach aufgrund ihres Inhalts erneut erzeugt, ersetzt oder ausgeschlossen werden. Ein NOMOS Evidenzbündel MUSS das exakt zugewiesene und gesendete Prompt, die vollständige Rohantwort, alle visuellen Nachweise, Systemzustands-Metadaten, Versuchprotokolle, Zeitevidenz, Datei-Hashes, Bündel-Hash, Version des Erfassungswerkzeugs, Datenschutzstatus und eine anonymisierte Erfassungs-Gültigkeitsentscheidung beibehalten. Ein Screenshot, Hash, digitale Signatur, Anbieterprotokoll oder Zeitstempel DARF NICHT einzeln als vollständiger Nachweis der Authentizität der Beobachtung repräsentiert werden. Rohbeweise MÜSSEN unveränderlich oder nur anhängbar bleiben. Schwärzungen, Korrekturen, Rücknahmen, Ausschlüsse und Änderungen durch die Entscheidung MÜSSEN verknüpfte Versionen erzeugen und den vorherigen Datensatz dort bewahren, wo dies ethisch und rechtlich zulässig ist. Materielle KI-Produktänderungen oder externe Ereignisse während einer Welle MÜSSEN zeitlich erfasst und durch Unterwellen, explizite Modellierung, Neustart oder Mischzustandswarnungen behandelt werden. Die Gültigkeit der Erfassung MUSS unabhängig von der semantischen Korrektheit entschieden werden. Öffentliche Nachweis-Manifeste MÜSSEN die Überprüfung unterstützen, ohne unnötig die Identität von Teilnehmern, Zugangsdaten, private Gesprächshistorie oder den genauen Standort offenzulegen. NOMOS Die Einhaltung der Erfassung MUSS durch offene, gleichwertige Evidenzsysteme umsetzbar sein und DARF NICHT ausschließlich von einem proprietären Tool abhängen, das von dem Gründer des Standards kontrolliert wird. Jede Welle, jedes Evidenzpaket, jede Erfassungsentscheidung, jede Manifestüberarbeitung und jeder Integritätsdatensatz MUSS versioniert und einer verantwortlichen Person oder Organisation zuordenbar sein.