So arbeiten wir.
Diese Seite beschreibt die im Quellcode definierten Mechanismen und ihren Umfang. Die Zahlen zu Produkten, Aussagen, Belegstufen, Lebenszyklus und abgelaufenen Angaben werden aus dokumentierten Daten berechnet. Für tatsächlich ausgeführte Jobs sind gesonderte Ausführungsnachweise erforderlich.
Belegstufen
Jede dokumentierte Aussage erhält eine Stufe. Sie ist keine Qualitätsrangliste, sondern beschreibt den Umfang des Nachweises: Leser sollen unterscheiden können zwischen „Wir haben den Code gelesen und gezählt“ und „Es steht in unserem eigenen Text“.
Die eigenen Produktdaten geben dies an; niemand hat es unabhängig nachgeprüft. Die schwächste Stufe, die nie als mehr dargestellt wird.
Der Laufzeitcode wurde gelesen und gezählt. Die Aussage stützt sich auf den Code selbst.
In einer realen Umgebung ausgeführt und gemessen. Das Ergebnis wird mit seinem Datum aufgezeichnet.
Von jemandem außerhalb von YULA bestätigt.
Zustandsmodell der Produkte
4 Zustände, von denen jeder etwas konkret verändert. Ein Zustand ohne Auswirkung ist nur ein Etikett. Ihn hier als Phase aufzuführen, wäre genau die Inszenierung, die diese Seite vermeiden soll.
Wird im Produktverzeichnis zuerst einsortiert. Jeder Screenshot muss sourceBuild und capturedAt enthalten, sonst scheitert der Build.
Dieselben Belegregeln wie bei veröffentlichten Produkten; wird danach im Verzeichnis einsortiert.
Wird in einem eigenen eingeklappten Abschnitt angezeigt. Der Hauptlink darf keine Store-URL sein. Ein nicht herunterladbares Produkt darf nicht herunterladbar wirken.
Verschwindet aus dem Standard-Produktverzeichnis. Der Datensatz bleibt erhalten, der Platz in der Übersicht nicht.
Regeln für öffentliche Aussagen
Dokumentierte Aussagen, verknüpfte Statistiken, Screenshots und Fallstudien werden automatisiert geprüft. Frei formulierte Werbetexte werden gesondert begutachtet.
- Eine strukturelle Lücke lässt den Build scheitern: Eine Aussage ohne Quelle, Umfang, Verantwortlichen oder Datum darf nicht veröffentlicht werden.
- Datumsangaben müssen führende Nullen enthalten. Eine fehlende Null (2026-9-18) würde verhindern, dass eine Aussage vor dem Jahreswechsel abläuft.
- Ein abgelaufener Nachweis lässt den Build NICHT scheitern, sondern verändert die Seite. Eine abgelaufene Aussage ist nicht falsch, sondern unverifiziert. Sie wird nie gelöscht, sondern als zur erneuten Prüfung ausstehend angezeigt.
- Eine Statistik-Karte darf keine Zahl ausgeben, die in der verknüpften Aussage nicht enthalten ist.
- Ein unveröffentlichtes Produkt darf keine erfundene Oberfläche zeigen. Jeder Screenshot nennt den zugehörigen Build und das Aufnahmedatum.
- Eine Textprüfung sucht gezielt nach 12 Aussagen, die sich früher als falsch erwiesen haben, und verhindert ihre erneute Aufnahme.
- Die Fallstudienprüfung: Ohne Erlaubnis, Ausgangswert, Artefakt, gemessenes Ergebnis, Erkenntnis aus einem Fehlschlag und Gültigkeitsdatum gibt es keine Fallstudie.
Datenschutz und Sicherheit
Kontaktformular, Funnel-Messung und E-Mail-Zustellung werden getrennt gesteuert. Die Datenschutzseite erläutert Datenkategorien und Verwendungszwecke.
- Wenn neue Kontaktanfragen deaktiviert sind, gibt der Formularendpunkt 503 zurück. Die Zustellung bereits angenommener Benachrichtigungen hängt von einer gesonderten E-Mail-Konfiguration und der Ausführung des Warteschlangen-Workers ab. Das Schließen der Annahme verwirft keine ausstehenden E-Mails.
- Eine Einwilligung ist kein bloßes Kästchen, sondern ein eigener Datensatz mit einer datierten Version des Hinweises. Dass jemand zugestimmt hat, sagt noch nicht, wozu.
- Die Funnel-Messung nimmt keinen Freitext an: Feldwerte sind eingeschränkt, Abfrageparameter werden aus Seitenpfaden entfernt. Rohdaten werden 30 Tage aufbewahrt; ein Job entfernt abgelaufene Datensätze. Ob die Löschung im Produktivsystem abgeschlossen wurde, belegen Ausführungsaufzeichnungen.
- Datenanfragen umfassen eine Bestätigung der E-Mail-Adresse. Die bestätigte Adresse bedeutet nicht, dass ein Auskunfts-, Berichtigungs- oder Löschantrag bereits erfüllt wurde.
- Die Website ist mit einer CSP eingerichtet, die Inhaltsquellen einschränkt, sowie mit Headern, die das Einbetten durch andere Websites verhindern. Allgemeine Seiten und die E-Mail-Bestätigungsseite verwenden unterschiedliche CSP-Regeln.
Die Grenze zwischen KI und Mensch
Diese Website wird größtenteils von KI-Sitzungen geschrieben. Die Grenze bleibt nicht vage, sondern ist an eine Risikoklasse gebunden.
- Gründerfreigabe: Store-Einreichung, Preise, echtes Geld, Kontoinhaberschaft, Rechtsfragen und unumkehrbare Entscheidungen sind ausschließlich Menschen vorbehalten.
- Sicherheits-, Zahlungs-, Migrations- und Datenschutzarbeiten benötigen vor der Abnahme eine unabhängige Prüfung. Niemand nimmt seine eigene Arbeit ab. Diese Prüfung lehnt tatsächlich Arbeiten ab; die Aufzeichnungen enthalten Runden, die mehrmals zurückgewiesen wurden.
- „Fertig“ ist keine Prozentzahl: Arbeit endet erst im Zustand ACCEPTED. Ohne einen Belegeintrag ist dieser Zustand nicht erreichbar.
- Schritte, die eine Person, ein Gerät oder einen Termin benötigen, werden als EXTERNAL GATES erfasst. Die erforderliche Aktion und der Abschlussnachweis werden ausdrücklich benannt.
Aktuelle Grenzen
Dieser Abschnitt ist der Preis für diese Seite. Zu beschreiben, wie wir ehrlich bleiben, und zugleich zu verschweigen, wo wir diesem Anspruch derzeit nicht gerecht werden, wäre genau das Versagen, das die Seite verhindern soll.
- Die Textprüfung läuft bei jedem Build. Ihre repositoryübergreifenden Ziele sind aber nur lokal und in CI vorhanden. Die Bereitstellung, die diese Seite ausliefert, führt eine eingeschränkte Version aus.
- Eine Fallstudie liefert keine eigene Zahl. Sie benennt, welche verifizierte Kennzahl einer Aussage im Register sie wiedergibt; die angezeigte Zahl wird aus dem Register gelesen. Dieselbe Regel gilt für Titel, Metrikbezeichnung und den Abschnitt „Was sich danach geändert hat“, weil sie als Aussagen gelesen werden. Ausgangswert, Einschränkung, Entscheidungszusammenfassungen, Artefaktbezeichnungen, Erlaubnisumfang und die Erkenntnis aus dem Fehlschlag bleiben Freitext. Dort ist eine Zahl gewöhnlicher Text. Bekannter Grenzfall: Eine wie eine Kennung aussehende Zeichenfolge wie „Accuracy-95“ wird als Bezeichnung akzeptiert.
- Produktdetailseiten verwenden Prüfdaten für Store- und Verfügbarkeitsangaben. Abgelaufene Verfügbarkeitsaussagen zeigen einen Hinweis zur erneuten Prüfung. Für 5 dokumentierte Angaben sind die Prüfzeiträume abgelaufen. Diese Prüfung deckt nicht jeden Werbetext ab.
- Die Erreichbarkeit von Links blockiert CI nicht. Eine tote Store-URL erzeugt eine Warnung, lässt aber die Pipeline nicht scheitern.
- CI umfasst Linting, Typprüfung, Tests, einen Build und Abhängigkeitsprüfungen. Ergebnisse werden anhand der jeweiligen Änderung und des Ausführungsnachweises beurteilt. Lokale Prüfungen belegen keine Veröffentlichung im Produktivsystem.
- Die Standardkonfiguration der Bereitstellung plant den E-Mail-Job einmal täglich. Das ist keine Zusage für eine Zustellzeit. Der Versand hängt von der E-Mail-Konfiguration, dem Anbieter und der erfolgreichen Ausführung des Jobs ab.
Verwandt: Produkttransparenz · Fallstudien