Agieren Sie als: Ein leitender Lösungsarchitekt für die Onboarding-Prozesse im Bereich Professional Services, spezialisiert auf Datenmodellierung, regulierte Datenerfassung und Supabase/Postgres-Design.

Warum diese Aufgabe wichtig ist: Service-Intake übersieht oft erforderliche Details und speichert PII unsicher. Ein streng definiertes Schema mit Validierungen, Einwilligungsstrukturen und Abbildung auf eine relationale Datenbank verhindert Nacharbeit und Compliance-Probleme.

Wichtige Grenzen: Gehen Sie von Supabase Postgres + Auth aus. Verwenden Sie ISO-Formate für Datum/Uhrzeit. Markieren Sie alle PII/PHI-Felder. Fügen Sie Einwilligungs- und Aufbewahrungsfelder hinzu. Verwenden Sie snake_case für Benennungen. Vermeiden Sie Übernormalisierung, die die Benutzererfahrung beeinträchtigt.

Benutzereingaben (geben Sie diese an oder fragen Sie mich danach, falls sie fehlen):
1) Branche und Servicetyp(en)
2) Liste der erforderlichen Dokumente und maximale Größen
3) Regulatorische Vorgaben (z.B. DSGVO, HIPAA, SEC)
4) Benötigte Sprachen/Locales
5) Unterschiedliche Benutzerrollen (Kunde, Intake-Prüfer, Admin)
6) Wichtige nachgelagerte Systeme (Abrechnung, CRM)

Ziele:
- Erstellen Sie einen Entitäts-Feld-Blueprint mit Typen, Validierungen und bedingter Logik
- Identifizieren Sie Pflicht- vs. optionale Felder und Abhängigkeiten zwischen Feldern
- Kennzeichnen Sie PII/PHI und definieren Sie Felder zur Einwilligungserfassung
- Abbildung auf ein Supabase-fertiges Tabellendesign mit RLS-Annahmen

Analyseablauf:
1) Klärung branchenspezifischer Daten- und regulatorischer Anforderungen
2) Entwurf der Entitäten: client_profile, engagement, intake_submission, file_upload, consent, status_event
3) Für jedes Feld: Name, Label, Typ, Regex/Bereich, Pflichtfeld, conditional_on, pii_flag, Beispielwert
4) Definition von Enumerationen und Normalisierungsgrenzen
5) Skizzierung von RLS-Mustern nach Rolle und Datensatzbesitz
6) Vorschlag für Indexierungsstrategie, eindeutige Einschränkungen und Fremdschlüssel

Erforderliches Ausgabeformat:
- Abschnitt A: ERD-Hinweise auf hoher Ebene (Stichpunkte)
- Abschnitt B: JSON-Schema für jede Entität und Felder mit Validierungen
- Abschnitt C: Supabase-Tabellendefinitionen (DDL-Umriss, kein vollständiges SQL)
- Abschnitt D: RLS-Policy-Absichten pro Tabelle
- Abschnitt E: Matrix für Einwilligung und Aufbewahrung

Qualitätskontrollen:
- Jedes erforderliche Dokument hat file_type, size_limit_mb, virus_scan=true, storage_path-Muster
- Alle Datumsfelder geben Zeitzone und Format an
- Keine mehrdeutigen Freitextfelder, wenn kontrollierte Listen sicherer sind

Verifikations-Checkliste:
- Kann ein einzelner Kunde mehrere Engagements verwalten?
- Werden Einwilligungsversionen und Zeitstempel erfasst?
- Sind status_events nur anhängbar mit Akteur und Grund?

Abschließende Anweisung: Erstellen Sie den vollständigen Blueprint mit klaren Überschriften und kompaktem, kopierbarem JSON für Schemas. Stellen Sie zuerst 3 Klärungsfragen, falls etwas unklar ist.