Vertrag über die Auftragsverarbeitung (AVV)

nach Art. 28 DSGVO — für die Shopify-App Kuno

Erste Fassung. Sie bildet den Stand ab, mit dem Kuno zum ersten Mal in einem fremden Shop läuft. Ändert KYTH den Inhalt, ändert sich die Kennung, und jeder Händler wird beim nächsten Öffnen der App erneut gefragt (§ 0.3). Die Anlagen 1 und 2 sind gegen den Quelltext erhoben und nicht abgeschrieben; die Prüfungen, die sie dagegen halten, sind Bestandteil des Prüfstands und laufen bei jeder Änderung mit.

⚠ Die angekündigte eine Hebung ist am 13.09.2026 geschehen. Die Kennung des Zustimmungsnachweises steht seither auf 1.0-2026-09-13, und derselbe Wert steht im Nutzungsvertrag, in der Datenschutzerklärung und in der einen Stelle des Programms, die ihn beim Zustimmen mitschreibt. Jede Änderungsnotiz dieses Vertrages, die von „derselben einen Hebung" spricht, meint diese — sie sind damit alle wirksam geworden, in einem Zug und nicht nacheinander. Der Tag ist gemessen und nicht geplant: Er ist der Tag, an dem die letzte Textänderung dieses Durchgangs geschrieben wurde. Ein Plantext vom 30.08.2026 hatte dafür einen späteren, damals bloß erwarteten Tag vorgesehen; eine Fassungskennung, die in der Zukunft datiert, behauptete auf einem Zustimmungstext einen Stand, den es am Tag der Zustimmung noch nicht gibt. Die Fassungsnummer bleibt 1.0, weil die Gliederung dieses Vertrages unverändert ist. Wer schon zugestimmt hatte, wird beim nächsten Öffnen der App erneut gefragt (§ 0.3) — zugestimmt hatte bis zu jenem Tag niemand.

Bis zum 13.09.2026 nannte dieser Hinweis den 12.09.2026 und die Kennung 1.0-2026-09-12. Es bleibt dieselbe eine Hebung: Sie trägt den Tag, an dem die Texte wirklich fertig wurden, und dazwischen ist nichts ausgeliefert worden und hat niemand zugestimmt.

⚠ Inhaltlich nachgezogen am 01.09.2026 — die Fassungskennung ist am 13.09.2026 nachgezogen worden. Bis zum 12.09.2026 sagte diese Überschrift, sie stehe noch aus. Die Angaben über die Sendungsdaten und die Anlage 1 bilden den Schemastand vom 02.09.2026 ab — seit dem 01.09.2026 das Mengenkonto, seit dem 02.09.2026 die Buchführung des Abrufs und die Vorfälle bei der Verarbeitung (Anlage 1 Abschnitt A) samt den beiden zweiten Richtlinien in Anlage 2 Abschnitt 1.2. § 3.4, § 6.4, § 6.5 und die Anlagen 1 und 2 bilden zusätzlich den Quelltextstand vom 02.09.2026 ab: Seit diesem Tag stehen der Auftrag für die Bestellhistorie und die Frage nach seinem Stand im Programm — der dritte und der vierte Aufruf an die Admin-API. Seit demselben Tag arbeitet der Lauf für die Bestellhistorie sie ab und holt die Ergebnisdatei von der Ergebnisablage, die Shopify dafür bereitstellt: der dritte Endpunkt außerhalb von KYTH und der einzige, der nicht beim Händler-Shop liegt (§ 6.5). Bis zum 02.09.2026 nannte dieser Hinweis beide Aufrufe „von keiner Stelle ausgelöst"; das trägt so nicht mehr, und § 3.4, § 6.4 und § 6.5 sagen jetzt genau, was geschieht — die datierten Selbstkorrekturen stehen dort, wo sie in die Nachführliste (§ 0.3) gehören. Der Lauf greift ausschließlich Aufträge auf, die in der Warteschlange stehen. Seit dem 03.09.2026 gibt es die Stelle, die einen Auftrag anlegt: Kuno legt ihn auf Anforderung des Händlers an (§ 3.4). Gebaut ist dabei die Schnittstelle; die Seite im Adminbereich, auf der der Händler den Abruf auslöst, entsteht mit dem Ausbau der Oberfläche. Bis zum 03.09.2026 stand hier, einen Auftrag lege „heute keine Stelle des Programms" an und es gebe „weder Route noch Lauf, der einen anfordert".

⚠ Am selben Tag ist der Abgleich dazugekommen, und er ändert die Lage der Sache. Seit dem 02.09.2026 steht der Abgleich im Programm (kiloAbgleich, § 3.4) — der fünfte Aufruf an die Admin-API und der erste, den niemand auslösen muss: Solange die App installiert ist, fragt der Lauf etwa alle 15 Minuten und einmal je Nacht nach, welche versendeten Bestellungen sich geändert haben, und verbucht sie im Mengenkonto (Anlage 1 Abschnitt A). Damit werden read_orders, read_fulfillments und die geschützte Kundendatenkategorie address erstmals wirklich ausgeübt (§ 2.3), und die Tabellen des Mengenkontos füllen sich im laufenden Betrieb. Grund ist die Zusicherungslücke bei Shopifys Ereignismeldungen: „Webhook delivery isn't always guaranteed", und Shopify empfiehlt dafür selbst regelmäßige Abgleichläufe. Sätze, die bis zum 02.09.2026 sagten, Bestell- und Sendungsdaten würden nicht abgefragt und die Tabellen des Mengenkontos seien leer, sind in § 2.3, § 3.4, § 6.4, § 6.5 und den Anlagen 1 und 2 nachgezogen. Die Kennung und der abgebildete Quelltextstand in der Tabelle darüber standen bis zum 12.09.2026 auf dem 30.08.2026. Die Hebung ist am 13.09.2026 geschehen und fiel damit vor die erste Installation in einem fremden Shop: Kuno ist bei Shopify nicht veröffentlicht, und bis zu jenem Tag hatte kein Händler zugestimmt. Bis zum 12.09.2026 kündigte dieser Hinweis sie als bevorstehend an; er steht weiter hier, weil er belegt, welche Sätze sie erfasst hat.

⚠ Am 03.09.2026 sind die Meldungen von Shopify eingeschaltet worden. Bis dahin beschrieben alle Abschnitte dieses Vertrages die Bestell- und Sendungsmeldungen als „in der App-Konfiguration ausgeschaltet"; seit diesem Tag stehen sie in der Konfiguration, und vier Routen nehmen sie entgegen (§ 3.4, § 6.4, Anlage 2 Abschnitt 2.1): die Sendungsmeldung, der Storno einer Bestellung, die Erstattung und die Fertigmeldung einer Sammelabfrage. Aus der Sendungsmeldung entsteht eine Zeile des Mengenkontos, Storno und Erstattung sind Vermerke ohne Mengenwirkung, die Fertigmeldung trägt gar keine Sendungsdaten. Damit kommt der sechste Aufruf an die Admin-API dazu: die Abfrage einer einzelnen Bestellung (kiloBestellung, § 3.4). Sie überträgt nichts als die Kennung der gemeldeten Bestellung und holt die sieben Felder, ohne die eine Testbestellung oder eine Abholung als gemeldete Verpackung zählte. Kein Scope kommt dazu, und deshalb wird kein Händler dadurch erneut gefragt: Alle vier Meldungen hängen an read_orders und read_fulfillments, die seit dem 30.08.2026 angefordert werden (§ 2.3). Kennung und abgebildeter Quelltextstand in der Tabelle oben blieben bis zum 12.09.2026 auf dem 30.08.2026 — auch dieser Stand wird von derselben einen Hebung erfasst, die oben angekündigt ist.

Am 01.09.2026 ist zusätzlich der Außenname von „Kilo" auf Kuno geändert worden und der Leitspruch auf „Ship. Weigh. Repeat."; die Wortmarke lautet jetzt KYTH.Kuno. Auch das wird mit derselben einen Hebung wirksam und löst keine zweite aus. Der Name in diesem Dokument war deshalb schon der neue, während die Kennung darüber bis zum 12.09.2026 die alte blieb. Wo der alte Name in Anführungszeichen stehen geblieben ist, gehört er zu einer datierten Selbstkorrektur und wird nicht mitgezogen — sonst wäre der Beleg falsch. Intern heißt alles unverändert kilo (Paket, Datenbank, Rolle, Logger).

Die Adresse in der Tabelle oben ist am 12.09.2026 gewechselt. Bis zum 12.09.2026 stand in der Zeile „Gilt für“ https://kilo.kyth.systems, und dieser Absatz begründete das eigens: Die Adresse sei „kein übersehener Rest, sondern derselbe interne Name“, unter ihr laufe die Anwendung, an ihr hängen die Bereitstellung, die Weiterleitungsadresse der Anmeldung und die Einrichtung beim Betreiber. Die erste Hälfte war eine richtige Beobachtung mit einer falschen Folgerung, die zweite war unwahr. Richtig war, dass die Adresse den Innennamen trug; daraus folgt aber nicht, dass sie bei ihm bleiben dürfe — eine Adresse ist eine Angabe nach außen, und sie steht in drei Zustimmungstexten und in jeder Weiterleitung der Anmeldung. Unwahr war der Rest: Die Adresse kilo.kyth.systems hat es nie gegeben — gemessen am 12.09.2026 mit nslookup: „Non-existent domain“. Der Absatz beschrieb damit im Präsens einen Betriebszustand, den es nie gab, und zwar in einem Text, dem ein Händler zustimmt.

Was seither gilt. Die Anwendung wird unter https://kuno.kyth.systems erreichbar sein, sobald sie ausgeliefert ist. Der Name steht seit dem 06.09.2026 im DNS und löst unmittelbar auf die Adresse des Servers in Berlin auf (§ 6.4, Cloudflare); unter derselben Adresse wird auch dieser Text ausgeliefert. Am 12.09.2026 ist Kuno noch nicht ausgeliefert — die App ist bei Shopify nicht veröffentlicht, und bis zu jenem Tag hatte kein Händler zugestimmt. Der Innenname bleibt unverändert kilo (Paket, Datenbank, Rolle, Logger); er ist kein Bestandteil einer Adresse, unter der jemand etwas aufruft.

Vertragsparteien

Verantwortlicher

Der Händler, der Kuno in seinem Shopify-Shop installiert. Er entscheidet über Zwecke und Mittel der Verarbeitung der Daten, die in seinem Shop anfallen.

Der Händler wird gegenüber dem Auftragsverarbeiter durch zwei Angaben identifiziert, die beide beim Vertragsschluss nach § 0 festgehalten werden:

1. seine myshopify-Domain — sie bezeichnet den Shop eindeutig und stammt aus dem von Shopify signierten Sitzungsnachweis, ist also nicht frei behauptbar;
2. eine E-Mail-Adresse als Kontaktadresse, die der Händler im Zustimmungsschritt selbst angibt (Pflichtfeld, § 2a Nr. 4).

Damit sind Name und Kontaktdaten des Verantwortlichen im Sinne von Art. 30 Abs. 2 lit. a DSGVO führbar. Die vollständigen Firmendaten (Firmierung, Anschrift, Vertretung) erhebt KYTH nicht selbst; sie ergeben sich aus dem Shopify-Konto des Händlers und werden bei Bedarf über die genannte Kontaktadresse erfragt.

Auftragsverarbeiter

KYTH. Systems UG (haftungsbeschränkt) Prof.-Mederer-Straße 4 92348 Berg Deutschland

Datenschutzbeauftragter: Ein Datenschutzbeauftragter ist nicht bestellt. Nach § 38 BDSG besteht dazu bei der derzeitigen Unternehmensgröße keine Pflicht. Zuständige Anlaufstelle für Datenschutzfragen ist datenschutz@kyth.systems; das ist kein Datenschutzbeauftragter im Sinne von Art. 37 DSGVO.

Im Folgenden „KYTH".

§ 0 Zustandekommen des Vertrages

0.1 Zustimmung im Installationsablauf

Dieser Vertrag kommt dadurch zustande, dass der Händler ihm im Installationsablauf der App zustimmt. Der Ablauf ist folgender:

1. Der Händler öffnet Kuno in seinem Shopify-Adminbereich und löst das Verbinden aus.
2. Liegt für die aktuelle Fassung keine Zustimmung vor, führt die App den Vorgang nicht aus, sondern zeigt den Zustimmungsschritt: Verweise auf diesen Vertrag, auf die Datenschutzerklärung und auf den Nutzungsvertrag, ein Feld für die Kontaktadresse (Pflichtfeld) und ein Zustimmungshäkchen, das nicht vorbelegt ist.
3. Erst wenn der Händler beides ausfüllt, wird der Vorgang ausgeführt.

Ohne Zustimmung geschieht nichts. Vor der Zustimmung wird weder ein Datensatz zum Shop angelegt noch ein Zugangstoken bei Shopify abgeholt. Das ist keine Zusage über gute Absichten, sondern die Reihenfolge, in der die App arbeitet: Die Prüfung, ob eine Zustimmung zur aktuellen Fassung vorliegt, steht vor jedem Schreibzugriff und vor jedem Aufruf bei Shopify.

Eine Ausnahme, und zwar eine, die außerhalb der Kontrolle von KYTH liegt. Bei der von Shopify verwalteten Installation ist die App bereits installiert und sind die Meldungen bereits abonniert, bevor der Händler die eingebettete Seite überhaupt zum ersten Mal öffnet. Klickt er den Zustimmungsschritt weg und deinstalliert wieder, sendet Shopify gleichwohl app/uninstalled. Diese signierten Meldungen nimmt KYTH entgegen: Die Shop-Domain wird zu einem Suchwert verrechnet, in der Datenbank nachgeschlagen und — wenn kein Shop zu ihr gehört — für 14 Tage im Anwendungsprotokoll vermerkt. Ein Datensatz zum Shop entsteht dabei nicht; gespeichert wird lediglich die technische Kennung der Meldung im Duplikatschutz. Diese Verarbeitung findet also ohne geschlossenen Vertrag statt, und sie steht deshalb als eigener Fall in Anlage 1 Abschnitt A. Rechtsgrundlage ist Art. 6 Abs. 1 lit. f DSGVO — berechtigtes Interesse daran, eine von Shopify verpflichtend abonnierte Meldung signaturgeprüft entgegenzunehmen und einen unbekannten Shop nicht lautlos zu verschlucken —, ergänzend Art. 6 Abs. 1 lit. c DSGVO, soweit die Entgegennahme der Datenschutz-Meldungen der Erfüllung der Pflichten aus Art. 12 ff. DSGVO dient.

Eine gesonderte Unterschrift ist nicht erforderlich (Art. 28 Abs. 9 DSGVO lässt das elektronische Format ausdrücklich zu).

0.2 Nachweis

KYTH hält den Vertragsschluss in der Datenbank fest — drei Angaben, entweder alle oder keine:

Die Fassungskennung setzt ausschließlich der Server; eine vom Browser mitgeschickte Angabe bleibt wirkungslos. Andernfalls ließe sich eine Zustimmung zu einer Fassung protokollieren, die dem Händler nie angezeigt wurde — ein Nachweis, der eine Genauigkeit behauptet, die er nicht hat, ist im Streitfall schlechter als keiner.

Der Nachweis überdauert eine Deinstallation. Installiert der Händler die App innerhalb der Frist nach § 9.3 Nr. 1 erneut, muss er nicht erneut zustimmen — seine Zustimmung zu genau dieser Fassung liegt vor. Mit der Löschung des Shops verschwindet auch der Nachweis.

Der Verlauf steht von Anfang an. Neben der zuletzt erteilten Zustimmung an der Shop-Zeile hält eine eigene Tabelle jede erteilte Zustimmung fest. Dieser Zustimmungsverlauf wird ausschließlich anhängend geschrieben und trägt kein Änderungsrecht: Ein geschriebener Nachweis lässt sich nicht mehr ändern. Ein Löschrecht besteht dagegen, und es wird gebraucht — der Löschpfad räumt jede Tabelle mit einer Shop-Zuordnung, und diese trägt eine. Ohne dieses Recht bliebe der Zustimmungsnachweis nach der Löschung des Shops liegen, also das Gegenteil dessen, was der Absatz darüber zusagt. Die Tabelle führt Shop-Zuordnung, Fassungskennung und Zeitpunkt; eine personenbezogene Angabe steht nicht darin.

Bei Kartuu, dem Gerüst dieser App, gab es diesen Verlauf lange nicht: Eine neue Zustimmung überschrieb den Beleg der vorigen, und der Nachweis einer älteren Fassung war damit fort. Kuno führt ihn deshalb von der ersten Fassung an mit.

0.3 Geltende Fassung und Änderungen

Der Vertrag gilt in der Fassung, deren Kennung beim Zustimmen festgehalten wurde. Ändert KYTH den Text inhaltlich, erhöht KYTH die Fassungskennung; beim nächsten Öffnen der App wird der Händler erneut um Zustimmung gebeten. Eine reine Berichtigung von Schreibfehlern führt nicht zu einer neuen Kennung — ein Zustimmungsfenster ohne Anlass entwertet die Zustimmung.

Einmal ist das nicht in dieser Reihenfolge geschehen, und der Absatz darüber steht deshalb seit dem 01.09.2026 mit diesem Vorbehalt: Alle drei Zustimmungstexte sind an jenem Tag inhaltlich nachgezogen worden, bevor die Kennung gehoben war. Die Hebung ist am 13.09.2026 geschehen, und damit vor der ersten Installation in einem fremden Shop; bis zu jenem Tag hatte kein Händler zugestimmt. Bis zum 12.09.2026 stand hier, sie folge zum Abschluss des laufenden Ausbaus. Der Vorgang steht im Hinweis im Kopf, dieselbe Zeile tragen der Nutzungsvertrag (§ 4) und die Datenschutzerklärung (13).

Was bei der nächsten Erhöhung nachzuführen ist. Dieser Vertrag beschreibt eine App im Aufbau. § 0.2, § 0.3, § 1.1, § 1.3, § 2.1, § 2.2, § 2.3, § 2a, § 3.4, § 4, § 6.3, § 6.4, § 6.5, § 7.2, § 7.3, § 9.1, § 9.2, § 9.3 Nr. 2, Nr. 4, Nr. 6 und Nr. 7, § 9.4, § 11 Nr. 6 und § 12 sind die Stellen, an denen er heute etwas verneint, was morgen zutrifft, oder einen Vorbehalt trägt; dazu Anlage 1 und Anlage 2 — dort insbesondere die Abschnitte 1.5, 2.1, 3, 5, 6 und 7.2 —, die ohnehin gemeinsam neu zu erheben sind, und der Hinweis im Kopf. Wer eine dieser Stellen berührt, hebt die Kennung. Die entsprechende Liste führt der Nutzungsvertrag in § 12 und die Datenschutzerklärung in Abschnitt 14.

Am 12.09.2026 ist § 9.2 in die Aufzählung aufgenommen worden: Der Paragraph über Löschung oder Rückgabe trägt seit jenem Tag eine datierte Selbstkorrektur, weil die automatische Ausleitung, die er bis dahin verneinte, gebaut ist. Auch diese Änderungsnotiz steht in einem eigenen Absatz und ohne Fettdruck.

Bis zum 03.09.2026 nannte diese Liste von § 9.3 nur Nr. 4 und Nr. 6; Nr. 2 (Sicherungen) trägt mit „Ab Inbetriebnahme gilt:" denselben Vorbehalt, und ihr Spiegelbild in der Datenschutzerklärung (9.6) stand dort längst. Diese Liste stand bis zum 01.09.2026 nur im nicht ausgelieferten Arbeitsteil und nannte § 11 Nr. 6 und den Hinweis im Kopf nicht; sie steht jetzt hier, weil ein Händler die Stellen finden können soll, an denen dieser Vertrag heute einen Vorbehalt trägt.

Am selben Tag ist die Aufzählung darüber um sechs Stellen erweitert worden — § 1.1, § 1.3, § 2.2, § 2a, § 9.4 und § 12 —, die einen Vorbehalt tragen und in keiner der beiden vorigen Fassungen der Liste standen. Diese Änderungsnotiz steht bewusst in einem eigenen Absatz und ohne Fettdruck: Die Prüfung im Prüfstand liest die fett gesetzte Aufzählung des ersten Absatzes hinter der Überschrift, und eine zweite fette Aufzählung daneben wäre eine zweite Liste über denselben Gegenstand.

Am 02.09.2026 ist § 6.5 dazugekommen: Der Abruf der Ergebnisdatei hat an diesem Tag seinen ersten Aufrufer bekommen, und der Absatz über die Verbindungen nach draußen ist deshalb berichtigt worden — er nennt seither drei Stellen statt zwei und die Ergebnisablage als Empfänger. Auch diese Änderungsnotiz steht in einem eigenen Absatz und ohne Fettdruck.

Am selben Tag sind außerdem § 3.4, § 4, § 6.3, § 6.4, § 9.3 Nr. 4 sowie die Abschnitte 3 und 5 der Anlage 2 dazugekommen. Sie beschreiben im Präsens, wo Server, Datenbank und Sicherungen stehen und in wie vielen Umgebungen Kuno läuft. Diese Sätze werden mit der Inbetriebnahme wahr und sind deshalb nicht umgeschrieben, sondern hier verzeichnet worden — mit einer Ausnahme: Anlage 2 Abschnitt 5 stand im Widerspruch zu Abschnitt 3 derselben Anlage und ist berichtigt. Dieselben Stellen führt die Prüfliste der Einrichtung, damit sie beim Aufbau der Umgebung nicht ein zweites Mal übersehen werden.

Am 05.09.2026 ist die Zeile über die Berichte und Exportdateien in Anlage 1 Abschnitt C fünfmal fortgeschrieben worden — von einem Dateibauer auf fünf —, und Anlage 1 Abschnitt A hat an demselben Tag die Bestände der Meldung bekommen. Bis zum 06.09.2026 nannte dieser Satz Abschnitt B; dort steht „Nur flüchtig berührte Daten — keine Speicherung" und keine solche Zeile, während der Absatz über die vier am 06.09.2026 berichtigten Stellen für denselben Vorgang richtig auf Abschnitt C zeigte. Wer dem Verweis folgte, landete in einem Abschnitt über nicht gespeicherte Daten und fand die Änderung nicht — in dem Paragraphen, dessen Zweck die Nachvollziehbarkeit der Änderung ist. Der Kopf dieses Vertrages nannte dabei bis zum 12.09.2026 weiter den abgebildeten Quelltextstand 30.08.2026, während der Fließtext an mehreren Stellen den 04. und den 05.09.2026 beschreibt. Auch dieser Abstand wird von derselben einen Hebung erfasst, die oben angekündigt ist; er steht hier, weil ein Vorbehalt, den nur der Kopf trägt, beim Abschluss übersehen wird. Diese Änderungsnotiz steht in einem eigenen Absatz und ohne Fettdruck in der Aufzählung, damit die Prüfung im Prüfstand die eine Aufzählung liest und nicht zwei.

Am 12.09.2026 ist die Aufzählung darüber um § 0.2 erweitert worden. Der Nachweisabschnitt nennt die Kennung, die beim Zustimmen mitgeschrieben wird, mit einem konkreten Wert; mit der Hebung ist er von 1.0-2026-08-30 über 1.0-2026-09-12 auf 1.0-2026-09-13 gewandert und trägt seither eine datierte Selbstkorrektur. Bis dahin stand § 0.2 in keiner der drei Nachführlisten — ein Beispiel, das den Wert einer laufenden Verarbeitung nennt, gehört in dieselbe Liste wie jeder Vorbehalt. Diese Änderungsnotiz steht in einem eigenen Absatz und ohne Fettdruck in der Aufzählung.

Am 06.09.2026 sind vier Stellen berichtigt worden, an denen dieser Vertrag hinter dem Programm zurückgeblieben war. § 2.2 führt die vier Bestände der Meldung jetzt auch in der Kurzform — samt dem Hinweis, dass der Bestätigungstext freier Text des Händlers ist. Bis zum 07.09.2026 endete dieser Halbsatz mit „die einzige Freitextspalte des Schemas ist"; das war schon am 06.09.2026 falsch, ist in § 2.2 und in der Notiz weiter unten noch am selben Tag zurückgenommen worden und wäre hier als dritte Fundstelle stehen geblieben — ausgerechnet in dem Paragraphen, dessen Zweck die Nachvollziehbarkeit der Änderungen ist, und damit an der Stelle, an der man den Vertrag als Erstes aufschlägt. Die gemessene Zahl steht in § 2.2. § 1.1 beschreibt nicht mehr den Stand vom 03.09.2026, sondern auch die Mengenermittlung und die Meldung; Anlage 1 Abschnitt A nennt neben dem Bestätigungstext den anmeldenden Shop statt einer Person, weil die App den Wert seit demselben Tag aus dem geprüften Sitzungstoken belegt; und die Notiz zum 05.09.2026 verweist für die Zeile über die Berichte und Exportdateien auf Abschnitt C statt auf Abschnitt B. Auch diese Änderungen werden von derselben einen Hebung erfasst; keine von ihnen erweitert den Gegenstand der Verarbeitung — drei beschreiben Vorhandenes vollständiger, die vierte beschreibt WENIGER, weil eine Angabe über eine Person weggefallen ist. Diese Änderungsnotiz steht in einem eigenen Absatz und ohne Fettdruck in der Aufzählung.

Am Abend desselben Tages ist der Weg nach draußen dazugekommen: Neun Adressen der App führen seither einen Meldezeitraum und liefern die fünf Dateien an den Händler aus. Berührt sind § 1.1, § 1.3 Nr. 6, § 12 Nr. 7, Anlage 1 Abschnitt C — Vorspann und die Zeile über die Berichte und Exportdateien — sowie Anlage 2 Abschnitt 6, wo der Prüfstand seit jenem Tag keine Wendung mehr führt, die eine Leistung als vorhanden verböte. Auch diese Änderung wird von derselben einen Hebung erfasst; der Gegenstand der Verarbeitung ändert sich dadurch nicht — es sind dieselben Bestände des Abschnitts A und dieselben Summen, und die Bytes werden weiterhin nicht gespeichert. Auch diese Änderungsnotiz steht in einem eigenen Absatz und ohne Fettdruck in der Aufzählung.

Am 06.09.2026 sind zwei Bestände dazugekommen, mit denen der Händler seine Meldevorgaben festhält: die Zielsysteme je Land und der Fristenkalender (Migration 0025). Berührt sind § 2.2 — ein neuer Punkt in der Kurzform — und Anlage 1 Abschnitt A, wo beide spaltengenau aufgezählt und beide als frei von Angaben über die Kundschaft des Händlers eingeordnet sind; das Bestätigungskennzeichen einer erledigten Frist trägt denselben Vorbehalt wie der Bestätigungstext eines Meldezeitraums, weil es freier Text ist. Auch diese Änderung wird von derselben einen Hebung erfasst; sie erweitert den Gegenstand der Verarbeitung um zwei Bestände über den Händler und um keine einzige Angabe über eine Endkundin oder einen Endkunden. Bis zum Abend desselben Tages endete dieser Absatz mit „Eine Adresse oder eine Bedienseite, über die der Händler sie füllen könnte, gibt es an diesem Tag nicht"; das traf am Abend nicht mehr zu, und die Berichtigung steht im Absatz über die Adressen zu beiden Beständen. Auch diese Änderungsnotiz steht in einem eigenen Absatz und ohne Fettdruck in der Aufzählung.

Am Nachmittag desselben Tages ist Anlage 1 Abschnitt A um einen Zusatz zum Fristenkalender ergänzt worden. Der Absatz über die beiden neuen Bestände sagte, was der Händler „an Zielsystemen und Terminen einträgt", komme mit dem Ausbau der Oberfläche — für die Zielsysteme trifft das zu, für den Kalender nur halb: Seit jenem Nachmittag leitet ein Programmteil die Termine aus den Zielsystemen ab, je Land die mit geprüfter öffentlicher Quelle, und getippt ist davon allein die Vertragsfrist. Hinzugekommen ist, woher der Inhalt stammt, sobald es ihn gibt. Auch diese Ergänzung wird von derselben einen Hebung erfasst; sie erweitert den Gegenstand der Verarbeitung um keine Angabe — es sind dieselben Spalten derselben Tabelle. Verzeichnet ist sie trotzdem, weil ein abgeleiteter Bestand etwas anderes ist als ein getippter: Beim ersten stammt der Inhalt aus einer Rechnung dieser App, beim zweiten aus der Hand des Händlers. Bis zum Abend desselben Tages standen in diesem Absatz zwei weitere Sätze: „Der Satz über die fehlende Adresse und die fehlende Bedienseite steht unverändert" und „der Bestand bleibt leer, weil den Programmteil nichts anstößt". Beide trafen am Abend nicht mehr zu — der erste war schon vorher unrichtig, weil derselbe Tag Anlage 1 Abschnitt A und § 2.2 geändert hat; die Berichtigung steht im Absatz über die Adressen zu beiden Beständen. Auch diese Änderungsnotiz steht in einem eigenen Absatz und ohne Fettdruck in der Aufzählung.

Am Abend desselben Tages sind die Adressen zu beiden Beständen dazugekommen: fünf Wege der App, über die der Händler seine Zielsysteme liest, eines für ein Land anlegt, ändert oder zurücknimmt, seinen Fristenkalender liest und einen Termin abhakt. Berührt sind Anlage 1 Abschnitt A, § 2.2 und § 1.3 Nr. 4; die drei Sätze, die sagten, es gebe keine Adresse und der Bestand bleibe leer, sind dort datiert berichtigt. Angestoßen wird der Fristenerzeuger seither von jeder Änderung an einem Zielsystem, und zwar so, dass die noch bevorstehenden offenen Termine des Landes weggeräumt und neu erzeugt werden; ein bereits überfälliger offener Termin bleibt stehen, weil ihn kein Lauf wieder anlegte, und ein abgehakter ebenfalls, weil er der Nachweis über eine abgegebene Meldung ist. Auch diese Änderung wird von derselben einen Hebung erfasst; sie erweitert den Gegenstand der Verarbeitung um keine Angabe — es sind dieselben Spalten derselben Tabellen, die sich nun wirklich füllen. Die Bedienelemente darauf stehen seit dem späten Abend desselben Tages — die Karten „Zielsysteme je Land" und „Fristen" der Administration; verzeichnet ist das im Absatz über die Bedienelemente von Meldungsseite und Administration. Bis zum 07.09.2026 endete dieser Absatz mit „Was weiterhin fehlt, sind die Bedienelemente darauf"; das traf seit jenem Abend nicht mehr zu, und Anlage 1 Abschnitt A desselben Vertrages führte den richtigen Stand bereits. Auch diese Änderungsnotiz steht in einem eigenen Absatz und ohne Fettdruck in der Aufzählung.

Ebenfalls am 06.09.2026 haben vier Adressen der App ihre Seiten bekommen — Sendungen, Verpackungen, Produkte und Meldungen —, und das Menü der App führt seither sechs Punkte statt zweier. An der Verarbeitung ändert das nichts, und zwar nachweislich nichts: Die vier Seiten liefern eine HTML-Datei aus, in der keine einzige Angabe über den Shop und keine einzige über seine Kundschaft steht; eingesetzt werden allein die öffentliche App-Kennung, das Stylesheet, das Menü, die Fußzeile und die rechtlichen Hinweistexte, und alle fünf sind für jeden Händler dieselben. Es gibt auf ihnen kein Feld und keinen Knopf, und von sich aus rufen sie nichts über den Shop ab — das beschreibt den Stand jenes Vormittags; drei der vier Seiten haben ihre Bedienelemente noch am selben Tag bekommen: die Sendungsseite am Nachmittag, die Verpackungsseite am Abend und die Meldungsseite am späten Abend, jede in einem eigenen Absatz weiter unten. Bis zum 07.09.2026 nannte dieser Satz zwei Seiten und verwies auf „die beiden Absätze darunter"; ein Absatz über die Sendungsseite stand bis dahin in dieser Liste überhaupt nicht, der Verweis führte also ins Leere. Einen Abruf lösen sie trotzdem aus, und er steht hier, weil er sonst zwischen zwei Abschnitten dieses Vertrages verschwände: Wie jede eingebettete Seite dieser App laden sie die Bibliothek App Bridge aus dem Shopify-CDN; dieser Aufruf geht aus dem Browser des Händlers an Shopify und ist in § 6.4 beschrieben. Bis zum 06.09.2026 endete dieser Satz mit „und keinen Abruf"; absolut gelesen traf das nicht zu. Berührt ist Anlage 1 Abschnitt C: Die Zeile über Katalog und Regeln sagte an jenem Vormittag dazu, dass die Adresse besteht und die Bedienelemente fehlen — dieselbe Trennung, die dieser Vertrag seit dem 04.09.2026 zwischen dem Weg und dem Bildschirm zieht, eine Stufe weiter. Am Abend desselben Tages ist sie erneut geändert worden und beginnt seither mit „Für Katalog und Regeln seit dem 06.09.2026 vorhanden"; der Absatz über die Bedienelemente der Verpackungsseite verzeichnet das. Bis zum 07.09.2026 stand dieser Satz im Präsens und beschrieb damit einen Inhalt jener Zelle, der dort seit jenem Abend nicht mehr steht. Auch diese Änderung wird von derselben einen Hebung erfasst. Auch diese Änderungsnotiz steht in einem eigenen Absatz und ohne Fettdruck in der Aufzählung.

Am Nachmittag desselben Tages hat die Startseite ihre Kennzahlen bekommen: Sendungen und Kilogramm, die Mengen je Zielland und je Materialfraktion samt ihrer Paarung, der Verlauf der letzten zwölf Monate, die noch offenen Posten und die nächste Frist mit ihrer Quelle; bedienbar sind dort die Anforderung der Nacherfassung, die Wahl des Meldejahres und die drei Einrichtungspunkte. Der Gegenstand der Verarbeitung erweitert sich dadurch um keine Angabe: Es sind dieselben Bestände, die Anlage 1 Abschnitt A führt, in Summen über den Shop des Händlers; eine Angabe über seine Kundschaft steht auf keiner Karte. Berührt sind § 2.3 und Anlage 1 Abschnitt C, wo die Zeile über die Bedienseite der Nacherfassung seither die Karte „Sendungen nachladen" nennt. Diese Notiz ist am 07.09.2026 nachgetragen worden; bis dahin verzeichnete diese Liste die Startseite nicht, obwohl Anlage 1 Abschnitt C sie seit dem 06.09.2026 beschreibt. Auch diese Änderung wird von derselben einen Hebung erfasst. Auch diese Änderungsnotiz steht in einem eigenen Absatz und ohne Fettdruck in der Aufzählung.

Am selben Nachmittag hat die Sendungsseite ihre Bedienelemente bekommen: eine Filterzeile über Zeitraum, Lieferland, Zuordnungsquelle und den offenen Rest, darunter die Sendungen mit ihren Paketen und je Paket die Materialfraktionen mit Gewicht in Gramm, dazu zwei Knöpfe, mit denen der Händler mehreren Paketen zugleich eine Verpackung zuweist oder sie von Hand aus der Zählung nimmt. Der Gegenstand der Verarbeitung erweitert sich auch dadurch um keine Angabe: Es sind dieselben Bestände des Abschnitts A und dieselben pseudonymen Angaben — Ländercode, Kennungen aus Shopify, Bestellnummer, Zusteller —, die § 2.3 seit dem 03.09.2026 führt; Namen, Anschriften, E-Mail-Adressen und Telefonnummern stehen dort nicht, weil es für sie keine Spalte gibt. Berührt sind § 2.3 und Anlage 1 Abschnitt C. Auch diese Notiz ist am 07.09.2026 nachgetragen worden. Auch diese Änderung wird von derselben einen Hebung erfasst. Auch diese Änderungsnotiz steht in einem eigenen Absatz und ohne Fettdruck in der Aufzählung.

Am Abend desselben Tages hat die Verpackungsseite ihre Bedienelemente bekommen: zwei Reiter, unter denen der Händler seine Verpackungskomponenten anlegt, eine Verpackungseinheit zusammensetzt oder eine fertige aus der Bibliothek übernimmt, eine geänderte Stückliste als neue Version ab einem gewählten Tag speichert und seine Zuordnungsregeln anlegt, vorab ansieht und beendet. Der Gegenstand der Verarbeitung erweitert sich dadurch um keine Angabe: Es sind dieselben Bestände, die Anlage 1 Abschnitt A seit dem 03. und 04.09.2026 führt, und über dieselben Endpunkte, die seit dem 04.09.2026 bestehen. Berührt sind § 2.2, § 2.3, § 7.3, Anlage 1 Abschnitt A und Anlage 1 Abschnitt C; die Sätze über die Bedienung von Katalog und Regeln sind dort datiert berichtigt. Was dort weiterhin fehlt, ist das Ändern einer bereits angelegten Komponente und einer bestehenden Regel. Auch diese Änderung wird von derselben einen Hebung erfasst. Auch diese Änderungsnotiz steht in einem eigenen Absatz und ohne Fettdruck in der Aufzählung.

Später am Abend desselben Tages sind aus der Prüfung zu jener Aufgabe drei Bedienwege auf derselben Seite nachgezogen worden: die Maßeinheit einer Komponente (je Stück oder je laufendem Meter) als eigenes Feld, ein Wiege-Assistent, der aus mehreren Wiegungen des Händlers Mittelwert und Spanne ausrechnet und zurückgibt, und die Fassungen je Verpackungseinheit mit ihrer Gültigkeit. Der Gegenstand der Verarbeitung erweitert sich auch dadurch um keine Angabe: Die Wiegungen sind dieselben, die Anlage 1 Abschnitt A seit dem 03.09.2026 als Spalte wiegungen führt, und der Assistent legt nichts ab — er rechnet und antwortet. Berührt ist Anlage 1 Abschnitt C; die Sätze über die Bedienung des Katalogs sind dort datiert nachgezogen, und die Vorschauzeile nennt dort seither die angesehene Menge statt „zwölf Monate". Auch diese Änderung wird von derselben einen Hebung erfasst. Auch diese Änderungsnotiz steht in einem eigenen Absatz und ohne Fettdruck in der Aufzählung.

Am späten Abend desselben Tages haben die Meldungsseite und die Administration ihre Bedienelemente bekommen. Die Meldungsseite führt vier Reiter: „Exporte" (Meldezeitraum anlegen, Vorschau der Mengenzeilen, festschreiben, Nachtragsmeldung, LUCID-Meldedatei, Meldebogen und PPWR-Tabelle herunterladen), „Prognose" (Planmenge und Kostenschätzung), „Nachweise" (Nachweis und Länderübersicht) und „Zusatzmengen", der kein Bedienelement trägt und das sagt. Die Administration führt seither zusätzlich die Karten „Wie Kuno rechnet", „Zielsysteme je Land" und „Fristen". Der Gegenstand der Verarbeitung erweitert sich dadurch um eine einzige Angabe, und die stand schon vorher in Anlage 1 Abschnitt A: den Bestätigungstext, mit dem der Händler einen Meldezeitraum trotz unzugeordneter Pakete festschreibt — die Meldungsseite ist seit jenem Abend die Stelle, an der er ihn eintippt. Bis zum 07.09.2026 stand hier zusätzlich „es ist die einzige Freitextspalte des Schemas"; das traf schon damals nicht zu (Registrierungsnummer und Bestätigungskennzeichen aus Migration 0025 stehen unter keiner Formprüfung) und trifft seit der Migration 0026 noch weniger zu. Der berichtigte Satz steht in § 2.2. Alles Übrige sind dieselben Bestände des Abschnitts A und dieselben Summen. Berührt sind § 2.2, Anlage 1 Abschnitt A und Anlage 1 Abschnitt C, wo die Zeilen über die Bedienelemente für Meldung, Zielsysteme und Fristen datiert berichtigt sind. Diese Notiz ist am 07.09.2026 nachgetragen worden; bis dahin verzeichnete diese Liste weder die Meldungsseite noch die drei Karten, obwohl Anlage 1 Abschnitt A und Abschnitt C sie seit jenem Abend beschreiben. Auch diese Änderung wird von derselben einen Hebung erfasst. Auch diese Änderungsnotiz steht in einem eigenen Absatz und ohne Fettdruck in der Aufzählung.

In der Nacht darauf sind aus der Prüfung zu jener Aufgabe acht Befunde nachgezogen worden. Der Gegenstand der Verarbeitung erweitert sich auch dadurch um keine Angabe: Die Meldungsseite fragt seither vor der LUCID-Meldedatei und vor dem Meldebogen nach der Kennung des Systembetreibers — sie steht in der Datei, ist eine Registernummer des Betreibers und keine Angabe über den Händler oder seine Kundschaft, und sie wird nicht gespeichert. Berührt ist Anlage 1 Abschnitt C. Auch diese Notiz ist am 07.09.2026 nachgetragen worden. Auch diese Änderung wird von derselben einen Hebung erfasst. Auch diese Änderungsnotiz steht in einem eigenen Absatz und ohne Fettdruck in der Aufzählung.

Am 07.09.2026 ist ein Bestand dazugekommen, mit dem der Händler die Mengen festhält, die er außerhalb von Shopify verschickt hat: die Mengen aus anderen Kanälen (Migration 0026). Berührt sind § 2.2 — ein neuer Punkt in der Kurzform und die Berichtigung des Satzes über die einzige Freitextspalte — und Anlage 1 Abschnitt A, wo der Bestand spaltengenau aufgezählt und als frei von Angaben über die Kundschaft des Händlers eingeordnet ist; Beleg-Referenz und Notiz tragen denselben Vorbehalt wie der Bestätigungstext eines Meldezeitraums, weil sie freier Text sind. Auch diese Änderung wird von derselben einen Hebung erfasst; sie erweitert den Gegenstand der Verarbeitung um einen Bestand über die Vorgänge des Händlers und um keine einzige Angabe über eine Endkundin oder einen Endkunden. Bis zum Abend des 07.09.2026 endete dieser Absatz mit „Eine Adresse oder eine Bedienseite, über die der Händler ihn füllen könnte, gibt es an diesem Tag nicht"; die Adressen dorthin gibt es seit jenem Abend, und die Berichtigung steht im Absatz über die fünf Adressen für die Mengen aus anderen Kanälen. Der Reiter „Zusatzmengen" der Meldungsseite trägt weiterhin kein Bedienelement. Auch diese Änderungsnotiz steht in einem eigenen Absatz und ohne Fettdruck in der Aufzählung.

Am selben Tag ist der Programmteil um einen Leser für Tabellendateien erweitert worden: Er nimmt eine Datei mit denselben neun Angaben entgegen, die Anlage 1 Abschnitt A für diesen Bestand aufzählt, prüft jede Zeile einzeln und trägt sie erst auf ausdrückliche Anweisung ein; die Datei selbst wird nicht gespeichert, sondern nur für die Dauer der Prüfung gelesen. Berührt ist damit keine Stelle dieses Vertrages — es kommt weder eine Angabe noch ein Bestand hinzu. Bis zum Abend des 07.09.2026 endete dieser Absatz mit dem Satz, die Aussage in Anlage 1 Abschnitt A, „dass es an diesem Tag keine Adresse und keine Bedienseite in diesen Bestand gibt", trage unverändert, ein Händler könne eine solche Datei heute nicht übergeben; seit jenem Abend gibt es die Adresse, über die er genau das tut, und die Berichtigung steht im Absatz über die fünf Adressen für die Mengen aus anderen Kanälen. Diese Notiz steht hier, weil ein Leser dieser Liste sonst nicht erkennt, ob die Stelle geprüft und für nicht berührt befunden oder schlicht übersehen wurde. Auch diese Änderungsnotiz steht in einem eigenen Absatz und ohne Fettdruck in der Aufzählung.

Am Abend des 07.09.2026 sind die fünf Adressen dazugekommen, über die der Händler die Mengen aus anderen Kanälen führt: eine, die seine Posten auflistet, eine, die einen Posten anlegt, eine, die einen Posten löscht, eine, die eine Tabellendatei zuerst zur Ansicht prüft und sie erst auf ausdrückliche Anweisung einträgt, und eine, die ihm die leere Vorlage dieser Datei ausliefert. Alle fünf verlangen einen angemeldeten Händler-Nutzer dieses Shops; keine verlangt ein aktives Abonnement, weil ein eingetragener Posten eine Eingabe des Händlers ist und keine Leistung, die KYTH herstellt. Berührt sind § 2.2 — der Satz über den Weg in diesen Bestand — und Anlage 1 Abschnitt A an derselben Stelle. Der Gegenstand der Verarbeitung erweitert sich dadurch um keine einzige Angabe: Es sind dieselben neun Angaben, die Anlage 1 Abschnitt A seit dem Morgen desselben Tages aufzählt, und die Vorlagedatei enthält für jeden Shop dieselben Bytes und keinen Wert aus einem Bestand. Was weiterhin fehlt, ist die Bedienung: Der Reiter „Zusatzmengen" der Meldungsseite trägt kein Bedienelement und sagt das. Auch diese Änderung wird von derselben einen Hebung erfasst. Auch diese Änderungsnotiz steht in einem eigenen Absatz und ohne Fettdruck in der Aufzählung.

Ebenfalls am 07.09.2026 ist ein Bestand für die Verpackung je Produktvariante dazugekommen (Migration 0027): je Variante und Fassung die Shopify-Kennungen von Variante und Produkt, die Stückliste aus Verpackungskomponenten, die vom Händler ausgewählten Länder, eine Fassungsnummer und der Beginn der Gültigkeit. Berührt sind § 2.2 und Anlage 1 Abschnitt A, wo der Bestand spaltengenau aufgezählt und als frei von Angaben über die Kundschaft des Händlers eingeordnet ist. Der Gegenstand der Verarbeitung erweitert sich dadurch um keine Angabe über eine Endkundin oder einen Endkunden: Was hier steht, beschreibt ein Produkt des Händlers und keine Bestellung. Freien Text nehmen die beiden Kennungen und die Länderauswahl nicht auf; die Stückliste ist ein strukturiertes Feld, an dem das Schema nur die Form bindet, und der Vorbehalt dazu steht in Anlage 1 Abschnitt A. Auch diese Änderung wird von derselben einen Hebung erfasst. Geschrieben wird in den Bestand über einen eigenen Programmteil; seit dem Abend des 08.09.2026 führen drei Adressen der App dorthin — die Verpackung je Variante ansehen, eine Fassung speichern und alle Fassungen einer Variante zurücknehmen —, und die Produktseite trägt seit demselben Abend die Bedienelemente dazu: eine Liste der zuletzt versendeten Varianten mit dem Vermerk, ob eine Verpackung hinterlegt ist, die Zusammenstellung der Stückliste aus den eigenen Verpackungskomponenten, die Auswahl der Länder, in denen der Händler diese Verpackung mitzählt, und eine Abdeckungszahl über die versendeten Einheiten der letzten zwölf Monate. Die Länderauswahl bleibt eine Wahl des Händlers: Die Seite belegt kein Land vor, und eine leere Auswahl wird als leere Auswahl gespeichert. Am 08.09.2026 nachgezogen: Zur Auswahl stehen die Länder der letzten zwölf Monate und jedes Land, das an dieser Verpackung bereits angehakt ist. Bis zu jenem Tag entstanden die Kästchen allein aus den Lieferzielen des Fensters, und wer eine Stückliste änderte und speicherte, verlor damit jedes Land außerhalb — die Seite hätte dem Händler eine Auswahl genommen, die er selbst getroffen hatte, ohne es zu sagen. Bis zu jenem Abend stand hier „eine Adresse der App und einen Bildschirm dafür gibt es an diesem Tag nicht — die Produktseite trägt kein Bedienelement, und Anlage 1 Abschnitt C führt die fehlenden Bedienelemente weiterhin auf. Die fehlende Adresse führt allein Anlage 1 Abschnitt A: Abschnitt C spricht nach seinem eigenen Vorspann nicht von einem Bestand und nicht von einer Adresse, sondern von den Bedienelementen zweier Bildschirme."; keine der beiden Hälften trägt seither, und Anlage 1 Abschnitt C ist am selben Abend nachgezogen worden. Bis zum Vormittag des 08.09.2026 stand hier zusätzlich, Abschnitt C führe „beides" als nicht vorhanden, und beides — Adresse und Bildschirm — führte er nicht; ein Zustimmungstext, der sich an einer Stelle selbst falsch belegt, schickt jeden Leser ins Leere. Auch diese Änderungsnotiz steht in einem eigenen Absatz und ohne Fettdruck in der Aufzählung.

Am 08.09.2026 sind zwei Bestände dazugekommen, mit denen ein Händler mehrere Shops zu einer Rechtseinheit verbindet: die Einheit selbst mit Firmenname, Umsatzsteuer- Identifikationsnummer und LUCID-Nummer sowie die Verbindungscodes, von denen nur ein Prüfwert gespeichert wird. Nachgeführt sind dafür Anlage 1 Abschnitt A (zwei neue spaltengenaue Aufzählungen), § 2.2 — die Zahl der Textspalten ohne Formprüfung steht dort seit diesem Tag auf 42 statt 41, weil der Firmenname eine davon ist — und die Zeile zu shops in § 7.2, die seither den Verweis auf die Rechtseinheit mitnennt. Der Firmenname ist die erste Spalte des Schemas, in der ein Personenname nicht nur stehen KANN, sondern bei einem Einzelunternehmen die richtige Eingabe ist; dieser Vorbehalt steht in Anlage 1 Abschnitt A und in § 2.2. Auch diese Änderung wird von derselben einen Hebung erfasst. Geschrieben wird in beide Bestände über einen eigenen Programmteil; sechs Adressen der App führen seit demselben Tag dorthin — die Einheit ansehen, benennen und auflösen, einen Verbindungscode erzeugen, ihn einlösen und die eigene Verbindung lösen. Bis zum Abend des 08.09.2026 stand hier „eine Adresse der App und einen Bildschirm dafür gibt es an diesem Tag nicht"; die erste Hälfte trägt seit jenen Adressen nicht mehr. Der Bildschirm dagegen fehlt weiter: Die Administration führt eine Karte „Rechtseinheit" ohne ein einziges Bedienelement, und ohne Bildschirm bleibt dieser Weg für einen Händler unbedienbar. Auch diese Änderungsnotiz steht in einem eigenen Absatz und ohne Fettdruck in der Aufzählung.

Ebenfalls am 08.09.2026 ist ein Bestand dazugekommen, der Verpackungsdaten aus KYTH.Karl aufnehmen kann — der erste dieses Schemas, dessen Inhalt nicht von Shopify stammt. Nachgeführt sind dafür Anlage 1 Abschnitt A (eine neue spaltengenaue Aufzählung samt der Einordnung, dass dadurch kein weiterer Unterauftragsverarbeiter entsteht), § 6.4, das Karl seither ausdrücklich als Quelle und nicht als Empfänger führt, § 7.2, dessen Aufzählung der im Löschweg durchsuchten Bestände ihn seither mitnennt, und die Zeile zu shops in Anlage 2 Abschnitt 7.2, die den Zeitpunkt der Karl-Verbindung aufführt. Die Zahl der Textspalten ohne Formprüfung in § 2.2 bleibt bei 42: Beide Textspalten des neuen Bestandes stehen unter einem CHECK-Muster, die Nutzlast ist JSON und kein Text im Sinne jener Messung. Genau daraus folgt der Vorbehalt, den Anlage 1 Abschnitt A zu diesem Bestand mitführt: Die Nutzlast ist ein strukturiertes Feld, an dem das Schema nur die Form bindet, und die Zusage über Namen, Anschriften, E-Mail-Adressen und Telefonnummern ruht auf dem Vertrag kyth_packaging/1 und der Prüfung des Eingangs, nicht auf einer CHECK-Bedingung. Auch diese Änderung wird von derselben einen Hebung erfasst. In diesen Bestand konnte am Vormittag jenes Tages nichts gelangen: Die Adresse, unter der Karl eine Meldung abliefert, entstand erst am Abend desselben Tages — die Notiz dazu steht im Absatz über den Eingang aus KYTH.Karl —, und die Stelle, an der der Händler diese Übernahme anweist, kam am 09.09.2026 dazu; bis zu jenem Tag stand hier, sie fehle weiterhin. Bis zu jenem Abend stand hier zusätzlich der Satz, was noch offen sei, führe Anlage 2 Abschnitt 7.2 nicht als Lücke — es sei keine, solange nichts ankommen könne —, und sobald der Weg stehe, gehöre diese Stelle erneut angesehen. Angesehen worden ist sie am selben Abend, und sie bleibt unverändert: Der Empfang aus KYTH.Karl gehört nicht in jene Aufzählung. Bis zum 09.09.2026 lautete die Begründung dafür hier „keine offene Stelle mehr, sondern ein gebauter Weg" — und das war zu weit. Gemessen an jenem Tag: Der Programmteil, der die Zeile schreibt, ist ein Rumpf, der abbricht; ein vollständig vertragsgemäßer, richtig signierter Push wird mit „vorübergehender Fehler" abgewiesen und zur Wiederholung aufgefordert. Die Adresse stand also, ohne dass dahinter etwas verbucht wurde. Am 09.09.2026 ist auch das nicht mehr richtig: Seit dem Nachmittag jenes Tages schreibt der Programmteil dahinter die Sendung und ihre Pakete, und er tut es ausschließlich für einen Händler, der die Übernahme angewiesen hat — der Absatz „Was an diesem Tag besteht" weiter unten nennt beide Stücke mit ihrer Migration. Bis dahin schloss dieser Absatz mit „verbucht wird dahinter noch nichts". Der Empfang bleibt trotzdem aus jener Aufzählung heraus, aber aus einem anderen Grund: Die Aufzählung nennt offene Stellen, und diese ist geschlossen. Auch diese Änderungsnotiz steht in einem eigenen Absatz und ohne Fettdruck in der Aufzählung.

Am Nachmittag desselben Tages ist die Prüfung gebaut worden, die vor jenem Eingang steht — nicht der Eingang selbst. Nachgeführt sind dafür Anlage 2 Abschnitt 2.1, der seither nicht mehr nur die Meldungen von Shopify und den Sitzungsnachweis nennt, sondern als dritten eingehenden Weg die Meldungen aus KYTH.Karl mit ihrem eigenen Geheimnis, ihrem Zeitfenster und der Antwort „gibt es nicht", solange kein Geheimnis hinterlegt ist, und Anlage 2 Abschnitt 4, der die Prüfung dieses Geheimnisses beim Start beschreibt. Abschnitt 2.1 steht in der Aufzählung oben bereits; Abschnitt 4 kommt nicht hinzu, weil er keinen Vorbehalt trägt, sondern beschreibt, was das Programm tut. Bis zum Abend jenes Tages stand hier zusätzlich, die Sätze über die fehlende Adresse blieben unverändert richtig — gebaut sei die Tür und nicht die Adresse. Der Absatz über den Eingang aus KYTH.Karl hält fest, was seither gilt. Auch diese Änderungsnotiz steht in einem eigenen Absatz und ohne Fettdruck.

Am Abend desselben Tages ist der Eingang selbst entstanden: eine Adresse, an der Karl eine Meldung abliefert, mit Vertragsprüfung, Mandantenzuordnung und einer Quittung, die den Absender zur Wiederholung auffordert, wenn das Verbuchen scheitert. Damit ist der Empfang aus KYTH.Karl kein Platz im Schema mehr, sondern eine Adresse, die Karl anrufen kann. Bis zum 09.09.2026 schloss dieser Satz mit „verbucht wird dahinter noch nichts", und davor stand hier, es sei seither „ein Weg, über den Zeilen in diesen Bestand gelangen" — jene erste Fassung war eine Zusage über etwas, das es nicht gab. Beide Notizen bleiben stehen statt gelöscht zu werden: Es ist derselbe Fehler, den dieser Vertrag in Anlage 1 Abschnitt A für die Nutzlast eigens benennt — eine Zusage darf nicht weiter sein als ihre Begründung. Nachgeführt sind dafür Anlage 1 Abschnitt A, dessen Absatz über den heutigen Programmstand die Adresse seither nennt, und § 6.4. Was sich dadurch nicht ändert, ist der Bestand selbst: Es kommt kein anderes Feld an als die, die Anlage 1 Abschnitt A aufzählt, denn der Vertrag kyth_packaging/1 weist jeden Körper ab, der ein Feld trägt, das er nicht kennt.

Am Nachmittag des 09.09.2026 sind die beiden letzten Stücke dieses Weges entstanden, und sie gehören zusammen: die Verbuchung — aus einer eingegangenen Meldung werden die Sendung, ihre Pakete und deren Materialmengen — und die Weisung, ohne die sie nicht läuft. Die Migration 0033 legt dafür in der Shop-Zeile den Zeitpunkt ab, zu dem der Händler die Übernahme angeordnet hat; die Karte „Paketmeldungen aus KYTH.Karl" in der Administration setzt und widerruft ihn. Ohne diesen Zeitpunkt weist die Adresse jede Meldung ab und speichert nichts — auch keinen Eingangsbeleg. Bis zu jenem Nachmittag stand an dieser Stelle, ein Bedienelement, mit dem der Händler diese Übernahme anordnet oder abstellt, stehe weiterhin aus. Nachgeführt sind dafür Anlage 1 Abschnitt A (der Zeitpunkt der Weisung als eigene Angabe in der Shop-Zeile und der Absatz über den heutigen Programmstand) und § 3.2, dessen Nummer 3 die Karl-Weisung seither unter den Einstellungen aufzählt, die als Weisung gelten. Bis zum Abend des 09.09.2026 nannte diese Notiz zusätzlich Anlage 2 Abschnitt 7.2, aus dessen Aufzählung der offenen Stellen die fehlende Weisung damit herausfalle, und sie führte § 3.2 als bereits nachgeführt. Beides traf nicht zu: § 3.2 war an jenem Nachmittag unberührt geblieben, und in Anlage 2 Abschnitt 7.2 hat die fehlende Weisung nie gestanden — die einzige Karl-Zeile dort ist die zum fehlenden Zeilenschutz auf shops, und die bleibt. Eine Änderungsnotiz, die eine Nachführung behauptet, die nicht stattgefunden hat, ist der schwerere Fehler von beiden: Der nächste Leser hält den Paragrafen für aktuell und zieht ihn nicht nach. Ein Widerruf wirkt nach vorn: Er löscht nichts, was bereits verbucht ist — dafür gilt § 9 wie für jede andere Menge dieses Nachweises. Auch diese Änderung wird von derselben einen Hebung erfasst, und auch diese Änderungsnotiz steht in einem eigenen Absatz und ohne Fettdruck.

Am 11.09.2026 ist aus der einen Frage „ist ein Tarif gebucht?" eine zweite geworden: „reicht dieser Tarif für das, was hier angefragt wird?". Die App führt seither zwei Stufen, und der Tarifname aus dem Abonnementstand entscheidet zusammen mit dem Zeitpunkt der Karl-Verbindung, welche Auswertung oder Datei ein Händler bekommt; dazu liest dieselbe Prüfung aus dem Mengenkonto die Zahl der Lieferländer des Kalenderjahres und die Zahl der Pakete des betroffenen Monats. Die Stellen sind dieselben drei wie bisher — das Festschreiben eines Meldezeitraums, die Dateien um die LUCID-Meldedatei herum und die Planmenge —; neu ist, was dort geprüft wird. Nachgeführt sind dafür § 1.3 Nr. 4, der bis dahin sagte, KYTH lese „ausschließlich, ob ein aktives Abonnement besteht", und Anlage 1 Abschnitt A, Zeile „Abonnementstand des Shops", deren Zweckspalte bis dahin nur die Feststellung und die Anzeige nannte. Beide Sätze waren damit enger als die Verwendung — in einem Text, dem der Händler zustimmt. Wirksam wird der Unterschied für ihn erst mit den veröffentlichten Tarifen; auch diese Änderung wird von derselben einen Hebung erfasst. Auch diese Änderungsnotiz steht in einem eigenen Absatz und ohne Fettdruck in der Aufzählung.

Am 12.09.2026 ist der Mailweg des Händlers dazugekommen: Kuno soll ihm den Monatsreport, die Erinnerung an seine Fristen und sein Abschlusspaket über SEINEN Mailserver schicken, und dafür stehen an seiner Shop-Zeile seit diesem Tag der Mailserver, der Port, Benutzername und Passwort seines Postfachs, die Absender- und die Antwortadresse, der Schalter für den Monatsreport und zwei Stände der Tagesläufe. KYTH betreibt weiterhin kein Versandkonto für Händlerpost; ein Konto der Installation wäre ein weiterer Unterauftragsverarbeiter (§ 6.4), und genau deshalb gehört der Weg dem Händler. Nachgeführt sind dafür Anlage 1 Abschnitt A (eine neue spaltengenaue Zeile „Mailweg des Händlers"), § 2.2 — die Zahl der Textspalten ohne Formprüfung steht dort seit diesem Tag auf 45 statt 42, weil Mailserver, Absender- und Antwortadresse im Klartext stehen — und die Zeile zu shops in Anlage 2 Abschnitt 7.2, die den Mailweg seither mitnennt. Benutzername und Passwort sind verschlüsselt und stehen unter derselben Formatprüfung wie die Token; die Antwort der App trägt das Passwort nie zurück. Bis zum Nachmittag des 12.09.2026 stand hier „An diesem Tag geht über diesen Weg noch nichts hinaus: Die drei Mails sind nicht gebaut, und der Bestand ist bis dahin eine Einstellung und kein Versand.“ Das galt für wenige Stunden; der Absatz über Monatsreport und Fristen-Erinnerung sagt, was seither hinausgeht. Seinen Mailweg trägt der Händler über die Administration ein, Karte „Mailversand"; zwei Adressen der App führen dorthin. Auch diese Änderung wird von derselben einen Hebung erfasst. Auch diese Änderungsnotiz steht in einem eigenen Absatz und ohne Fettdruck in der Aufzählung.

Von dieser Nachführung ist die erste Hälfte noch am 12.09.2026 eingelöst. Bis dahin stand hier: „Nachzuführen, sobald das Versandprogramm gebaut ist: Anlage 1 Abschnitt A sagt zur Portliste heute ausdrücklich nur, welche drei Ports die Datenbank zulässt, und gibt keine Zusage über die Verschlüsselung der Verbindung — auf 587 und 2525 ist STARTTLS eine Aushandlung, die das Versandprogramm verlangen muss. Wer dieses Programm baut, erzwingt sie dort und schreibt die Zusage in jene Zeile, oder er benennt an derselben Stelle, dass sie ausbleibt.“ Gebaut ist es am selben Tag, es erzwingt die Aushandlung und bricht ohne sie ab; die Zusage steht seither in jener Zeile. Bis zum Nachmittag des 12.09.2026 endete dieser Absatz mit „Offen bleibt die zweite Hälfte: Die drei Mails selbst — Monatsreport, Fristen-Erinnerung, Abschlusspaket — gibt es an diesem Tag nicht, und Anlage 1 Abschnitt A sagt das dort ebenso.“ Noch am selben Tag sind ZWEI der drei gebaut worden: Der Monatsreport und die Fristen-Erinnerung gehen seither über den Mailserver des Händlers hinaus, einmal am Tag und nur, wenn es etwas zu melden gibt; zwei Stände an der Shop-Zeile halten fest, wie weit gemeldet wurde. Beide Mails nennen ausschließlich Zahlen, Ländercodes, Materialfraktionen und Termine — keinen Namen, keine Anschrift, keine Bestellnummer; Empfänger ist allein die nach § 2a Nr. 4 hinterlegte Kontaktadresse des Händlers. Bis zum späten Abend des 12.09.2026 endete dieser Absatz mit „Offen bleibt allein das Abschlusspaket bei der Deinstallation; Anlage 1 Abschnitt A sagt das dort ebenso.“ Noch am selben Tag ist auch die dritte Mail gebaut worden, und mit ihr die Tabelle abschlusspakete: Deinstalliert ein Händler Kuno, entsteht vor dem Leeren des Zugangstokens ein ZIP aus seinen eigenen Beständen — Katalog, Verpackungseinheiten, Meldezeiträume, Sendungsliste und, soweit vorhanden, die eingefrorenen Meldebögen und Nachweise —, und es geht anschließend über seinen eigenen Mailserver an seine Kontaktadresse. Der Grund für diese Reihenfolge ist § 9.1: shop/redact kommt 48 Stunden nach der Deinstallation und löscht jede Zeile, aus der das Paket entstehen könnte. Auch dieses Paket nennt keinen Namen, keine Anschrift und keine Bestellnummer — die Sendungsliste darin trägt Lieferland, Datum, Masse je Materialfraktion und die pseudonymen Kennungen von Bestellung und Versandvorgang. Nachgeführt sind dafür Anlage 1 Abschnitt A (eine neue Zeile „Abschlusspaket des Händlers") und die Zeile zu shops in Anlage 2 Abschnitt 7.2, die den Spiegel abschlusspaket_offen_seit seither mitnennt. Auch diese Änderung wird von derselben einen Hebung erfasst.

Am Abend des 12.09.2026 in zwei Punkten berichtigt. Erstens stand im Absatz darüber „höchstens einmal am Tag“. Diese Zusage gibt das Programm nicht: Die Anwendung läuft mit vier Arbeitern, jeder von ihnen hält seinen eigenen Tageslauf, und die beiden Stände werden erst nach dem Versand gesetzt — damit eine Mail, deren Versand scheitert, am nächsten Tag erneut versucht wird und nicht verschluckt ist. Treffen zwei Arbeiter im selben Augenblick auf denselben Shop, kann dieselbe Mail an einem Tag zweimal hinausgehen. Das ist der bewusst gewählte Preis dafür, dass keine ausfällt, und steht seither auch auf der Karte „Mailversand“ der Administration. Zweitens setzen beide Mails einen Tarif voraus, der sie trägt, und nicht nur der Monatsreport: Die Fristen-Erinnerung steht ebenso wenig im Umfang des Tarifs „Free“, und im Tarif „Free“ geht über diesen Weg deshalb nichts hinaus. Auch diese Berichtigung wird von derselben einen Hebung erfasst.

Unabhängig davon informiert KYTH den Händler über eine Änderung dieses Vertrages mindestens 30 Tage vor dem Wirksamwerden in Textform an die nach § 2a Nr. 4 hinterlegte Kontaktadresse. Widerspricht der Händler nicht innerhalb von 30 Tagen ab Zugang der Mitteilung in Textform, gilt die neue Fassung als angenommen; widerspricht er, kann jede Partei die Nutzung der App beenden — der Händler durch Deinstallation.

0.4 Veröffentlichung

Alle vier Texte liefert die App unter https://kuno.kyth.systems/rechtliches/ aus, ohne Anmeldung und aus derselben Quelle, aus der die Fassungskennung stammt. Unabhängig davon stellt KYTH sie auf Anfrage an datenschutz@kyth.systems bereit.

Der Auslieferungsriegel. Trägt ein Rechtstext noch eine offene Stelle, verweigert die App in der Produktivumgebung den Start, statt einen Entwurf wie einen fertigen Vertragstext auszuliefern. Eine Zustimmung zu einem Text, den der Zustimmende nicht lesen kann, ist unwirksam. Alle vier Texte sind vollständig; der Riegel bleibt als Mechanismus bestehen und greift wieder, sobald jemand eine neue Stelle öffnet.

§ 1 Gegenstand, Dauer, Art und Zweck der Verarbeitung

1.1 Gegenstand

KYTH stellt dem Händler die Shopify-App Kuno zur Verfügung. Kuno ist dafür bestimmt, aus den Sendungen des Händler-Shops Verpackungsmengen je Zielland und Materialfraktion zu ermitteln und als Datei bereitzustellen, damit der Händler seine Verpackungsmeldungen erstellen kann.

Was der abgebildete Quelltextstand davon wirklich verarbeitet: Kuno speichert die Shopdomain, die Zugangstoken, den Zustimmungsnachweis, den Abonnementstand und den Einrichtungsstand. Für die Sendungen des Shops bestehen seit dem 01.09.2026 drei Tabellen — die Sendung selbst, ihre Pakete und ihre Positionen; was sie aufnehmen, zählt Anlage 1 Abschnitt A auf. Diese Zeilen entstehen seit dem 02.09.2026 im laufenden Betrieb: Der Abgleich (§ 3.4) fragt die versendeten Bestellungen selbst ab — etwa alle 15 Minuten und einmal je Nacht, solange die App installiert ist. Seit dem 03.09.2026 kommt der zweite Weg dazu: Die Bestell- und Sendungsmeldungen sind in der App-Konfiguration eingeschaltet, und vier Routen nehmen sie entgegen (§ 3.4). Bis zum 03.09.2026 stand hier, sie seien „weiterhin in der App-Konfiguration ausgeschaltet". Der Auftrag für die Bestellhistorie ist seit demselben Tag gebaut (§ 3.4) und wird erst erteilt, wenn ein Auftrag in der Warteschlange steht; seit dem 03.09.2026 trägt Kuno einen solchen Auftrag auf Anforderung des Händlers dort ein (§ 3.4; gebaut ist die Schnittstelle, und seit dem 06.09.2026 steht auch die Bedienseite: Die Startseite der App führt die Karte „Sendungen nachladen“ mit einem Knopf, der genau diese Anforderung auslöst, und zeigt daneben den Stand des Laufs. Bis zum 06.09.2026 stand hier, die Bedienseite entstehe „mit dem Ausbau der Oberfläche“). Bis zum 03.09.2026 stand hier, einen Auftrag trage „heute keine Stelle des Programms dort ein". Bis zum 02.09.2026 stand hier nacheinander, der Auftrag werde „von keiner Stelle ausgelöst" — den Lauf, der ihn erteilt, gab es damals noch nicht — und danach „Eine Zeile steht darin heute nicht"; mit dem Abgleich trägt auch das nicht mehr. Seit dem 04.09.2026 rechnet Kuno aus diesen Zeilen die Mengen: Der Verpackungskatalog und die Zuordnungsregeln bestehen, die Endpunkte, über die der Händler sie füllt, ebenso, und der Zuordnungslauf schreibt je Paket und Materialfraktion eine berechnete Materialzeile. Seit dem 05.09.2026 kommt die Meldung dazu: vier weitere Bestände — Meldezeitraum, Mengen je Materialart, erzeugte Meldedateien und das Protokoll der Neuberechnungen — sowie die Fachschicht darüber und fünf Dateibauer. Angestoßen wird das vom Händler über neun Adressen der App (§ 1.3 Nr. 6, Anlage 1 Abschnitt C), und seit dem späten Abend des 06.09.2026 steht auch die Bedienseite dazu: Der Menüpunkt „Meldungen“ führt vier Reiter — unter „Exporte“ legt der Händler einen Meldezeitraum an, sieht seine Mengenzeilen als Vorschau, schreibt ihn fest und lädt LUCID-Meldedatei, Meldebogen oder PPWR-Tabelle herunter; daneben steht die Länderübersicht über ein Zeitfenster seiner Wahl. Unter „Prognose“ rechnet er die Planmenge fürs kommende Jahr und, mit selbst eingetragenen Sätzen, eine Kostenschätzung dazu; unter „Nachweise“ lädt er zu jedem festgeschriebenen Zeitraum das Nachweis-PDF. Der vierte Reiter „Zusatzmengen“ trägt bis heute kein Bedienelement: Er nennt den Bestand und sagt, dass sich dort nichts eintragen lässt. Der Weg dorthin dagegen steht — fünf Adressen der App führen seit dem Abend des 07.09.2026 in diesen Bestand (§ 1.3 Nr. 6, Anlage 1 Abschnitt C), und was auf ihnen eingetragen wird, rechnet Kuno seit dem 08.09.2026 in den Meldezeiträumen mit. Was fehlt, sind die Bedienelemente davor: Der Reiter trägt keines, und ohne sie bleibt dieser Weg für einen Händler unbedienbar. Bis zum Abend des 08.09.2026 endete dieser Satz mit „Er sagt, dass das manuelle Nachtragen von Mengen noch nicht gebaut ist“. Beide Hälften dieses Satzes trafen an jenem Abend nicht mehr: Der Schreibweg samt seinen fünf Adressen stand seit dem Vortag, und der Reiter selbst sagte seit dem 08.09.2026 etwas anderes. Ein Händler, der diesen Absatz las, trug seine Mengen aus anderen Kanälen deshalb nicht ein und meldete um deren Masse zu wenig. Auch diese Änderungsnotiz steht ohne Fettdruck im laufenden Absatz. Bis zum späten Abend des 06.09.2026 endete dieser Absatz mit „was fehlt, sind die Bedienseiten dazu“. Bis zum 06.09.2026 endete er mit dem Stand vom 03.09.2026 und verwies für alles Weitere pauschal auf Anlage 1 — obwohl § 2.2 und jene Anlage beides seit dem 04. und 05.09.2026 führen. Anlage 1 führt den heutigen Bestand abschließend auf; Abschnitt C derselben Anlage führt getrennt davon, was beantragt und nicht ausgeübt wird.

Kuno rechnet, es berät nicht. Was die App liefert, sind Berechnungen und Exportdateien. Ob eine Registrierung oder eine Meldung geschuldet ist, gegenüber welcher Stelle und mit welcher Frist, entscheidet der Händler; eine Rechtsdienstleistung erbringt KYTH nicht. Der Satz steht hier, weil er den Gegenstand des Auftrags begrenzt und nicht bloß eine Werbeaussage einschränkt.

Bis zum 05.09.2026 stand er in der Vorsichtsform: „Kuno soll rechnen, nicht beraten. Was die App liefern soll, sind Berechnungen und Exportdateien." Sie war richtig, solange es keinen Weg zu einem Bericht und zu einer Datei gab; seit jenem Tag gibt es ihn, und Anlage 1 Abschnitt C führt die Zeile „Berichte und Exportdateien" seither als abrufbar. Bis zum 01.09.2026 stand hier dafür das Präsens: „Kilo rechnet, es berät nicht. Die App erstellt Berechnungen und Exportdateien." Das war elf Zeilen unter dem Absatz, der denselben Zweck richtig mit „ist dafür bestimmt" beschreibt, und in einer Fassung, in der derselbe Abschnitt C dieselbe Zeile noch als nicht vorhanden führte. Eine Grenze, die eine Leistung voraussetzt, sagt sie zugleich zu — damals zu Unrecht, heute zu Recht.

1.2 Art der Verarbeitung

Erheben, Erfassen, Speichern, Verwenden, Abfragen, Verschlüsseln, Übermitteln an den in § 6 genannten Empfängerkreis, Löschen und Einschränken der Verarbeitung — jeweils im Umfang der Anlage 1.

1.3 Zweck der Verarbeitung

Ausschließlich:

1. Installation und Betrieb der App im Shop des Händlers: Zuordnung des Shops, Beschaffung und Erneuerung der Shopify-Zugangstoken, Authentifizierung von Aufrufen aus der eingebetteten Oberfläche.
2. Erfüllung der von Shopify vorgeschriebenen Datenschutz-Meldungen (Auskunft, Löschung einer Person, Löschung eines Shops).
3. Nachweis über Zugriffe auf geschützte Kundendaten (Zugriffsprotokoll für geschützte Kundendaten): Auflage aus der Shopify-Freigabe für geschützte Kundendaten und eigene Rechenschaftsfähigkeit nach Art. 5 Abs. 2 DSGVO. Art. 5 Abs. 2 DSGVO ist dabei der Zweck, nicht die Rechtsgrundlage; zur Rechtsgrundlage siehe Abschnitt 5.1 der Datenschutzerklärung.
4. Feststellung des Abonnementstands des Händler-Shops bei Shopify. Die Tarife verwaltet Shopify; KYTH liest, ob ein aktives Abonnement besteht und unter welchem Tarifnamen, und speichert diese Antwort zwischen. Bis zum 11.09.2026 stand hier „ausschließlich, ob ein aktives Abonnement besteht". Das traf ab jenem Tag nicht mehr zu: Seither entscheidet der Tarifname bei jeder Anfrage darüber, welche Auswertung oder Datei der Händler bekommt, und neben ihm wirkt der Zeitpunkt der Karl-Verbindung als zweites Merkmal — ein Shop, für den eine Meldung aus KYTH.Karl ohne Testlabel angekommen ist, bekommt den größeren Leistungsumfang, auch wenn sein Tarif der kostenlose ist. Bis zum 13.09.2026 genügte dafür jede angekommene Meldung, auch eine mit Testlabel. Dazu liest dieselbe Prüfung aus dem Mengenkonto des Shops, in wie viele Länder er in diesem Kalenderjahr geliefert hat und wie viele Pakete auf den Monat entfallen, in dem der angefragte Zeitraum endet. Gemessen wird beides nur für die Frage, ob die angefragte Datei herausgeht; geschrieben wird dabei nichts. Die Bezahlschranke ist seit dem 05.09.2026 wirklich aufgerufen, und seit dem 06.09.2026 an vier Stellen des Programms: am Festschreiben eines Meldezeitraums und an der Nachtragsmeldung, an vier der fünf Dateien (LUCID-Meldedatei, Meldebogen, Nachweis, PPWR-Tabelle) und an der Hochrechnung der Planmenge für das kommende Jahr. Frei bleiben die Länderübersicht, das Auflisten und Anlegen eines Meldezeitraums, das Abrufen der Methoden zur Planmenge, die Startseite, die Meldevorgaben und der Fristenkalender. Sie wird nie an der Erfassung der Mengen und nie an der Nacherfassung hängen, weil ein Mengenkonto mit Lücken nach einer Kündigung wertlos wäre. Bis zum 06.09.2026 stand hier, die Bezahlschranke sei „gebaut und heute an keiner Route aufgerufen"; das traf seit dem 05.09.2026 nicht mehr zu, und wer den Satz las, hielt den kostenpflichtigen Teil für offen.
5. Anzeige des Einrichtungsstands im Adminbereich: welche Schritte der Händler als erledigt bestätigt hat und welcher als Nächstes ansteht.
6. Ermittlung der Verpackungsmengen aus den Sendungen des Shops und deren Ausgabe als Bericht und als Exportdatei. Dieser Zweck ist der eigentliche Gegenstand der App. Zu ihm werden seit dem 02.09.2026 laufend Sendungsdaten erhoben und gespeichert: Der Abgleich fragt die versendeten Bestellungen ab und schreibt daraus die Zeilen des Mengenkontos (§ 1.1, § 2.1, § 3.4), seit dem 03.09.2026 zusätzlich die vier Routen, die Shopifys Meldungen entgegennehmen, und die Nacherfassung. Die Ausgabe der Mengen als Bericht und als Exportdatei gibt es seit dem 05.09.2026: Seit jenem Tag führt das Programm neun Adressen, über die der Händler einen Meldezeitraum anlegt, ihn festschreibt und daraus eine von fünf Dateien abholt (Anlage 1 Abschnitt C) — vier für den Meldezeitraum selbst und fünf für die fünf Dateien. Bis zum Abend des 05.09.2026 stand hier „acht Adressen"; acht ist die Zahl der verschiedenen Pfade, weil das Auflisten und das Anlegen sich denselben Pfad teilen, und dieser Vertrag zählt an jeder anderen Stelle Adressen und nicht Pfade — zwei Zahlen für denselben Bestand in einem Verzeichnis, dessen Zweck die abzählbare Vollständigkeit ist. Bis zu jenem Tag stand hier „Die Ausgabe der Mengen als Bericht und als Exportdatei ist noch nicht gebaut — die Erhebung für diesen Zweck ist es"; die zweite Hälfte trifft weiterhin zu, die erste seit jenem Tag nicht mehr. Die Berechnung gibt es seit dem 04.09.2026, und seit demselben Tag ruft sie die Zuordnung eines Pakets — der Programmteil, der entscheidet, welche Verpackung ein Paket bekam. Angestoßen wird diese Zuordnung seit dem Abend desselben Tages (19:56 Uhr) vom Zuordnungslauf, der mit der Anwendung startet und Pakete ohne Verpackungswahl aus der Datenbank holt, und seit dem 06.09.2026 zusätzlich vom Händler selbst: Die Sendungsseite der App führt seit jenem Tag zwei Knöpfe, mit denen er mehreren Paketen zugleich eine Verpackung zuweist oder sie von Hand aus der Zählung nimmt; beides rechnet die betroffenen Materialzeilen neu. Bis zu jenem Tag nannte dieser Satz nur den Zuordnungslauf; die Adressen für die Handzuweisung standen seit dem 04.09.2026 im Programm, eine Bedienseite dorthin nicht. Seither entstehen aus den Sendungen eines Shops laufend Materialzeilen, soweit der Katalog des Shops für ein Paket eine Verpackung hergibt — ohne Katalog und ohne Standardverpackung bleibt das Paket unzugeordnet, und für dieses Paket wird keine Materialzeile geschrieben. Bis zu jener Stunde stand hier „Diese Zuordnung selbst stößt im laufenden Betrieb heute keine Stelle des Programms und keine Bedienseite an"; das traf bis zu der Stunde zu, in der der Zuordnungslauf gebaut wurde. Bis zum Abend des 04.09.2026 stand hier „ausgelöst wird sie heute von keiner Stelle des Programms und von keiner Bedienseite"; das traf ab der Stunde nicht mehr zu, in der die Zuordnungskette gebaut wurde. Bis zu diesem Tag stand hier „Die Berechnung der Mengen und ihre Ausgabe als Bericht und Exportdatei sind noch nicht gebaut"; das traf ab dem Tag nur noch auf die Ausgabe zu, an dem der Rechenkern gebaut wurde. Bis zum 03.09.2026 stand hier, dieser Zweck sei „noch nicht gebaut; er steht hier, weil die dafür angeforderten Berechtigungen bereits erteilt werden (§ 2.3)". Das beschrieb den Stand vom 30.08.2026: Die Berechtigungen sind seit dem 02.09.2026 nicht mehr nur erteilt, sondern ausgeübt, und Nr. 6 ist die einzige der sieben Nummern, die die Bestell- und Sendungsdaten der Endkundschaft überhaupt abdeckt.
7. Betriebsdiagnose und Sicherheit in dem in Anlage 1 beschriebenen, sehr engen Umfang.

Eine Verarbeitung zu eigenen Zwecken von KYTH — insbesondere zu Werbung, Profiling, Weiterverkauf, Training von Modellen oder Auswertung über Händler hinweg — findet nicht statt.

1.4 Dauer

Die Verarbeitung beginnt mit der Zustimmung nach § 0 und dem darauf folgenden Verbinden der App. Der Vertrag läuft auf unbestimmte Zeit, solange die App installiert ist.

Der Vertrag endet, ohne dass es einer Kündigung bedarf, mit der Deinstallation der App. Für Daten, die zu diesem Zeitpunkt noch vorhanden sind, gelten die Pflichten dieses Vertrages bis zu deren Löschung nach § 9 fort.

Höchstdauer dieses Nachlaufens. Die in der Datenbank verbliebenen Daten werden spätestens 30 Tage nach der Deinstallation gelöscht — im Regelfall früher, nämlich mit der Meldung shop/redact, die Shopify regelmäßig 48 Stunden nach der Deinstallation sendet. Bleibt diese Meldung aus, greift der Aufräumlauf nach § 9.3 Nr. 1. Die Nachwirkung dieses Vertrages ist damit auf 30 Tage begrenzt, mit einer Einschränkung, die hier stehen muss, damit die Frist nicht mehr behauptet, als sie trägt: In den Sicherungen bestehen gelöschte Daten fort, bis die dortigen Fristen ablaufen (§ 9.3 Nr. 2).

§ 2 Art der personenbezogenen Daten und Kategorien betroffener Personen

2.1 Kategorien betroffener Personen

2.2 Art der Daten

Abschließend aufgeführt in Anlage 1. In Kurzform:

• Gespeichert werden zum Shop: die myshopify-Domain im Klartext, ein nicht umkehrbarer HMAC-Suchwert derselben Domain als Suchindex, der Shopify-Access-Token und der Shopify-Refresh-Token (beide verschlüsselt), die Kontaktadresse des Händlers (verschlüsselt), Zeitpunkt und Fassungskennung seiner Zustimmung samt deren Verlauf, der zuletzt bei Shopify gelesene Abonnementstand, der Einrichtungsstand, technische Zeitstempel und der Berechtigungsumfang. Dazu die Einträge im Zugriffsprotokoll für geschützte Kundendaten und die technischen Kennungen eingehender Meldungen.
• Angelegt und im laufenden Betrieb gefüllt: die drei Tabellen des Mengenkontos — die Sendung, ihre Pakete und ihre Positionen. Was sie aufnehmen können, zählt Anlage 1 Abschnitt A spaltengenau auf: das Lieferland als Zwei-Buchstaben-Code, die Empfängerart als eine von drei Kategorien, pseudonyme Kennungen von Shopify, Mengen, Gewichte und Zeitpunkte. Wie viele Zeilen dort stehen, hängt am Bestand des Shops und ist keine Zusage dieses Vertrages. Bis zum 03.09.2026 stand hier „Angelegt, heute ohne Zeile" — seit dem 02.09.2026 legt der Abgleich (§ 3.4) Zeilen an und seit dem 03.09.2026 zusätzlich die vier Routen, die Shopifys Meldungen entgegennehmen; § 1.1 desselben Vertrages sagte das an diesem Tag bereits.
• Angelegt und gefüllt, sobald ein Paket gerechnet wird: die berechneten Materialzeilen einer Sendung, seit dem 04.09.2026 im Datenbankschema. Sie halten je Paket und Materialfraktion ein Gewicht in Gramm fest — das Rechenergebnis, aus dem eine Jahresmenge entsteht. Der Rechenlauf, der sie erzeugt, steht seit dem 04.09.2026 im Programm, und seit demselben Tag ruft ihn die Zuordnung eines Pakets; angestoßen wird diese Zuordnung seit dem Abend desselben Tages (19:56 Uhr) vom Zuordnungslauf, der mit der Anwendung startet, und seit dem 06.09.2026 zusätzlich vom Händler selbst über die Sendungsseite der App (Abschnitt C, Zeile über die Bedienelemente). Wie viele Zeilen dort stehen, hängt damit am Bestand des Shops und an dem, was der Händler dort von Hand entscheidet, und ist keine Zusage dieses Vertrages. Bis zum 06.09.2026 nannte dieser Satz nur den Zuordnungslauf. Bis zu jener Stunde stand hier „angestoßen wird diese Zuordnung im laufenden Betrieb von keiner Stelle des Programms und von keiner Bedienseite" — richtig, solange die Kette gebaut war und niemand sie rief, und mit dem Start des Zuordnungslaufs überholt. Bis zum späten Abend des 04.09.2026 stand hier „ausgelöst wird er heute von keiner Stelle des Programms und von keiner Bedienseite" — an dem Tag richtig, an dem der Rechenkern allein gebaut wurde, und wenige Stunden später nicht mehr, weil die Zuordnungskette ihn ruft. Bis zum Abend desselben Tages stand hier „wie viele Zeilen dort stehen, hängt am Bestand des Shops und ist keine Zusage dieses Vertrages" — richtig in der Sache, und ohne den Vorbehalt las es sich wie eine laufende Verarbeitung. Bis zum Vormittag desselben Tages hieß dieser Punkt „Angelegt, ohne dass ein Programmteil hineinschreibt" und schloss mit „Der Rechenlauf, der sie erzeugt, kommt mit der Mengenermittlung; bis dahin beschreibt Anlage 1 Abschnitt A ihr Schema und nicht ihren Füllstand." Angefügt wurde auch die Betriebsart des Shops und was mit ihr zusammenhängt: die Regel für Nebenbestandteile, eine Standardverpackung, das Sitzland, die LUCID-Nummer, die Aufbewahrungsdauer und der Beginn der erfassten Historie — Angaben über den Händler und sein Unternehmen, nicht über seine Kundschaft.
• Angelegt, sobald der Händler seine Meldevorgaben einträgt: die Zielsysteme je Land (Ländercode, Systemcode, Registrierungsnummer beim System, Vertragsfrist, Meldeintervall) und der Fristenkalender (Ländercode, Bezeichnung, Datum, Quelle, Erledigungsvermerk, Bestätigungskennzeichen), seit dem 06.09.2026 im Datenbankschema (Migration 0025). Spaltengenau zählt sie Anlage 1 Abschnitt A auf. Es sind Angaben über den Händler und sein Unternehmen, nicht über seine Kundschaft: welches duale System er beauftragt hat und wann er etwas melden wollte. Geschrieben wird in beide über je einen eigenen Programmteil, und seit dem Abend des 06.09.2026 gibt es Adressen dorthin — der Bestand füllt sich damit wirklich. Bis zu jenem Abend stand hier, „eine Adresse und eine Bedienseite dorthin gibt es an diesem Tag nicht, und bis dahin bleibt der Bestand leer"; die Bedienelemente darauf stehen seit dem späten Abend desselben Tages — die Karten „Zielsysteme je Land" und „Fristen" der Administration, spaltengenau beschrieben in Anlage 1 Abschnitt A. Bis zum 07.09.2026 endete dieser Punkt mit „was weiterhin fehlt, sind allein die Bedienelemente darauf"; das traf seit jenem Abend nicht mehr zu, und Anlage 1 Abschnitt A desselben Vertrages sagte es bereits — zwei Stände desselben Sachverhalts in einem Zustimmungstext.
• Angelegt und gefüllt, sobald der Händler eine Meldung führt: die vier Bestände der Meldung, seit dem 05.09.2026 im Datenbankschema (Migration 0022) — der Meldezeitraum (Land, Zielsystem, Zeitraum, Meldeart, Codesatz, Status, Prüfsumme über die Eingangsdaten, zwei Zählwerte, Fassung und Zeitpunkte), seine Mengen je Materialart, die daraus erzeugten Meldedateien (nur Kanal, Prüfsumme und Zeitpunkte; die Bytes werden nicht gespeichert) und das Protokoll der Neuberechnungen. Spaltengenau zählt sie Anlage 1 Abschnitt A auf. Eine dieser Spalten ist freier Text des Händlers: der Bestätigungstext, mit dem er einen Meldezeitraum trotz unzugeordneter Pakete festschreibt. Trägt er dort den Namen einer natürlichen Person ein, steht diese Angabe in dieser Tabelle; das Datenbankschema kann das nicht verhindern. Bis zum 07.09.2026 stand hier „Es ist die einzige Freitextspalte des ganzen Schemas." Der Satz traf schon am Tag seines Schreibens nicht: Die Registrierungsnummer eines Zielsystems und das Bestätigungskennzeichen einer Frist (Migration 0025) stehen unter einer Längengrenze und unter keinem Muster, nehmen also ebenfalls jeden Satz an; seit dem 07.09.2026 kommen die Beleg-Referenz und die Notiz eines Postens aus einem anderen Kanal dazu (Migration 0026). Die erste Fassung dieser Berichtigung schloss am selben Tag mit „prüfte eine Spalte statt fünf" — auch diese Zahl war nicht gemessen, sondern aus den fünf Spalten abgeschrieben, die dieser Absatz selbst nennt. Gemessen wurde sie noch am 07.09.2026 gegen das Datenbankschema, mit der Zählweise des Prüfstands: Eine Textspalte ist frei, wenn kein CHECK ihre Form bindet — eine Längen- oder Leerstringgrenze bindet sie nicht, denn „Max Mustermann, Kunde" ist achtzig Zeichen lang und nicht leer. Danach stehen 45 Textspalten des Schemas unter keiner Formprüfung; einundzwanzig davon in den Tabellen, für die dieser Vertrag einen Personenweg ausdrücklich verneint, und der Bestätigungstext selbst ist nicht einmal eine eigene Spalte, sondern ein Feld in einem JSON-Objekt. Wer den ursprünglichen Satz las, um zu entscheiden, wo im Schema ein Personenname stehen KANN, prüfte damit eine Spalte statt fünfundvierzig. Welche Angabe in welcher davon steht, wer sie füllt und wie sie gelöscht wird, zählt Anlage 1 Abschnitt A einzeln auf; der Prüfstand hält die Zahl 45 gegen das Schema, damit sie mit der nächsten Migration nicht still veraltet. Bis zum 12.09.2026 standen hier „42 Textspalten" und „zweiundvierzig"; beide Zahlen waren am Tag ihrer Messung richtig und sind es seit der Migration 0035 nicht mehr — dazugekommen sind der Mailserver, die Absenderadresse und die Antwortadresse des Mailwegs, den der Händler selbst einträgt (Anlage 1 Abschnitt A, Zeile „Mailweg des Händlers"). Benutzername und Passwort desselben Mailwegs zählen nicht mit: Sie stehen verschlüsselt und unter einem CHECK-Muster. Die Zahl einundzwanzig bleibt, weil shops keine der Tabellen ist, für die dieser Vertrag einen Personenweg verneint. Bis zum 08.09.2026 standen hier „41 Textspalten" und „zwanzig davon"; beide Zahlen waren am Tag ihrer Messung richtig und sind es seit der Migration 0028 nicht mehr — dazugekommen ist der Firmenname der Rechtseinheit, und er ist die Spalte, bei der ein Personenname nicht nur hineinpasst, sondern die richtige Eingabe ist (Anlage 1 Abschnitt A, Zeile „Rechtseinheit mehrerer Shops"). Angaben über die Kundschaft des Händlers nimmt keiner der vier Bestände auf: Eine Meldung ist eine Summe über viele Sendungen. Bis zum 06.09.2026 fehlte dieser Punkt in der Kurzform, obwohl Anlage 1 Abschnitt A die vier Bestände seit dem 05.09.2026 spaltengenau führt und § 1.1 sowie Anlage 1 diese Kurzform als Übersicht in Bezug nehmen. Wer sie als Übersicht las — der Vertrag bietet sie genau dafür an —, übersah diese Bestandsklasse samt ihrem freien Textfeld und beurteilte seine Weisungslage und sein Löschinteresse an einer um vier Bestände zu kurzen Aufzählung. Bis zum 07.09.2026 stand hier „die Bestandsklasse mit dem einzigen Freitextfeld" — derselbe widerlegte Satz, acht Zeilen unter seiner eigenen Berichtigung, weil die Berichtigung an einer Stelle des Absatzes vorgenommen und an der anderen vergessen worden war.
• Angelegt, sobald der Händler Mengen aus anderen Kanälen einträgt: die Mengen aus anderen Kanälen (Kanalbezeichnung, Lieferland, Zeitraum, Materialfraktion, Masse in Kilogramm, Stückzahl, Beleg-Referenz, Notiz), seit dem 07.09.2026 im Datenbankschema (Migration 0026). Spaltengenau zählt sie Anlage 1 Abschnitt A auf. Es ist eine Angabe des Händlers über einen Kanal, den Kuno nicht sieht — Amazon, eBay, Ladenverkauf —, und keine Angabe über seine Kundschaft: Ein Posten ist eine Summe über einen fremden Kanal und gehört keiner einzelnen Bestellung. Kuno holt davon nichts ab. Beleg-Referenz und Notiz sind freier Text, den der Händler füllt; trägt er dort den Namen einer natürlichen Person ein, steht diese Angabe in dieser Tabelle. Geschrieben wird in den Bestand über einen eigenen Programmteil, und seit dem Abend des 07.09.2026 führen fünf Adressen dorthin — auflisten, anlegen, löschen, eine Tabellendatei zuerst zur Ansicht prüfen und dann eintragen, die leere Vorlage holen. Was fehlt, ist die Bedienung: Der Reiter „Zusatzmengen" der Meldungsseite trägt kein Bedienelement, und bis dahin bleibt der Bestand in aller Regel leer. Bis zum Abend des 07.09.2026 endete dieser Punkt mit „eine Adresse und eine Bedienseite dorthin gibt es an diesem Tag nicht"; die erste Hälfte traf ab jenem Abend nicht mehr zu. Bis in die Nacht des 07.09.2026 endete er außerdem mit „und bis dahin bleibt der Bestand leer" — also mit der unbedingten Form. Sie trug schon an dem Abend nicht mehr, an dem die fünf Adressen dazukamen: Zwei von ihnen schreiben, und wer einen angemeldeten Händler-Nutzer dieses Shops hat, legt darüber einen Posten an, ohne dass es den Reiter braucht. Anlage 1 Abschnitt A und die Datenschutzerklärung (5.1) sagten seit jenem Abend richtig „in aller Regel leer"; diese Kurzform ist als einzige der drei Stellen stehen geblieben und widersprach damit der eigenen Anlage 1 Abschnitt A.
• Angelegt, sobald der Händler die Verpackung seiner Produkte pflegt: die Verpackung je Produktvariante (Shopify-Kennung der Variante und des Produktes, Stückliste aus Verpackungskomponenten mit Menge, die vom Händler ausgewählten Länder, Fassungsnummer, Beginn der Gültigkeit), seit dem 07.09.2026 im Datenbankschema (Migration 0027). Spaltengenau zählt sie Anlage 1 Abschnitt A auf. Gemeint ist die Verpackung des Produktes — Glas, Deckel, Etikett —, nicht der Karton, in dem es verschickt wird; es sind Angaben über das Sortiment des Händlers und nicht über seine Kundschaft. In welchen Ländern er diese Verpackung in seiner Meldung führt, wählt er selbst aus, und KYTH beurteilt diese Wahl nicht (§ 1.3 Nr. 6). Freien Text nehmen die beiden Kennungen und die Länderauswahl nicht auf: Beide Kennungen stehen unter einem festen Muster, jedes Land unter genau zwei Großbuchstaben. Die Stückliste ist dagegen ein strukturiertes Feld, an dem das Schema nur die Form bindet — ein bis zwanzig Einträge —, nicht die Namen der Felder darin; der Vorbehalt dazu steht in Anlage 1 Abschnitt A und gilt hier ebenso. Bis zum 08.09.2026 sagte diese Kurzform „Freien Text nimmt dieser Bestand nicht auf" und begründete es allein mit den Kennungen und der Länderauswahl — über die Stückliste sagte sie nichts, und die Zusage war damit weiter als ihre Begründung. Geschrieben wird in den Bestand über einen eigenen Programmteil; seit dem Abend des 08.09.2026 führen drei Adressen der App dorthin, und die Produktseite trägt die Bedienelemente dazu (Anlage 1 Abschnitt C). Bis zu jenem Abend stand hier „eine Adresse der App und einen Bildschirm dafür gibt es an diesem Tag nicht — die Produktseite trägt kein Bedienelement".
• Nur flüchtig im Arbeitsspeicher berührt und nirgends abgelegt: der Sitzungsnachweis des eingeloggten Händler-Nutzers sowie Kundenkennung und E-Mail-Adresse aus den Datenschutz-Meldungen.
• Nicht gespeichert: Namen, Anschriften, E-Mail-Adressen, Telefonnummern und Zahlungsdaten der Kundschaft des Händlers. Für keines davon gibt es eine Spalte. Vom Inhalt einer Bestellung wird nur geführt, was Anlage 1 Abschnitt A aufzählt — Kennung, Artikelnummer, Menge, Gewicht und Schlagworte des Produkts —, kein Freitext und keine Nachricht aus der Bestellung.

2.3 Erteilte Berechtigungen und ihre Ausübung

Dieser Abschnitt trennt zwei Dinge, die leicht verwechselt werden: was KYTH darf und was KYTH tut.

Was der Händler erteilt. In der Shopify-App-Konfiguration sind drei Berechtigungen angefordert sowie der Zugriff auf die geschützte Kundendatenkategorie address. Bis zum 13.09.2026 waren es vier; die Zeile zu read_all_orders sagt, was sich geändert hat:

Keine Schreibberechtigung. write_orders und write_products sind ausdrücklich nicht angefordert; Kuno liest aus dem Shop und schreibt nichts hinein. Ebenso wenig angefordert ist read_customers.

Warum eine neue Zustimmung bevorsteht. Eine Änderung des Berechtigungsumfangs zwingt jeden Händler zu einer erneuten Zustimmung bei Shopify, und eine solche Änderung ist eingeplant: Sobald Shopify read_all_orders erteilt, trägt KYTH den Zugriff wieder in die App-Konfiguration ein, und Shopify verlangt daraufhin von jedem installierten Shop eine erneute Zustimmung. Über die Erteilung entscheidet Shopify, über den Tag dieses Eintrags KYTH. Was von den angeforderten Berechtigungen heute ausgeübt wird, sagt die rechte Spalte.

Am 13.09.2026 berichtigt: Hier stand „Sie einmal vollständig anzufordern stört den Händler seltener" — eine Zusage, er werde nicht noch einmal gefragt. Sie trägt nicht mehr, seit read_all_orders an jenem Tag aus der App-Konfiguration genommen ist. Am selben Tag ist ein zweiter Satz gefallen: „Ob und wann das geschieht, entscheidet Shopify" — über die Erteilung ja, über den Tag des Eintrags nicht.

Was der Prüfstand daran hält, ist die Aufzählung und nicht die rechte Spalte. Ob die rechte Spalte zutrifft, misst kein Test — sie ist erhoben und gelesen, nicht gemessen.

Am 13.09.2026 gestrichen: Hier stand, wie viele Prüfungen an dieser Aufzählung hängen und was jede einzelne von ihnen fängt — zuletzt „Drei Prüfungen laufen mit … die dritte, wenn er eine ausbleibende zweite Zustimmung zusagt oder das anstehende Re-Consent verschweigt". Das leistet sie nicht. Ein Vertrag, der eine Prüfung verspricht, die es nicht gibt, ist schlechter als einer, der nichts verspricht; dieselbe Rücknahme haben § 7.2 und Anlage 1 Abschnitt C schon hinter sich. Bis zum 01.09.2026 stand hier, ein Wächter halte die rechte Spalte gegen die App-Konfiguration.

Drei Herkünfte, und sie sind auseinanderzuhalten. Personenbezogene Daten erreichen Kuno auf drei Wegen, und jeder hat eine andere Folge:

1. Aus dem Shop des Händlers — über die Sendungs- und Bestellmeldungen bzw. über eine Nacherfassung. Die beiden Wege stehen unterschiedlich weit: Der Weg der Nacherfassung ist seit dem 02.09.2026 gebaut — der Lauf für die Bestellhistorie erteilt den Auftrag bei Shopify, holt die Ergebnisdatei ab und schreibt die Sendungen fort; beschritten wird er aber erst, wenn ein Auftrag in der Warteschlange steht — und einen solchen Auftrag trägt Kuno seit dem 03.09.2026 auf Anforderung des Händlers dort ein (§ 3.4, § 6.5; gebaut ist die Schnittstelle, und seit dem 06.09.2026 steht auch die Bedienseite: Die Startseite der App führt die Karte „Sendungen nachladen“ mit einem Knopf, der genau diese Anforderung auslöst, und zeigt daneben den Stand des Laufs. Bis zum 06.09.2026 stand hier, die Bedienseite entstehe „mit dem Ausbau der Oberfläche“). Bis zum 03.09.2026 stand hier, einen trage „heute keine Stelle des Programms dort ein". Die laufende Entgegennahme aus dem Shop besteht seit dem 03.09.2026: Vier Routen nehmen die Meldungen von Shopify entgegen — die Sendungsmeldung (angelegt und geändert), den Storno einer Bestellung, die Erstattung und die Fertigmeldung einer Sammelabfrage. Was dabei ankommt, zählt Anlage 1 Abschnitt A auf; Namen, Anschriften, E-Mail-Adressen und Telefonnummern werden aus der Meldung nicht übernommen, aus der Lieferadresse ausschließlich der Ländercode. Sobald auf einem der beiden Wege Daten ankommen, sind sie Gegenstand der Auftragsverarbeitung, und der Händler ist Verantwortlicher. Bis zum 02.09.2026 stand hier für beide Wege zusammen „Dieser Weg ist noch nicht gebaut"; für die Nacherfassung trifft das seit diesem Tag nicht mehr zu, und derselbe Vertrag sagte an vier anderen Stellen bereits das Gegenteil. Bis zum 03.09.2026 stand hier für die Entgegennahme „Es gibt keine Route und keine Meldung, die eine Sendung entgegennähme"; seit diesem Tag gibt es beides.
2. Aus der Eingabe des Händlers in der App — heute die Kontaktadresse im Zustimmungsschritt. Dafür ist KYTH Verantwortlicher, nicht Auftragsverarbeiter (siehe Abschnitt 5 der Datenschutzerklärung).
3. Aus dem signierten Sitzungsnachweis des angemeldeten Nutzers — flüchtig, siehe Anlage 1 Abschnitt B.

Wenn sich das ändert. Vor jeder Erweiterung, die den Kreis der verarbeiteten Daten verändert, sind Anlage 1 und Anlage 2 neu zu erheben, dieser Vertrag ist in neuer Fassung vorzulegen und die Fassungskennung zu erhöhen — der Händler wird dann erneut um Zustimmung gebeten (§ 0.3, § 11 Nr. 6).

Einmal ist das nicht in dieser Reihenfolge geschehen, und es steht im Kopf dieses Vertrages. Die drei Tabellen des Mengenkontos sind am 01.09.2026 angelegt worden, bevor die Fassungskennung gehoben war. Anlage 1 und Anlage 2 sind am selben Tag nachgezogen; die Hebung ist am 13.09.2026 geschehen und fiel damit vor die erste Installation in einem fremden Shop. Bis zum 12.09.2026 stand hier, sie folge, sobald der laufende Ausbau abgeschlossen sei. Der Absatz steht hier, weil eine Zusage, die schon einmal nicht eingehalten wurde, nicht unverändert stehen bleiben soll.

2.4 Besondere Datenkategorien

Daten besonderer Kategorien nach Art. 9 DSGVO und Daten nach Art. 10 DSGVO sind nicht Gegenstand der Verarbeitung. KYTH wird sie auch künftig nicht anfordern.

§ 2a Pflichten und Rechte des Verantwortlichen

Art. 28 Abs. 3 Satz 1 DSGVO verlangt, dass ein Auftragsverarbeitungsvertrag auch die Pflichten und Rechte des Verantwortlichen festlegt. Das geschieht hier.

1. Rechtmäßigkeit der Verarbeitung. Der Händler ist allein dafür verantwortlich, dass die von ihm angewiesene Verarbeitung rechtmäßig ist und dass eine Rechtsgrundlage nach Art. 6 DSGVO vorliegt. Er entscheidet über Zwecke und Mittel. KYTH prüft die Rechtsgrundlage nicht und kann sie nicht prüfen.
2. Informationspflichten. Die Informationspflichten nach Art. 13 und Art. 14 DSGVO gegenüber der Kundschaft des Händlers treffen den Händler. Er nimmt Kuno in seine eigene Datenschutzerklärung auf; die Angaben dafür stehen in Anlage 1.
3. Weisungen. Der Händler ist berechtigt und verpflichtet, Weisungen nach § 3 zu erteilen; seine Weisungen müssen rechtmäßig sein. Er benennt KYTH die Personen, die für ihn weisungsberechtigt sind, und hält diese Angabe aktuell. Benennt er niemanden, gelten die vertretungsberechtigten Organe des Händlers als weisungsberechtigt.
4. Kontaktadresse. Der Händler gibt beim Zustimmungsschritt nach § 0 eine E-Mail-Adresse an, unter der KYTH ihn erreichen kann. Die Angabe ist Pflicht; ohne sie wird die App nicht verbunden. An diese Adresse gehen die Mitteilungen nach § 0.3, § 6.6 und § 8.2 — und seit dem 12.09.2026 außerdem jede Post, die die App selbst verschickt: der Monatsreport, die Fristen-Erinnerung und das Abschlusspaket nach § 9.2. Bis zum 12.09.2026 endete die Aufzählung nach § 8.2, und die drei Zustellungen gingen an jenem Tag bereits an dieselbe Adresse. Der Unterschied bleibt: Die drei Mitteilungen dieses Vertrages schreibt KYTH über ihr eigenes Postfach, die drei Zustellungen der App gehen über den Mailserver des Händlers hinaus (§ 6.5, letzter Absatz). Am späten Abend des 12.09.2026 berichtigt: Hier stand „Der Unterschied bleibt und steht in § 6.5". Jener Paragraph trägt nur die zweite Hälfte — „Server, Zugangsdaten und Absenderadresse gehören dem Händler" —; über das eigene Postfach von KYTH steht dort kein Wort. In einem Vertrag, der seine Belege sonst verzeigert, war das ein Verweis, der nur zur Hälfte trägt. Der Händler hält die Adresse aktuell und teilt eine Änderung in Textform an datenschutz@kyth.systems mit. In der App lässt sie sich beim Zustimmungsschritt ändern: Steigt die Fassung dieser Texte, fragt Kuno erneut und zeigt dabei die hinterlegte Adresse zur Bearbeitung an; einen eigenen Bildschirm dafür gibt es nicht. Wird die Adresse unzustellbar, kann KYTH den Händler nicht mehr unmittelbar erreichen — auch nicht bei einer Verletzung des Schutzes personenbezogener Daten, für deren Meldung dem Händler nach Art. 33 Abs. 1 DSGVO nur 72 Stunden bleiben. Die Aktualität liegt deshalb in seinem eigenen Interesse.
5. Nachweise und Prüfungen. Der Händler hat die Rechte auf Nachweise und Überprüfungen nach § 10.
6. Meldung von Datenpannen. Die Meldung einer Verletzung des Schutzes personenbezogener Daten an die Aufsichtsbehörde (Art. 33 DSGVO) und die Benachrichtigung der betroffenen Personen (Art. 34 DSGVO) obliegen dem Händler. KYTH unterstützt ihn dabei nach § 8.2.
7. Eigene Kontrolle. Der Händler überzeugt sich vor Beginn der Verarbeitung und danach regelmäßig von den technischen und organisatorischen Maßnahmen nach Anlage 2. Anlage 2 benennt in Abschnitt 7 ausdrücklich die bekannten Lücken.
8. Richtigkeit der eigenen Angaben. Der Händler verantwortet, dass die Angaben, mit denen Kuno rechnen wird, zutreffen — insbesondere Verpackungen, Materialien und Gewichte. KYTH kann sie nicht prüfen, und ein falsches Gewicht ergibt eine falsche Menge, ohne dass irgendetwas fehlschlägt. Eintragen kann der Händler seit dem 04.09.2026: Die drei Tabellen des Verpackungskatalogs bestehen seit dem 03.09.2026 (Anlage 1 Abschnitt A), die Fachschicht dazu und die Endpunkte, über die der Händler sie füllt, seit dem 04.09.2026 (§ 2.3). Bedienen kann er sie seit dem Abend des 06.09.2026: Die Verpackungsseite der App führt seither die Reiter „Katalog" und „Regeln" mit den Feldern und Knöpfen dazu (Anlage 1 Abschnitt C). Was dort fehlt, ist das Ändern einer bereits angelegten Komponente und einer bestehenden Regel; beides legt der Händler heute neu an. Bis zum Abend jenes Tages stand hier „Was fehlt, sind die Bedienelemente dazu — eine Aussage über die Bedienung eines Bildschirms, den es seit dem 06.09.2026 gibt, und nicht mehr über einen Weg". Bis zu jenem Tag stand hier „gerechnet wird noch nicht. Eintragen kann der Händler heute ebenfalls nichts … eine Bedienseite dafür gibt es nicht"; die erste Hälfte trug seit dem Bau des Rechenkerns nicht mehr, die zweite seit dem Bau der Endpunkte. Bis zum 01.09.2026 hieß es hier „mit denen Kilo rechnet". Bis zum 03.09.2026 stand hier stattdessen, es gebe „einen Verpackungskatalog, in dem sich etwas hinterlegen ließe", nicht — das sagte über das Datenbankschema mehr, als seit der Migration 0018 zutrifft.

Zum Umgang mit der Kontaktadresse. KYTH speichert sie verschlüsselt, verwendet sie ausschließlich für die in Nummer 4 genannten Anlässe — die drei Mitteilungen dieses Vertrages und die drei Zustellungen der App — sowie für die Weiterleitung von Anfragen betroffener Personen nach § 7.1, gibt sie nicht weiter und wirbt darüber nicht. Sie wird mit der Shop-Zeile gelöscht (§ 9).

Am späten Abend des 12.09.2026 berichtigt. Die Weiterleitung nach § 7.1 stand für wenige Stunden INNERHALB des Einschubs, also unter den „in Nummer 4 genannten" Anlässen. Nummer 4 zählt § 0.3, § 6.6, § 8.2 und die drei Zustellungen der App auf und nennt § 7.1 nicht; eine Zweckbindung, die das Wort „ausschließlich" führt, darf sich nicht auf eine Aufzählung berufen, in der einer der aufgezählten Zwecke fehlt. Der Stand davor hatte beides sauber getrennt.

Bis zum 12.09.2026 lautete er „KYTH speichert sie verschlüsselt, verwendet sie ausschließlich für die in Nummer 4 genannten Mitteilungen und für die Weiterleitung von Anfragen betroffener Personen nach § 7.1, gibt sie nicht weiter und wirbt darüber nicht." Das war unvollständig: Der Monatsreport, die Fristen-Erinnerung und das Abschlusspaket gingen an jenem Tag bereits an dieselbe Adresse, und im Anhang des Abschlusspakets liegen Katalog, Verpackungseinheiten, Meldezeiträume, Sendungsliste und — soweit vorhanden — die eingefrorenen Meldebögen und Nachweise. Am späten Abend des 12.09.2026 berichtigt: Hier stand, das Abschlusspaket trage „eine vollständige Kopie des Mengenkontos" — unbedingt, und § 9.2 desselben Vertrages sagt zur selben Sache „Das Abschlusspaket ist ein Ausschnitt". Das Paket muss in einen Mailanhang passen; was nicht hineinpasst, bleibt draußen und wird in einer Textdatei im Paket beim Namen genannt, und bei einem großen Mengenkonto trifft das zuerst die Sendungsliste. Eine Zweckbindung, die das Wort „ausschließlich" führt und drei Verwendungen ausspart, ist in einem Text, dem der Händler zustimmt, die schlechteste Art von Zusage.

§ 3 Verarbeitung nur auf dokumentierte Weisung

3.1 Grundsatz

KYTH verarbeitet personenbezogene Daten ausschließlich auf dokumentierte Weisung des Händlers. Das gilt auch für die Übermittlung in ein Drittland.

3.2 Was als Weisung gilt

Weisungen sind:

1. dieser Vertrag einschließlich seiner Anlagen — er ist die Grunderklärung der Weisungen; die Zustimmung nach § 0 ist die Erteilung dieser Grunderklärung,
2. die Installation der App und die Erteilung der Berechtigungen im Shopify-Adminbereich,
3. Einstellungen, die der Händler in der App vornimmt. Zum abgebildeten Quelltextstand sind das die Kontaktadresse im Zustimmungsschritt und die Bestätigung einzelner Einrichtungsschritte; beides wirkt allein auf Daten des Händlers und auf keine Daten seiner Kundschaft. Mit dem Verpackungskatalog und den Zuordnungsregeln kommt eine dauerhaft wirkende Einstellung hinzu, die den Inhalt jeder späteren Berechnung bestimmt — sie ist dann die Weisung, nach der gerechnet wird. Seit dem 09.09.2026 gehört die Übernahme der Paketmeldungen aus KYTH.Karl dazu, und sie ist die einzige dieser Einstellungen, von der eine ganze Verarbeitung abhängt: Der Händler ordnet sie auf der Karte „Paketmeldungen aus KYTH.Karl“ in der Administration an, die App legt den Zeitpunkt in seiner Shop-Zeile ab (Migration 0033, Anlage 1 Abschnitt A), und ohne diesen Zeitpunkt weist sie jede Meldung aus Karl ab und speichert nichts daraus — auch keinen Eingangsbeleg. Der Zeitpunkt ist der Beleg dieser Weisung; ein Widerruf leert das Feld und wirkt nach vorn. Bis zu jenem Tag zählte diese Nummer die Karl-Weisung nicht auf, obwohl Anlage 1 Abschnitt A, der Absatz „Was an diesem Tag besteht“ und der Kasten am Ende jenes Abschnitts sie alle als die Weisung nach § 3.2 führen; wer hier nachschlug, welche Einstellung als Weisung gilt, fand ausgerechnet die eine nicht, von der die Verarbeitung der Karl-Daten abhängt,
4. Einzelweisungen in Textform an datenschutz@kyth.systems.

Mündlich erteilte Weisungen bestätigt der Händler unverzüglich in Textform. KYTH dokumentiert Einzelweisungen und bewahrt sie für die Dauer des Vertrages auf.

3.3 Grenzen der Weisung

KYTH informiert den Händler unverzüglich, wenn eine Weisung nach Auffassung von KYTH gegen die DSGVO oder gegen andere Datenschutzvorschriften verstößt. KYTH darf die Ausführung einer solchen Weisung aussetzen, bis der Händler sie bestätigt oder ändert.

Ist KYTH gesetzlich zu einer Verarbeitung verpflichtet, teilt KYTH dem Händler die rechtliche Anforderung vor der Verarbeitung mit, sofern das Gesetz die Mitteilung nicht wegen eines wichtigen öffentlichen Interesses verbietet.

3.4 Verarbeitungsort und Drittlandtransfer

Die Verarbeitung durch KYTH selbst findet in Deutschland statt: Anwendung und Datenbank laufen auf einem einzigen virtuellen Server bei der IONOS SE am Standort Berlin. Die täglichen Datenbanksicherungen liegen im Objektspeicher der IONOS in der Region eu-central-3, ebenfalls Berlin. Es gibt keine weitere Verarbeitungsumgebung, insbesondere keine getrennte Testumgebung mit Händlerdaten. Der Objektspeicher begründet keinen Drittlandbezug.

Übermittlungen an Stellen außerhalb von KYTH ergeben sich ausschließlich aus dem in § 6 genannten Kreis:

• Shopify: Kuno ruft ausgehend drei Endpunkte bei Shopify auf. Bis zum 12.09.2026 nannte dieser Punkt sie „fremde Endpunkte“ — ohne die Einschränkung auf Shopify, und seit dem 12.09.2026 gibt es einen vierten ausgehenden Weg, der nicht zu Shopify führt (eigener Punkt weiter unten, § 6.5). Zwei davon liegen beim Händler-Shop selbst: der Token-Endpunkt (https://{shop-domain}/admin/oauth/access_token) und die Admin-API (https://{shop-domain}/admin/api/{version}/graphql.json). Übertragen werden dabei die Zugangsdaten der App und der jeweilige Token. Der dritte liegt nicht beim Händler-Shop: die Ergebnisablage, auf der Shopify die Datei einer Sammelabfrage unter einer signierten Adresse bereitstellt (§ 6.5). Bis zum 02.09.2026 kannte dieser Absatz nur die beiden Endpunkte beim Händler-Shop; der Abruf der Ergebnisdatei war an diesem Tag gebaut und hatte keinen Aufrufer. Über die Admin-API laufen sechs verschiedene Aufrufe, und keiner von ihnen trägt eine Angabe über eine Person (bis zum 03.09.2026 waren es fünf; der sechste, die Abfrage einer einzelnen Bestellung, steht seit dem 03.09.2026 im Programm):

Welche Felder der Auftrag anfordert: Bestell- und Sendungskennungen, Bestellnummer, Storno- und Testkennzeichen, Versandzeitpunkt, das Lieferland als Zwei-Buchstaben-Code, die Versandzeile, Standort, Versandart und Zusteller sowie je Position Artikelnummer, Menge, Gewicht, Versandpflicht, Varianten- und Produktkennung. Namen, Anschriften, E-Mail-Adressen und Telefonnummern fordert er nicht an; aus der Lieferadresse nennt er als einziges Feld den Ländercode.

Bis zum 02.09.2026 stand hier, Bestell-, Sendungs- und Kundendaten würden über die Admin-API nicht abgefragt, und danach, das gelte „nur noch, solange den Auftrag niemand erteilt". Für Kundendaten gilt es unverändert: Name, Anschrift, E-Mail-Adresse und Telefonnummer fordert kein Aufruf an. Für Bestell- und Sendungsdaten gilt es seit dem 02.09.2026 nicht mehr — der Abgleich fragt sie regelmäßig ab, ohne dass jemand ihn anfordert. Für den Auftrag für die Bestellhistorie gilt es seit dem 03.09.2026 ebenfalls nicht mehr: Er wird zwar weiterhin erst erteilt, wenn ein Auftrag in der Warteschlange steht — einen solchen Auftrag legt Kuno seither aber auf Anforderung des Händlers an (gebaut ist die Schnittstelle, und seit dem 06.09.2026 steht auch die Bedienseite: Die Startseite der App führt die Karte „Sendungen nachladen“ mit einem Knopf, der genau diese Anforderung auslöst, und zeigt daneben den Stand des Laufs. Bis zum 06.09.2026 stand hier, die Bedienseite entstehe „mit dem Ausbau der Oberfläche“). Bis zum 03.09.2026 stand hier, es bleibe dabei, weil einen Auftrag „heute keine Stelle des Programms dort ein" trage, und dieser Absatz sei „mit der ersten Anforderung erneut nachzuziehen" — das ist an diesem Tag geschehen. Shopify ist zugleich die Plattform, auf der der Shop des Händlers ohnehin betrieben wird; der Händler unterhält hierzu ein eigenes Vertragsverhältnis mit Shopify. Vertragspartnerin für Händler im Europäischen Wirtschaftsraum ist regelmäßig die Shopify International Ltd. mit Sitz in Irland; eine Verarbeitung durch verbundene Unternehmen außerhalb des EWR, insbesondere die Shopify Inc. in Kanada, ist nicht ausgeschlossen.

Weisung. Mit Abschluss dieses Vertrages weist der Händler KYTH an, den Token-Endpunkt und die Admin-API seines eigenen Shops bei Shopify aufzurufen und die eingehenden Meldungen von Shopify entgegenzunehmen, auch soweit dabei eine Übermittlung an Shopify-Stellen außerhalb des EWR stattfindet (Art. 28 Abs. 3 lit. a DSGVO). Ohne diesen Datenfluss lässt sich die App nicht betreiben.

Kanada. Für Kanada besteht ein Angemessenheitsbeschluss der Europäischen Kommission (Entscheidung 2002/2/EG) für privatwirtschaftliche Organisationen, die dem kanadischen Datenschutzgesetz PIPEDA unterliegen.

Übrige Drittländer, insbesondere die USA: Standardvertragsklauseln. Shopify bezieht in sein Data Processing Addendum die EU-Standardvertragsklauseln ein — die Klauseln aus dem Durchführungsbeschluss (EU) 2021/914 der Europäischen Kommission vom 4. Juni 2021. Auf sie stützen sich Übermittlungen an Shopify-Stellen außerhalb des Europäischen Wirtschaftsraums, also auch an Stellen in den USA. Das Addendum ist unter https://www.shopify.com/legal/dpa öffentlich abrufbar; eine Kopie der Klauseln erhält der Händler auf Anfrage an datenschutz@kyth.systems (Art. 13 Abs. 1 lit. f DSGVO).

Zwei Dinge, die hier bewusst NICHT stehen.

Keine Zertifizierung unter dem EU-US Data Privacy Framework. Das Addendum nennt keine, und ohne Beleg gehört sie nicht in einen Vertrag. Die Standardvertragsklauseln tragen die Übermittlung auch ohne sie.

Welches Modul der Klauseln greift, ist nicht gesondert festgestellt. Für das Verhältnis KYTH zu Shopify wäre Modul 3 einschlägig; belegt ist bislang nur, DASS das Addendum die Klauseln nach 2021/914 einbezieht. Eine Modulangabe ohne Beleg wäre geraten, und geraten wird hier nichts.

• Mailserver des Händlers: seit dem 12.09.2026. Hinterlegt der Händler einen Mailweg (§ 2.2, Anlage 1 Abschnitt A), baut Kuno eine ausgehende SMTP-Verbindung zu seinem Server auf und übergibt ihm dort drei Nachrichten: den Monatsreport, die Fristen-Erinnerung und — bei der Deinstallation — das Abschlusspaket nach § 9.2. Empfänger ist ausschließlich die Kontaktadresse nach § 2a Nr. 4. Wo dieser Server steht, bestimmt der Händler; KYTH kennt weder seinen Betreiber noch dessen Sitz, und eine Drittlandprüfung kann KYTH dafür nicht führen. Es ist zugleich keine Übermittlung an eine Stelle, die KYTH beauftragt hätte: Der Händler wählt den Server, stellt die Zugangsdaten und ist Absender wie Empfänger. Trägt er keinen Mailweg ein, unterbleibt diese Verbindung vollständig — und mit ihr Monatsreport, Fristen-Erinnerung und die Zustellung des Abschlusspakets. Bis zum 12.09.2026 kannte dieser Abschnitt nur Shopify und Cloudflare, während der Weg bereits gebaut war.

• Cloudflare: keine Übermittlung. Die DNS-Zone kyth.systems wird bei Cloudflare geführt. Für Kuno ist Cloudflare damit ausschließlich autoritativer Namensdienst; der Name der App löst unmittelbar auf die IP-Adresse des Servers in Berlin auf, der Datenverkehr läuft nicht über Cloudflare. Cloudflare erhält weder Händler- noch Kundendaten und ist deshalb kein Unterauftragsverarbeiter dieses Vertrages. Siehe § 6.4.

Andere Übermittlungen in Drittländer finden nicht statt. Insbesondere liegen die Sicherungen in Deutschland (§ 6.3).

§ 4 Vertraulichkeit der eingesetzten Personen

KYTH setzt zur Verarbeitung nur Personen ein, die zur Vertraulichkeit verpflichtet sind oder einer angemessenen gesetzlichen Verschwiegenheitspflicht unterliegen (Art. 28 Abs. 3 lit. b DSGVO). Die Verpflichtung wirkt über das Ende der Tätigkeit hinaus.

KYTH stellt sicher, dass diese Personen personenbezogene Daten ausschließlich auf Weisung des Händlers verarbeiten und mit den für sie maßgeblichen Datenschutzvorgaben vertraut sind.

Der Kreis der Zugriffsberechtigten. Zugriff auf die Produktivumgebung — Server, Betriebswerkzeug, Datenbank und das Shopify Partner Dashboard — haben ausschließlich die beiden Geschäftsführer von KYTH, Stefan Grasse und Stephan Wittmann. Stefan Grasse führt daneben die technische Leitung; die Betriebsdokumentation weist ausdrücklich aus, dass diese bei einer einzelnen Person liegt.

Darüber hinaus hat niemand Zugriff. Es gibt keine Beschäftigten, keine freie Mitarbeit und keine Dienstleister mit Zugang zur Produktivumgebung. Die Unterauftragsverarbeiter aus § 6.3 sind davon nicht berührt: Sie stellen Infrastruktur und haben keinen Zugriff auf die Anwendung.

Warum keine gesonderten Verpflichtungserklärungen vorliegen. Art. 28 Abs. 3 lit. b DSGVO verlangt eine Verpflichtung zur Vertraulichkeit oder eine angemessene gesetzliche Verschwiegenheitspflicht. KYTH stützt sich auf die zweite Alternative: Für Geschäftsführer einer Unternehmergesellschaft folgt die Verschwiegenheitspflicht aus ihrer organschaftlichen Treuepflicht (§ 43 GmbHG, für die UG über § 5a Abs. 1 GmbHG). Eine zusätzliche Erklärung, mit der sich jemand sich selbst gegenüber verpflichtet, brächte keinen Nachweis, den es nicht schon gibt.

Das ist eine Bewertung von KYTH und kein geprüftes Gutachten. Ob die organschaftliche Treuepflicht im Sinne von Art. 28 Abs. 3 lit. b DSGVO angemessen ist, ist eine Rechtsfrage. Der Sachverhalt darunter — zwei Geschäftsführer, sonst niemand — ist dagegen eine Feststellung und keine Auslegung.

Sobald eine dritte Person Zugriff bekommt, trägt diese Begründung nicht mehr: Für Beschäftigte, freie Mitarbeit und Dienstleister braucht es eine unterschriebene Vertraulichkeitsverpflichtung, und dieser Abschnitt ist vorher zu ändern.

§ 5 Technische und organisatorische Maßnahmen (Art. 32 DSGVO)

KYTH trifft die in Anlage 2 beschriebenen technischen und organisatorischen Maßnahmen. Anlage 2 enthält ausschließlich Maßnahmen, die im Quelltext oder in der Betriebsdokumentation belegt sind, und benennt in einem eigenen Abschnitt die bekannten Lücken.

Die Maßnahmen unterliegen dem technischen Fortschritt. KYTH darf sie anpassen, solange das Schutzniveau nicht unterschritten wird. Wesentliche Änderungen werden dokumentiert und dem Händler auf Anfrage mitgeteilt.

KYTH verfügt über keine Datenschutz- oder Sicherheitszertifizierung (weder ISO/IEC 27001 noch SOC 2 noch eine Zertifizierung nach Art. 42 DSGVO) und behauptet auch keine. Anlage 2 ist eine Selbstauskunft, kein Prüfbericht.

§ 6 Unterauftragsverarbeiter

6.1 Zustimmung

Der Händler stimmt mit Abschluss dieses Vertrages der Beauftragung der unter 6.3 genannten Unterauftragsverarbeiter zu (allgemeine schriftliche Genehmigung nach Art. 28 Abs. 2 Satz 2 DSGVO).

6.2 Bedingungen

KYTH verpflichtet jeden Unterauftragsverarbeiter vertraglich auf Datenschutzpflichten, die den Pflichten aus diesem Vertrag entsprechen, insbesondere auf hinreichende Garantien nach Art. 28 Abs. 4 DSGVO. Kommt der Unterauftragsverarbeiter seinen Datenschutzpflichten nicht nach, haftet KYTH gegenüber dem Händler für dessen Einhaltung nach Maßgabe von Art. 28 Abs. 4 Satz 2 DSGVO.

Was dafür heute belegt ist. Für die IONOS-Gesellschaften stützt sich KYTH auf deren Vereinbarung zur Auftragsverarbeitung nach Art. 28 Abs. 3 DSGVO, die leistungsunabhängig gefasst ist und den Objektspeicher mit abdeckt. Der vorstehende Absatz beschreibt im Übrigen die Pflicht, die KYTH übernimmt — nicht einen bereits geführten Nachweis für jede denkbare künftige Stelle.

6.3 Liste der Unterauftragsverarbeiter

Ein eigener Eimer, nicht der eines anderen Produkts. Die KYTH. Systems UG betreibt weitere Anwendungen auf demselben Server. Kuno bekommt für seine Sicherungen einen eigenen Eimer mit eigener Sperr- und Aufräumregel; die Eimer der übrigen Anwendungen werden dabei nicht angefasst. Der Grund ist nicht Ordnungsliebe: Ein gemeinsamer Eimer hieße, dass eine Aufräumregel oder ein Zugriffsschlüssel für Kuno zugleich auf die Sicherungen der anderen Anwendungen wirkt.

Kein Objektspeicher für Betriebsdaten. Die Anwendung selbst spricht mit keinem Objektspeicher. Die Übertragung der Sicherung dorthin besorgt ein eigenes Skript auf dem Server, das den Abzug verschlüsselt, bevor er den Server verlässt (§ 9.3 Nr. 2). Damit liegt der Zugangsschlüssel zum Eimer nicht in der Umgebung der Anwendung.

6.4 Weitere Empfänger, die keine Unterauftragsverarbeiter sind

Der Vollständigkeit halber, weil ein Datenfluss oder eine Beteiligung besteht:

• Shopify International Limited, The Sidings, 4th Floor, Grand Canal Quay, Dublin D02 E7K8, Irland (Vertragspartnerin für Händler im EWR), verbunden mit Shopify Inc., 151 O'Connor Street, Ground floor, Ottawa, Ontario K2P 2L8, Kanada — eigener Auftragsverarbeiter des Händlers, nicht Unterauftragsverarbeiter von KYTH.

Was tatsächlich fließt: Bezug und Erneuerung der Zugangstoken über den Token-Endpunkt des Shops; die Aufrufe an die Admin-API des Shops (§ 3.4); das Abholen der Ergebnisdatei einer Sammelabfrage von der Ergebnisablage bei Shopify, die nicht beim Händler-Shop liegt (§ 6.5); Zustellung der eingehenden Meldungen an Kuno; Verwaltung und Abrechnung der App-Tarife.

Welche Daten: Zugangsdaten der App, Sitzungsnachweis bzw. Refresh-Token, Access-Token, Shopdomain; zur Ergebnisablage geht nichts als die signierte Adresse, die Shopify selbst dafür genannt hat. Kundendaten gehen an Shopify nicht zurück; Kuno hat keine.

Warum das keine Unterauftragsverarbeitung von KYTH ist. Eine solche setzt voraus, dass KYTH den Dienstleister beauftragt. Hier ist es umgekehrt: Der Händler hat Shopify längst beauftragt — Shopify betreibt seinen Shop. Belegt ist das an zwei Stellen: Shopifys Data Processing Addendum benennt seine Parteien selbst als Händler und Shopify, und das Shopify Partner Program Agreement, das KYTH bindet, enthält kein solches Addendum und begründet keine Auftragsverarbeitung Shopifys für KYTH.

Getrennt davon zu sehen ist die Abrechnung der App-Tarife. Dort ist KYTH selbst Kunde von Shopify; das ist eine eigene Vertragsbeziehung von KYTH und keine Verarbeitung im Auftrag des Händlers.

Das ist eine Einordnung und kein Gutachten. Die herangezogenen Verträge sind öffentlich, die Schlussfolgerung daraus ist die Bewertung von KYTH. Wer sie anders trifft, stellt die Zeile nach 6.3 — dann braucht es einen Vertrag nach Art. 28 Abs. 4 DSGVO zwischen KYTH und Shopify, und den gibt es nach heutigem Stand nicht.

• Cloudflare (Cloudflare, Inc., San Francisco, USA; in der EU Cloudflare Germany GmbH, München) — autoritativer Namensdienst für die Zone kyth.systems, mehr nicht. Der Name der App löst unmittelbar auf die IP-Adresse des Servers in Berlin auf; der Datenverkehr zwischen dem Browser des Händlers und Kuno läuft nicht über Cloudflare, ein Proxy-Modus ist für die App nicht eingeschaltet. Cloudflare beantwortet lediglich Namensauflösungen und verarbeitet dabei weder Verbindungs- noch Inhaltsdaten der Händler oder ihrer Kundschaft. Wird die App künftig auf den Proxy-Modus umgestellt, wird Cloudflare damit Unterauftragsverarbeiter mit allen Folgen; die Umstellung darf deshalb erst erfolgen, nachdem die Liste unter 6.3 ergänzt und der Händler nach 6.6 informiert wurde.
• GitHub, Inc. (San Francisco, USA; Tochter der Microsoft Corporation) — privates Quelltext-Repository und Bereitstellungsschlüssel. GitHub verarbeitet keine Händler- und keine Kundendaten. Zugangsgeheimnisse liegen ausschließlich in der Bereitstellungsumgebung und sind von Repository und Container-Abbild ausgeschlossen.
• cdn.shopify.com — die eingebettete Oberfläche lädt die Shopify-Bibliothek „App Bridge" direkt vom Shopify-CDN. Dieser Aufruf erfolgt aus dem Browser des Händlers, nicht vom Server von KYTH. Übertragen werden dabei die Verbindungsdaten des Händler-Browsers (IP-Adresse, Browserkennung) und die Herkunftsangabe; keine Kunden- oder Bestelldaten und kein Token. Die Herkunftsangabe ist durch die Richtlinie Referrer-Policy: strict-origin-when-cross-origin auf https://kuno.kyth.systems beschränkt, der Parameter mit der Shopdomain wird also nicht mitübertragen. Empfänger ist Shopify — dieselbe Stelle, die die umgebende Adminoberfläche ausliefert.

Eine Stelle steht hier ausdrücklich NICHT, obwohl ein Datenfluss besteht: KYTH.Karl. Seit dem 08.09.2026 gibt es im Schema einen Bestand, der Verpackungsdaten aus dieser zweiten App aufnehmen kann, und seit dem Abend desselben Tages auch die Adresse, an der Karl sie abliefert (Anlage 1 Abschnitt A). Seit dem Nachmittag des 09.09.2026 verbucht der Programmteil dahinter auch — für jeden Händler, der die Übernahme angewiesen hat, und für keinen anderen. Bis zu jenem Nachmittag stand hier „Verbucht wird dahinter noch nichts", und bis zum Vormittag desselben Tages über den Datenfluss „keiner mehr, der erst entstehen soll"; die erste Fassung war eine Zusage über einen Zufluss, den es nicht gab, die zweite war für einen halben Tag richtig. Beide sind berichtigt und nicht gelöscht, weil die Gegenseite ein eigenes Vorhaben ist und ein späterer Leser den Stand nachmessen soll. An der Einordnung ändert das alles nichts. Karl ist weder Empfänger noch Unterauftragsverarbeiter, sondern eine Quelle — und zwar eine, die dieselbe KYTH. Systems UG für denselben Händler betreibt. Es wird deshalb nichts an einen Dritten weitergegeben, sondern etwas innerhalb desselben Auftragsverarbeiters von einem Auftrag in den anderen übernommen. Die vollständige Einordnung, ihre Grenze und die Folge daraus — dass eine solche Übernahme die Weisung des Händlers braucht — stehen in Anlage 1 Abschnitt A und sind dort als Einordnung gekennzeichnet.

6.5 Ausdrücklich nicht beteiligt

Gesucht und nicht vorhanden: kein Versanddienstleister für E-Mail, kein externer Schrift- oder Symboldienst, kein Analyse- oder Tag-Dienst, kein externer Fehlererfassungsdienst, kein Zahlungsdienstleister — zum Mailserver, den der Händler selbst hinterlegt, siehe den letzten Absatz dieses Abschnitts. Die einzige HTTP-Bibliothek im Anwendungscode öffnet an drei Stellen eine Verbindung nach draußen. Zwei davon sprechen den Händler-Shop an: den Token-Endpunkt und die Admin-API (§ 3.4).

Die dritte ist die Ergebnisablage der Sammelabfrage. Sie steht unter dieser Überschrift, weil dieser Abschnitt die Vollzähligkeit der ausgehenden Verbindungen belegt — nicht, weil sie unbeteiligt wäre: Beteiligt ist sie, nur eben nicht als weitere Stelle neben Shopify. Sie liegt nicht beim Händler-Shop: Shopify legt das Ergebnis eines Auftrags für die Bestellhistorie als Datei auf einer eigenen Ablage ab und nennt dafür eine signierte Adresse, unter der Kuno sie abholt. Dorthin übertragen wird nichts als diese Adresse; zurück kommt die Datei mit den Sendungs- und Bestelldaten des angeforderten Zeitraums, und was darin steht, zählt § 3.4 Feld für Feld auf. Empfänger ist damit Shopify — dieselbe Stelle, die den Shop des Händlers ohnehin betreibt (§ 6.4).

Das ist eine Einordnung und kein Gutachten. Nach der Bewertung von KYTH entsteht durch die Ergebnisablage kein weiterer Unterauftragsverarbeiter: Empfänger ist Shopify, und KYTH beauftragt Shopify nicht — der Händler hat es längst getan. Die Begründung und die herangezogenen öffentlichen Verträge stehen in § 6.4, und dort ist sie ebenso als Bewertung gekennzeichnet. Sie trägt hier eine eigene Marke, weil sie hier für die Ablage gilt, die ausdrücklich nicht beim Händler-Shop liegt — das ist nicht derselbe Sachverhalt wie „Shopify betreibt seinen Shop". Wer die Einordnung anders trifft, stellt die Zeile nach § 6.3: Dann braucht es einen Vertrag nach Art. 28 Abs. 4 DSGVO zwischen KYTH und Shopify, und den gibt es nach heutigem Stand nicht. Bis zum 02.09.2026 stand der Schluss hier als Feststellung im selben Satz, mit einem bloßen Klammerverweis auf § 6.4; der Verweis überträgt die Marke nicht.

Abgeholt wird die Datei vom Lauf für die Bestellhistorie, und der greift ausschließlich Aufträge auf, die in der Warteschlange stehen. Einen solchen Auftrag legt Kuno seit dem 03.09.2026 auf Anforderung des Händlers dort an (§ 3.4); mit der ersten Anforderung wird die Ergebnisablage aufgerufen. Bis zum 03.09.2026 stand hier, einen Auftrag trage „heute keine Stelle des Programms dort ein" und die Ergebnisablage werde deshalb „nicht aufgerufen".

Bis zum 02.09.2026 kannte dieser Absatz nur die beiden Verbindungen zum Händler-Shop und sagte, beide sprächen den Händler-Shop an. Am selben Tag stand hier zunächst, der Abruf sei gebaut und habe keinen Aufrufer — auch das trägt seit dem 02.09.2026 nicht mehr: Der Lauf, der ihn ruft, ist gebaut und startet mit der Anwendung.

Seit dem 12.09.2026 gibt es einen VIERTEN ausgehenden Weg, und er läuft nicht über HTTP. Kuno spricht per SMTP den Mailserver an, den der Händler selbst hinterlegt (§ 2.2, Anlage 1 Abschnitt A): Über ihn gehen der Monatsreport, die Fristen-Erinnerung und das Abschlusspaket nach § 9.2 hinaus, jeweils an die Kontaktadresse nach § 2a Nr. 4. Diese Verbindung trägt die größte Datenmenge der Anwendung — das Abschlusspaket enthält Katalog, Sendungsliste und, soweit vorhanden, die eingefrorenen Meldebögen und Nachweise. Sie begründet trotzdem keinen weiteren Unterauftragsverarbeiter von KYTH: Server, Zugangsdaten und Absenderadresse gehören dem Händler, er wählt den Betreiber, und KYTH beauftragt dort niemanden. Wer diesen Weg nicht will, trägt keinen Mailweg ein; dann bleiben Monatsreport und Fristen-Erinnerung aus und das Abschlusspaket wird nicht zugestellt (§ 9.2). Bis zum 12.09.2026 nannte dieser Abschnitt drei Verbindungen und belegte damit ihre Vollzähligkeit — die vierte bestand an jenem Tag bereits, und weil sie nicht über die HTTP-Bibliothek läuft, zählte der Wächter über die Byte-Wege sie nicht mit. Er zählt sie seit dem 12.09.2026.

6.6 Änderungen und Widerspruchsrecht

KYTH informiert den Händler über die beabsichtigte Hinzuziehung eines weiteren oder den Austausch eines bestehenden Unterauftragsverarbeiters mindestens 30 Tage vorher in Textform an die vom Händler nach § 2a Nr. 4 hinterlegte Kontaktadresse. Ist diese Adresse unzustellbar geworden, erfolgt die Information zusätzlich durch Veröffentlichung unter https://kuno.kyth.systems/rechtliches/auftragsverarbeitung; die Frist läuft dann ab der Veröffentlichung.

Der Händler kann der Änderung innerhalb von 30 Tagen ab Zugang der Mitteilung aus einem sachlichen, datenschutzbezogenen Grund in Textform widersprechen. Einigen sich die Parteien nicht, kann der Händler die Nutzung der App beenden, indem er sie deinstalliert; die Löschung richtet sich dann nach § 9. Widerspricht der Händler nicht, gilt die Änderung als genehmigt.

Erfordert eine Änderung wegen einer unmittelbaren Gefahr für die Sicherheit oder Verfügbarkeit ein sofortiges Handeln, informiert KYTH den Händler gleichzeitig mit der Maßnahme, spätestens innerhalb von 24 Stunden. Der Händler kann der Maßnahme innerhalb von 14 Tagen ab Zugang der Mitteilung widersprechen. Im Fall des Widerspruchs beendet KYTH die Einbindung des Unterauftragsverarbeiters unverzüglich, oder der Händler kann den Vertrag mit sofortiger Wirkung beenden. Das Einspruchsrecht nach Art. 28 Abs. 2 Satz 2 DSGVO bleibt damit erhalten.

§ 7 Unterstützung bei den Rechten betroffener Personen

7.1 Grundsatz

Anträge betroffener Personen richten sich an den Händler als Verantwortlichen. Wendet sich eine betroffene Person unmittelbar an KYTH, leitet KYTH den Antrag unverzüglich an den Händler weiter und beantwortet ihn nicht selbst.

KYTH unterstützt den Händler mit geeigneten technischen und organisatorischen Maßnahmen dabei, seiner Pflicht zur Beantwortung nachzukommen (Art. 12 bis 23 DSGVO), soweit dem Händler das nicht bereits über seinen eigenen Shopify-Zugang möglich ist.

7.2 Was technisch bereitsteht

Kuno ist an die von Shopify vorgeschriebenen Datenschutz-Meldungen angebunden:

Warum beide Funktionen trotzdem gebaut sind. Ein Auskunfts- und ein Löschweg, die erst mit der ersten Kundenzeile entstehen, entstehen erfahrungsgemäß später als die Zeile. Sie laufen deshalb von Anfang an mit und melden ehrlich null.

Wie die beiden Meldungen das Mengenkonto erreichen — die Entscheidung vom 02.09.2026. Der Weg von der gemeldeten Person zu einer Zeile ist die Bestellkennung: Shopify nennt in beiden Meldungen die Bestellungen, um die es geht, und genau diese Kennung führen die Tabellen des Mengenkontos. Eine Kundenkennung und einen Suchwert über eine E-Mail-Adresse führen sie nicht und sollen sie nicht führen (Anlage 1 Abschnitt A); ohne die Bestellkennung gäbe es überhaupt keinen Weg. Bis zum 02.09.2026 standen die Tabellen nicht in der genannten Liste, und der Vertrag hielt an dieser Stelle fest: „Vor der ersten verbuchten Sendung ist deshalb zu entscheiden und hier festzuhalten, wie die beiden Meldungen das Mengenkonto erreichen." Das ist hiermit geschehen. Bis zum 01.09.2026 stand hier als Grund für das Nullergebnis „Diese Liste ist heute leer, das Ergebnis deshalb nachweislich leer"; eine leere Liste war der Zustand des Programms und nicht der Grund.

Geleert wird im Mengenkonto nichts, und das ist der zweite Teil derselben Entscheidung. Zwei Gründe tragen sie. Erstens ist jede dieser Zeilen der Nachweis über eine abgegebene Verpackungsmeldung; die Aufbewahrung ist zur Erfüllung einer rechtlichen Verpflichtung erforderlich und geht dem Löschverlangen insoweit vor (Art. 17 Abs. 3 lit. b DSGVO). Eine geleerte Mengenzeile wäre kein Datenschutz, sondern eine rückwirkend falsche Meldung. Zweitens ist von den Angaben, die überhaupt zu einer Person führen, keine einzige über den Anwendungspfad änderbar: Die Rechte der Anwendungsrolle sind spaltengenau vergeben und schließen die Kennungen der Bestellung, der Sendung und der Position ausdrücklich aus (Anlage 2 Abschnitt 1.3). Eine Zusage, sie zu leeren, wäre an der Rechtevergabe gescheitert — und zwar erst im Ernstfall. Was der Händler stattdessen bekommt, ist die Zahl: wie viele Zeilen dieses Bestandes zu der gemeldeten Person gehören, festgehalten im Zugriffsprotokoll. Eine Null, die daher rührt, dass niemand gesucht hat, wäre keine Auskunft.

Für die Verpackungsdaten aus KYTH.Karl gilt seit dem 08.09.2026 dasselbe Ergebnis, aber nicht dieselbe Begründung. Auch dort wird gefunden und gezählt und nichts geleert — die Anwendungsrolle darf die Nutzlast nicht ändern, ebenso wenig wie die Kennungen im Mengenkonto. Der erste Grund trägt hier jedoch nur mittelbar: Nicht die eingegangene Meldung ist der Nachweis über eine abgegebene Verpackungsmeldung, sondern die Sendung, die aus ihr entsteht. Aufbewahrt wird sie, weil sie belegt, woher eine verbuchte Menge stammt. Bis zum 11.09.2026 stand hier als zweiter Grund „und weil aus ihr nachgearbeitet wird, wenn die Auswertung gescheitert ist". Diesen Grund gibt es im Programm heute nicht: Ein Lauf, der einen gescheiterten Eingang erneut auswertet, ist nicht gebaut — die Leseabfrage dafür steht, ein Aufrufer nicht. Ein gescheiterter Eingang bleibt deshalb mit seinem Fehlergrundwort liegen, bis jemand ihn ansieht. Die Aufbewahrung steht damit auf einem Bein, und das trägt; sie stand vorher auf zweien, von denen eines nichts trug (Anlage 1 Abschnitt A). Wer den Lauf baut, trägt diesen Grund hier wieder ein — der Prüfstand hält beide Richtungen. Diese Unterscheidung steht hier ausdrücklich, weil ein Grund, der abgeschrieben und nicht geprüft wird, beim nächsten Bestand wieder abgeschrieben wird.

Was der Prüfstand hier leistet, und was nicht. Seit dem 02.09.2026 fällt eine Prüfung, sobald eine Tabelle mit Mandantenbezug besteht, über die niemand entschieden hat: Sie muss entweder in der Liste der zu durchsuchenden Tabellen stehen oder mit Begründung als „von einer gemeldeten Person führt hier kein Weg zu einer Zeile" ausgenommen sein. Bis zu diesem Tag gab es diese Prüfung nicht; die Tabellen des Mengenkontos sind am 01.09.2026 entstanden, und ihr Fehlen in der Liste hätte kein Prüflauf gemeldet. Was sie nicht leistet: Sie fragt, ob entschieden wurde, nicht, ob richtig entschieden wurde. Daneben steht weiterhin die ältere Prüfung über Spaltennamen — sie fällt, wenn eine Spalte Name, E-Mail-Adresse, Kunde, Empfänger, Absender, Anschrift oder Telefonnummer im Namen trägt und ihre Tabelle nicht in der Liste steht. Auf die Tabellen des Mengenkontos greift sie nicht: Von ihren Spalten passt nur die Empfängerart auf diese Muster, und die ist mit Begründung ausgenommen, weil sie eine von drei Kategorien führt und niemanden bezeichnet (Anlage 1 Abschnitt A); pseudonyme Kennungen tragen kein solches Namensmuster. Bis zum 01.09.2026 stand hier, dieser Wächter fange den Fall ab. Ein Vertrag, der eine Prüfung verspricht, die es nicht gibt, ist schlechter als einer, der nichts verspricht.

7.3 Berichtigung, Einschränkung, Übertragbarkeit

Von den heute gespeicherten Daten des Shops (Shopdomain, Token, verschlüsselte Kontaktadresse, Zustimmungsnachweis samt Verlauf, Abonnementstand, Einrichtungsstand, technische Zeitstempel, Mailweg) — die vollständige Aufstellung führt Anlage 1 Abschnitt A — berichtigt der Händler die Hälfte selbst — über Shopify oder, für den Mailweg, über die Administration. Vier dieser acht Angaben kann er nicht selbst berichtigen, und das steht hier, weil ein Prüfer die Berichtigung in genau diesem Paragraphen nachschlägt: der Zustimmungsnachweis samt Verlauf, die verschlüsselte Kontaktadresse, der Einrichtungsstand und die technischen Zeitstempel.

Der Zustimmungsverlauf wird ausschließlich anhängend geschrieben und trägt kein Änderungsrecht — der Anwendungsrolle ist auf dieser Tabelle nichts erteilt, womit sie eine bestehende Zeile ändern könnte (Anlage 1 Abschnitt A); die beiden Spalten an der Shop-Zeile schreibt allein der Zustimmungsschritt, und der öffnet sich nur, solange die gespeicherte Fassung von der geltenden abweicht. Dieselbe Schranke trifft die verschlüsselte Kontaktadresse: Sie steht in derselben Anweisung wie die beiden Zustimmungsspalten, und außerhalb des Zustimmungsschritts führt keine Bedienseite und keine Adresse der App dorthin. Beim Einrichtungsstand greift sie nicht: Die abgehakten Schritte öffnet der Händler auf der Startseite selbst wieder, den Zeitpunkt des Abschlusses schreibt die Anwendung genau einmal und danach nie wieder. Die technischen Zeitstempel samt den beiden Ständen der Tagesläufe („bis wann der Monatsreport hinausging", „bis wann an die Fristen erinnert wurde") schreibt allein die Anwendung; weder eine Adresse der App noch eine Bedienseite führt dorthin einen Schreibweg für den Händler. Wer hier etwas Unrichtiges findet, wendet sich an datenschutz@kyth.systems; KYTH berichtigt es dann selbst und unverzüglich (Art. 16 DSGVO). Verlangt der Händler eine Einschränkung der Verarbeitung, setzt KYTH sie nach Absprache um; das praktisch wirksame Mittel ist die Deinstallation der App.

Am frühen Morgen des 13.09.2026 ein viertes Mal berichtigt, in einem Punkt. Der Absatz über den Mailweg sagte, was „der Absatz darüber" bis zum 12.09.2026 aufzählte; gemeint war und ist der erste Absatz dieses Paragraphen, und zwischen beiden stehen inzwischen mehrere datierte Selbstkorrekturen. Der Verweis nennt seither sein Ziel, statt Absätze zu zählen — aus demselben Grund, aus dem „(nächster Absatz)" am selben Tag gestrichen worden ist.

Am 13.09.2026 ein drittes Mal berichtigt, in drei Punkten. Der erste Halbsatz sagte „berichtigt der Händler die meisten selbst", während die Berichtigung darunter die Klammer auf acht Posten und die Ausnahmen auf vier gehoben hatte — vier von acht ist die Hälfte; bei sieben Posten und zwei Ausnahmen war das Mengenwort richtig. Hinter der Administration stand „(nächster Absatz)", gemeint war der Absatz über den Mailweg — der steht mehrere Absätze weiter, im nächsten stehen die vier Ausnahmen; der Verweis ist gestrichen. Und beim Einrichtungsstand stand „dieselbe Schranke": Gemeint war die des Zustimmungsschritts, und die greift dort nicht — die Abschlussmarke schreibt die Anwendung, solange sie leer ist.

Am 13.09.2026 ein zweites Mal berichtigt, und zwar in vier Punkten. Bis dahin zählte dieser Absatz sieben Posten und nannte zwei Ausnahmen — und er las sich so, als sei die Klammer die vollständige Aufstellung; sie war es nie, und der Verweis auf Anlage 1 Abschnitt A steht seither dabei. Die verschlüsselte Kontaktadresse kam darin überhaupt nicht vor, obwohl § 9.2 desselben Vertrages sie unter den technischen Daten des Shops führt — und gemessen ist sie eine weitere Angabe ohne Selbstbedienungsweg: kontakt_email_encrypted wird im Anwendungscode an einer einzigen Stelle geschrieben, in derselben Anweisung wie die beiden Zustimmungsspalten, und dieser Zweig öffnet sich nur, solange die gespeicherte Fassung von der geltenden abweicht. Der Einrichtungsstand stand unter den Angaben, die der Händler selbst berichtigt; gemessen gilt das nur für die abgehakten Schritte und nicht für die Abschlussmarke, die allein geschrieben wird, solange sie leer ist. Und als Korrekturweg nannte der Absatz „über den Zustimmungsschritt", obwohl dieser Schritt allein die drei Spalten schreibt, die seither unter den Ausnahmen „Zustimmungsnachweis samt Verlauf" und „verschlüsselte Kontaktadresse" stehen — ein Weg ohne Gegenstand. Das ist derselbe Befund, den die Berichtigung in der Nacht zuvor für den Zustimmungsverlauf behoben hat, an den Nachbarangaben.

In der Nacht zum 13.09.2026 berichtigt. Bis dahin zählte dieser Paragraph als dritten Posten „Zustimmungsnachweis" und als sechsten „Zeitstempel" und benannte als die beiden Ausnahmen den „Zustimmungsverlauf" und die „technischen Zeitstempel". Der Verlauf stand damit als Ausnahme da, ohne in der Aufzählung vorzukommen — dieser Vertrag hält ihn an anderer Stelle ausdrücklich getrennt („Neben der zuletzt erteilten Zustimmung an der Shop-Zeile hält eine eigene Tabelle jede erteilte Zustimmung fest") und schreibt, wo er beide meint, „Zustimmungsnachweis samt Verlauf" (§ 9.2) —, und der Zustimmungsnachweis selbst fiel damit unter die Angaben, die der Händler „selbst berichtigt". Gemessen trifft das nicht zu: Die Anwendung schreibt zustimmung_am und zustimmung_fassung an genau einer Stelle, und dieser Zweig öffnet sich nur, solange die gespeicherte Fassung von der geltenden abweicht. Ein Prüfer, der die Berichtigung nach Art. 16 DSGVO hier nachschlug, zählte sieben Posten und fand zwei benannte Ausnahmen, von denen eine nicht in der Liste stand.

Am späten Abend des 12.09.2026 berichtigt. Bis zum Morgen des 12.09.2026 lautete der Absatz: „gibt es keine Angabe, die inhaltlich unrichtig sein könnte und die der Händler nicht selbst über Shopify oder über den Zustimmungsschritt korrigieren könnte." Beim Nachziehen des Mailwegs an jenem Tag ist die Einschränkung „die inhaltlich unrichtig sein könnte" entfallen, und aus dem Satz wurde eine unbedingte Selbstbedienungszusage über alle sieben Posten. Für zwei von ihnen gibt es sie nicht — der Vertrag sagte damit ausgerechnet an der Stelle, an der ein Prüfer nachsieht, einen Weg zu, den die App nicht führt.

Der Mailweg gehört seit dem 12.09.2026 dazu, und er wird an einer eigenen Stelle berichtigt. Serveradresse, Port, Absenderadresse, Antwortadresse und die beiden verschlüsselten Zugangsdaten (Anlage 1 Abschnitt A) trägt der Händler in der Administration über die Karte „Mailversand" ein und ändert sie dort — nicht über Shopify und nicht über den Zustimmungsschritt. Eine falsche Absenderadresse lässt jede der drei Zustellungen nach § 6.5 scheitern; berichtigt wird sie am selben Ort, an dem sie eingetragen wurde. Bis zum 12.09.2026 zählte der erste Absatz dieses Paragraphen sechs Angaben auf und nannte als Korrekturwege allein Shopify und den Zustimmungsschritt — die Spalten des Mailwegs bestanden an jenem Tag bereits (Migration 0035), und für sie trug keiner der beiden Wege. Die Änderungsnotiz zum Mailweg nannte § 2.2, Anlage 1 Abschnitt A und Anlage 2 Abschnitt 7.2 als nachgeführte Stellen; dieser Paragraph fehlte dort.

Mit dem Verpackungskatalog ändert sich das. Dann trägt der Händler Angaben ein, die falsch sein können, und aus ihnen entsteht eine Berechnung. Eine Berichtigung ist dort die Änderung des Katalogs und eine erneute Berechnung.

Bis zum 04.09.2026 stand hier: „beides ist noch nicht gebaut, und dieser Absatz ist vor der ersten Berechnung nachzuziehen." Für die erste Hälfte trifft das seit jenem Tag nicht mehr zu. Die Änderung des Katalogs ist gebaut, und sie ist so gebaut, wie es eine Berichtigung verlangt: Ein Gewicht, ein Material und eine Stückliste sind nicht änderbar, eine Änderung ist eine neue Zeile mit eigener Gültigkeit, die alte bleibt als Grundlage der bereits gerechneten Mengen stehen, und die Stücklisten, die auf sie zeigten, werden auf die neue Zeile nachgezogen. Die erneute Berechnung gibt es seit dem 04.09.2026: Ein Programmteil rechnet die Pakete ab einem gewählten Stichtag neu — höchstens 30 Jahre zurück —, und der Händler stößt ihn seit demselben Tag über eine eigene Adresse der App selbst an. Bis zum 06.09.2026 stand hier „Die erneute Berechnung ist weiterhin nicht gebaut, und dieser Absatz ist vor der ersten Berechnung erneut nachzuziehen.“ Beide Hälften trafen schon beim Schreiben nicht mehr zu: Der Programmteil ist am Abend des 04.09.2026 entstanden, die Adresse dorthin zwei Stunden später am selben Tag. Ein Händler, dem nach Art. 16 DSGVO ein falsch hinterlegtes Gewicht auffällt, las in diesem Vertrag, die Berichtigung lasse sich nicht in die bereits gerechneten Mengen durchziehen; sie lässt sich, und ohne diesen Schritt bliebe die Jahresmenge falsch, die er meldet.

Die Tabellen dafür bestehen seit dem 03.09.2026 (Anlage 1 Abschnitt A). Eintragen kann der Händler seit dem 04.09.2026: Sieben Endpunkte nehmen entgegen, was er an Verpackungen, Gewichten und Regeln einträgt (Anlage 1 Abschnitt C). Seit dem Abend des 06.09.2026 bedient er sie auch selbst: Die Verpackungsseite der App trägt die Reiter „Katalog" und „Regeln", und über sie berichtigt der Händler ein hinterlegtes Gewicht selbst — für eine Komponente, indem er sie mit dem richtigen Gewicht und einem Stichtag neu anlegt, für eine Verpackung, indem er ihre Stückliste als neue Version ab einem gewählten Tag speichert. Bis zu jenem Abend endete dieser Satz mit „Was fehlt, ist die Bedienseite dazu; sie kommt mit einem späteren Ausbau". Bis zum Vormittag des 06.09.2026 stand hier „eintragen kann der Händler noch nichts, weil es keine Bedienseite gibt“ — derselbe Fehler, für den Anlage 1 Abschnitt C am 04.09.2026 berichtigt worden ist: Was damals fehlte, war der Bildschirm und nicht der Weg; den Bildschirm gibt es seit dem 06.09.2026 und seine Bedienelemente seit dem Abend desselben Tages. Bis zum 07.09.2026 stand der Halbsatz über den Bildschirm hier im Präsens. Ein Händler, der ausgerechnet den Paragraphen über die Berichtigung liest, hielt die Katalogpflege für unerreichbar und trug kein Gewicht ein; seine Pakete liefen weiter über Referenzwerte statt über belegte Wiegungen.

7.4 Aufwand

Die Unterstützung nach diesem Paragraphen erbringt KYTH unentgeltlich, im Rahmen dessen, was Art. 28 Abs. 3 lit. e DSGVO verlangt. Eine Vergütung für darüber hinausgehenden Aufwand ist nicht vereinbart und wird nicht verlangt.

§ 8 Unterstützung bei Sicherheit, Datenpannen und Datenschutz-Folgenabschätzung

8.1 Sicherheit der Verarbeitung (Art. 32 DSGVO)

KYTH unterhält die in Anlage 2 beschriebenen Maßnahmen und überprüft sie anlassbezogen, insbesondere bei jeder Erweiterung des Funktionsumfangs.

8.2 Verletzungen des Schutzes personenbezogener Daten (Art. 33, 34 DSGVO)

KYTH meldet dem Händler jede Verletzung des Schutzes personenbezogener Daten, die Daten aus dessen Shop betrifft, unverzüglich nach Bekanntwerden in Textform an die vom Händler nach § 2a Nr. 4 hinterlegte Kontaktadresse. Die Meldung enthält, soweit bekannt:

• Beschreibung der Art der Verletzung, die Kategorien und die ungefähre Zahl der betroffenen Personen und Datensätze,
• Kontaktstelle für weitere Auskünfte (datenschutz@kyth.systems),
• die wahrscheinlichen Folgen,
• die ergriffenen und die vorgeschlagenen Gegenmaßnahmen.

Sind noch nicht alle Angaben verfügbar, meldet KYTH zunächst den bekannten Sachverhalt und liefert das Übrige unverzüglich nach. Die Meldung an die Aufsichtsbehörde und die Benachrichtigung betroffener Personen obliegen dem Händler (§ 2a Nr. 6); KYTH unterstützt ihn dabei mit den vorliegenden Informationen.

Grenze dieser Zusage. Der Kanal zum Händler steht, weil die Kontaktadresse beim Vertragsschluss erhoben wird (§ 0.2, § 2a Nr. 4). Er hängt aber daran, dass der Händler sie aktuell hält. Ist die hinterlegte Adresse unzustellbar geworden, kann KYTH ihn nicht mehr unmittelbar erreichen; KYTH veröffentlicht die Meldung dann unter https://kuno.kyth.systems/rechtliches/auftragsverarbeitung und weist in der eingebetteten Oberfläche darauf hin. Das ersetzt eine unmittelbare Benachrichtigung nicht — die 72-Stunden-Frist des Händlers nach Art. 33 Abs. 1 DSGVO lässt sich auf diesem Weg nicht zuverlässig wahren.

KYTH unterhält einen dokumentierten Ablaufplan für Sicherheitsvorfälle mit Eskalationsstufen, benannten Zuständigkeiten, der 72-Stunden-Frist des Art. 33 DSGVO und der zuständigen Aufsichtsbehörde (Bayerisches Landesamt für Datenschutzaufsicht, BayLDA).

8.3 Datenschutz-Folgenabschätzung und vorherige Konsultation (Art. 35, 36 DSGVO)

Führt der Händler eine Datenschutz-Folgenabschätzung durch oder konsultiert er die Aufsichtsbehörde, stellt KYTH auf Anfrage die dafür erforderlichen Informationen über die Verarbeitung durch Kuno zur Verfügung — insbesondere die Anlagen 1 und 2 dieses Vertrages sowie Auskunft über die eingesetzten Unterauftragsverarbeiter.

§ 9 Löschung oder Rückgabe nach Ende der Verarbeitung

9.1 Was wann geschieht

Das Abschlusspaket ist eine Rückgabe im Sinne von § 9.2 und keine Aufbewahrung. Es entsteht aus den Beständen dieses einen Shops, geht an die nach § 2a Nr. 4 hinterlegte Kontaktadresse des Händlers und an keine andere, und es fällt mit der Shop-Zeile — nach der Zustellung ebenso wie ohne sie (§ 9.3 Nr. 1). KYTH behält es nicht, wertet es nicht aus und gibt es niemandem sonst. Dieser Absatz steht hier seit dem 12.09.2026.

Die in shops.aufbewahrung_jahre eingestellte Frist ist die Frist des Händlers, nicht die von KYTH. Sie steht im Abschlusspaket und in den Nachweisen, damit der Händler weiß, wie lange er die Unterlagen selbst vorhalten wollte. Die Löschfristen dieses Abschnitts verlängert sie nicht — auch dann nicht, wenn sie auf zehn Jahre steht. Auch dieser Absatz steht hier seit dem 12.09.2026.

Die zu leerenden Tabellen werden dabei nicht aus einer gepflegten Liste, sondern zur Laufzeit aus dem Datenbankkatalog ermittelt. Erfasst werden alle Tabellen im Schema public, die eine Spalte mit dem Namen shop_id tragen. Innerhalb dieser Grenze verhindert das, dass eine neu hinzugekommene Tabelle beim Löschen vergessen wird. Der Aufräumlauf nach 9.3 Nr. 1 benutzt genau denselben Pfad: Es gibt eine Löschlogik, nicht zwei, weil zwei mit der Zeit auseinanderlaufen.

Die drei Tabellen des Mengenkontos und die der Materialzeilen kommen auf diesem Weg mit. Bis zum 04.09.2026 nannte dieser Satz nur die drei; die vierte gibt es seit jenem Tag, und sie trägt dieselbe Spalte. Jede von ihnen trägt die Shop-Zuordnung, weil dieselbe Spalte zugleich den Zeilenschutz der Datenbank trägt (Anlage 2 Abschnitt 1.2); der Prüfstand löscht einen Shop und zählt die geleerten Zeilen je Tabelle nach.

Was der Mechanismus nicht erfasst — diese Grenzen sind im Quelltext ausdrücklich festgehalten:

1. Tabellen in einem anderen Schema als public,
2. Tabellen, deren Shop-Spalte anders heißt als shop_id,
3. Views mit einer shop_id-Spalte, auf denen ein Löschbefehl scheitert oder ungewollt auf die Basistabelle durchschlägt,
4. Tabellen ohne eigene shop_id, die nur über einen Fremdschlüssel an einer Shop-Tabelle hängen — sie verschwinden nur mit, wenn dieser Fremdschlüssel eine Löschweitergabe trägt.

Für diese vier Fälle muss die Löschung gesondert sichergestellt werden. Der heutige Datenbestand fällt vollständig in den erfassten Bereich; die Einschränkung wird mit jeder neuen Tabelle wichtiger.

9.2 Löschung oder Rückgabe — der Händler wählt

Nach Beendigung der Verarbeitung löscht KYTH sämtliche Daten des Händlers oder gibt sie nach Wahl des Händlers heraus (Art. 28 Abs. 3 lit. g DSGVO).

⚠ Ein Teil der Rückgabe geschieht seit dem 12.09.2026 von selbst, und das ändert diesen Paragraphen in der Sache. Deinstalliert der Händler die App, entsteht ohne jeden Antrag ein Abschlusspaket und geht über seinen eigenen Mailserver an seine hinterlegte Kontaktadresse (§ 9.1). Es enthält den Katalog, die Verpackungseinheiten, die Meldezeiträume, die Sendungsliste und — soweit vorhanden — die eingefrorenen Meldebögen und Nachweise; das ist genau die Aufstellung, um deren Rückgabe es in diesem Paragraphen geht. Bis zum 12.09.2026 stand hier „Eine automatische Ausleitung ist nicht umgesetzt; KYTH stellt die Daten in diesem Fall von Hand zusammen“, und am Ende dieses Abschnitts stand „Wer die App beendet, ohne seine Aufstellung anzufordern, verliert sie mit Ablauf der Löschfrist“. Beide Sätze waren an jenem Tag falsch geworden: Der Versandlauf lief seit demselben Tag, und er fragt niemanden. Ein Händler, der sie las, hielt eine Übermittlung an seinen Mailserver für ausgeschlossen, die längst geschah — und das ist die Angabe, die ein Prüfer an § 9 zuerst sucht.

Was die Wahl trotzdem bedeutet. Das Abschlusspaket ist ein Ausschnitt: Es trägt die Aufstellung und die daraus erzeugten Dokumente, nicht die technischen Angaben über den Shop (Absatz „Zur Einordnung“ unten) und kein anderes Format. Wer mehr will oder JSON braucht, teilt seine Wahl vor der Deinstallation oder innerhalb von 14 Tagen danach in Textform an datenschutz@kyth.systems mit; KYTH stellt die Daten dann innerhalb von 14 Tagen nach Zugang der Mitteilung in einem gängigen maschinenlesbaren Format (JSON) bereit. Für diesen Weg gibt es keine Ausleitefunktion; KYTH stellt die Daten von Hand zusammen, und beim heutigen Umfang ist das eine überschaubare Menge. Ohne Mitteilung bleibt es beim Abschlusspaket, und alles Übrige wird gelöscht.

⚠ Das Abschlusspaket setzt zweierlei voraus, und wer es braucht, prüft es vor der Deinstallation: eine hinterlegte Kontaktadresse und einen hinterlegten Mailweg. Fehlt eines von beiden, geht nichts hinaus; nach fünf gescheiterten Versuchen ruht das Paket, und spätestens sieben Tage nach seiner Erzeugung gewinnt die Löschung (§ 9.3 Nr. 1). Wer sichergehen will, fordert seine Daten zusätzlich in Textform an.

Zur Einordnung: Zu den heutigen technischen Daten des Shops — Shopdomain, deren Suchwert, verschlüsselte Zugangstoken, verschlüsselte Kontaktadresse, Zustimmungsnachweis samt Verlauf, zuletzt gelesener Abonnementstand, Einrichtungsstand, technische Zeitstempel und die Einträge des Zugriffsprotokolls für geschützte Kundendaten — gilt: Für den Händler haben sie außerhalb von Kuno voraussichtlich wenig Nutzen, und die Zugangstoken sind nach der Deinstallation ohnehin ungültig. Das ist eine Einschätzung; die Wahl bleibt beim Händler.

Anders wird es mit dem Mengenkonto, und dort ist die Wahl praktisch bedeutsam. Ein Mengenkonto ist zugleich der Nachweis darüber, was der Händler gemeldet hat. Verlangt er die Herausgabe, gibt KYTH sie in einem gängigen maschinenlesbaren Format heraus, ausschließlich an den Händler als Verantwortlichen und ausschließlich an die nach § 2a Nr. 4 hinterlegte Kontaktadresse. Wer die App beendet, bekommt sie seit dem 12.09.2026 unaufgefordert als Abschlusspaket an eben diese Adresse; wer darüber hinaus etwas braucht, fordert es binnen 14 Tagen an. Nach Ablauf der Löschfrist ist beides nicht mehr möglich, weil es die Zeilen dann nicht mehr gibt.

9.3 Vernichtung vorhandener Kopien — verbindliche Fristen

Art. 28 Abs. 3 lit. g DSGVO verlangt, dass KYTH nach Beendigung der Verarbeitung auch die vorhandenen Kopien vernichtet, soweit keine gesetzliche Aufbewahrungspflicht besteht. KYTH sagt dafür die folgenden Fristen zu.

Übersicht:

1. Wenn shop/redact ausbleibt: 30 Tage. Bleibt die Meldung aus — die Zustellung geht verloren, der Endpunkt ist vorübergehend nicht erreichbar, Shopify meldet sie nie —, löscht ein Aufräumlauf die Shop-Zeile 30 Tage nach dem Deinstallationszeitpunkt vollständig, über denselben Löschpfad wie shop/redact. Die Frist ist bewusst deutlich länger als die 48 Stunden des Regelwegs: Wer die App versehentlich deinstalliert und in derselben Woche neu installiert, soll seine Zustimmung und seine Kontaktadresse nicht verloren haben. ⚠ Die eine Ausnahme, und sie ist am 12.09.2026 nachgetragen worden: das noch offene Abschlusspaket — bis zu sieben Tage. Liegt für den Shop ein Abschlusspaket bereit, das noch nicht zugestellt werden konnte, wartet dieser Aufräumlauf damit, bis es zugestellt ist oder sieben Tage seit seiner Erzeugung vergangen sind; danach gewinnt die Löschung, auch wenn das Paket nie ankam. Die Shop-Zeile kann damit bis zu 37 Tage nach der Deinstallation stehen. Der Grund ist der Zweck des Pakets selbst: Es ist die einzige Kopie, die dem Händler bleibt, es hängt mit Löschweitergabe an der Shop-Zeile und fiele mit ihr — eine Löschung, die es mitnimmt, nähme ihm genau das, wofür er es bekommen soll. Sieben Tage sind die Obergrenze und keine Regeldauer: Der Versandlauf bietet jedes Paket höchstens fünfmal an, also rund fünf Tage lang, und die beiden weiteren decken einen ausgefallenen Durchlauf. Die Ausnahme wirkt nur hier und nicht auf den Regelweg: shop/redact löscht 48 Stunden nach der Deinstallation und fragt nicht nach dem Paket — es ist eine Weisung des Verantwortlichen, und sie aufzuhalten wäre die schlechtere Entscheidung. Bis zum 12.09.2026 nannte dieser Punkt die 30 Tage ohne jede Ausnahme, während Anlage 1 Abschnitt A die sieben Tage in der Zeile über das Abschlusspaket bereits führte und der Aufräumlauf sie seit demselben Tag durchsetzte — der Vertrag widersprach sich also selbst, und die Frist, die ein Händler las, war um bis zu sieben Tage zu kurz. Die Belegtabelle am Ende dieses Dokuments nennt seither die Stelle im Programm, an der die sieben Tage stehen. Zweiter Fall desselben Aufräumlaufs: nie zustande gekommene Verbindungen — 90 Tage. Die Frist oben rechnet ab dem Deinstallationszeitpunkt. Es gibt eine Lage, in der es diesen Zeitpunkt nie gibt: Der Händler stimmt zu, KYTH legt den Datensatz zum Shop an, und der unmittelbar folgende Abruf des Zugangstokens bei Shopify scheitert. Eine Deinstallationsmeldung kommt für diesen Datensatz nie, weil die App gar nicht (mehr) installiert ist. Damit er nicht dauerhaft stehen bleibt, löscht derselbe Aufräumlauf über denselben Löschpfad einen Datensatz, der keinen Deinstallationszeitpunkt trägt, kein Zugangs- und kein Erneuerungstoken hat und dessen letztes Lebenszeichen länger als 90 Tage zurückliegt.

Was auch diese Regel nicht erfasst: einen Datensatz, dessen Token noch stehen, obwohl der Shop längst deinstalliert ist — möglich, wenn die Deinstallationsmeldung den Shop wegen eines nach einem Schlüsselwechsel veralteten Suchwertes nicht auflösen konnte. Ein solcher Datensatz ist von dem eines arbeitenden Shops nicht zu unterscheiden; eine Regel, die ihn träfe, träfe auch arbeitende Shops. Dieser Fall wird deshalb dort behoben, wo er entsteht: Nach jedem Schlüsselwechsel werden die Suchwerte neu berechnet. Der Lauf dafür ist gebaut und fester Bestandteil eines Schlüsselwechsels; er steht in Anlage 2 Abschnitt 7.1 und nicht unter den offenen Punkten.

Der Auslöser ist eingerichtet. Ein Aufräumlauf startet mit dem Anwendungsprozess und ruft beide Regeln alle 24 Stunden auf. Bei Kartuu war die Löschung eine Zeitlang gebaut und geprüft, wurde aber von nichts aufgerufen — die Frist war eine Absicht und keine Wirklichkeit. Dasselbe gilt hier auch für Nr. 3, die denselben Lauf benutzt. 2. Sicherungen: 30 Tage lokal, 95 Tage im Objektspeicher — davon 90 Tage unlöschbar. Ab Inbetriebnahme gilt: Es wird täglich nachts eine vollständige Sicherung der Datenbank erstellt und mit AES-256 verschlüsselt, bevor sie den Server verlässt. Sie liegt auf dem Server (Aufbewahrung 30 Tage) und im Objektspeicher der IONOS in Berlin, im Eimer kilo-kyth-db-backup-worm. Dort gilt zweierlei: Die Sicherung ist durch Object Lock im COMPLIANCE-Modus 90 Tage lang für niemanden löschbar — auch nicht für KYTH selbst und auch nicht für jemanden, der den Server samt Zugangsdaten übernimmt —, und eine Lebenszyklusregel (sicherungen-nach-95-tagen-loeschen, gesamter Eimer, Ablauf 95 Tage nach Erstellung) löscht sie danach auf Speicherebene.

Warum 95 und nicht 90: Die Sperre gilt nach Alter, die Aufräumregel greift zu ihrem eigenen Zeitpunkt. Stehen beide auf derselben Zahl, fällt der Aufräumlauf an der Kante auf die gesperrte Seite und scheitert — dauerhaft und unbemerkt. Die fünf Tage sind die Frist zwischen zwei Mechanismen und keine verlängerte Vorratshaltung.

Das Sicherungsskript löscht selbst nichts. Aufgeräumt wird ausschließlich über die Lebenszyklusregel des Eimers. Ein Sicherungsskript, das im Objektspeicher löschen kann, ist genau die Fähigkeit, die demjenigen nützt, der den Server übernimmt — deshalb hat es sie nicht. Lebenszyklusregeln fallen nicht still aus, Aufräumjobs schon.

Ausdrücklich, weil es für den Händler zählt: Wird ein Shop gelöscht — durch shop/redact, durch den Aufräumlauf nach Nr. 1 oder auf Verlangen des Händlers —, bleiben seine Daten in bereits erstellten Sicherungen enthalten und verschwinden von dort erst mit dem Ablauf der genannten Fristen: spätestens 30 Tage später auf dem Server, spätestens 95 Tage später im Objektspeicher — dort sind die ersten 90 Tage zusätzlich für niemanden löschbar, gelöscht wird nach 95. Ein gezieltes Herausschneiden einzelner Datensätze aus vorhandenen Sicherungen findet nicht statt; es würde die Sicherung als Wiederherstellungspunkt entwerten. Solange die Daten dort liegen, werden sie ausschließlich zur Wiederherstellung im Störungsfall verwendet.

Zur Verschlüsselung — was KYTH zusagt und was nicht. Die Übertragung zum Objektspeicher erfolgt mit TLS. IONOS verschlüsselt ruhende Objekte mit AES-256; KYTH sagt das nicht als eigene Maßnahme zu, weil die Dokumentation von IONOS die Standardverschlüsselung für Uploads über die Weboberfläche beschreibt und nicht belegt ist, ob der Sicherungslauf über die S3-Schnittstelle dieselbe Verschlüsselung anfordert. Was KYTH zusagt und was tatsächlich trägt: Der Abzug ist als Ganzes verschlüsselt, bevor er den Server verlässt, und die schutzbedürftigen Felder — die Zugangstoken und die Kontaktadresse des Händlers — liegen innerhalb der Sicherung zusätzlich feldweise mit AES-256-GCM verschlüsselt. Der Feldschlüssel steht in der Umgebung der Anwendung, nicht in der Sicherung und nicht bei IONOS, und er ist ein anderer als das Kennwort der Sicherungsdatei. 3. Technische Kennungen eingehender Meldungen: 30 Tage nach Abschluss. Die Tabelle mit den Kennungen (Duplikatschutz) trägt keine Shop-Zuordnung und wird vom Löschvorgang des Shops nicht erfasst. Ein eigener Aufräumlauf entfernt einen abgeschlossenen Eintrag 30 Tage nach seinem Abschluss. Shopify wiederholt eine Meldung über höchstens 48 Stunden; die 30 Tage sind Puffer für die Frage, ob eine Meldung je angekommen ist. Inhaltlich sind das ausschließlich von Shopify vergebene technische Kennungen ohne Personenbezug.

Benannte Ausnahme: Einträge, deren Verarbeitung nie abgeschlossen wurde — etwa weil ein Prozess abgebrochen ist —, werden von diesem Lauf nicht entfernt. Sie zu löschen hieße, eine Wiederholung derselben Meldung ein zweites Mal durchlaufen zu lassen. Personenbezug haben sie nicht. 4. Anwendungs- und Containerprotokolle: 14 Tage. Sie enthalten die Shopdomain, die interne Shop-Kennung und den Typ aufgetretener Ausnahmen — keine Token, keine Kontaktadresse und keine Kundendaten. Welchen Inhalt ein Protokolleintrag tragen darf, entscheidet das Programm; das gilt ab der ersten Zeile, die überhaupt geschrieben wird. Ab Inbetriebnahme gilt: Nach 14 Tagen werden sie verworfen. Die Frist wird im Betriebswerkzeug eingestellt, nicht im Programm, und ist beim Einrichten herzustellen; sie steht dort auf der Prüfliste.

Bis zum 01.09.2026 endete dieser Punkt mit „sie steht hier, weil sie gilt" — die Frist war damit als geltender Zustand zugesagt, während Abschnitt 9.7 der Datenschutzerklärung dieselbe Frist ausdrücklich ab Inbetriebnahme zusagt und die Einrichtungsliste sie als Schritt führt. Der unmittelbare Nachbar Nr. 2 trug den Vorbehalt bereits. 5. Zugriffsprotokoll für geschützte Kundendaten. Es trägt eine Shop-Zuordnung und verschwindet deshalb vollständig mit dem Shop — über shop/redact und über den Aufräumlauf nach Nr. 1. Eine eigene Frist ist dafür weder nötig noch zulässig: Ein früheres Löschen würde die Nachweisauflage aus der Shopify-Freigabe verletzen, ein späteres wäre eine Aufbewahrung ohne Shop und ohne Zweck. 6. Mengendaten: seit dem 02.09.2026 füllen sie sich, und die Frist ist offen. Die Tabellen des Mengenkontos stehen, und der Abgleich (§ 3.4) legt Zeilen darin an; bis zu diesem Tag stand hier „heute keine Zeile … sie sind leer". Ihre Zeilen tragen eine Shop-Zuordnung und verschwinden deshalb mit dem Shop. Ob darüber hinaus eine aggregierte Aufstellung ohne Kennungen aufzubewahren ist, folgt nicht aus dem Programm, sondern aus handels- und steuerrechtlichen Aufbewahrungspflichten; entschieden ist das nicht. Solange es nicht entschieden ist, gilt der Löschpfad ohne Ausnahme, und dieser Punkt steht in Anlage 2 Abschnitt 7.2. 7. Betriebsspuren der Erfassung: 90, 90 und 30 Tage. Drei Bestände dokumentieren, WIE die Zeilen des Mengenkontos entstanden sind, und tragen selbst keine Angabe über eine Person:

• die Abgleichläufe (je Lauf Zeitfenster, Zählwerte, Beginn und Ende) — 90 Tage nach dem Ende des Laufs. Der jüngste Lauf je Art bleibt unabhängig davon stehen: An ihm hängt, ab wann das nächste Zeitfenster beginnt; ohne ihn entstünde eine Lücke im Mengenkonto.
• die Warteschlange der Nacherfassung (je Abruf Kennung, Zeitraum, Zustand, Zählwerte) — 90 Tage, nachdem der Abruf abgeschlossen oder endgültig fehlgeschlagen ist. Der jüngste Abruf je Shop bleibt stehen: Er ist die Antwort auf die Frage, ob überhaupt schon einer gelaufen ist.
• die Verarbeitungsvorfälle — 30 Tage, nachdem der Händler sie abgehakt hat. Ein OFFENER Vorfall wird nie entfernt: Er ist die Angabe, an der der Händler abliest, was ihm fehlt.

Alle drei Fristen laufen über denselben Aufräumlauf wie Nr. 1 und Nr. 3. Bis zum 03.09.2026 nannte dieser Paragraph für diese drei Bestände keine Frist, und es gab auch keine: Sie wuchsen unbegrenzt, während jeder andere Bestand hier eine Frist hat.

9.4 Gesetzliche Aufbewahrung

Besteht ausnahmsweise eine gesetzliche Pflicht zur weiteren Aufbewahrung, unterbleibt insoweit die Löschung; die Daten werden in ihrer Verarbeitung eingeschränkt und ausschließlich zu diesem Zweck verwendet. KYTH teilt dem Händler eine solche Aufbewahrung mit.

Für den heutigen Datenbestand greift das nicht. Shopdomain, Token, Zustimmungsnachweis, Abonnementstand und Einrichtungsstand sind keine Aufzeichnungen im Sinne der handels- oder steuerrechtlichen Aufbewahrungspflichten. Mit dem Mengenkonto kann sich das ändern; die Frage ist in § 9.3 Nr. 6 offen benannt und nicht vorweg beantwortet.

§ 10 Nachweise und Prüfrechte des Verantwortlichen

10.1 Nachweise

KYTH stellt dem Händler auf Anfrage an datenschutz@kyth.systems alle Informationen zur Verfügung, die zum Nachweis der Einhaltung der Pflichten aus Art. 28 DSGVO erforderlich sind. Regelmäßig genügen dafür:

• dieser Vertrag mit Anlage 1 (Verarbeitungsübersicht) und Anlage 2 (technische und organisatorische Maßnahmen),
• die aktuelle Liste der Unterauftragsverarbeiter,
• der Ablaufplan für Sicherheitsvorfälle,
• Auskunft über die zum Shop des Händlers gespeicherten Daten.

10.2 Prüfungen

Reichen diese Nachweise im Einzelfall nicht aus, ermöglicht KYTH Überprüfungen einschließlich Inspektionen und trägt zu ihnen bei (Art. 28 Abs. 3 lit. h DSGVO). Der Händler kann die Prüfung selbst durchführen oder einen von ihm beauftragten Prüfer einsetzen, der nicht in Wettbewerb zu KYTH steht und zur Verschwiegenheit verpflichtet ist.

Prüfungen erfolgen nach Ankündigung mit angemessenem Vorlauf — in der Regel 30 Tage —, zu üblichen Geschäftszeiten, ohne Störung des Betriebsablaufs und höchstens einmal je Kalenderjahr; bei einem konkreten Anlass, insbesondere nach einer Verletzung des Schutzes personenbezogener Daten oder auf Verlangen einer Aufsichtsbehörde, auch darüber hinaus und kurzfristig.

10.3 Was eine Prüfung nicht umfassen kann

• Zertifikate: KYTH hält keine. Es kann kein Prüfbericht vorgelegt werden, den es nicht gibt (siehe § 5).
• Rechenzentrum: Die Serverinfrastruktur ist bei der IONOS SE angemietet. Eine Prüfung vor Ort im Rechenzentrum kann KYTH nicht gewähren; hierfür ist auf die Nachweise und Zertifizierungen von IONOS zu verweisen.
• Daten anderer Händler: Eine Prüfung darf nicht dazu führen, dass der Prüfer Zugang zu Daten anderer Händler erhält. KYTH wird Zugriffe entsprechend beschränken.

10.4 Behörden

KYTH unterstützt den Händler bei Prüfungen durch die zuständige Aufsichtsbehörde und erteilt dieser auf Verlangen unmittelbar Auskunft (Art. 31 DSGVO). KYTH informiert den Händler unverzüglich über behördliche Maßnahmen, die dessen Daten betreffen, soweit das rechtlich zulässig ist.

§ 11 Rangfolge und Schlussbestimmungen

1. Dieser Vertrag geht den übrigen Vertragsbedingungen zwischen den Parteien vor, soweit es um die Verarbeitung personenbezogener Daten im Auftrag geht.
2. Die Anlagen 1 und 2 sind Bestandteil dieses Vertrages.
3. Änderungen und Ergänzungen bedürfen der Textform. Das gilt auch für die Aufhebung dieses Formerfordernisses.
4. Ist eine Bestimmung unwirksam, bleibt der übrige Vertrag wirksam. Die Parteien ersetzen die unwirksame Bestimmung durch eine wirksame, die dem verfolgten Zweck am nächsten kommt.
5. Eine Rechtswahl und ein ausschließlicher Gerichtsstand sind nicht vereinbart. Es gelten die gesetzlichen Regeln. Die Begründung steht in § 13 des Nutzungsvertrags und trägt für diesen Vertrag genauso: Kuno wird über den Shopify App Store weltweit angeboten, und eine Klausel, die für jeden Händler deutsches Recht und den Sitz von KYTH festschriebe, wäre gegenüber einem Teil von ihnen nicht durchsetzbar — eine unwirksame Klausel ist schlechter als keine, weil sie Klarheit vortäuscht, auf die sich dann jemand verlässt. Sitz von KYTH ist Berg, Deutschland.
6. Fortschreibungspflicht: Vertrag und Anlagen bilden den im Kopf genannten Quelltextstand ab. Vor jeder Erweiterung, die den Kreis der verarbeiteten Daten verändert — insbesondere vor der ersten entgegengenommenen Sendung —, sind Anlage 1 und Anlage 2 gegen den dann geltenden Quelltext neu zu erheben und die Fassungskennung ist zu erhöhen. Bei Kartuu ist genau diese Pflicht einmal verletzt worden: Ein ganzer Verarbeitungsstrang wurde in vier Schritten gebaut, während die Anlagen ihn weiter als nicht verarbeitet führten. Kuno führt deshalb Prüfungen mit, die Anlage 1 gegen das echte Datenbankschema und Anlage 2 gegen die tatsächlich erteilten Datenbankrechte halten.

Und einmal in Kuno selbst, weshalb der Satz oben nicht als eingehaltene Zusage gelesen werden darf: Die drei Tabellen des Mengenkontos sind am 01.09.2026 angelegt worden, bevor die Fassungskennung gehoben war. Anlage 1 und Anlage 2 sind am selben Tag nachgezogen, und die Hebung ist am 13.09.2026 geschehen (⚠-Hinweis im Kopf). Bis zum 12.09.2026 stand hier, sie folge zum Abschluss des laufenden Ausbaus. Der Unterschied zu Kartuu ist nicht der Vorgang, sondern dass er benannt ist, dass die Anlagen nicht hinterherhinken und dass er vor der ersten fremden Installation behoben worden ist — bis zu jenem Tag hatte kein Händler zugestimmt.

§ 12 Was Sie als Händler tun müssen

Die Pflichten aus § 2a stehen dort im Vertragston. Hier stehen sie noch einmal kurz und im Klartext, damit Sie nach dem Lesen wissen, was Sie übernommen haben.

1. Halten Sie Ihre Kontaktadresse aktuell. Die E-Mail-Adresse, die Sie beim Verbinden der App angegeben haben, ist unser einziger Weg zu Ihnen — bei einer Datenpanne, bei einer Vertragsänderung, bei einem Wechsel eines Unterauftragsverarbeiters. Ändert sie sich, schreiben Sie uns an datenschutz@kyth.systems.
2. Sorgen Sie für die Rechtsgrundlage. Für die Verarbeitung der Daten Ihrer Kundschaft brauchen Sie eine Rechtsgrundlage nach Art. 6 DSGVO. Wir prüfen sie nicht und können sie nicht prüfen.
3. Informieren Sie Ihre Kundschaft. Die Informationspflichten nach Art. 13 und Art. 14 DSGVO treffen Sie, nicht uns. Nehmen Sie Kuno in Ihre eigene Datenschutzerklärung auf.
4. Beantworten Sie Anfragen betroffener Personen selbst. Wendet sich jemand an uns, leiten wir die Anfrage an Sie weiter und beantworten sie nicht (§ 7.1).
5. Melden Sie Datenpannen selbst an Ihre Aufsichtsbehörde. Wir melden Ihnen den Vorfall; die Meldung nach Art. 33 DSGVO und die Benachrichtigung der Betroffenen nach Art. 34 DSGVO machen Sie (§ 8.2).
6. Erteilen Sie Weisungen in Textform. Einzelweisungen gehen an datenschutz@kyth.systems. Was Sie mündlich sagen, bestätigen Sie uns bitte unverzüglich in Textform (§ 3.2).
7. Prüfen Sie, was Sie einreichen. Was Kuno liefert, sind Berechnungen und Exportdateien; die Erklärung gegenüber einer Stelle geben Sie ab. Registrierung und Meldung nehmen Sie selbst vor. Bis zum 05.09.2026 stand hier die Vorsichtsform „Was Kuno liefern soll"; seit jenem Tag gibt es den Weg zu Bericht und Datei, und die Form ist zurückgenommen (§ 1.1). Bis zum 01.09.2026 stand hier „Kilo erstellt Berechnungen und Exportdateien" — damals im Präsens für etwas, das es noch nicht gab.

Anlage 1 — Verarbeitungsübersicht

Bildet den im Kopf genannten Quelltextstand ab. Grundlage ist eine Erhebung am Quelltext und am Datenbankschema.

Warum hier keine Belegstellen stehen. Eine Datei- und Zeilenangabe aus dem Quellcode-Repository trüge hier nichts: Das Repository ist privat (§ 6.4), der Händler kann dort ohnehin nichts einsehen, und Zeilennummern veralten mit jeder Änderung. Ein Vertrag, der auf Zeilennummern verweist, wird mit jedem Programmierschritt ein Stück unrichtiger, ohne dass es jemandem auffällt.

Die Belegführung findet weiterhin statt, nur an ihrem Platz: in der internen Erhebung, die dieser Anlage zugrunde liegt, und in den Prüfungen, die sie gegen das echte Datenbankschema halten. Der für den Händler offene Weg zur Nachprüfung ist § 10.

Angaben nach Art. 30 Abs. 2 DSGVO

Die vollständigen Firmendaten des Händlers (Firmierung, Anschrift, Vertretung) erhebt KYTH nicht; sie ergeben sich aus dem Shopify-Konto des Händlers und werden bei einer Anfrage nach Art. 31 DSGVO über die hinterlegte Kontaktadresse erfragt.

Garantien nach Art. 30 Abs. 2 lit. c DSGVO. Für Übermittlungen an Shopify-Stellen außerhalb des EWR: die EU-Standardvertragsklauseln nach Durchführungsbeschluss (EU) 2021/914, einbezogen über Shopifys Data Processing Addendum. Für Kanada daneben der Angemessenheitsbeschluss 2002/2/EG. Einzelheiten und die beiden ausdrücklichen Nichtaussagen stehen in § 3.4.

A. Tatsächlich gespeicherte Daten

Die genannten Daten liegen in der PostgreSQL-Datenbank auf dem Server in Berlin und gehen in die Sicherungen nach § 9.3 Nr. 2 ein. Es gibt keinen gespeicherten Bestand außerhalb der Datenbank — keine Dateiablage, keinen Objektspeicher für Betriebsdaten, keine erzeugten und aufbewahrten Dokumente.

Diese Aufzählung nennt sich abschließend, und sie wird daran gemessen. Der Prüfstand liest die Tabellen des Datenbankschemas und fällt, sobald eine hinzukommt, die hier nicht geführt ist. Bei Kartuu nannte sich dieselbe Anlage abschließend und deckte zwei von elf Tabellen.

Die Zeile zu den Anwendungsprotokollen ist am 02.09.2026 berichtigt worden. Bis dahin nannte sie die Verbuchung einer Sendung gar nicht — obwohl der Programmteil, der sie schreibt, seit dem Vortag besteht und je verbuchter Sendung eine Zeile ausgab. Diese Zeile trug bis zum 02.09.2026 zusätzlich das Lieferland („Land AT"). Das Lieferland ist die einzige Angabe über eine Endkundin oder einen Endkunden, die diese App überhaupt führt; im Protokoll stand sie damit außerhalb der Datenbank, und § 9.1 sagt zu, mit dem Shop verschwinde alles — eine Protokollzeile erreicht aber weder shop/redact noch customers/redact. Sie ist deshalb ersatzlos aus dem Programm entfernt worden; geschrieben wird nur noch, ob ein Lieferland vorliegt. Der Prüfstand liest die Protokollzeile einer verbuchten Sendung und fällt, sobald das Lieferland wieder darin steht.

Am 09.09.2026 ist dieselbe Zeile um den Weg aus KYTH.Karl ergänzt worden. Der Programmteil, der eine Meldung aus Karl verbucht, gab in einem seiner Zweige die Kennung der Karl-Sendung aus — also einen Wert, den derselbe Bestand nach Anlage 1 Abschnitt A speichert und der damit im Löschweg steht. Das ist dieselbe Klasse wie beim Lieferland: Ein Protokoll erreicht keine Löschung und steht 14 Tage. Die Kennung ist ersatzlos aus dem Programm entfernt; geschrieben wird nur noch die interne Zeilenkennung des Eingangsbelegs, ein Zählwert dieser Datenbank, der außerhalb von ihr nichts bezeichnet. Der Prüfstand liest die Protokollzeile jenes Zweiges und fällt, sobald die Kennung der Karl-Sendung wieder darin steht.

Am 12.09.2026 ist dieselbe Zeile ein drittes Mal berichtigt worden, und zwar am selben Tag, an dem der Programmteil entstand. Das Versandprogramm schrieb in jeder seiner fünf Fehlerzeilen den Mailserver und den Port des Händlers mit („Versand: mail.seinname.de:587 hat den Empfänger abgelehnt"). Beide sind in Abschnitt A dieser Anlage als gespeicherte Angaben des Mailwegs geführt und stehen damit im Löschweg — dieselbe Klasse wie das Lieferland und die Kennung der Karl-Sendung: Ein Protokoll erreicht keine Löschung und steht 14 Tage, auch nach shop/redact. Sie sind ersatzlos aus dem Programm entfernt. Geschrieben wird stattdessen die interne Shop-Kennung — ohne sie sagte keine der fünf Zeilen, WELCHER Shop nicht verschicken kann, denn zwei Händler beim selben Anbieter erzeugten Wort für Wort dieselbe Ausgabe —, dazu der Ausnahmetyp und der Antwortcode des Mailservers. Der Prüfstand liest die Protokollzeile eines abgelehnten Empfängers und fällt, sobald der Mailserver oder sein Port wieder darin steht.

Ein Bestand hält die Mengen, die der Händler außerhalb von Shopify verschickt hat. Seine Tabelle besteht seit dem 07.09.2026 (Migration 0026). Der Bestand gibt es dem Händler in die Hand, seiner Meldung Mengen hinzuzufügen, die nicht aus seinem Shop stammen — Kuno sieht nur die Sendungen dieses einen Shops. Bis zum 07.09.2026 stand hier stattdessen „Eine Meldung an ein duales System geht über ALLE Kanäle eines Herstellers und nicht je Shopsystem; wer nur seine Shopify-Sendungen meldet, meldet zu wenig." Das war eine Aussage über die Pflichtenlage eines bestimmten Händlers, ohne Quelle, ohne Datum und ohne Ausnahme — in einem Text, dem er zustimmt, und von einer Stelle, die nach § 1.3 und nach der Spezifikation (§ 1, Nicht-Ziele) ausdrücklich keine Rechtsbeurteilung abgibt. Sie traf so auch nicht: § 7 Abs. 2 VerpackDG erhält für Serviceverpackungen die Übertragung auf den Vorvertreiber, und ein Händler mit Ladengeschäft, der vorbeteiligte Serviceverpackungen einsetzt, hätte nach diesem Satz Mengen doppelt gemeldet. Wer wissen will, welche Mengen aus welchen Kanälen in seine Meldung gehören, findet die Rechtsgrundlagen bei seinem Zielsystem und bei seiner Rechtsberatung; dieser Vertrag beschreibt nur, was Kuno mit den Zahlen tut, die der Händler selbst einträgt. Was hier steht, ist deshalb eine Angabe des Händlers über einen Kanal, den Kuno nicht sieht — Amazon, eBay, Ladenverkauf. Kuno holt davon nichts ab: Es gibt keine Amazon-Schnittstelle, keinen eBay-Abgleich und keinen Abgleich gegen fremde Umsätze. Der Bestand trägt keine Angabe über die Kundschaft des Händlers — eine Bestell-, Fulfillment- oder Kundenkennung kommt darin nicht vor, und er wird deshalb im Löschweg einer einzelnen Person nicht durchsucht (§ 7.2). Ein Posten ist eine Summe über einen fremden Kanal und gehört keiner einzelnen Bestellung. Das Lieferland steht darin; es ist die Angabe über ein Land und nicht über eine Person — welche Person in welches Land bestellt hat, steht in den Sendungen, und dort läuft der Personenweg. Für den Händler selbst gilt, was für jeden Bestand dieser Anlage mit einer Shop-Zuordnung gilt: Der Personenbezug ist mittelbar — hinter einem Shop steht in der Regel ein Unternehmen, bei einem Einzelunternehmen kann das eine natürliche Person sein. Beleg-Referenz und Notiz sind freier Text, den der Händler tippt oder als CSV übergibt; trägt er dort den Namen einer natürlichen Person ein, steht diese Angabe in dieser Tabelle, und das Datenbankschema kann das nicht verhindern — dieselbe Lage und dieselbe Einordnung wie beim Bestätigungstext eines Meldezeitraums. Eine eingetragene Menge ist nicht änderbar: Die Anwendungsrolle darf auf dieser Tabelle nur Beleg-Referenz und Notiz überschreiben. Wer eine Zahl korrigiert, löscht den Posten und legt ihn neu an — dann steht die Korrektur mit eigenem Eingabezeitpunkt in der Zeile; eine Menge, die sich lautlos verstellen lässt, wäre kein Beleg. Geschrieben wird in diesen Bestand seit dem 07.09.2026 über einen eigenen Programmteil, und seit dem Abend desselben Tages führen fünf Adressen dorthin: Der Händler listet seine Posten auf, legt einen an, löscht einen, übergibt eine Tabellendatei — die zuerst nur zur Ansicht geprüft und erst auf ausdrückliche Anweisung eingetragen wird — und holt sich die leere Vorlage dieser Datei. Alle fünf verlangen einen angemeldeten Händler-Nutzer dieses Shops. Was fehlt, ist die Bedienung — der Reiter „Zusatzmengen" der Meldungsseite trägt kein Bedienelement —, und bis dahin bleibt der Bestand in aller Regel leer. Bis zum Abend des 07.09.2026 stand hier „eine Adresse und eine Bedienseite dorthin gibt es an diesem Tag nicht — was der Händler einträgt, kommt mit dem Ausbau der Oberfläche, und bis dahin bleibt der Bestand leer"; die erste Hälfte traf ab jenem Abend nicht mehr zu, und ein Bestandsverzeichnis, das einen Weg in einen Bestand verschweigt, beschreibt den Bestand nicht. Er verschwindet vollständig mit dem Shop — Fremdschlüssel mit Löschweitergabe, wie jeder Bestand mit Shop-Zuordnung (§ 9.3 Nr. 1).

Auch diese Aufzählung ist spaltengenau, und der Prüfstand hält sie gegen das Datenbankschema; seine Reichweite und seine Grenze sind dieselben wie bei den übrigen Aufzählungen dieses Abschnitts und stehen dort.

Mengen aus anderen Kanälen — je Posten: die Bezeichnung des Kanals, das Lieferland, Beginn und Ende des Zeitraums, die Materialfraktion, die Masse in Kilogramm, die Stückzahl, eine Beleg-Referenz und eine Notiz des Händlers sowie der Zeitpunkt der Anlage dieser Zeile, dazu ein technischer Zeilenschlüssel und die Shop-Zuordnung, über die zugleich der Zeilenschutz der Datenbank wirkt (Anlage 2 Abschnitt 1.2). Ein Posten liegt in genau einem Kalenderjahr — die Datenbank weist einen Zeitraum über den Jahreswechsel ab, weil die Materialarten am Jahr hängen (§ 42 Abs. 2 und § 68 VerpackDG) und ein solcher Posten keiner der beiden Fassungen zuzuordnen wäre.

Ein Bestand führt die berechneten Materialzeilen einer Sendung. Seine Tabelle besteht seit dem 04.09.2026. Sie ist das Ergebnis einer Rechnung: Für jedes Paket steht darin je Materialfraktion und Verpackungsebene ein Gewicht in Gramm — die Zahl, aus der später die Jahresmenge für ein duales System entsteht. Eine eigene Angabe über die Kundschaft des Händlers trägt sie nicht; sie hängt über den Verweis auf das Paket an einer Sendung, und über deren Bestellkennung wird sie im Löschweg einer einzelnen Person gefunden und gezählt (§ 7.2). Geleert wird darin nichts, aus demselben Grund wie bei den drei Beständen des Mengenkontos: Die Zeile ist der Nachweis über eine abgegebene Meldung (Art. 17 Abs. 3 lit. b DSGVO). Die Anwendungsrolle hat auf der Tabelle der Materialzeilen kein Änderungsrecht — auf keiner einzigen Spalte; sie darf darin nur einfügen, lesen und löschen. Bis zum 04.09.2026 stand hier „auf dieser Tabelle"; der Prüfstand bindet eine solche Zusage satzweise an den Tabellennamen und erreichte sie deshalb nicht. Ändert sich der Katalog rückwirkend, wird das Paket neu gerechnet: Die alten Zeilen werden gelöscht, die neuen geschrieben, und der Zeitpunkt der Berechnung sagt, wann das geschah. Ein umgeschriebenes Gewicht wäre dasselbe Ergebnis ohne den sichtbaren Anlass. Seit dem 04.09.2026 gibt es den Rechenlauf, der diese Tabelle füllt — die Materialisierung eines Pakets. Seit demselben Tag ruft ihn die Zuordnung eines Pakets; angestoßen wird diese Zuordnung seit dem Abend desselben Tages (19:56 Uhr) vom Zuordnungslauf, der mit der Anwendung startet und offene Pakete aus der Datenbank holt. Wie viele Zeilen darin stehen, hängt damit am Bestand des Shops und ist keine Zusage dieses Vertrages. Bis zu jener Stunde stand hier „angestoßen wird diese Zuordnung im laufenden Betrieb von keiner Stelle des Programms und von keiner Bedienseite"; das galt eine Stunde und achtundfünfzig Minuten, nämlich zwischen der Zuordnungskette (17:57 Uhr) und dem Lauf, der sie ruft (19:56 Uhr). Bis zum späten Abend des 04.09.2026 stand hier „Ausgelöst wird er heute von keiner Stelle des Programms und von keiner Bedienseite"; das war für den Vormittag desselben Tages richtig und wurde am Abend durch die Zuordnungskette überholt. Bis zum Abend des 04.09.2026 endete dieser Absatz mit „Wie viele Zeilen darin stehen, hängt damit am Bestand des Shops und ist keine Zusage dieses Vertrages" - ohne den Vorbehalt, der im Impressum und in § 2.1 des Nutzungsvertrages von Anfang an stand. Dieselbe Sache in vier Dokumenten unterschiedlich vollständig zu führen ist genau der Befund, mit dem das Schlussreview zu Plan 2 das Impressum beanstandet hat. Bis zum Vormittag desselben Tages stand hier „Geschrieben wird diese Tabelle heute von keinem Programmteil — der Rechenlauf, der sie füllt, entsteht mit der Mengenermittlung; diese Aufzählung beschreibt das Schema und nicht seinen Füllstand." Der Satz war an dem Tag richtig, an dem er geschrieben wurde, und einen Tag später nicht mehr; er steht hier als Zitat, damit dieselbe Formulierung nicht zurückkehrt.

Auch diese Aufzählung ist spaltengenau, und der Prüfstand hält sie gegen das Datenbankschema; seine Reichweite und seine Grenze sind dieselben wie bei den Aufzählungen weiter unten und stehen dort.

Materialzeilen einer Sendung — je Materialfraktion und Verpackungsebene eines Pakets: der Verweis auf das Paket, der Materialcode, die Verpackungsebene (Versand- oder Verkaufsverpackung), das Gewicht in Gramm, die Stückzahl, der Belegstatus (belegt oder Referenzwert), der Verweis auf die Stücklistenfassung, mit der gerechnet wurde, sowie der Zeitpunkt der Berechnung, dazu ein technischer Zeilenschlüssel und die Shop-Zuordnung, über die zugleich der Zeilenschutz der Datenbank wirkt (Anlage 2 Abschnitt 1.2).

Ein Bestand führt die Zuordnungsregeln des Händlers. Seine Tabelle besteht seit dem 04.09.2026. Sie trägt keine Angabe über die Kundschaft des Händlers — eine Bestell-, Fulfillment- oder Kundenkennung kommt darin nicht vor, und sie wird deshalb im Löschweg einer einzelnen Person nicht durchsucht (§ 7.2). Für den Händler selbst gilt, was für jeden Bestand dieser Anlage mit einer Shop-Zuordnung gilt: Der Personenbezug ist mittelbar — hinter einem Shop steht in der Regel ein Unternehmen, bei einem Einzelunternehmen kann das eine natürliche Person sein. Eine Regel besteht aus einer Bezeichnung, einer Reihenfolge und einer Bedingung; die Bedingung kann ein Zielland, ein Gewichts- oder Stückzahlband, den Anfang einer Artikelnummer, ein Schlagwort, eine Produkt-, Standort- oder Versanddienstkennung und den Zusteller nennen. Alle diese Angaben beschreiben ein Sortiment oder einen Versandweg und keine Person; welches Paket eine bestimmte Bestellung bekommen hat, steht nicht hier, sondern in den Paketen einer Sendung. Die Bezeichnung ist wie beim Katalog freier Text, den der Händler selbst füllt — trägt er dort den Namen eines Einzelkaufmanns ein, steht in dieser Tabelle eine Angabe über eine natürliche Person; das Datenbankschema kann das nicht verhindern. Bis zum 04.09.2026 standen die Zuordnungsregeln in Abschnitt C dieser Anlage mit dem Satz „Die Regeln, nach denen aus dem Verpackungskatalog ein Paket gewählt wird, haben im Datenbankschema keine Tabelle; niemand kann heute eine Regel schreiben“; seit der Migration 0019 trifft der erste Halbsatz nicht mehr zu, und seit dem Bau der Endpunkte am selben Tag auch der zweite nicht mehr — geschrieben werden kann eine Regel. Seit dem Abend des 06.09.2026 trägt der Reiter „Regeln" der Verpackungsseite die Bedienelemente dazu: anlegen, vorab ansehen, beenden. Was in Abschnitt C bleibt, ist das Ändern einer bestehenden Regel, und das ist eine Aussage über einen Bildschirm und keine darüber, ob eine Regel überhaupt entstehen kann. Bis zu jenem Abend stand hier „Was in Abschnitt C bleibt, sind die fehlenden Bedienelemente". Bis zum späten Abend des 04.09.2026 stand an dieser Stelle das Gegenteil: der zweite Halbsatz stehe „als Aussage über die fehlende Bedienseite in Abschnitt C weiter“ — zwei Sätze vor der Berichtigung, die derselbe Änderungsdurchgang gleich daneben gesetzt hat. Eintragen kann der Händler seit dem 04.09.2026, bedienen seit dem Abend des 06.09.2026 — dieselbe Lage wie beim Verpackungskatalog darunter. Bis zu jenem Abend endete dieser Satz mit „Die Endpunkte dorthin bestehen, die Bedienelemente fehlen". Bis zu jenem Tag stand hier „Eintragen kann der Händler heute nichts: Es gibt keine Bedienseite und keine Route dorthin"; die zweite Hälfte trägt seit dem Bau der Endpunkte nicht mehr. Wie bei den Beständen darunter trägt auch dieser zusätzlich zu den genannten Angaben einen technischen Zeilenschlüssel und die Shop-Zuordnung, über die zugleich der Zeilenschutz der Datenbank wirkt (Anlage 2 Abschnitt 1.2).

Auch diese Aufzählung ist spaltengenau, und der Prüfstand hält sie gegen das Datenbankschema; seine Reichweite und seine Grenze sind dieselben wie bei den Aufzählungen weiter unten und stehen dort. Die Bedingung einer Regel ist nachträglich nicht änderbar — die Anwendungsrolle hat auf dieser Spalte kein Änderungsrecht. Eine geänderte Bedingung ist eine neue Zeile mit eigener Fassungsnummer; die alte bleibt stehen, weil in jeder mit ihr zugeordneten Paketzeile die Kennung genau dieser Fassung steht.

Zuordnungsregeln — je Regel: die Reihenfolge, in der sie geprüft wird, ihre Bezeichnung, die Bedingung als Objekt, der Verweis auf die Verpackungseinheit, die laufende Fassungsnummer, ein Pflegevermerk aktiv, Beginn und Ende der Gültigkeit sowie der Zeitpunkt der Anlage dieser Zeile.

Drei Bestände führen den Verpackungskatalog des Händlers. Ihre Tabellen bestehen seit dem 03.09.2026. Sie tragen keine Angabe über die Kundschaft des Händlers — eine Bestell-, Fulfillment- oder Kundenkennung kommt in keiner der drei Tabellen vor, und keine von ihnen wird deshalb im Löschweg einer einzelnen Person durchsucht (§ 7.2). Für den Händler selbst gilt, was für jeden Bestand dieser Anlage mit einer Shop-Zuordnung gilt: Der Personenbezug ist mittelbar — hinter einem Shop steht in der Regel ein Unternehmen, bei einem Einzelunternehmen kann das eine natürliche Person sein. Hinzu kommt, dass drei Angaben dieser Tabellen freier Text sind, den der Händler selbst füllt: der Lieferant, der Belegverweis und die eigenen Wiegungen. Trägt er dort den Namen eines Einzelkaufmanns ein, steht in diesen Tabellen eine Angabe über eine natürliche Person; das Datenbankschema kann das nicht verhindern. Der Katalog wird deshalb durchgehend als Angabe des Händlers behandelt — so führt ihn auch die Datenschutzerklärung in Abschnitt 5.1, mit Art. 6 Abs. 1 lit. b DSGVO als Rechtsgrundlage. Bis zum 04.09.2026 stand hier: „Sie tragen keine Angabe über eine Person — weder über die Kundschaft des Händlers noch über ihn selbst: Was hier steht, beschreibt sein Lager." Der zweite Halbsatz war eine Zusage, die das Schema nicht hält, und er widersprach der Datenschutzerklärung, der derselbe Händler im selben Durchgang zustimmt. Am Löschweg ändert die Berichtigung nichts: Von einer gemeldeten Person führt in diese Tabellen weiterhin kein Merkmal (§ 7.2). Bis zum 03.09.2026 stand in Abschnitt C dieser Anlage: „Der Katalog und die Regeln haben im Datenbankschema keine Tabelle." Seit der Migration 0018 trifft das für den Katalog nicht mehr zu, und er ist deshalb hierher gewandert. Eintragen kann der Händler seit dem 04.09.2026, bedienen seit dem Abend des 06.09.2026 — der Reiter „Katalog" der Verpackungsseite führt seither die Felder und Knöpfe dazu. Was Abschnitt C dieser Anlage noch als nicht bedienbar führt, ist das Ändern einer bereits angelegten Komponente. Bis zu jenem Abend endete dieser Satz mit „Die Endpunkte dorthin bestehen, die Bedienelemente fehlen — genau das, und nur das, führt Abschnitt C dieser Anlage seit jenem Tag noch als nicht gebaut". Bis dahin stand hier „Eintragen kann der Händler heute nichts: Es gibt keine Bedienseite und keine Route dorthin"; die zweite Hälfte trägt seit dem Bau der Endpunkte nicht mehr. Bis zu jenem Tag stand an dieser Stelle, die Zuordnungsregeln, mit denen aus dem Katalog eine Menge entsteht, stünden „weiterhin in Abschnitt C"; ihre Tabelle ist an diesem Tag mit der Migration 0019 angelegt worden, und sie stehen seither eine Aufzählung weiter oben in diesem Abschnitt. Bis zum 04.09.2026 stand hier stattdessen: „Zeilen trägt heute keine der drei: Der Zugriffsweg auf diese Tabellen ist gebaut, aber kein Programmteil ruft ihn". Der zweite Halbsatz trägt seit diesem Tag nicht mehr — die Fachschicht der Katalogpflege ruft alle drei Schreibwege —, und damit ist auch der erste keine Zusage mehr, die ein Vertrag halten kann: Wie viele Zeilen dastehen, hängt vom Katalog des Händlers ab und nicht von diesem Text. Was gleich geblieben ist und die eigentliche Auskunft trägt, ist die Bedienbarkeit — und die ist seit dem Abend des 06.09.2026 gegeben, bis auf das Ändern einer bereits angelegten Komponente. Bis zu jenem Abend endete dieser Satz mit „sind die fehlenden Bedienelemente". Wie bei den Beständen darunter trägt jede der drei zusätzlich zu den genannten Angaben einen technischen Zeilenschlüssel und die Shop-Zuordnung, über die zugleich der Zeilenschutz der Datenbank wirkt (Anlage 2 Abschnitt 1.2).

Auch diese drei Aufzählungen sind spaltengenau, und der Prüfstand hält sie gegen das Datenbankschema; seine Reichweite und seine Grenze sind dieselben wie bei den Aufzählungen weiter unten und stehen dort. Ein Gewicht, ein Material und eine Stückliste sind nachträglich nicht änderbar — die Anwendungsrolle hat auf diesen Spalten kein Änderungsrecht. Eine Änderung ist eine neue Zeile mit eigener Gültigkeit; die alte bleibt stehen, weil sie die Grundlage jeder Menge ist, die je mit ihr gerechnet wurde.

Verpackungskomponenten — je Komponente: die Bezeichnung der Komponente, die Art der Komponente aus einem festen Vokabular (Karton, Versandtasche, Polsterumschlag, Klebeband, Etikett, Füllmaterial, Folie, Sonstiges), der Materialcode, eine Kunststoffbezeichnung, eine Formangabe (starr oder flexibel), die Bezugsgröße (Stück oder Meter), das Gewicht in Milligramm je Bezugsgröße, die Art des Belegs (Referenzwert, Lieferantenrechnung, Herstellerdatenblatt oder eigene Wiegung), ein Belegverweis und ein Belegdatum, die eigenen Wiegungen als Liste, Beginn und Ende der Gültigkeit, der Lieferant und die Artikelnummer des Lieferanten, ein Pflegevermerk aktiv, das Kennzeichen gebrandet — die Angabe des Händlers, ob er diese Komponente selbst erstmals in Verkehr bringt — sowie der Zeitpunkt der Anlage dieser Zeile. Das Kennzeichen gebrandet steht seit dem 04.09.2026 dort; es wirkt nur unter der Betriebsart „nur gebrandet“ und ist mit ihr zusammen entstanden. Setzen kann der Händler es seit dem 06.09.2026, beim Anlegen einer Komponente und bei jeder Änderung. Bis zu diesem Tag war die Angabe an dieser Stelle keine des Händlers: Die Spalte trug den Vorgabewert der Migration (gebrandet = ja), es gab keinen Weg, sie zu setzen, und eine Änderung an der Komponente stellte sie zusätzlich auf diesen Vorgabewert zurück. Wer zugekaufte, vom Lieferanten bereits lizenzierte Verpackung führte, konnte das nicht erklären — und der Nachweis wies sie trotzdem als selbst in Verkehr gebracht aus.

Verpackungseinheiten — je Einheit: die Bezeichnung der Einheit, Länge, Breite und Höhe in Zentimetern, ein Pflegevermerk aktiv, die Kennungen fremder Systeme, unter denen der Händler dieselbe Verpackung führt (etwa ein Preset seiner Versand-App), sowie der Zeitpunkt der Anlage dieser Zeile.

Stücklistenversionen — je Fassung: der Verweis auf die Verpackungseinheit, die laufende Fassungsnummer, die Stückliste als Liste aus Komponentenkennung, Menge und Mengenregel, Beginn und Ende der Gültigkeit sowie der Zeitpunkt der Anlage dieser Zeile. Bis zum 04.09.2026 nannte diese Zeile nur „Komponentenkennung und Menge" und ließ damit das dritte Feld jedes Eintrags ungenannt.

Ein Bestand führt die Produktverpackung je Variante. Seine Tabelle besteht seit dem 07.09.2026 (Migration 0027). Gemeint ist die Verpackung des Produktes — das Glas, der Deckel, das Etikett —, nicht der Karton, in dem es verschickt wird; welche Länder der Händler damit in seiner Meldung führt, wählt er selbst aus, und KYTH beurteilt diese Wahl nicht (§ 1.3 Nr. 6). Der Bestand trägt keine Angabe über die Kundschaft des Händlers — eine Bestell-, Fulfillment- oder Kundenkennung kommt darin nicht vor, und er wird deshalb im Löschweg einer einzelnen Person nicht durchsucht (§ 7.2). Die Variantenkennung ist eine Kennung aus dem eigenen Produktkatalog des Händlers; welche Person welche Variante bestellt hat, steht in den Positionen einer Sendung, und dort läuft der Personenweg. Für den Händler selbst gilt, was für jeden Bestand dieser Anlage mit einer Shop-Zuordnung gilt: Der Personenbezug ist mittelbar — hinter einem Shop steht in der Regel ein Unternehmen, bei einem Einzelunternehmen kann das eine natürliche Person sein. Freien Text nehmen die beiden Kennungen und die Länderauswahl nicht auf: Beide Kennungen stehen unter einem festen Muster, jedes Land unter genau zwei Großbuchstaben; ein Name ließe sich in keines dieser Felder eintragen — anders als bei der Beleg-Referenz eines Postens aus einem anderen Kanal, die diese Anlage ausdrücklich mit dem gegenteiligen Vorbehalt führt. Für die Stückliste gilt dieser Satz nicht, und das steht hier ausdrücklich. Sie ist kein Textfeld, sondern ein strukturiertes Feld, und das Datenbankschema bindet an ihr nur die Form — ein Array mit einem bis zwanzig Einträgen —, nicht die Namen der Felder in einem Eintrag. Heute schreibt der Programmteil dort ausschließlich die Kennung einer Verpackungskomponente und eine Menge; nimmt der Programmteil je Eintrag einmal ein freies Feld auf, kann darin auch ein Name stehen, und dann sind dieser Absatz und die Einordnung zum Löschweg (§ 7.2) zu berichtigen. Bis zum 08.09.2026 sagte dieser Absatz „Freien Text nimmt dieser Bestand nicht auf" und begründete es allein mit den beiden Kennungen und der Länderauswahl — die Stückliste blieb ungenannt, und die Zusage galt damit einem Feld mit, das sie nicht deckte. Die Prüfung im Prüfstand, die diese Klasse misst, sieht ein strukturiertes Feld nicht: Sie liest Textspalten. Dieser Absatz ist deshalb der einzige Ort, an dem der Vorbehalt steht, und eine eigene Prüfung hält ihn in allen drei Zustimmungstexten. Die Hausform ist dieselbe wie bei der Bedingung einer Zuordnungsregel, die ebenfalls in einem strukturierten Feld steht und über die diese Anlage aus demselben Grund keine solche Absolutzusage macht. Auf der Tabelle varianten_verpackungen hat die Anwendungsrolle kein Änderungsrecht. Eine geänderte Stückliste verschöbe rückwirkend, was in einer abgegebenen Meldung steht; eine Änderung ist deshalb eine neue Fassung mit eigenem „Gilt ab", und die alte bleibt als Grundlage jeder Menge stehen, die je mit ihr gerechnet worden ist. Entfernen kann der Händler eine Variante, und dann samt allen ihren Fassungen. Geschrieben wird in diesen Bestand seit dem 07.09.2026 über einen eigenen Programmteil; seit dem Abend des 08.09.2026 führen drei Adressen der App dorthin — die Verpackung je Variante ansehen, eine Fassung speichern und alle Fassungen einer Variante zurücknehmen —, und die Produktseite trägt seit demselben Abend die Bedienelemente dazu (Abschnitt C dieser Anlage). Bis zu jenem Abend stand hier „eine Adresse der App und einen Bildschirm dafür gibt es an diesem Tag nicht — die Produktseite trägt kein Bedienelement, und Abschnitt C dieser Anlage führt genau das auf: die fehlenden Bedienelemente. Die fehlende Adresse führt allein dieser Abschnitt hier."; beide Hälften tragen seither nicht mehr. Bis zum Vormittag des 08.09.2026 stand hier zusätzlich, Abschnitt C führe „beides" als nicht vorhanden; das trug schon damals nicht: Jene Zeile sagte für die Produktverpackung ausdrücklich nur, dass die Bedienelemente fehlen, und der Vorspann desselben Abschnitts stellt klar, sie spreche „überhaupt nicht von einem Bestand, sondern von den Bedienelementen zweier Bildschirme". Eine Aufsicht, die dem Verweis folgte, fand die zugesagte Aussage dort nicht. Er verschwindet vollständig mit dem Shop — Fremdschlüssel mit Löschweitergabe, wie jeder Bestand mit Shop-Zuordnung (§ 9.3 Nr. 1).

Auch diese Aufzählung ist spaltengenau, und der Prüfstand hält sie gegen das Datenbankschema; seine Reichweite und seine Grenze sind dieselben wie bei den übrigen Aufzählungen dieses Abschnitts und stehen dort.

Verpackung je Produktvariante — je Fassung: die Shopify-Kennung der Variante, die Shopify-Kennung des Produktes, die Stückliste aus Verpackungskomponenten mit ihrer Menge, die vom Verantwortlichen ausgewählten Länder, die laufende Fassungsnummer, der Beginn der Gültigkeit sowie der Zeitpunkt der Anlage dieser Zeile. Dazu — wie bei den Beständen darüber — ein technischer Zeilenschlüssel und die Shop-Zuordnung, über die zugleich der Zeilenschutz der Datenbank wirkt (Anlage 2 Abschnitt 1.2).

Zwei Bestände führen die Meldevorgaben des Händlers. Ihre Tabellen bestehen seit dem 06.09.2026 (Migration 0025). Sie tragen keine Angabe über die Kundschaft des Händlers — eine Bestell-, Fulfillment- oder Kundenkennung kommt in keiner von beiden vor, und keine von ihnen wird deshalb im Löschweg einer einzelnen Person durchsucht (§ 7.2). Für den Händler selbst gilt, was für jeden Bestand dieser Anlage mit einer Shop-Zuordnung gilt: Der Personenbezug ist mittelbar — hinter einem Shop steht in der Regel ein Unternehmen, bei einem Einzelunternehmen kann das eine natürliche Person sein. Die Registrierungsnummer bei einem dualen System ist eine Registernummer des UNTERNEHMENS und kein Kundendatum — dieselbe Einordnung wie bei der LUCID-Nummer weiter oben. Geschrieben werden beide seit dem 06.09.2026 über je einen eigenen Programmteil, und seit dem Abend desselben Tages gibt es Adressen dorthin — über sie liest der Händler seine Zielsysteme, legt eines für ein Land an, ändert es, nimmt es zurück, liest seinen Fristenkalender und hakt einen Termin ab. Bis zum Abend des 06.09.2026 stand hier, „eine Adresse und eine Bedienseite dorthin gibt es an diesem Tag nicht — was der Händler an Zielsystemen und Terminen einträgt, kommt mit dem Ausbau der Oberfläche, und bis dahin bleibt der Bestand leer"; die Adressen gibt es seither, und der Bestand füllt sich damit wirklich. Seit dem späten Abend des 06.09.2026 stehen auch die Bedienelemente darauf: Die Administration führt die Karte „Zielsysteme je Land“ — Land, System, Registrierungsnummer, Vertragsfrist und Meldeintervall werden dort eingetragen und ein Land wird dort zurückgenommen — und die Karte „Fristen“, die jeden Termin mit seinem Datum, seiner Quelle und seinem Abstand zu heute zeigt und ihn abhaken lässt, wahlweise mit einer Bestätigungsnummer. Bis zu jenem Abend endete dieser Satz mit „Was weiterhin fehlt, sind die Bedienelemente darauf: Sie kommen mit dem Ausbau der Oberfläche“. Woher die Termine kommen, sobald es sie gibt: Seit dem Nachmittag des 06.09.2026 steht über dem Fristenkalender ein Programmteil, der sie aus den Zielsystemen ableitet — je Land die Termine, für die eine öffentliche Quelle geprüft ist, samt der Fundstelle und ihrem Stand, und daneben die Frist, die der Händler in seinem Systemvertrag eingetragen hat. Getippt ist davon nur seine Vertragsfrist; alles andere ist eine Rechnung dieser App und keine Angabe aus seiner Hand. Angestoßen wird dieser Programmteil seit dem Abend des 06.09.2026 vom Händler selbst: Jede Änderung an einem Zielsystem räumt die noch BEVORSTEHENDEN offenen Termine dieses Landes weg und lässt sie neu entstehen. Zwei Arten von Terminen bleiben dabei stehen: die bereits abgehakten, weil sie der Nachweis über eine abgegebene Meldung sind, und die überfälligen offenen, weil der Erzeuger keinen vergangenen Termin anlegt und sie sonst spurlos verschwänden. Nimmt der Händler ein Land dagegen ganz zurück, gehen alle offenen Termine dieses Landes mit — dann steht kein Zielsystem mehr da, aus dem ein Termin folgen könnte. Bis zum Abend jenes Tages stand hier, „Angestoßen wird dieser Programmteil an diesem Tag von nichts, und deshalb bleibt der Bestand leer, bis es die Bedienseite gibt"; beide Hälften treffen seither nicht mehr zu. Dieser Zusatz steht hier, weil der Satz darüber sonst gelesen wird, als stamme der ganze Kalender aus Eingaben des Händlers. Das Bestätigungskennzeichen einer erledigten Frist ist freier Text, den der Händler aus seinem Zielsystem abschreibt; trägt er dort den Namen einer natürlichen Person ein, steht diese Angabe in dieser Tabelle, und das Datenbankschema kann das nicht verhindern — dieselbe Lage und dieselbe Einordnung wie beim Bestätigungstext der Meldezeiträume. Wie bei den Beständen darüber trägt jede der beiden zusätzlich zu den genannten Angaben einen technischen Zeilenschlüssel und die Shop-Zuordnung, über die zugleich der Zeilenschutz der Datenbank wirkt (Anlage 2 Abschnitt 1.2). Beide verschwinden vollständig mit dem Shop — Fremdschlüssel mit Löschweitergabe, wie jeder Bestand mit Shop-Zuordnung (§ 9.3 Nr. 1).

Beide Aufzählungen sind spaltengenau, und der Prüfstand hält sie gegen das Datenbankschema; seine Reichweite und seine Grenze sind dieselben wie bei den übrigen Aufzählungen dieses Abschnitts und stehen dort. Das Land einer bestehenden Zeile ist nachträglich nicht änderbar — die Anwendungsrolle hat auf dieser Spalte in beiden Tabellen kein Änderungsrecht; ein geändertes Land wäre ein Termin, der lautlos in einen anderen Kalender umzieht. Aus demselben Grund lassen sich Bezeichnung, Datum und Quelle eines Termins nicht überschreiben: Ein Termin wird abgehakt oder gelöscht, nicht umgeschrieben.

Zielsysteme je Land — je Land: der Ländercode, der Code des beauftragten Systems, die Registrierungsnummer des Händlers bei diesem System, die Frist seines Vertrages, das vereinbarte Meldeintervall (jährlich, quartalsweise oder monatlich) sowie der Zeitpunkt der Anlage dieser Zeile. Je Shop und Land steht genau eine Zeile; die Datenbank lässt keine zweite zu.

Fristenkalender des Händlers — je Termin: der Ländercode, die Bezeichnung des Termins, sein Datum, die Quelle als Zitat mit Datum, der Zeitpunkt der Erledigung und das Bestätigungskennzeichen aus dem Zielsystem sowie der Zeitpunkt der Anlage dieser Zeile. Derselbe Termin steht je Shop, Land, Bezeichnung und Datum genau einmal; die Datenbank lässt keine zweite Zeile zu, und deshalb darf der Erzeuger beliebig oft laufen.

Zwei Bestände führen den Verbund mehrerer Shops zu einer Rechtseinheit. Ihre Tabellen bestehen seit dem 08.09.2026 (Migration 0028). Sie tragen keine Angabe über die Kundschaft des Händlers — eine Bestell-, Fulfillment- oder Kundenkennung kommt in keiner von beiden vor, und keine von ihnen wird deshalb im Löschweg einer einzelnen Person durchsucht (§ 7.2). Es sind Angaben des Verantwortlichen über sich selbst: Die Rechtseinheit ist der Hersteller, für den gemeldet wird. Für ihn gilt, was für jeden Bestand dieser Anlage mit einer Shop-Zuordnung gilt: Der Personenbezug ist mittelbar — hinter einem Shop steht in der Regel ein Unternehmen, bei einem Einzelunternehmen kann das eine natürliche Person sein. Beim Firmennamen ist das mehr als eine Möglichkeit: Bei einem Einzelunternehmen ist die Firma der Name einer natürlichen Person, und das Feld nimmt jeden Text an (siehe die Zeile darunter). Geschrieben wird über einen eigenen Programmteil; seit dem 08.09.2026 führen sechs Adressen der App dorthin — die Einheit ansehen, benennen und auflösen, einen Verbindungscode erzeugen, ihn einlösen und die eigene Verbindung lösen. Was weiterhin fehlt, sind die Bedienelemente: Die Administration führt eine Karte „Rechtseinheit" ohne ein einziges, und ohne sie bleibt dieser Weg für einen Händler unbedienbar. Bis zum 08.09.2026 stand hier „eine Adresse und eine Bedienseite dorthin gibt es am 08.09.2026 nicht — sie kommen mit den folgenden Aufgaben desselben Plans, und bis dahin bleiben beide Bestände leer"; die erste Hälfte trägt seit den Adressen nicht mehr, und mit ihr fällt auch der Zusatz über die leeren Bestände. Die Bestände stehen trotzdem hier und nicht in Abschnitt C, weil beide Abschnitte gegen die Tabellen des Datenbankschemas gemessen werden — und diese Tabellen gibt es. Auch diese beiden Aufzählungen sind spaltengenau; ihre Reichweite und ihre Grenze sind dieselben wie bei den übrigen Aufzählungen dieses Abschnitts und stehen dort.

Rechtseinheit mehrerer Shops — je Einheit: der Firmenname, die Umsatzsteuer-Identifikationsnummer, die LUCID-Nummer sowie der Zeitpunkt der Anlage dieser Zeile. Dazu ein technischer Zeilenschlüssel und die Shop-Zuordnung; sie benennt hier den Shop, der die Einheit verwaltet, und über sie wirkt zugleich der Zeilenschutz der Datenbank (Anlage 2 Abschnitt 1.2). Je Shop gibt es höchstens eine verwaltete Einheit; die Datenbank lässt keine zweite zu. Der Firmenname ist freier Text, den der Verantwortliche selbst einträgt — trägt er dort den Namen einer natürlichen Person ein, was bei einem Einzelunternehmen die richtige Eingabe ist, steht diese Angabe in dieser Tabelle; das Datenbankschema kann das nicht verhindern und prüft nur, dass das Feld nicht leer und nicht länger als 120 Zeichen ist. Umsatzsteuer- und LUCID-Nummer stehen dagegen unter einem Muster. Welche weiteren Shops zu einer Einheit gehören, steht nicht hier, sondern als Verweis in der Shop-Zeile selbst (§ 2.2, Aufzählung „Shop"). Die Einheit verschwindet mit dem Shop, der sie verwaltet — Fremdschlüssel mit Löschweitergabe (§ 9.3 Nr. 1); die verbundenen Shops bleiben bestehen und stehen danach wieder allein. Ebenso bleiben bereits erzeugte Meldezeiträume stehen und verlieren nur den Verweis auf die Einheit — auch ein festgeschriebener, an dem sonst nichts mehr geändert wird. Bis zum 08.09.2026 sagte dieser Vertrag das, und die Datenbank tat es nicht: Der Riegel, der einen festgeschriebenen Meldezeitraum unverändert hält, wies auch das Leeren dieses einen Verweises ab, und das Auflösen der Einheit brach damit ab (gemessen am selben Tag). Seither lässt der Riegel genau diesen einen Übergang durch und sonst nichts.

Verbindungscodes der Rechtseinheit — je Code: ein Prüfwert (SHA-256) des Codes, sein Ablaufzeitpunkt, der Zeitpunkt der Anlage sowie der Vermerk, welcher Shop wann beigetreten ist, dazu ein technischer Zeilenschlüssel und der Verweis auf die Einheit. Der Code selbst wird nicht gespeichert — aus dem Prüfwert lässt er sich nicht zurückrechnen, und wer die Datenbank liest, kann damit keinen Shop in eine fremde Einheit hängen. Ein Code gilt 24 Stunden und genau einmal, und beide Grenzen hält die Datenbank selbst: ein Prüfsatz auf der Zeile lässt keinen späteren Ablaufzeitpunkt zu, und der Beitrittsvermerk lässt kein zweites Einlösen zu. Bis zum 08.09.2026 stand die Zahl 24 nur in diesem Satz und in der Datenschutzerklärung und in keiner Prüfung — eine Zahl in einem Zustimmungstext, die das Programm nicht trägt; seither steht sie einmal im Quelltext, einmal im Datenbankschema, und eine Prüfung hält beide gegen diese Stelle. Diese Tabelle trägt keine Shop-Zuordnung, und das ist eine Entscheidung: Wer einen Code einlöst, gehört noch zu keiner Einheit und wäre über den Zeilenschutz gar nicht auffindbar. Sie ist damit eine von vier Tabellen dieser Anlage ohne eine solche Zuordnung; die drei anderen sind shops selbst — sie IST die Zuordnung —, webhook_claims (Duplikatschutz eingehender Meldungen) und alembic_version (Migrationsstand des Schemas), alle drei oben in der Tabelle dieses Abschnitts. Bis zu seiner Berichtigung am 08.09.2026 sagte dieser Satz „als einzige dieser Anlage" — das war falsch, und dieselbe Anlage widerlegte es einige hundert Zeilen weiter oben in ihrer eigenen Tabelle, die webhook_claims ausdrücklich „ohne Shop-Zuordnung" führt. Wer Abschnitt A liest, um für sein Verarbeitungsverzeichnis nach Art. 30 DSGVO festzustellen, welche Bestände keinem Mandanten zugeordnet sind, bekam damit „genau einer" statt vier. Die Tabelle enthält dafür sieben Spalten: einen Prüfwert, DREI Zeitpunkte (Ablauf, Anlage, Beitritt) und drei Kennungen (die Zeile selbst, die Einheit und — sobald ein Code eingelöst ist — den beigetretenen Shop). Über einen fremden Shop erfährt man daraus sehr wohl etwas, und dieser Satz sagte bis zum Schlussreview zu Plan 5 das Gegenteil („nichts, woraus jemand etwas über einen fremden Shop erführe — einen Prüfwert, zwei Zeitpunkte und zwei Kennungen"): Wer die Anwendungsrolle hat, liest hier ohne Mandantenschranke, welcher Shop wann welcher Einheit beigetreten ist. Ein Name, eine Adresse oder eine Angabe über Kundschaft steht nicht darin. Sie verschwindet mit der Einheit, zu der sie gehört (Löschweitergabe), und der Beitrittsvermerk verliert seinen Shop, sobald dieser Shop gelöscht wird.

Zwei Bestände führen die Buchführung des Abrufs. Ihre Tabellen bestehen seit dem 02.09.2026; die Zeilen der Abgleichläufe entstehen seither im laufenden Betrieb (§ 3.4), die der Warteschlange erst mit dem ersten angeforderten Auftrag. Bis zum 02.09.2026 stand hier, beide trügen „heute keine Zeile". Sie stehen aus demselben Grund hier wie die vier Bestände darunter: Beide Abschnitte werden gegen die Tabellen des Datenbankschemas gemessen, und diese Tabellen gibt es. Wie dort trägt jede von ihnen zusätzlich zu den genannten Angaben einen technischen Zeilenschlüssel und die Shop-Zuordnung, über die zugleich der Zeilenschutz der Datenbank wirkt (Anlage 2 Abschnitt 1.2). Eine Angabe über eine Person steht in keiner von beiden — auch keine Bestell-, Fulfillment- oder Kundenkennung.

Auch diese beiden Aufzählungen sind spaltengenau, und dieselbe Prüfung im Prüfstand hält sie gegen das Datenbankschema wie die vier Aufzählungen weiter unten; ihre Reichweite und ihre Grenze stehen dort. Bis zum 02.09.2026 waren sie es nicht: Sie ließen bei den Abrufen sechs Spalten ungenannt, und keine Prüfung maß sie.

Abrufe der Bestellhistorie — je Abruf: Art des Abrufs, Kennung der Shopify-Sammelabfrage, angefragter Zeitraum, Zustand und Zeitpunkt des letzten Zustandswechsels, Zahl der Fehlversuche, Fehlerkennung und Zeitpunkt des letzten Fehlschlags, ein Prüfwert über die Ergebnisdatei, deren Zeilenzahl sowie der Zeitpunkt der Anlage. Keine Bestell- und keine Kundendaten. Und seit dem 02.09.2026 auch nicht mehr die Adresse der Ergebnisdatei: Bis zu diesem Tag stand sie hier und in der Tabelle. Sie ist von Shopify signiert und gibt eine Woche lang ohne weitere Anmeldung die vollständige Ausleitung der Bestell- und Versanddaten des Shops heraus — in einer Zeile, die nach Anlage 2 Abschnitt 1.2 ohne gesetzten Mandanten lesbar ist, darf so etwas nicht stehen. An ihrer Stelle steht der Prüfwert, der belegt, woraus die Zahlen entstanden sind, ohne selbst zu etwas Zugang zu geben.

Abgleiche mit Shopify — je Lauf: Art des Abgleichs, das abgedeckte Zeitfenster, wie viele Sendungen gefunden, neu angelegt und geändert wurden, sowie Beginn und Ende des Laufs.

Die vier folgenden Bestände entstehen aus den Sendungen des Shops. Drei ihrer Tabellen bestehen seit dem 01.09.2026, die vierte — Vorfälle bei der Verarbeitung — seit dem 02.09.2026. Die Zeilen entstehen seit dem 02.09.2026 über den Abgleich (§ 3.4) und seit dem 03.09.2026 zusätzlich über die laufende Entgegennahme der Sendungsmeldungen aus dem Shop (§ 2.3, Absatz „Drei Herkünfte"). Bis zum 03.09.2026 stand hier, die „Entgegennahme der Sendungsmeldungen ist weiterhin nicht gebaut"; bis zum 02.09.2026 stand hier „Die vier folgenden Bestände tragen heute keine Zeile". Sie stehen trotzdem hier und nicht in Abschnitt C, weil beide Abschnitte gegen die Tabellen des Datenbankschemas gemessen werden — und diese Tabellen gibt es. Bis zum 02.09.2026 sagte dieser Vorspann „drei", während vier Aufzählungen unter ihm standen: Die vierte kam an diesem Tag dazu, ohne dass die Zahl und die Prüfzusage darunter mitgezogen wurden.

Diese vier Aufzählungen sind spaltengenau, und der Prüfstand hält sie gegen das Datenbankschema. Wie weit er dabei reicht, steht hier, damit die Zusage nicht größer ist als die Prüfung: Jede Spalte der vier Tabellen muss im Prüfstand einem Wort dieser Aufzählungen zugeordnet sein, jedes zugeordnete Wort muss hier stehen, und ein Wort, zu dem es keine Spalte mehr gibt, fällt ebenfalls auf. Eine neu hinzugekommene Spalte fällt damit auf. Nicht erkannt wird, ob das zugeordnete Wort die Spalte wirklich bezeichnet — wer eine neue Spalte einem Wort zuordnet, das hier schon aus einem anderen Grund steht, kommt an der Prüfung vorbei. Eine Prüfung zählt seit dem 02.09.2026 die Aufzählungen dieses Blocks gegen die Zahlwörter der Vorspannsätze; bis dahin hätte eine fünfte Aufzählung dieselbe Zusage stillschweigend mitbekommen, ohne dass es für sie eine Prüfung gäbe. Genau das war zwischen dem 02.09.2026 und der Behebung am selben Tag der Fall: Die Vorfälle bei der Verarbeitung standen unter einer Zusage, die für sie noch niemand eingelöst hatte. Bis zum 01.09.2026 ließen die Aufzählungen einen Teil der bestehenden Spalten ungenannt, und es gab überhaupt keine Prüfung; bis zum selben Tag stand hier außerdem, die Prüfung falle, sobald eine der Tabellen eine Spalte trage, die hier nicht benannt ist — das ist eine Spur mehr, als sie leistet. Jede der vier Tabellen trägt zusätzlich zu den unten genannten Angaben einen technischen Zeilenschlüssel ohne Aussage über eine Person und die Shop-Zuordnung, über die zugleich der Zeilenschutz der Datenbank wirkt (Anlage 2 Abschnitt 1.2).

Sendungen — je versendetem Fulfillment: das Herkunftssystem der Sendung (Shopify oder Karl), Bestell- und Fulfillment-Kennung von Shopify (pseudonym), Bestellnummer, Versandzeitpunkt, Lieferland als Zwei-Buchstaben-Code, Ursprungsland, Empfängerart als Kategorie (privat/gewerblich/unbekannt, keine Kennung der Person), Artikelanzahl, Warengewicht in Gramm, Standort- und Versanddienstkennung, die Bezeichnung des beauftragten Zustellunternehmens (etwa „DHL"), Status und Ausschlussgrund, Retouren- und Stornovermerk, der Zeitpunkt des ersten Auftauchens und der Zeitpunkt des letzten Abgleichs mit Shopify sowie ein Prüfwert über die übernommenen Felder — ein nicht umkehrbarer SHA-256, der ausschließlich die Frage beantwortet, ob sich seit dem letzten Mal etwas geändert hat, und über den nicht gesucht wird. Kein Name, keine Anschrift, keine E-Mail-Adresse, keine Telefonnummer — gemeint sind damit Angaben über die Kundschaft des Händlers und über ihn selbst. Bis zum 01.09.2026 hieß die vorletzte Angabe hier „Name des Zustellers", drei Zeilen über „Kein Name"; ein Zustellunternehmen ist keine dieser beiden Personen, aber die beiden Sätze lasen sich als Widerspruch.

Pakete einer Sendung — je Paket: der Verweis auf die Sendung, die laufende Nummer, die zugeordnete Verpackungseinheit, die Herkunft der Zuordnung und ihr Klartextgrund (ein Satz aus dem Programm, keine Angabe über eine Person), die festgehaltene Fassung der angewandten Zuordnungsregel samt den Angaben derselben Sendung, an denen diese Regel gemessen hat — Lieferland, Gesamtgewicht, Artikelanzahl, Versanddienst, Zusteller und Standortkennung —, die Karl-Referenz (die Kennung des Labels in der Versand-App des Händlers), Bruttogewicht und Maße, Zeitpunkt und Urheber der Zuordnung sowie der Zeitpunkt der Anlage dieser Zeile.

Bis zum 04.09.2026 endete die vorige Aufzählung bei der „festgehaltenen Fassung der angewandten Zuordnungsregel" und nannte damit nur die eine Hälfte dessen, was in diese Spalte geht. Die andere Hälfte ist das Bild der Sendung im Augenblick der Zuordnung: Ohne es ließe sich zwei Jahre später nicht sagen, ob eine Sendung dem Band 500–1000 g wegen ihres damaligen Gewichts entsprach — das Gewicht selbst kann sich durch einen späteren Abgleich geändert haben. Die sechs genannten Angaben sind dieselben, die diese Übersicht bei der Sendung selbst bereits führt; neu ist nicht die Angabe, sondern die zweite Stelle, an der sie steht. Nicht mit hinein gehen die Artikelnummern, die Schlagworte und die Produktkennungen der einzelnen Positionen; sie stehen bei den Positionen einer Sendung.

Geschrieben wird diese Spalte seit dem späten Abend des 04.09.2026 vom Zuordnungslauf, der an jenem Abend gebaut worden ist: Wendet er eine Regel an, hält er ihre Fassung und das gemessene Bild der Sendung in dieser Spalte fest. Angestoßen wird diese Zuordnung seit 19:56 Uhr desselben Abends vom Zuordnungslauf, der mit der Anwendung startet; wie viele Zeilen dort einen solchen Eintrag tragen, hängt damit am Bestand des Shops und an den Regeln, die der Händler geschrieben hat, und ist keine Zusage dieses Vertrages.

Seit dem 06.09.2026 setzt auch der Händler selbst Werte in diese Zeile, und zwar über die Sendungsseite der App: Er weist mehreren Paketen zugleich eine Verpackungseinheit zu oder nimmt sie von Hand aus der Zählung. Im ersten Fall stehen danach die gewählte Einheit und die Herkunft manuell in der Zeile, im zweiten die Herkunft ausgeschlossen:manuell; die Zeile bleibt in beiden Fällen stehen — ein von Hand ausgenommenes Paket wird nicht gelöscht, sondern führt seine Herkunft weiter, damit ein Prüfer sieht, dass es die Sendung gab und dass jemand sie herausgenommen hat. Ein Klartextgrund entsteht über diese Seite nicht: Sie sendet ausschließlich die Kennungen der gewählten Pakete und die Kennung der Verpackungseinheit, und das Feld für den Grund bleibt damit leer. Bis zum Abend des 06.09.2026 stand hier, im ersten Fall stehe „sein Klartextgrund in der Zeile" und die Herkunft heiße „ausgeschlossen: von Hand"; beides war ungenau — das erste beschrieb ein Feld, das diese Bedienung nicht füllt, das zweite nannte einen Wert, den der Datenbestand so nicht führt. Das Feld für einen Klartextgrund gibt es weiterhin; gefüllt wird es heute allein von der Zuordnungskette, wenn sie festhalten muss, warum eine Regel nicht greifen konnte. Als Urheber der Zuordnung wird dabei die Shop-Domain aus dem geprüften Sitzungstoken festgehalten und nichts, was der Browser mitschickt — kein Personenname des für den Händler handelnden Personals; dieselbe Regel und dieselbe Begründung wie beim Bestätigungstext eines Meldezeitraums. Bis zu jener Stunde stand hier „Angestoßen wird diese Zuordnung im laufenden Betrieb weiterhin von keiner Stelle des Programms und von keiner Bedienseite"; das galt eine Stunde und achtundfünfzig Minuten. Bis zu jenem Abend stand hier „Geschrieben wird diese Spalte heute von keinem Programmteil — der Zuordnungslauf, der sie füllt, kommt erst; die Aufzählung beschreibt das Schema und nicht seinen Füllstand"; das war am Vormittag desselben Tages richtig und mit der Stunde falsch, in der die Zuordnungskette entstand. Es ist dieselbe Aussageklasse, für die derselbe Tag an sieben anderen Stellen dieser vier Dokumente datierte Selbstkorrekturen eingezogen hat — hier fehlte sie, und kein Wächter zeigte darauf.

Positionen einer Sendung — je Bestellposition: der Verweis auf die Sendung, Positions-, Varianten- und Produktkennung von Shopify, Artikelnummer, Menge, Stückgewicht, ob die Position versandpflichtig ist, Produkt-Schlagworte.

Vorfälle bei der Verarbeitung — je Vorfall: das Grundwort aus einem festen Vokabular (etwa „Lieferland unbekannt" oder „Körper der Meldung unlesbar"), Bestell- und Fulfillment-Kennung von Shopify (pseudonym; beide dürfen fehlen, weil ein Vorfall oft entsteht, bevor eine Sendung angelegt werden konnte), ein Zusatzobjekt aus eigenen Kennungen und Zahlen (etwa die Fehlerkennung von Shopify und die Zahl der Versuche), der Zeitpunkt der Anlage und der Erledigungsvermerk des Händlers, dazu ein technischer Zeilenschlüssel und die Shop-Zuordnung, über die zugleich der Zeilenschutz der Datenbank wirkt (Anlage 2 Abschnitt 1.2). Keine Kundendaten und kein Meldungstext fremder Herkunft: Was in das Zusatzobjekt und in die beiden Kennungsfelder hineindarf, entscheidet nicht der aufrufende Programmteil, sondern der Schreibpfad selbst. Die beiden Kennungsfelder nehmen ausschließlich eine Kennung der Form gid://shopify/<Art>/<Zahl> an; in das Zusatzobjekt kommt nur, was flach ist, als Bezeichnung einen kleingeschriebenen Programmnamen trägt und als Wert eine Zahl oder eine Zeichenfolge ohne Leerzeichen ist — gebildet aus Buchstaben, Ziffern und sechs Trennzeichen: Punkt, Doppelpunkt, Schrägstrich, Bindestrich, Unterstrich und Raute, den Zeichen, aus denen die Kennungen dieser App bestehen. Das Zeichen @ kommt allein in der festen Form regel:<Kennung>@<Fassung> durch, mit der die App eine angewandte Zuordnungsregel bezeichnet. Abgewiesen wird zusätzlich jede Bezeichnung, die auf eine Angabe über eine Person deutet — Wortbestandteile wie „mail", „name", „kunde", „adresse", „telefon", „rufnummer" oder „token"; unter ihnen alle, mit denen der Prüfstand die Spaltennamen des gesamten Schemas absucht. Wie weit das trägt, steht hier, damit die Zusage nicht größer ist als die Prüfung: Erkannt wird die Form des Wertes und die Bezeichnung, unter der er abgelegt wird, nicht der Inhalt. Ein Ortsname unter einer unverfänglichen Bezeichnung bliebe unerkannt, und eine Ziffernfolge mit Punkten — 0049.30.1234567 — hat die Form einer Kennung; auffallen kann sie nur an ihrer Bezeichnung. Die Verantwortung dafür, diese Felder sparsam zu füllen, nimmt die Prüfung den Programmteilen nicht ab. Bis zum 02.09.2026 stand hier, der Schreibpfad weise „alles zurück, was nicht die Form einer Kennung hat": Das war zu viel gesagt. Er fragte nur nach dem Leerzeichen, und eine E-Mail-Adresse, eine Telefonnummer, ein Zugangsdatum und eine in zwei Felder zerlegte Anschrift tragen keines. Am selben Tag hieß der zulässige Wert hier „eine Zeichenfolge ohne Leerzeichen und ohne Satzzeichen": Auch das stimmte nicht — es war an derselben Stelle und am selben Tag die zweite Beschreibung, die enger klang als die Prüfung, die läuft. Punkt, Doppelpunkt und Bindestrich sind Satzzeichen und stehen in den Kennungen dieser App; die Prüfung lässt sie durch, und „0049.30.1234567" kam ihretwegen durch die Wertprüfung. Der Absatz nennt die zugelassenen Zeichen seither einzeln, und der Prüfstand hält diese Aufzählung gegen die Prüfung selbst, statt sie zu glauben. Die Tabelle besteht seit dem 02.09.2026; ihre Zeilen entstehen mit den Sendungen, die der Abgleich verbucht (§ 3.4) — bis zu diesem Tag stand hier, sie trage „heute keine Zeile". Der Händler hakt einen Vorfall ab, gelöscht wird er mit dem Shop.

Die vier folgenden Bestände halten fest, welche Zahl aus diesen Sendungen gemeldet worden ist. Ihre Tabellen sind seit dem 05.09.2026 im Schema angelegt (Migration 0022), und es gibt genau einen Weg, der in sie schreibt. Seit dem 05.09.2026 steht über diesem Weg die Fachschicht der Meldung — der Programmteil, der einen Meldezeitraum erzeugt, ihn einfriert, eine Nachtragsmeldung als Differenz bildet und eine Neuberechnung protokolliert. Angestoßen wird sie seit dem 05.09.2026 vom Händler — über vier Adressen der App, die einen Meldezeitraum auflisten, anlegen, festschreiben und die Differenzmeldung dazu bilden (Abschnitt C nennt sie zusammen mit den fünf Adressen der Dateien). Ein Arbeitslauf ruft sie weiterhin nicht, und das ist auch nicht nötig: Eine Meldung ist eine Entscheidung des Händlers und keine Nebenwirkung eines Laufs. Seit dem späten Abend des 06.09.2026 gibt es die Bedienseite dazu — der Menüpunkt „Meldungen“ mit den Reitern „Exporte“, „Prognose“ und „Nachweise“; über sie legt der Händler einen Meldezeitraum an, sieht seine Mengenzeilen, schreibt ihn fest, bildet die Differenzmeldung dazu und lädt die fünf Dateien herunter. Bis zu jenem Abend stand hier, eine Bedienseite gebe es nicht. Bis zum 06.09.2026 stand hier „Angestoßen wird sie im laufenden Betrieb bislang von keiner Stelle des Programms: Es gibt weder eine Bedienseite noch einen Abruf, über den eine Meldung entstünde, und auch kein Arbeitslauf ruft sie.“ Der Satz war seit dem 05.09.2026 falsch, und Abschnitt C desselben Vertrages sagte an diesem Tag schon das Gegenteil — zwei Stände derselben Tatsache in einem Zustimmungstext. Bis zum 05.09.2026 stand hier, der Schreibweg selbst werde von keiner Stelle des Programms angestoßen — bis zu diesem Tag war das richtig; seither liegt die Stelle, die niemand anstößt, eine Ebene höher. Wie viele Zeilen hier stehen, hängt daran und am Bestand des Shops; eine Zusage dieses Vertrages ist es nicht. Anders als die Bestände darüber werden diese vier nicht neu berechnet, wenn sich der Verpackungskatalog ändert — ein eingefrorener Stand bleibt stehen und bekommt bei Bedarf eine neue Fassung. Seit dem 05.09.2026 hält die Datenbank das selbst: Sie weist jede neue Mengenzeile zu einer eingefrorenen Meldung ab. Bis zu diesem Tag stützte sich dieselbe Zusage allein darauf, dass die Anwendung auf den Mengen einer Meldung kein Änderungsrecht hat — das trifft weiterhin zu und war als Riegel zu wenig, weil Löschen und Neuschreiben dasselbe leistet wie ein Ändern.

Auch diese vier Aufzählungen sind spaltengenau, und der Prüfstand hält sie gegen das Datenbankschema; seine Reichweite und seine Grenze sind dieselben wie bei den Aufzählungen weiter oben und stehen dort. Bis zum 05.09.2026 stand dieser Satz hier nicht, und drei der vier Aufzählungen ließen den technischen Zeilenschlüssel, die Shop-Zuordnung und den Verweis auf den Meldezeitraum ungenannt — acht Spalten, darunter die Mandantenspalte, über die zugleich der Zeilenschutz der Datenbank wirkt.

• Meldezeiträume — je Meldung: Land, Zielsystem, Zeitraum, Meldeart, Codesatz, ein Verweis auf die meldende Rechtseinheit, der Vermerk, dass über eine Rechtseinheit zusammengerechnet wurde, Status, Prüfsumme über die Eingangsdaten, Anzahl unzugeordneter Pakete, Anzahl Positionen ohne eigenen Gewichtsbeleg, Bestätigungstext des Händlers samt anmeldendem Shop und Zeitpunkt, Version und Verweis auf die vorherige Fassung, Zeitpunkte der Erzeugung und des Einfrierens, dazu ein technischer Zeilenschlüssel und die Shop-Zuordnung, über die zugleich der Zeilenschutz der Datenbank wirkt (Anlage 2 Abschnitt 1.2). Keine Angabe über die Kundschaft des Händlers. Neben dem Text steht der anmeldende Shop und keine Person: Der Wert wird seit dem 06.09.2026 aus dem geprüften Sitzungstoken belegt — er ist die Shopdomain —, und was der Browser unter diesem Namen mitschickt, wird verworfen. Bis zum 06.09.2026 stand hier „samt Person", und die Datenschutzerklärung schloss daraus auf eine Angabe über die für den Händler handelnde Person; das beschrieb eine Verarbeitung von Beschäftigtendaten, die es seither nicht mehr gibt — wer die Kategorie daraus in sein eigenes Verarbeitungsverzeichnis nach Art. 30 Abs. 1 DSGVO übernahm, führte einen Datenbestand, den Kuno nicht hält. Der Bestätigungstext selbst ist freier Text, den der Händler füllt — trägt er dort den Namen einer natürlichen Person ein, steht diese Angabe in dieser Tabelle; das Datenbankschema kann das nicht verhindern. Bis zum 05.09.2026 schloss diese Zeile mit „Keine Kundendaten" ohne diesen Vorbehalt, obwohl sie den Bestätigungstext selbst aufzählt. Der Vermerk über die Zusammenrechnung ist am 08.09.2026 dazugekommen, und er steht neben dem Verweis auf die Rechtseinheit und nicht statt seiner: Wird eine Rechtseinheit aufgelöst, verliert jeder Meldezeitraum seinen Verweis auf sie — der Vermerk bleibt und hält fest, dass diese Meldung über mehrere Shops gerechnet wurde. Ohne ihn läse sich eine solche Meldung nachträglich wie die eines einzelnen Shops, und eine spätere Korrektur nähme die Mengen der übrigen Shops zurück. Es ist ein Ja-Nein-Wert und keine Angabe über eine Person.
• Mengen je Materialart — je Zeile einer Meldung: der Verweis auf den Meldezeitraum, Zielcode, Bezeichnung, Masse in Kilogramm, Stückzahl, Anzahl der zugrunde liegenden Sendungen, Belegstatus, dazu ein technischer Zeilenschlüssel und die Shop-Zuordnung, über die zugleich der Zeilenschutz der Datenbank wirkt (Anlage 2 Abschnitt 1.2). Keine Kundendaten.
• Erzeugte Meldedateien — je Datei: der Verweis auf den Meldezeitraum, Kanal (LUCID-XML oder Meldebogen), Prüfsumme der Datei, Zeitpunkt der Erzeugung, vom Händler nachgetragener Abgabezeitpunkt und Bestätigungskennzeichen aus dem Zielsystem, dazu ein technischer Zeilenschlüssel und die Shop-Zuordnung, über die zugleich der Zeilenschutz der Datenbank wirkt (Anlage 2 Abschnitt 1.2). Die Dateien selbst werden nicht gespeichert; sie entstehen aus dem eingefrorenen Meldezeitraum jederzeit erneut. Keine Kundendaten.
• Neuberechnungsläufe — je Lauf: Auslöser, betroffene Meldezeiträume, Start, Ende, Ergebniszahlen, dazu ein technischer Zeilenschlüssel und die Shop-Zuordnung, über die zugleich der Zeilenschutz der Datenbank wirkt (Anlage 2 Abschnitt 1.2). Keine Kundendaten.

Ein Bestand nimmt auf, was eine ANDERE Anwendung schickt — und er ist der erste seiner Art. Bis zu diesem Bestand hat alles, was Kuno speichert, genau eine Herkunft: Kuno holt es bei Shopify ab oder der Händler trägt es selbst ein. Mit der Migration 0032 vom 08.09.2026 gibt es eine zweite Herkunft, und deshalb steht sie hier neben der Datenart und nicht bloß im Vorspann: KYTH.Karl, die Scanner-App derselben KYTH. Systems UG. Karl kennt zu jedem gekauften Versandlabel die tatsächlich verwendete Verpackung; Shopify kennt sie nicht und hat kein Feld dafür.

• Verpackungsdaten aus KYTH.Karl — je eingehender Meldung: die Kennung der Karl-Sendung (eine Zeichenkette aus Buchstaben, Ziffern und vier Trennzeichen, datenbankseitig auf diese Form festgelegt), der Zeitpunkt des Eingangs, die unveränderte Nutzlast als JSON-Objekt, der Zeitpunkt der Verarbeitung und — falls sie scheiterte — ein Grundwort aus Kleinbuchstaben, Ziffern und Unterstrich, dazu ein technischer Zeilenschlüssel und die Shop-Zuordnung, über die zugleich der Zeilenschutz der Datenbank wirkt (Anlage 2 Abschnitt 1.2). In der Nutzlast steht, was der Vertrag kyth_packaging/1 zulässt — und seit dem 08.09.2026 steht es hier Feld für Feld statt als Zusammenfassung: die Version des Vertrags, die Kennung der Karl-Sendung, die Shop-Domain, die pseudonyme Kennung der Bestellung und die der Fulfillung, die Bestellnummer, das Versanddatum, das Lieferland, das Versandland, der Zusteller sowie drei Ja/Nein-Merker — ob das Label storniert wurde, ob es ein Retourenlabel ist und ob es ein Testlabel ist. Je Paket dazu die Paketnummer, die Kennung des verwendeten Verpackungs-Presets, dessen Bezeichnung, das Bruttogewicht, die drei Kantenmaße und der Merker, ob dieses einzelne Label storniert wurde; je Bestandteil eines Pakets die Materialfraktion, das Gewicht des Bestandteils, die Menge des Bestandteils und die Bezeichnung des Bestandteils. Bis zum 08.09.2026 nannte diese Aufzählung zwölf dieser Felder nicht — darunter alle vier, die freien Text tragen; wer sie las, hielt sie für nicht vorhanden. Der Merker am einzelnen Paket ist am 09.09.2026 dazugekommen: Die Versand-App führt den Storno je Label, und ein Merker allein an der Sendung konnte einen von mehreren gevoideten Labels nicht ausdrücken. Er ist ein Ja-Nein-Wert und keine Angabe über eine Person. Welche Felder es sind, hält seither eine Prüfung gegen den Vertrag selbst fest, damit die Aufzählung ihm nicht ein zweites Mal hinterherläuft. Keine Namen, Anschriften, E-Mail-Adressen oder Telefonnummern — weder von der Kundschaft des Händlers noch von seinem Personal. Eine eigene Frist trägt dieser Bestand nicht: Die Zeile wird mit dem Shop gelöscht (§ 9), und ein Aufräumlauf, der sie früher entfernte, besteht an diesem Tag nicht.
• Weisung zur Übernahme aus KYTH.Karl — seit dem 09.09.2026 (Migration 0033) ein einzelner Zeitpunkt in der Shop-Zeile: wann der Händler angeordnet hat, dass Kuno diese Meldungen übernimmt. Herkunft ist der Händler selbst — die Karte „Paketmeldungen aus KYTH.Karl" in der Administration. Zweck ist die Dokumentation der Weisung nach § 3.2 und zugleich ihre Durchsetzung: Steht der Zeitpunkt nicht, weist die Adresse jede Meldung ab und legt keine Zeile an. Ein Widerruf leert das Feld und wirkt nach vorn; bereits verbuchte Mengen bleiben stehen, denn sie sind der Nachweis über in Verkehr gebrachte Verpackungen (§ 9). Die Spalte liegt in shops und trägt deshalb dieselbe Lücke wie jede andere dort — Anlage 2 Abschnitt 7.2, Zeile „Kein Zeilenschutz auf shops".

Diese eine Zusage ruht nicht auf dem Datenbankschema, und das steht hier, statt still zu bleiben. Die Nutzlast ist ein JSON-Objekt; die Datenbank bindet an ihr nur die Form — dass es überhaupt ein Objekt ist —, nicht die Namen der Felder darin. Dass keine Namen, Anschriften, E-Mail-Adressen oder Telefonnummern ankommen, folgt aus dem Vertrag kyth_packaging/1 und aus der Prüfung des Eingangs, die ihn durchsetzt: Deren Schema ist geschlossen — ein Feld, das der Vertrag nicht kennt, führt zur Ablehnung der ganzen Meldung, nicht zum Herausschneiden einzelner Felder. Was gespeichert wird, ist deshalb tatsächlich unverändert. Diese Prüfung steht seit dem 08.09.2026, und seit dem Abend desselben Tages auch die Adresse dahinter (Absatz „Was an diesem Tag besteht" weiter unten). Bis zum Vormittag des 08.09.2026 stand hier, beides sei ungebaut; ab dem Nachmittag traf das nur noch auf die Adresse zu, ab dem Abend auf keines von beidem. Seit dem Nachmittag des 09.09.2026 ist es eine Zusage über einen Bestand, der sich füllen kann: Der Programmteil, der die Zeile schreibt, verbucht seither — sobald der Händler die Übernahme angewiesen hat. Sie hängt trotzdem an jener Prüfung und nicht an einer CHECK-Bedingung. Bis zu jenem Nachmittag stand hier „verbucht wird dahinter noch nichts", und bis zum Vormittag desselben Tages „keine über einen Bestand, der leer bleibt, sondern eine über einen, der sich füllt". Die erste Fassung war zu weit, die zweite für einen halben Tag zu eng; beide stehen datiert da statt gelöscht. Für die Stückliste der Variantenverpackung steht an anderer Stelle dieses Abschnitts derselbe Vorbehalt aus demselben Grund — eine Zusage darf nicht weiter sein als ihre Begründung.

Und der Vorbehalt hat eine zweite Hälfte: vier Felder der Nutzlast sind freier Text. Die Bestellnummer, der Zusteller, die Bezeichnung des Verpackungs-Presets und die Bezeichnung eines Bestandteils tragen, was Karl in seine eigenen Tabellen geschrieben hat; der Vertrag bindet an ihnen die Länge und sonst nichts, und Kuno wertet sie nicht aus — sie sind Beschriftungen. Trüge eine spätere Karl-Fassung dort einen Personennamen ein, etwa als Preset-Bezeichnung „Karton M / Mustermann", käme er durch die Eingangsprüfung. Die Zusage über Namen ruht an dieser Stelle also auf dem, was Karl in jene vier Felder schreibt, und nicht auf einer Formprüfung dieses Vertrags. Sie steht hier, weil ein Händler, der die Aufzählung darüber liest, sonst vier freie Textfelder für nicht vorhanden hielte.

Warum die Nutzlast ungeteilt gespeichert wird. Karl löscht seine eigenen Sendungen nach 90 Tagen — die Zahl ist nicht geschätzt: Sie ist die Aufbewahrungsfrist, die jene App in § 9 ihres eigenen Auftragsverarbeitungsvertrages zusagt und über einen nächtlichen Aufräumlauf durchsetzt (nachgeschlagen am 08.09.2026). Scheitert die Auswertung — an einer fehlenden Verpackung im Katalog, an einer unbekannten Preset-Kennung oder an einem Programmfehler —, ist die Meldung hier trotzdem vollständig vorhanden und kann später erneut ausgewertet werden. Ohne diesen Beleg wäre ein Fehlschlag für diese Angaben ein Datenverlust mit Frist.

Bis zum Vormittag des 11.09.2026 stand hier „Karl löscht seine eigenen Sendungen nach 90 Tagen" ohne die Hervorhebung. Am selben Tag ist an die Hervorhebung eine Begründung gehängt worden, und die ist am Abend desselben Tages wieder herausgenommen worden. Die Hervorhebung bleibt richtig: Die 90 Tage sind die Frist der Sendungstabelle jener App. Falsch war der Zusatz „Die Verpackungsdaten selbst — Preset, Maße, Bruttogewicht — stehen dort in einer eigenen Tabelle mit eigener Aufbewahrung (Vorgabe zehn Jahre, Einstellung des Shops)", und mit ihm der Schluss, der Beleg hier halte nur die Sendungsangaben vor einem Verlust mit Frist. Diese Tabelle gibt es nicht. Sie steht in docs/karl-sensor-plan.md unter der Überschrift über die dort erst noch vorzunehmenden Änderungen, Schritt 1 — also in einem Vorhaben für jene App und nicht in ihrem Programm. Nachgeschlagen am 11.09.2026 im Programm jener App: Maße und Bruttogewicht stehen in derselben Sendungstabelle, die der nächtliche Aufräumlauf nach 90 Tagen leert, und eine eigene Verpackungstabelle gibt es dort nicht. Für sie gilt die Frist also genauso, und der Beleg hier hält damit die ganze Meldung vor einem Verlust mit Frist und nicht nur einen Teil von ihr. Der Preis dafür steht in derselben Zeile: Es wird mehr gespeichert als der Teil, den Kuno auswertet, und deshalb zählt der Absatz darüber auf, was die Nutzlast überhaupt enthalten darf.

Die Bestellkennung in der Nutzlast ist ein Weg zu einer Person, und dieser Bestand steht deshalb im Löschweg einzelner Personen (§ 7.2). Gefunden wird eine Zeile über die Bestellkennung innerhalb der Nutzlast; geleert wird darin nichts, und das ist keine Bequemlichkeit: Die Anwendungsrolle darf auf dieser Tabelle ausschließlich den Zeitpunkt der Verarbeitung und das Grundwort eines Fehlschlags ändern — die Nutzlast selbst nicht. Eine Zusage, sie zu leeren, wäre an der Rechtevergabe gescheitert, und zwar erst im Ernstfall. Was der Händler stattdessen bekommt, ist die Zahl der gefundenen Zeilen, festgehalten im Zugriffsprotokoll. Anders als beim Mengenkonto trägt die Aufbewahrung sich hier nicht daraus, dass die Zeile selbst der Nachweis einer abgegebenen Meldung wäre — das ist die Sendung, die aus ihr entsteht —, sondern daraus, dass sie belegt, woher eine verbuchte Menge stammt. Bis zum 11.09.2026 stand hier zusätzlich „und dass aus ihr nachgearbeitet wird"; ein Lauf, der aus der Nutzlast nacharbeitet, ist nicht gebaut, und ein Grund ohne Gegenstand gehört nicht in einen Zustimmungstext (§ 7.2, Absatz über die Verpackungsdaten aus KYTH.Karl).

Das ist eine Einordnung und kein Gutachten. Nach der Bewertung von KYTH entsteht durch diesen Weg kein weiterer Unterauftragsverarbeiter im Sinne von § 6. Karl ist keine fremde Stelle: Beide Anwendungen betreibt dieselbe KYTH. Systems UG, und sie tut es für denselben Verantwortlichen — den Händler, der beide Apps in seinem eigenen Shop installiert hat und für beide gesondert einen Auftragsverarbeitungsvertrag schließt. Es wird also nichts an einen Dritten weitergegeben, sondern etwas innerhalb desselben Auftragsverarbeiters von einem Auftrag in den anderen übernommen. Was daraus folgt und hier ausdrücklich steht, statt still zu bleiben: Eine solche Übernahme ist keine Selbstverständlichkeit, sondern eine Verarbeitung zu einem anderen Zweck als dem, zu dem Karl die Daten erhoben hat, und sie braucht deshalb die Weisung des Händlers (§ 3.2). Wer die Einordnung anders trifft, stellt Karl nach § 6.3: Dann braucht es einen Vertrag nach Art. 28 Abs. 4 DSGVO — zwischen KYTH und KYTH, was auf dieselbe Stelle hinausliefe.

Was an diesem Tag besteht — und was der Händler dafür anordnen muss. Die Tabelle steht seit dem 08.09.2026 im Schema, seit dem Abend desselben Tages gibt es die Adresse, unter der Karl eine Meldung abliefert — sie prüft Signatur, Zeitfenster und Vertrag und ordnet die Meldung dem Shop zu —, und seit dem Nachmittag des 09.09.2026 verbucht der Programmteil dahinter: Aus einer eingegangenen Meldung entstehen die Sendung, ihre Pakete und deren Materialmengen. Bis zu jenem Nachmittag stand hier „Verbucht wird dahinter noch nichts", und bis zum Vormittag desselben Tages endete der erste Satz mit „bevor eine Zeile entsteht" — jenes las sich wie eine Zeile, die entsteht, obwohl keine entstand.

Er verbucht aber nur, wenn der Händler die Übernahme angeordnet hat. Die Migration 0033 vom 09.09.2026 legt dafür in der Shop-Zeile den Zeitpunkt der Weisung ab; die Karte „Paketmeldungen aus KYTH.Karl" in der Administration setzt ihn und nimmt ihn zurück. Steht er nicht, weist die Adresse jede Meldung mit einer eigenen Kennung ab und legt nicht einmal den Eingangsbeleg an. Bis zu jenem Tag stand hier, was fehle, sei die Stelle, an der der Händler diese Übernahme anweist — kein Schalter, keine Karte, kein Eingabefeld. Ein Widerruf wirkt nach vorn: Er weist die nächste Meldung ab und löscht nichts, was schon verbucht ist; dafür gilt § 9 wie für jede andere Menge dieses Nachweises. Die Einordnung, aus der diese Weisung folgt, steht im Kasten am Ende dieses Abschnitts und in § 3.2.

Bis zum Abend des 08.09.2026 stand hier, auch die Adresse sei ungebaut, und solange beides fehle, könne in diesen Bestand nichts gelangen; beide Hälften tragen nicht mehr. Was hier steht, ist eine Aussage über den heutigen Programmstand und keine Zusage über die Zahl der Zeilen: Wie viele es später sind, hängt am Bestand des Shops. Was hier steht, beschreibt also das Schema und nicht seinen Füllstand — dieselbe Unterscheidung wie bei den Beständen darüber, und sie ist datiert, damit ein späterer Leser sie nachmisst statt sie zu glauben. Der zweite Merker in der Shop-Zeile — seit wann für diesen Shop die erste Meldung aus Karl ohne Testlabel angekommen ist — steht in der Migration 0032 und wird seit dem 09.09.2026 von der Verbuchung gesetzt, und zwar einmalig beim ersten Push ohne Testlabel. Bis zum Vormittag des 09.09.2026 stand hier, er werde von keinem Programmteil gesetzt; davor stand hier, er werde von demselben gesetzt wie die Zeile. Beides ist seit dem Nachmittag jenes Tages wieder richtig, und die Notizen bleiben stehen, damit der Weg nachvollziehbar bleibt. Seit dem 11.09.2026 hat derselbe Merker eine zweite Verwendung: Er wirkt neben dem Tarifnamen als Merkmal dafür, welche Auswertungen und Dateien der Shop bekommt — ein Shop, für den eine Meldung aus Karl ohne Testlabel angekommen ist, erhält den größeren Leistungsumfang, auch wenn sein Tarif der kostenlose ist (§ 1.3 Nr. 4). Gelesen wird dabei nur, ob ein Zeitpunkt eingetragen ist. Bis zum 13.09.2026 setzte den Merker jeder erste Push, auch einer mit Testlabel; seit der Entscheidung jenes Tages setzt ihn ein Push mit Testlabel nicht.

Eine Hilfstabelle steht ausdrücklich nicht in dieser Aufzählung. Der Prüfstand legt für den Nachweis der Mandantentrennung eine Notiztabelle an; sie besteht nur, solange ein Prüflauf läuft, und wird im Produktivschema nicht angelegt. Bei Kartuu ist genau eine solche Tabelle einmal im Produktivschema gelandet und musste per Migration wieder entfernt werden.

B. Nur flüchtig berührte Daten — keine Speicherung

C. Vorgesehen, aber nicht verarbeitet

Diese Tabelle steht getrennt von A und B, weil die Unterscheidung zwischen „darf" und „tut" für die Beurteilung dieses Vertrages entscheidend ist (§ 2.3). Aufgeführt ist, was bei der Anlage dieser Tabelle nicht verarbeitet wurde, und der Grund dafür ist nicht bei jeder Zeile derselbe. Bei zwei der sechs Zeilen — Angaben aus der Lieferadresse sowie Namen und Anschriften der Kundschaft — gibt es im Datenbankschema weder Tabelle noch Spalte; eine dritte Zeile — die Bedienung von Katalog und Regeln — spricht überhaupt nicht von einem Bestand, sondern von den Bedienelementen zweier Bildschirme, die es seit dem 06.09.2026 gibt. Bis zu jenem Tag hieß der Halbsatz „sondern von einem Bildschirm, den es noch nicht gibt"; seither führt das Menü der App die Punkte Verpackungen und Produkte, und hinter beiden liegt eine Seite. Die Verpackungsseite trägt ihre Bedienelemente seit dem Abend desselben Tages, die Produktseite seit dem Abend des 08.09.2026. Bis zu jenem Abend endete dieser Satz mit „die Produktseite noch nicht"; bis zum Abend des 06.09.2026 mit „Was auf ihr fehlt, ist jedes Bedienelement". Bis zum 05.09.2026 waren es drei und eine vierte: Die Zeile über die Berichte und Exportdateien stand in der ersten Gruppe, während die Migration 0022 am selben Tag die vier Tabellen der Meldung angelegt hat und Abschnitt A sie spaltengenau aufzählt. Bis zum 04.09.2026 sprach dieselbe Zeile von „einem Weg, der nicht gebaut ist"; den Weg gibt es seit jenem Tag, und was ihr geblieben ist, ist der Bildschirm. Bis zum 04.09.2026 hieß diese vierte Zeile „Zuordnungsregeln des Händlers" und führte einen Bestand; seine Tabelle ist an diesem Tag angelegt worden, und er ist deshalb in Abschnitt A geführt. Bis zum 03.09.2026 hieß dieselbe Zeile „dem Verpackungskatalog"; auch dessen Tabellen sind inzwischen angelegt und in Abschnitt A geführt. Drei Zeilen führen inzwischen einen anderen Stand als die Überschrift dieses Abschnitts: Die Entgegennahme der Meldungen findet seit dem 03.09.2026 statt, der Abruf von Produkt- und Variantendaten seit dem 02.09.2026, und aus den Beständen des Abschnitts A entstehen seit dem 05.09.2026 Meldezeiträume, Mengen je Materialart und die Bytes von fünf Dateien — der LUCID-Meldedatei und dem Meldebogen als Tabellendatei und als Druckstück, dazu dem Nachweis, der den Rechenweg dazuschreibt, der Länderübersicht, die ohne Meldezeitraum auskommt, und der PPWR-Tabelle; seit demselben Tag führen neun Adressen aus dem Programm heraus zum Händler, und damit ist die dritte dieser Zeilen nicht mehr nur eine Rechnung ohne Ausgabe. Bis zu jenem Tag waren es zwei Zeilen und drei Dateien; bis zum Abend desselben Tages vier Dateien und kein Weg nach draußen. Alle drei bleiben trotzdem hier stehen und sagen ihren erreichten Stand jeweils selbst: Eine gestrichene Zeile wäre kein berichtigter Vertrag, sondern ein verschwundener Vorgang. Die Überschrift dieses Abschnitts beschreibt damit seinen Anlass und nicht mehr jede seiner Zeilen — das steht hier ausdrücklich, damit sie niemand als Zusage liest. Bis zum 03.09.2026 sagte dieser Vorspann, bei der ersten Zeile finde die Entgegennahme nicht statt, während dieselbe Zeile vierundzwanzig Zeilen weiter unten schon das Gegenteil trug; die Einteilung drei plus zwei plus eins trug damit nicht mehr. Bis zum 02.09.2026 stand hier, die Tabellen, die diese Daten aufnehmen würden, stünden „bereits … und leer". Welcher Fall vorliegt, sagt jede Zeile selbst; eine bestehende Spalte ist in jedem Fall zusätzlich in Abschnitt A geführt und wird hier nicht ein zweites Mal aufgezählt. Bis zum 01.09.2026 stand an dieser Stelle pauschal „Was hier steht, hat im Datenbankschema weder Tabelle noch Spalte" — für drei der sechs Zeilen war dieser Satz schon beim Schreiben falsch. Bis zum selben Tag hieß es danach „Bei den meisten"; gezählt sind es drei von sechs, also die Hälfte.

Was der Prüfstand daran misst, und was nicht. Eine Prüfung hält diesen Abschnitt gegen dasselbe Datenbankschema wie Abschnitt A. Sie fällt, wenn die Überschrift einer Zeile eine Tabelle bezeichnet, die inzwischen angelegt ist, und ebenso bei den im Prüfstand namentlich hinterlegten Umschreibungen früherer Fassungen. Sie erkennt nicht, wenn eine Leugnung denselben Bestand mit einem neuen Wort umschreibt — die Stichworte der Tabellen stecken sonst in jedem zweiten Satz dieses Abschnitts, und der Wächter meldete alles. Bis zum 01.09.2026 gab es überhaupt keine Prüfung, und zwei Zeilen dieser Tabelle standen im Widerspruch zu Abschnitt A. Der Satz, mit dem dieser Absatz bis dahin eine Prüfung zusagte, die sämtliche Einträge erfasst, ist auf das zurückgenommen, was der Prüfstand wirklich leistet: Ein Vertrag, der eine Prüfung verspricht, die es nicht gibt, ist schlechter als einer, der nichts verspricht.

Anlage 2 — Technische und organisatorische Maßnahmen (Art. 32 DSGVO)

Bildet den im Kopf genannten Quelltextstand ab. Aufgeführt sind ausschließlich Maßnahmen, die im Quelltext oder in der Betriebsdokumentation belegt sind. Belegstellen führt diese Anlage aus demselben Grund nicht mit wie Anlage 1. Der Abschnitt „Bekannte Lücken" gehört zur Darstellung dazu; er ist bewusst nicht weggelassen.

1. Vertraulichkeit

1.1 Verschlüsselung gespeicherter Daten

• Mit AES-256-GCM verschlüsselt gespeichert werden: der Access-Token, der Refresh-Token und die Kontaktadresse des Händlers. Jedes Chiffrat trägt eine Schlüsselkennung, und diese Kennung ist kryptografisch an das Chiffrat gebunden — ein nachträgliches Umschreiben der Kennung fällt beim Entschlüsseln auf.
• Die Datenbank lässt Klartext in einer verschlüsselten Spalte nicht zu. Jede dieser Spalten trägt eine Prüfregel auf das Chiffratformat, jede Suchwertspalte eine auf genau 64 Hexzeichen. Der Riegel fängt den teuersten denkbaren Fehler dieser Art ab: einen Klartext in einer Spalte, deren Name sagt, dass dort ein Chiffrat steht. Er fiele sonst nie auf.
• Ein Schlüsselwechsel ist vorgesehen und vorbereitet. Ein zweiter Schlüssel darf parallel gelten; die Schlüsselkennung im Chiffrat sagt, mit welchem entschlüsselt wird. Das Neuberechnen der Suchwerte nach einem Wechsel ist gebaut: Ein Lauf entschlüsselt mit dem Schlüssel, den das Chiffrat selbst nennt, und schreibt den Suchwert mit dem aktuellen neu. Er ist wiederholbar und schreibt keinen Wert, den er nicht belegen kann — lässt sich ein Feld nicht entschlüsseln, bleibt die Zeile unangetastet und wird gezählt. Eine Prüfung hält die Liste der Suchwertspalten gegen das echte Schema, damit eine später hinzugefügte nicht lautlos danebenfällt.
• Aufbewahrung des alten Schlüssels: mindestens 95 Tage — so lange wie die Sicherungen (§ 9.3 Nr. 2), denn eine Sicherung, die sich nicht mehr entschlüsseln lässt, ist keine.

1.2 Trennung der Mandanten

• Jede Tabelle mit einer Shop-Kennung (shop_id) ist mit Zeilenschutz auf Datenbankebene (Row-Level-Security, mit ENABLE und FORCE) und einer Richtlinie über den gesetzten Mandanten versehen. Ohne gesetzten Mandanten liefert die Datenbank für diese Tabellen keine Zeile — kein Mandant, kein Zugriff.
• Zwei Tabellen haben seit dem 02.09.2026 eine zweite Richtlinie, und sie ist die einzige Ausnahme von dem Satz darüber. Betroffen sind die beiden Bestände „Abrufe der Bestellhistorie" und „Abgleiche mit Shopify" aus Anlage 1 Abschnitt A. Ihre zweite Richtlinie greift ausschließlich, solange kein Mandant gesetzt ist, und erlaubt dann ausschließlich das Lesen. Ein Ablauf nimmt sie seit dem 02.09.2026 dauernd in Anspruch: Der Lauf für die Bestellhistorie sieht in jedem seiner Durchläufe nach, welche Abrufe fällig sind; er hat keine Anfrage im Rücken und damit keinen Mandanten, und er läuft in jedem Arbeitsprozess der Anwendung mit. Zwei weitere Abläufe werden sie brauchen und entstehen erst im laufenden Ausbau: Die Meldung, mit der Shopify das Ende einer Sammelabfrage anzeigt, nennt in ihrem signierten Inhalt nur die Kennung dieser Abfrage und nicht den Shop — der Shop wird dann über die Kennung gefunden. Und der Hintergrundlauf, der den Abgleich anstoßen soll, hat keine Anfrage im Rücken, aus der ein Shop hervorginge. Die Richtlinien stehen in der Migration, die die beiden Tabellen anlegt, und nicht in einer späteren. Bis zum 02.09.2026 stand hier, zwei Abläufe würden sie brauchen und beide entstünden erst im Ausbau — das sagte im Futur zu, was seit diesem Tag in jedem Durchlauf geschieht.
• Was diese Ausnahme öffnet. Ohne gesetzten Mandanten sind in diesen beiden Tabellen alle Zeilen lesbar; eine Richtlinie wirkt auf Zeilen und nicht auf Spalten. Geschrieben wird in beide ausschließlich mit gesetztem Mandanten. Bis zum 02.09.2026 stand oben „genau einer Richtlinie"; das war bis zu diesem Tag richtig und wäre ab ihm eine zu große Zusage gewesen. Die Wahl fiel bewusst auf zwei Tabellen ohne Personenbezug: In ihnen stehen eine Abfragekennung, ein Zeitraum, ein Zustand, Fehler- und Zählwerte, Zeitpunkte und ein Prüfwert über die Ergebnisdatei der Sammelabfrage. Maßgeblich und vollständig ist die spaltengenaue Aufzählung in Anlage 1 Abschnitt A; sie wird gegen das Datenbankschema geprüft, dieser Satz hier ist ihre Kurzfassung.
• Was die Zeile ausdrücklich nicht mehr trägt. Bis zum 02.09.2026 stand in den Abrufen der Bestellhistorie zusätzlich die von Shopify gelieferte Adresse der Ergebnisdatei, und die Aufzählung darüber nannte sie nicht — sie sagte „eine Abfragekennung, ein Zeitraum, ein Zustand und Zählwerte" und ließ damit gerade die eine Angabe aus, auf die es ankam. Diese Adresse ist signiert und eine Woche lang ohne weitere Anmeldung einlösbar; wer eine Zeile lesen kann, die ohne gesetzten Mandanten für jeden lesbar ist, könnte mit ihr die vollständige Ausleitung der Bestell- und Versanddaten eines fremden Shops abholen. Die Spalte ist deshalb entfallen und durch einen Prüfwert ersetzt, der zu nichts Zugang gibt. Anlage 1 Abschnitt A hatte die Adresse benannt, dieser Abschnitt nicht; die beiden Anlagen widersprachen einander bis zu diesem Tag.
• Gürtel und Hosenträger: Jede Datenbankfunktion setzt den Mandanten ausdrücklich und bindet die Shop-Kennung zusätzlich in jeder einzelnen Anweisung. Der Zeilenschutz allein wäre die stärkere Zusage, aber er hängt an einer Sitzungsvariablen; eine vergessene Zuweisung wäre sonst ein stiller Vollzugriff. Zwei Abfragen tun das seit dem 02.09.2026 nicht, und es sind genau die beiden, für die es die zweite Richtlinie gibt: Sie suchen erst, welcher Shop gemeint ist, und können ihn deshalb nicht vorher binden. Beide lesen nur, beide fassen ausschließlich die zwei Tabellen ohne Personenbezug an, und beide stehen namentlich mit Begründung in einer Ausnahmeliste des Prüfstands — er meldet jede weitere Stelle dieser Art und jeden Eintrag, der ins Leere zeigt.
• Die Tabelle shops selbst trägt keinen Zeilenschutz. Sie hat keine shop_id-Spalte, sondern ist die Shop-Tabelle; die Anwendungsrolle hat auf ihr Leserecht über alle Zeilen sowie Lösch- und spaltenweises Schreibrecht. Die Mandantentrennung wirkt dort ausschließlich über die Anwendung — jede Abfrage filtert über den Suchwert der Shop-Domain — und über spaltenweise Rechte (1.3). Damit ist die Tabelle, die die produktiven Händlerdaten führt, gerade nicht durch den Zeilenschutz abgesichert; siehe Abschnitt 7.2.
• Die Anwendung verbindet sich mit einer entrechteten Datenbankrolle, die den Zeilenschutz nicht umgehen darf und ausdrücklich nicht Eigentümerin der Tabellen ist (Eigentümer und Superuser würden den Zeilenschutz immer umgehen).
• Fehlt diese Rolle im Betrieb oder ist sie mit der Verwaltungsrolle identisch, bricht die Anwendung den Start ab, statt lautlos ohne wirksame Mandantentrennung zu laufen. Dasselbe gilt für eine Umgebungsangabe, die keinen der beiden erlaubten Werte trägt: Ein Tippfehler ergäbe sonst lautlos eine Umgebung, die als Entwicklung gilt.
• Die Datenzugriffsschicht kann ohne Mandantenangabe keine Abfrage bilden. Tabellennamen werden gegen eine Freigabeliste und ein festes Namensmuster geprüft, Werte ausschließlich als Parameter übergeben; ein rohes SQL-Fragment lässt sich nicht übergeben.

1.3 Rechte auf das Nötigste beschränkt

Datenbankrechte sind spaltenweise statt tabellenweit vergeben:

• Anlegen eines Shops nur mit Domain und Suchwert,
• Ändern nur auf den Spalten, die sich im Betrieb wirklich ändern — Token und ihre Zeitpunkte, Zustimmungsangaben, Abonnementstand, Einrichtungsstand, Berechtigungsumfang und der Zeitpunkt der Deinstallation,
• Lesen der Kennungen eingehender Meldungen nur auf den tatsächlich gelesenen Spalten,
• Schreiben des Zugriffsprotokolls nur auf den fünf tatsächlich geschriebenen Spalten — nicht auf der laufenden Nummer und nicht auf dem Zeitpunkt, der damit festgestellt und nicht behauptet wird,
• Schreiben einer Zustimmung nur auf Shop-Zuordnung und Fassungskennung; der Zeitpunkt entsteht in der Datenbank.

Zwei Bestände tragen deshalb eine Zusage, die sonst nur Vorsatz wäre:

• Auf dem Zugriffsprotokoll für geschützte Kundendaten gibt es kein Änderungsrecht, damit Einträge nachträglich nicht veränderbar sind. Es wird ausschließlich anhängend geschrieben.
• Auf dem Zustimmungsverlauf gibt es ebenfalls kein Änderungsrecht: Welcher Fassung ein Händler wann zugestimmt hat, ist eine Tatsache über die Vergangenheit.

Ein Löschrecht besteht auf beiden, und es wird gebraucht. Der Löschpfad räumt jede Tabelle mit einer Shop-Zuordnung; ohne dieses Recht bliebe ein Nachweis nach der Löschung des Shops liegen. Der Prüfstand hält die Zusagen dieses Abschnitts gegen die tatsächlich erteilten Rechte im Datenbankkatalog — bei Kartuu sprach dieselbe Anlage einer Tabelle ein Recht ab, das die Anwendungsrolle hielt.

1.4 Keine Geheimnisse an falscher Stelle

• Weder Access-, noch Refresh-, noch Sitzungsnachweis werden protokolliert — auch nicht gekürzt. Dasselbe gilt für die Kontaktadresse des Händlers. Im Fehlerfall wird nur der Ausnahmetyp geschrieben, nie die Ausnahmemeldung, weil diese Teile der Nutzdaten zitieren könnte. Von dieser Regel gibt es genau eine Ausnahme, und sie steht im Punkt über den gescheiterten Token-Tausch.
• Auch die Antworten von Shopify werden nicht im Wortlaut protokolliert. Lehnt Shopify eine Abfrage ab, werden ausschließlich Fehlerkennung und Feldpfad übernommen — beides Namen aus dem GraphQL-Schema. Die Meldung selbst bleibt draußen: Sie ist Fließtext, in dem ein abgelehnter Wert zitiert sein kann.
• Die eine benannte Ausnahme: Scheitert der Token-Tausch mit Shopify vorübergehend, schreibt das Protokoll zusätzlich die Meldung dieser einen Fehlerklasse. Sie ist keine von außen erhaltene Zeichenkette: KYTH setzt sie selbst zusammen, und sie besteht ausschließlich aus eigenem Text, einem HTTP-Statuscode, einem Ausnahmetyp und der Shop-Domain — Letztere steht ohnehin in derselben Zeile. Weder ein Token noch ein Geheimnis noch eine Antwort von Shopify im Wortlaut kann darin auftauchen. Der Grund für die Ausnahme ist betrieblich: Ohne sie ist im Störungsfall nicht unterscheidbar, ob das Netz weg war, ob das Anwendungsgeheimnis nicht passt, ob Shopify gedrosselt hat oder ob der Datensatz zum Shop fehlte — vier verschiedene Ursachen mit vier verschiedenen Behebungen.
• Ein Prüflauf gegen versehentlich eingecheckte Geheimnisse läuft automatisch vor jeder Übernahme in die Versionsverwaltung; die Umgebungsdatei ist von Repository und Container-Abbild ausgeschlossen.
• Zugangsgeheimnisse liegen ausschließlich in der Bereitstellungsumgebung.

1.5 Zugriffsprotokoll für geschützte Kundendaten

Wird vom ersten Tag an geführt und ist bewusst inhaltsfrei: Die zulässigen Werte für Akteur und Feldkategorie sind doppelt abgesichert (Prüfung im Code und Prüfregel in der Datenbank). Ein Fehler beim Protokollieren bringt den fachlichen Aufruf nicht zu Fall.

Fünf Zwecke schreiben hinein, und drei davon seit dem 03.09.2026. Die beiden Datenschutz-Meldungen schreiben ihren Eintrag unabhängig davon, ob sie eine Zeile treffen — durchsucht werden seit dem 02.09.2026 die drei Tabellen des Mengenkontos und die der Verarbeitungsvorfälle, seit dem 04.09.2026 zusätzlich die der Materialzeilen (§ 7.2). Dazu kommen die drei Wege des Ingest: die Entgegennahme einer Sendungsmeldung, der Abgleich der versendeten Bestellungen und die Nacherfassung der Bestellhistorie. Alle drei lesen aus der Lieferadresse den Ländercode und üben damit die geschützte Kundendatenkategorie address aus (§ 2.3); geschrieben wird ein Eintrag je Lauf mit der Zahl der Bestellungen, deren Lieferadresse gelesen wurde — beim Webhook also eins. Ein Eintrag je Sendung machte aus einem Nacherfassungslauf über 40.000 Bestellungen 40.000 Zeilen in einem Bestand, der eine Aussage über den ZUGRIFF machen soll und nicht über die Daten.

Bis zum 03.09.2026 stand hier „Es läuft heute ins Leere, und das steht so da. Beschrieben wird es allein von den beiden Datenschutz-Meldungen". Das war der Zustand des Programms und nicht seine Absicht: Der Ingest las die Kategorie address seit dem 02.09.2026 bei jedem Lauf und schrieb keinen einzigen Eintrag — für den Weg, der praktisch alle Zugriffe auf geschützte Kundendaten ausmacht, war damit nichts vorzulegen. Bis zum 02.09.2026 stand hier als erster Grund, in der Liste der zu durchsuchenden Tabellen stehe keine; das war der Zustand des Programms und nicht der Grund. Bis zum 01.09.2026 stand hier als Grund „es gibt keine Kundendaten"; seit die Tabellen des Mengenkontos bestehen, ist das der falsche Grund für ein weiterhin richtiges Ergebnis.

Was genau in einem Eintrag steht, ist eine bewusste Entscheidung und keine Ungenauigkeit. Vermerkt wird das vollständige Kategorienvokabular, das die Schnittstelle abdecken könnte — Name, Adresse, E-Mail-Adresse und Telefonnummer —, und daneben die Anzahl der betroffenen Datensätze: bei den beiden Datenschutz-Meldungen die Zahl der gefundenen Zeilen, bei den drei Wegen des Ingest die Zahl der Bestellungen, deren Lieferadresse gelesen wurde. Wie viele Zeilen die beiden Meldungen finden, hängt seit dem 02.09.2026 am Bestand des Shops und nicht an einer Zusage dieses Vertrages (§ 9.1). Bis zum 03.09.2026 stand hier allein die „Anzahl der tatsächlich gefundenen Datensätze, heute null" — es gab die drei anderen Zwecke noch nicht; am selben Tag stand hinter der ersten Angabe noch der Zusatz „(heute null)", obwohl der Abgleich die Zeilen bereits anlegte. Die beiden Angaben sind unterschiedlich genau, und das ist Absicht: Eine Zuordnung, welche Datenbankspalte zu welcher Kategorie gehört, gibt es im Programm nicht. Sie zu erfinden hieße, eine genauere Aussage zu protokollieren, als belegbar ist — und ein Nachweis, der genauer aussieht, als er ist, ist im Streitfall schlechter als keiner. Die Zahl dagegen ist gemessen und wird geschrieben, wie sie ist; ein Nachweis über einen Zugriff, den es nicht gegeben hat, entwertet das Protokoll genauso.

2. Integrität

2.1 Prüfung eingehender Aufrufe

• Meldungen von Shopify: HMAC-SHA256 über den rohen Inhalt, Vergleich in konstanter Zeit, Ablehnung mit Statuscode 401 bei Fehlern — und zwar vor jeder weiteren Verarbeitung, damit niemand ohne gültige Signatur Kennungen blockieren kann. Die Reihenfolge ist festgelegt: Größendeckel, Signatur, Anspruch, Arbeit, Antwort. Dieselbe Prüfung in derselben Reihenfolge gilt für jede eingehende Meldung, auch für die vier seit dem 03.09.2026 eingeschalteten Endpunkte des Ingest: die Sendungsmeldung (angelegt und geändert), den Storno einer Bestellung, die Erstattung und die Fertigmeldung einer Sammelabfrage (§ 3.4, § 6.4). Bis zum 03.09.2026 nannte dieser Abschnitt die vier Endpunkte nicht, und der Hinweis im Kopf verwies für sie auf einen Abschnitt 1.6, den diese Anlage nie hatte.
• Meldungen aus KYTH.Karl: eigenes Verfahren mit einem eigenen Geheimnis, das nur diesem Weg dient und in keiner anderen Anwendung eine zweite Bedeutung hat. HMAC-SHA256 über Zeitstempel, Shop-Domain und rohen Inhalt zusammen — der Zeitstempel und die Shop-Domain sind damit mitunterschrieben und nicht bloß Beiwerk: Ein mitgeschnittener Aufruf lässt sich weder mit frischer Zeit erneut einspielen noch mit geänderter Kopfzeile einem anderen Shop zuschreiben. Dazu ein Zeitfenster von fünf Minuten in beide Richtungen gegen Wiedereinspielung, derselbe Vergleich in konstanter Zeit und derselbe Größendeckel vor der Signaturprüfung wie oben; abgelehnt wird ohne Angabe eines Grundes. Ist für diesen Weg kein Geheimnis hinterlegt, antwortet die Adresse, als gäbe es sie nicht — ein nicht eingerichteter Eingang ist damit kein unbewachter. Diese Prüfung steht seit dem 08.09.2026, und seit dem Abend desselben Tages auch die Adresse dahinter (Anlage 1 Abschnitt A, Absatz „Was an diesem Tag besteht"); bis zu jenem Abend stand hier, die Adresse gebe es noch nicht. Seit dem Nachmittag des 09.09.2026 steht vor der Verbuchung dahinter ein weiterer Riegel: die Weisung des Händlers. Ohne sie antwortet die Adresse mit einer eigenen Kennung und legt keine Zeile an — auch keinen Eingangsbeleg. Bis zum 08.09.2026 nannte dieser Abschnitt nur die Punkte über die Meldungen von Shopify und über den Sitzungsnachweis, und das war richtig: Bis dahin gab es keinen zweiten Absender.
• Sitzungsnachweis: Prüfung mit erzwungenem Signaturverfahren, Vergleich in konstanter Zeit, enge Toleranz bei Gültigkeitszeitpunkten, Wiedereinspielfenster von 70 Sekunden, Prüfung des Adressaten gegen die eigene Anwendungskennung sowie Kreuzprüfung von Aussteller und Ziel einschließlich Schutz vor eingeschleusten Benutzerangaben im Hostnamen.

2.2 Absicherung der eingebetteten Oberfläche

Sicherheitskopfzeilen: Inhaltsrichtlinie (Content-Security-Policy) mit dynamischer Einbettungsbeschränkung, deren Shop-Parameter gegen ein vollständig verankertes Muster geprüft wird und bei mehrfacher Angabe abweisend reagiert; X-Content-Type-Options; Referrer-Policy: strict-origin-when-cross-origin. Die Oberfläche lädt keine fremde Quelle außer der App-Bridge-Bibliothek von Shopify.

2.3 Angriffsfläche klein halten

Schema-Beschreibung und interaktive Dokumentation der Schnittstelle sind im Produktivbetrieb abgeschaltet (die Routen existieren dort nicht). Es gibt keine Route, die einen Wert aus der Anfrage in einen Dateipfad übernimmt; die Rechtstexte werden über vier fest verdrahtete Adressen ausgeliefert und nicht über einen Pfadparameter.

2.4 Prüfung der Eingaben des Zustimmungsschritts

Die im Zustimmungsschritt eingegebene Kontaktadresse wird serverseitig gegen ein vollständig verankertes Muster geprüft (keine Zeilenumbrüche, keine Trennzeichen, kein spitzklammerartiger Anhang, Domäne mit Punkt, Längenbegrenzung), Randleerzeichen werden entfernt, die Groß- und Kleinschreibung bleibt erhalten. Die Zustimmung muss als echter Wahrheitswert übermittelt werden — Zeichenketten oder Zahlen gelten nicht als Zustimmung.

Begrenzung des Anfragekörpers. Der Körper dieser Anfrage darf 4 Kilobyte nicht überschreiten; mehr braucht er nie, denn er trägt eine E-Mail-Adresse und einen Wahrheitswert. Die Grenze wirkt an zwei Stellen: vorab gegen die vom Aufrufer angekündigte Länge und — entscheidend — während des Einlesens selbst, das abgebrochen wird, sobald die Grenze überschritten ist. Ohne den zweiten Teil wäre die Zusage wirkungslos: Eine Anfrage kann ihre Länge verschweigen, und der Körper läge dann vollständig im Arbeitsspeicher, bevor irgendeine Prüfung greift. Bei Kartuu war genau das eine Zeitlang der Fall.

Derselbe Deckel wirkt an jeder Route, die einen Körper entgegennimmt, und an jeder eingehenden Meldung von Shopify. Beide Grenzen stammen aus einer Umsetzung — eine kopierte Schutzmaßnahme wird an einer Stelle repariert und an der anderen vergessen. Ein Körper über dem Deckel endet ausdrücklich nicht in einer erfolgreichen Antwort mit leeren Werten, sondern in einer Ablehnung.

2.5 Nachvollziehbarkeit von Änderungen

Das Datenbankschema wird ausschließlich über Migrationen und in einem eigenen Prozess vor dem Start der Anwendung geändert; kein Arbeitsprozess sieht ein halbfertiges Schema. Jede Migration trägt einen funktionierenden Rückweg.

3. Verfügbarkeit und Belastbarkeit

Die ersten beiden Punkte beschreiben den Aufbau der Anwendung selbst und gelten, sobald sie läuft. Alles, was danach von Sicherungen und Prüfläufen handelt, ist eine Zusage ab Inbetriebnahme und kein laufender Ist-Zustand: Kuno ist noch in keiner Umgebung eingerichtet, und ein Zeitplan, der eine Sicherung anstößt, entsteht mit ihr. Der Punkt steht auch unten unter den bekannten Lücken (Abschnitt 7.2), weil eine Zusage, die man für einen Ist-Zustand hält, die teuerste Sorte Satz in dieser Anlage wäre.

• Der Container läuft nicht mit Systemrechten (eigener Benutzer), mehrstufiger Aufbau, Zustandsprüfung.
• Sperrkonflikte in der Datenbank laufen in eine Zeitgrenze und enden in einer sauberen Fehlermeldung statt in einem hängenden Arbeitsprozess. Ein erschöpfter Verbindungspool endet in einer Antwort mit Statuscode 503 und nicht in einem Serverfehler.
• Tägliche Datenbanksicherung, mit AES-256 verschlüsselt, bevor sie den Server verlässt, abgelegt auf dem Server (Aufbewahrung 30 Tage) und im Objektspeicher der IONOS in Berlin (Aufbewahrung 95 Tage, davon die ersten 90 durch Object Lock unlöschbar). Damit liegt eine Kopie außerhalb des Servers; ein Ausfall des Datenträgers nimmt nicht mehr Datenbank und Sicherung zugleich mit. Einzelheiten in § 9.3 Nr. 2.
• Die Sicherung prüft sich selbst. Vor dem Hochladen wird die verschlüsselte Datei wieder entschlüsselt und darauf geprüft, dass ein Datenbankabzug herauskommt; nach dem Hochladen wird beim Speicher zurückgefragt, ob das Objekt in der erwarteten Größe angekommen ist. Eine Datei, die niemand öffnen kann, und eine, die nie ankam, gelten damit nicht als Sicherung. Ein zu kleiner Abzug führt zum Abbruch — eine leere Sicherung sieht im Speicher aus wie eine echte und fällt sonst erst auf, wenn man sie braucht.
• Ein täglicher Prüflauf meldet ausgebliebene Sicherungen an die Betriebsadresse von KYTH, wenn seit mehr als 26 Stunden kein erfolgreicher Lauf vermerkt wurde. Er erfasst damit auch ausgebliebene Läufe und nicht nur gescheiterte — der Ausfall, den ein Alarm im Fehlerzweig des Sicherungsskripts gerade nicht bemerkt.

4. Belastbarkeit der Konfiguration

Die Anwendung startet nicht ohne die erforderlichen Konfigurationswerte; der Verschlüsselungsschlüssel wird auf das korrekte Format geprüft, die Umgebungsangabe gegen eine Erlaubnisliste und der App-Handle gegen ein Muster, weil er in eine Adresse eingesetzt wird. Fehlkonfiguration führt zum Abbruch, nicht zu stillem Weiterlaufen.

Dasselbe gilt seit dem 08.09.2026 für das Geheimnis des Eingangs aus KYTH.Karl (Abschnitt 2.1): Es ist freiwillig — ohne es arbeitet Kuno vollständig, und die Adresse antwortet, als gäbe es sie nicht. Ist es aber gesetzt, wird seine Länge geprüft und ein zu kurzer Wert bricht den Start ab, statt einen Eingang zu bewachen, den man raten kann. Die Fehlermeldung nennt dabei den abgelehnten Wert nicht, auch nicht gekürzt: Sie landet im Containerprotokoll, und das ist ein Ort mit anderen Zugriffsregeln als die Konfiguration.

5. Eine Umgebung, und das ist eine Entscheidung

Kuno soll in genau einer Umgebung mit echten Händlerdaten laufen. Eine Testumgebung mit einer zweiten Datenbank, einem zweiten Schlüssel und einer zweiten Shopify-Anwendung ist ausdrücklich nicht vorgesehen; gebaut und geprüft wird gegen einen Entwicklungs-Shop ohne echte Händlerdaten.

Bis zum 01.09.2026 stand der erste Satz im Präsens — und widersprach damit dem Abschnitt 3 derselben Anlage, der weiter oben festhält, dass Kuno noch in keiner Umgebung eingerichtet ist. Von den Stellen dieses Vertrages, die einen künftigen Betrieb im Präsens beschreiben, ist dies die einzige, die einem Satz desselben Dokuments widerspricht; deshalb ist sie berichtigt und nicht bloß in die Liste nach § 0.3 aufgenommen worden.

Warum das hier steht: Zwei Umgebungen sind die übliche Antwort und bringen ihre eigene Fehlerquelle mit — geteilte Schlüssel, verwechselte Werte in der Bereitstellung, eine Löschung in der einen, die Daten in der anderen trifft. Bei Kartuu ist eine Umgebung vier Tage lang unbemerkt auf einem alten Stand gelaufen, weil eine Variable in der einen von beiden fehlte. Wer für Kuno später eine zweite Umgebung einrichtet, muss diesen Abschnitt ändern und dabei je Umgebung eigenen Schlüssel, eigene Rolle, eigenes Kennwort und eigenen Eimer vorsehen.

6. Verfahren zur Überprüfung und Bewertung

• Löschpfad ohne pflegbare Liste: Die beim Löschen zu leerenden Tabellen werden zur Laufzeit aus dem Datenbankkatalog ermittelt — alle Tabellen im Schema public mit einer Spalte shop_id. Die Löschung läuft in einer Transaktion. Nicht erfasst werden Tabellen in anderen Schemata, Tabellen mit abweichend benannter Shop-Spalte, Views und Tabellen, die nur mittelbar über einen Fremdschlüssel hängen. Die vier Grenzen sind im Quelltext offen benannt und stehen ausformuliert in § 9.1.
• Ein Löschpfad, zwei Auslöser. Der Aufräumlauf für verwaiste Shops (§ 9.3 Nr. 1) benutzt genau dieselbe Löschfunktion wie shop/redact. Eine zweite Löschroutine müsste dieselbe Tabellenermittlung, dieselbe Mandantenbehandlung und dieselbe Transaktionsgrenze nachbilden — und würde über kurz oder lang eine Tabelle vergessen, die nur in einer der beiden gepflegt wird.
• Automatische Prüfungen gegen schleichende Abweichung. Sie laufen bei jeder Änderung mit, und sie sind der Grund, warum die Anlagen dieses Vertrages nicht veralten können, ohne dass es auffällt:
• Jede neue Tabelle mit Shop-Zuordnung muss Zeilenschutz mit ENABLE und FORCE, eine Mandantenrichtlinie, spaltengenaue Rechte und einen Eintrag in der Freigabeliste der Datenzugriffsschicht tragen — oder ausdrücklich und mit Begründung ausgenommen sein.
• Jede Tabelle mit einer Spalte, deren Name auf eine natürliche Person deutet, muss in der Liste stehen, die Auskunft und Löschung durchsuchen — oder die Spalte ist dort mit Begründung ausgenommen. Die Prüfung geht über Namensmuster und erkennt deshalb keine pseudonyme Kennung; was das für das Mengenkonto bedeutet, steht in § 7.2.
• Anlage 1 Abschnitt A wird gegen die Tabellen des echten Datenbankschemas gehalten: Kommt eine Tabelle hinzu, die hier nicht geführt ist, fällt die Prüfung.
• Keiner der vier Rechtstexte darf einen Bestand leugnen, den es im Datenbankschema gibt. Gemessen wird jedes der vier Dokumente vollständig, auch der nicht ausgelieferte Arbeitsteil, gegen ein Verzeichnis von Wendungen, die eine solche Leugnung tragen; jede Wendung hängt an einer Tabelle oder einer Spalte, die sie widerlegt, und ein Eintrag ohne Bestand fällt selbst auf. Zwei Grenzen benennt die Prüfung selbst. Erstens ist das Verzeichnis von Hand geführt: Eine neu formulierte Leugnung erkennt sie nicht (dieselbe Grenze wie in Anlage 1 Abschnitt C). Zweitens sucht sie im Text ohne die in Anführungszeichen gesetzten Stellen — anders schlüge sie auf jede datierte Selbstkorrektur an, mit der dieser Vertrag einen früheren Wortlaut stehen lässt, und wäre nach dem zweiten Fehlalarm abgeschaltet statt befolgt. Wer eine lebende Leugnung in Anführungszeichen setzt, kommt an ihr vorbei; dass die Grenze nicht zu viel wegschneidet, hält eine zweite Prüfung dagegen. Bis zum 01.09.2026 gab es diese Prüfung für zwei der vier Texte und stand in dieser Aufzählung überhaupt nicht.

• Kein Rechtstext darf im Präsens zusagen, was es im Quelltext nicht gibt. Die Gegenrichtung zum Punkt darüber, und sie hat gefehlt. Gemessen wird wieder jedes der vier Dokumente vollständig, auch der Arbeitsteil — diesmal gegen den Quelltextbaum statt gegen das Datenbankschema: gegen ein Verzeichnis von Wendungen, die eine Leistung als vorhanden behaupten, und je Wendung gegen eine Messung, die ihre Abwesenheit belegt. Seit dem 05.09.2026 führt dieses Verzeichnis keine Wendung mehr, und das ist eine Auskunft und kein Versehen: Die letzte Messung — dass keine Route einen Bericht oder eine Datei zum Händler bringt — ist an jenem Tag gefallen, weil es diese Routen seither gibt; die drei Sätze, die sie verbot, sind damit wahr, und die Frage steht seither umgedreht in der Prüfung darunter. Die Prüfung selbst bleibt scharf: Sie greift wieder, sobald ein späterer Ausbau in einen dieser Texte geschrieben wird, bevor es ihn gibt. Bis zu jenem Tag stand hier „heute ist das eine einzige: dass keine Route einen Bericht oder eine Datei zum Händler bringt“. Bis zum 03.09.2026 lautete die zweite Messung „keine Tabelle für einen Verpackungskatalog", bis zum 04.09.2026 „keine Route, über die er eine Verpackung anlegen könnte"; seit der Migration 0018 gibt es die Tabellen und seit dem 04.09.2026 die Endpunkte; die Verpackungsseite bedient beide seit dem Abend des 06.09.2026, und bis zu jenem Abend endete dieser Satz mit „was heute fehlt, ist die Bedienseite". Beide Fragen sind damit nicht weggefallen, sondern in die Prüfung darüber gewandert: Kein Text darf mehr sagen, für den Katalog gebe es im Datenbankschema keine Tabelle, und keiner, es gebe keinen Weg, über den der Händler ihn füllt. Wird eine dieser Fähigkeiten gebaut, fällt die Prüfung von der anderen Seite und verlangt, dass der Eintrag verschwindet. Genau das ist am 02.09.2026 geschehen: Bis dahin nannte diese Aufzählung als dritte Messung „kein Aufrufer des Schreibpfads". Seit diesem Tag gibt es den Programmteil, der eine Shopify-Sendung in die Zeilen des Mengenkontos umsetzt; die Prüfung ist gefallen, der Eintrag ist heraus, und dieselbe Frage steht seither umgedreht in der Prüfung darunter — kein Text darf die Verbuchung einer Sendung noch als fehlend beschreiben. Drei Grenzen benennt sie selbst. Erstens ist das Verzeichnis der Wendungen von Hand geführt: eine neu formulierte Zusage erkennt sie nicht. Zweitens misst sie nur, was im Quelltextbaum überhaupt vorkommen kann — eine Zusage über eine Tarifbeschreibung im Shopify App Store liegt außerhalb, und diese Stelle ist gelesen und nicht gemessen. Drittens erkannte sie jede Fähigkeit, solange sie eine führte, nur daran, dass es eine Route für sie gibt: Eine Ausgabe, die den Händler ohne eigene Route erreicht, und eine Katalogpflege, die an einer bestehenden Route mitfährt statt eine eigene zu haben, wären an ihr vorbeigekommen. Dieselbe Grenze gilt für die nächste Wendung, die hier eingetragen wird. Bis zum 03.09.2026 lautete diese dritte Grenze für den Katalog anders — sie sprach von „einem Verpackungskatalog, der gar nicht in der Freigabeliste der Datenzugriffsschicht steht"; seit der Migration 0018 stehen seine drei Tabellen ausdrücklich in dieser Liste, und die Messung fragt nicht mehr sie, sondern die Endpunkte. Die Zitatgrenze des Punktes darüber gilt auch hier. Bis zum 01.09.2026 gab es diese Prüfung nicht, und in drei der vier Dokumente standen Stellen, die im Präsens zusagten, was Anlage 1 Abschnitt C in derselben Fassung als nicht vorhanden führt.

  Bis zum selben Tag lautete die dritte Grenze anders und war größer: Zwei der drei Messungen erkannten die Fähigkeit an einem Namen — an Wörtern im Pfad einer Route und im Namen einer Tabelle. Eine Ausgaberoute oder eine Katalogtabelle unter einem anderen Namen wäre daran vorbeigekommen, und die Prüfung hätte weiter Sätze verboten, die inzwischen zutreffen. Seither führt sie zusätzlich den Bestand: die Endpunkte der Anwendung und die Freigabeliste der Datenzugriffsschicht, beide gemessen am 01.09.2026. Kommt eine Route oder eine Tabelle hinzu, fällt sie — gleich unter welchem Namen. - Kein Rechtstext darf ein Verhalten leugnen, das die App zeigt. Die dritte Textrichtung, gebaut am 03.09.2026. Der Punkt zwei Absätze darüber misst gegen das Datenbankschema und sieht deshalb nur Aussagen über Tabellen und Spalten; diese Prüfung misst gegen den Quelltextbaum, was die App entgegennimmt, was sie bei Shopify anfordert und welche Stelle des Programms etwas auslöst — die App-Konfiguration mit ihren eingeschalteten Meldungen, die Routen, die sie annehmen, die Felder der Abfragen und die Aufrufer. Auch sie misst alle vier Dokumente vollständig. Drei Grenzen benennt sie selbst: eine neu umschriebene Leugnung erkennt sie nicht, weil das Verzeichnis der Wendungen von Hand geführt ist; sie sucht im Text ohne die in Anführungszeichen gesetzten Stellen, wie die Prüfungen darüber; und ein Verhalten ohne eigene Messung fällt aus ihr heraus. Bis zu diesem Tag stand in beiden großen Zustimmungstexten an acht Stellen, die Entgegennahme einer Sendungsmeldung finde nicht statt — keine der drei damaligen Prüfungen konnte das sehen, weil zu einer solchen Aussage keine Tabelle gehört. - Wer einen Aufrufer leugnet, wird am Quelltextbaum gemessen — an der Form und nicht an einer Wortliste. Steht in einem der vier Dokumente ein Funktionsname in Rückwärtsstrichen und daneben die Behauptung, er habe keinen Aufrufer, wird genau dieser Name im Anwendungscode nachgeschlagen. Diese Sätze stehen in den Belegtabellen, also an der Stelle, an der nachvollziehbar ist, worauf ein Vertragssatz beruht; ein unrichtiger Beleg bestätigt beim nächsten Durchgang den Satz, den er berichtigen soll. Drei Grenzen: eine Leugnung ohne Namen in Rückwärtsstrichen erkennt sie nicht, ein Aufrufer außerhalb des Anwendungscodes zählt bewusst nicht, und eine Behauptung hinter einer datierten historischen Einleitung ist entlastet — sonst machte die Prüfung die Änderungshistorie rot und wäre nach dem zweiten Fehlalarm abgeschaltet. Damit sie nicht unbemerkt ins Leere läuft, wenn alle Belege berichtigt sind, wird ihre Wirksamkeit bei jedem Lauf an drei Probesätzen nachgewiesen statt an der Fundmenge des Tages. Bis zum 03.09.2026 entlastete sie außerdem an neun sehr häufigen deutschen Wörtern statt an einer Datumsangabe; damit wäre auch eine neue Behauptung in derselben Umgebung entlastet gewesen. - Kein Rechtstext darf einen Bestand leer sagen, der sich füllt. Die vierte Textrichtung, gebaut am 03.09.2026. Die Prüfung über die Bestände misst, ob es die Tabelle gibt; diese misst, ob der Text ihr Zeilen abspricht, die entstehen. Die Faktenseite ist bewusst keine Zeilenzahl — der Prüfstand misst gegen eine Prüfdatenbank, und die trägt andere Zeilen als der Shop eines Händlers. Gemessen wird stattdessen, ob es einen Schreibweg in die Tabelle gibt und ob dieser Schreibweg im Anwendungscode gerufen wird; ist das so, hängt die Zahl am Bestand des Shops und ist keine Zusage, die dieser Vertrag halten kann. Drei Grenzen: das Verzeichnis der Wendungen ist von Hand geführt, die Zitatgrenze der Punkte darüber gilt auch hier, und gemessen ist der Schreibweg samt Aufrufer, nicht die ganze Kette bis zu einem Auslöser — die misst die Prüfung über das Verhalten. Bis zum 03.09.2026 gab es diese Richtung nicht, und fünf Stellen der beiden großen Zustimmungstexte sagten weiter, das Mengenkonto sei leer bzw. die Zahl der betroffenen Datensätze null, während dieselben Dokumente an acht anderen Stellen sagten, die Tabellen füllten sich seit dem 02.09.2026 im laufenden Betrieb. Bis zum 06.09.2026 kannte diese Prüfung außerdem nur EINE Schreibweise der Einfügung und nur ZWEI Formen eines Aufrufers, und war damit für drei der vier Bestände der Meldung blind: Sie suchte die Spaltenliste unmittelbar hinter dem Tabellennamen in derselben Zeile — der schreibende Programmteil setzt sie auf die nächste —, und sie zählte einen Aufrufer nur, wenn er die Funktion beim Namen ruft oder einzeln einholt, nicht wenn er sie über den Namen ihres Moduls weiterreicht. Für die Meldezeiträume, die Mengen je Materialart und die erzeugten Meldedateien konnte die Prüfung deshalb nie anschlagen; zwei Sätze in Anlage 1 Abschnitt A und in Abschnitt 5.1 der Datenschutzerklärung sind genau daran vorbeigekommen. Beides ist an diesem Tag berichtigt, und der Prüfstand hält seither zusätzlich fest, welche Schreibfunktion zu welchem dieser vier Bestände gehört — sonst fiele die Fundmenge beim nächsten Umbau wieder lautlos auf null. - Jede Stelle mit einer datierten Selbstkorrektur muss in der Liste stehen, die beim Heben der Fassungskennung nachzuführen ist (§ 0.3, Abschnitt 14 der Datenschutzerklärung). Drei Grenzen benennt die Prüfung selbst. Erstens misst sie nur den ausgelieferten Teil eines Dokuments: Eine Selbstkorrektur im Arbeitsprotokoll steht in keiner Liste — die Liste sagt, was ein Händler beim Heben der Kennung erneut vorgelegt bekommt, und einem Arbeitsvermerk stimmt niemand zu. Zweitens misst sie nur die drei Zustimmungstexte; das Impressum ist keiner und hat keine nummerierten Abschnitte, gegen die sich eine Liste führen ließe. Drittens erkennt sie eine Vorbehaltsstelle nicht, die ohne Selbstkorrektur entstanden ist — dafür bleiben die Listen handgeführt. Bis zum 01.09.2026 nannte dieser Punkt nur die dritte Grenze; bis zum selben Tag las die Prüfung außerdem die Ordnungszahlen aus „Anlage 1" und „Nr. 6" als Abschnittsnummern und hielt § 1, § 2 und § 6 dieses Vertrages deshalb für aufgezählt, ohne dass sie jemand genannt hätte. Ebenfalls am 01.09.2026 berichtigt: Sie suchte die Selbstkorrekturen an einem fest eingetragenen Datum und hätte jede an einem anderen Tag geschriebene übersehen, ohne dass etwas aufgefallen wäre — und sie hatte keine Untergrenze, wäre also auch über einer leeren Fundmenge grün geblieben. - Die Zusagen dieser Anlage über Änderungs- und Löschrechte werden gegen den Rechtekatalog der Datenbank gehalten. - Die Angaben über die Aufrufe an die Admin-API und über die angeforderten Berechtigungen werden gegen den Quelltext bzw. gegen die App-Konfiguration gehalten. - Jeder Weg, auf dem Bytes das Haus verlassen, wird gezählt und muss im Vertrag stehen — mit Namen und nicht nur als Zahl. Gemessen wird jede Stelle im Anwendungscode, an der die HTTP-Bibliothek eine Verbindung öffnet; heute sind das der Token-Endpunkt, die Admin-API und die Ergebnisablage (§ 6.5). Bis zum 02.09.2026 zählte diese Messung nur die beiden Client-Klassen der Bibliothek und übersah damit ausgerechnet den einen Weg, der nicht zum Händler-Shop führt; seither zählt sie auch den Strom-Aufruf. - Ablaufplan für Sicherheitsvorfälle mit 72-Stunden-Frist, benannter Aufsichtsbehörde (BayLDA), Eskalationsstufen und benannten Zuständigkeiten.

7. Bekannte Lücken — offen benannt

Diese Punkte sind heute nicht oder nicht vollständig erfüllt. Sie stehen hier, weil eine Darstellung technischer Maßnahmen, die ihre Lücken verschweigt, wertlos ist.

7.1 Seit dem vorherigen Stand geschlossen

Was „der vorherige Stand" hier heißt. Kuno ist auf dem Gerüst der Shopify-App Kartuu derselben Gesellschaft gebaut. Die folgenden Lücken waren dort offen und sind in Kuno von Anfang an geschlossen; das genannte Datum ist der Tag, an dem die Maßnahme in Kuno gebaut wurde. Die Tabelle steht hier und nicht im Arbeitsteil, damit niemand einer überholten Fassung folgt und eine geschlossene Lücke für offen hält.

7.2 Weiterhin offen