Zweck, Population und Generierungs-Contracts
Intendierte Population, Generatormethode, Seed-Politik und Zweckgrenzen vor dem Generierungslauf vertraglich festlegen.
Ein Generator ohne Populations-Contract erfindet Demografien, die niemand intendiert hat. Eine Seed-Politik ohne Verantwortung macht „reproduzierbares“ Leakage ewig reproduzierbar. Dieser Teil bindet Zweck, Population und Methode in einen Betriebsvertrag — bevor Labeling und Re-ID-Gates darauf aufsetzen.
Vorher: Wann synthetische Daten erlaubt sind. Weiter: Labeling-Provenance und Qualität.
zierbares“ Leakage ewig reproduzierbar.
Lösung: Jeder Generierungslauf erhält vor Ausführung einen Generierungs-Contract (Zweck, Zielpopulation und Ausschlüsse, Volumen, Retention), einen Methoden-Record mit Seed- und Key-Politik, die Freigabe der Populationsabsicht durch den Data Owner, Pflege durch den Steward und Ausführung durch den Custodian unter kontrollierter Identität — plus Output-Tagging mit Contract-ID, bevor irgendetwas Downstream das Set berührt.
In einem Satz: Kein Generierungslauf ohne Populations-Contract, Methoden-Record, Owner-Freigabe und getaggten Output.
Entscheidung
Jeder Generierungslauf braucht:
- einen Generierungs-Contract: Zweck, Zielpopulation (und Ausschlüsse), Volumen, Retention;
- einen Methoden-Record: Algorithmus/Familie, Generator-Trainingsinputs (falls vorhanden), Seed-/Key-Politik, Version;
- Data-Owner-Freigabe der Populationsabsicht; Steward pflegt den Contract; Custodian führt den Job unter kontrollierter Identität aus;
- Verbote, reale Identifier als Free-Text-Prompts ohne Minimierungscontrols zu nutzen;
- Output-Tagging mit Contract-ID vor jeder Downstream-Nutzung.
Kein ungetaggter Output gilt als freigegebenes synthetisches Produkt.
Generierungs-Workflow
1. Populationsabsicht festlegen
Der Data Owner schreibt, welche Entities, Regionen, seltenen Gruppen und Edge Cases erscheinen müssen — und welche ausgeschlossen bleiben. Das Artefakt ist die Populationsabsicht im Generierungs-Contract, nicht eine Slack-Notiz. Der Steward prüft, ob die Absicht joinbar zu späteren Re-ID-Gates ist. Wird dieser Schritt übersprungen, overfitting der Generator an reale seltene Individuen und Teil 4 hat nichts zu testen.
2. Methode bewusst wählen
Regelbasiert, statistisch oder modellbasiert — jede Familie trägt ein anderes Leakage-Profil. Der Owner entscheidet die Familie zum Zweck; der Steward dokumentiert Version und Trainingsinputs des Generators. Privacy-Beratung liefert einen Risikohinweis, advisory oder verpflichtend laut Policy. Ohne Methoden-Record kann niemand Residualrisiko erklären, wenn das Set später geteilt wird.
3. Seeds und Keys kontrollieren
Der Custodian legt Seeds und Keys in gesteuerte Secret-Storage; der Steward definiert, wer identische Generierung erneut fahren darf. Seeds sind Geheimnisse, wenn sie Membership-Angriffe oder exaktes Replay sensibler Muster ermöglichen. Öffentliche Tickets mit Seed-Werten machen „reproduzierbar“ zu einem dauerhaften Leak.
4. Volumen und Retention begrenzen
Mehr Zeilen sind nicht immer besser: Volumen folgt dem Zweck, Retention folgt dem Zweck. Demo-Sets dürfen nicht wie Produktionsarchive leben; fehlgeschlagene Experimente bekommen eine dokumentierte Löschfrist. Der Owner setzt die Grenzen, der Custodian erzwingt sie im Job. Unbegrenzte Retention macht jedes gescheiterte Experiment zu einem unkontrollierten Archiv.
5. Lauf gaten
Der Custodian blockiert Läufe ohne Contract-ID. Der Steward prüft Tags in der Output-Landing-Zone, bevor Labeling- oder Eval-Teams das Set erhalten. Ändert sich die Populationsabsicht, entsteht eine neue Contract-Version — kein stilles Umschreiben mitten im Lauf. Fehlt das Gate, entstehen ungetaggte Kopien, die Teil 3 und 4 nicht mehr zuordnen können.
Handoffs
| Von | An | Artefakt |
|---|---|---|
| Data Owner | Steward | Populationsabsicht + Zweckgrenzen |
| Steward | Custodian | Generierungs-Contract + Methodenversion |
| Custodian | Steward | Run-Log (Seed-Politik, Volumen, Output-URI) |
| Steward | Labeling- / Eval-Teams | Getaggtes Set für nächste Controls |
| Privacy-Beratung | Data Owner | Methoden-Risikohinweis (advisory oder verpflichtend laut Policy) |
Anti-Patterns
- Generator mit Roh-Produktionsextrakten „für Realismus“ prompten
- Undokumentierte modellbasierte Generatoren auf uneingeschränkter Produktion
- Unbegrenzte Retention fehlgeschlagener Generierungsexperimente
- Populationsabsicht mitten im Lauf ohne neue Vereinbarung-Version ändern
- Seeds in öffentlichen Tickets teilen
Umsetzung im Alltag
Dieser Einstieg ist kein Kalenderzwang und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.
Arbeitsweise: Nutze den verlinkten Plan als Arbeitsfläche für Owner, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.
Starte mit dem kleinsten Fall, der fachlich wichtig genug ist. Prüfe danach, ob die Entscheidung wirklich auffindbar, umsetzbar und auditierbar ist. Rollenklärung: Wer hilft wem an der Quelle.
- Generierungs-Contracts für zwei aktive synthetische Pipelines veröffentlichen.
- Seeds/Keys in custodian-gesteuerte Secret-Storage legen.
- Eine Output-Landing-Zone mit Contract-IDs als Hard Gate taggen.
- Methodenfamilie und Version für den volumenstärksten Generator dokumentieren.
Synthetic data governance
Part 2 of 5
View series