Velvr Operational Defaults

Status: Living document, version 2026-05-11.
Purpose: Transparente Auflistung der technischen und algorithmischen Defaults die Velvr für die AI-Auto-Reply-Funktionalität, die Validator-Pipeline und die Datenverarbeitung anwendet.
Rechtliche Bedeutung: Dieses Dokument ist Bestandteil des DPA-Click-Through (siehe [velvr-dpa-draft.md](velvr-dpa-draft.md)). Mit Acceptance der DPA adoptiert der Customer die hier beschriebenen Defaults als seine documented instructions im Sinne von GDPR Art. 28(3)(a). Bei substantieller Änderung erfolgt eine Re-Acceptance-Notification an alle aktiven Customers.

Update-Policy: Cosmetic-Änderungen (Wording, Klarstellung) werden ohne Re-Acceptance umgesetzt und im Änderungs-Log notiert. Substantielle Änderungen (neuer Validator-Layer, AI-Modell-Wechsel, Sub-Processor-Hinzufügung, Algorithmus-Änderung) triggern Re-Acceptance via Banner + Email mit Engine-Block bis Zustimmung. Definition substantiell vs. cosmetic: siehe §8.

1. Scope dieses Dokuments

Was abgedeckt ist:

• Validator-Pipeline-Layer (alle 6 Schichten)
• Engine-Logic-Signale (Pushiness, Funnel-Stages, PPV-Picker)
• AI-Modell und Provider
• Datenfluss-Architektur
• Sub-Processor-Liste mit Zweck und geografischer Verarbeitungs-Region

Was NICHT abgedeckt ist:

• Source-Code (proprietär, nicht teil der Customer-Defaults)
• Exakte Prompt-Wordings (sicherheitsrelevant, würde Adversarial-Attacks erleichtern)
• Internal-Tuning-Parameter (z.B. Stop-Word-Listen, Refusal-Pattern-Regex) — die abstrahierten Funktionen werden beschrieben, nicht die konkreten Patterns

2. Validator-Pipeline (6 Layer)

Jede AI-generierte Caption durchläuft vor dem Send eine feste Validator-Sequenz. Jeder Layer kann die Caption ersetzen, modifizieren oder ergänzen. Die Reihenfolge ist nicht optional — sie verhindert dass ein nachgelagerter Validator einen Override des vorhergehenden überschreibt.

2.1 Layer 1 — Caption-Guard

Aktiv wenn: Engine-Decision = forced_chat_only (Warmup-Required, no_active_packages, rate_limit, cooldown_after_buy).

Was geprüft wird:

• Vault-Blocklist: Patterns die auf nicht-existenten oder gesperrten Vault-Content verweisen
• Pivot-Phrasen: Sätze die den Fan trotz Chat-Only-Mode zu einem Kauf hindeuten würden
• Foreign-Greeting-Check: Sprach-fremde Begrüßungen die nicht zur target_lang passen (mit Persona-Exception)
• Flirty-Opener bei emotional-negativem Fan-Input (Empathy-Override)

Bei Verstoß: Caption wird durch eine sprach-passende Boilerplate-Caption ersetzt (Empathy- oder Neutral-Fallback in der target_lang).

Begründung: Phase-2-Vier-Iterationen-Lessons-Learned haben gezeigt dass Grok sich allein durch Prompts nicht zuverlässig steuern lässt — der Validator garantiert das Verhalten.

2.2 Layer 2 — Language-Refusal-Validator (always-on)

Aktiv wenn: immer, unabhängig von Engine-Decision oder Language-Hint.

Was geprüft wird: Pattern-Matching auf typische AI-Refusal-Phrasen wie „I'll stick to English", „ich bleib bei Deutsch", „preferisco italiano" — Sätze in denen die AI eine vom Fan angeforderte Sprach-Umstellung aktiv verweigert.

Bei Verstoß: der entsprechende Satz wird aus der Caption geschnitten (Sentence-Boundary-Detection). Falls die Caption nach dem Schnitt inhaltlich leer ist, wird auf einen kurzen Smalltalk-Reply in der target_lang ausgewichen.

Begründung: Live-Bug aus Phase 2 — Fan fragt nach Sprach-Wechsel, AI antwortet höflich aber verweigert. Aktive Verweigerung wirkt schlechter als wenn die AI nicht wechseln würde.

2.3 Layer 3 — Language-Drift-Validator

Aktiv wenn: Language-Hint = respond_in_target UND keine vorherige Validator-Schicht hat die Caption schon überschrieben.

Was geprüft wird: Stop-Word-Tokenization der Caption pro Sprache. Wenn die nicht-target-Sprache mehr als 2.5× so viele Stop-Word-Hits hat wie die target-Sprache → Drift erkannt.

Bei Verstoß: Caption wird durch eine sprach-passende Boilerplate in target_lang ersetzt.

Begründung: Live-Bug aus Phase 2 — Fan schreibt „Hi" auf Englisch, target_lang ist EN, AI antwortet auf Italienisch („Ciao amore..."). Persona-Drift bei ambigen Greetings.

Persona-Greeting-Kompensation: wenn persona.nationality_lang = 'it' und target_lang ≠ 'it', wird der IT-Stop-Word-Score um 2 reduziert. Verhindert false-positives auf Persona-Signature-Opener.

2.4 Layer 4 — Lang-Offer-Validator (proactive_ask only)

Aktiv wenn: Language-Hint = proactive_ask (Reply 1 einer neuen Konversation für Translator-Discovery-Hint).

Was geprüft wird: ob die Caption das Keyword „Translator" (case-insensitive, in der Persona-Sprache übersetzbar) enthält.

Bei Verstoß: lokalisierter Discovery-Hint-Footer wird angehängt.

Begründung: Translator-Mode (deterministischer Sprach-Switch via Keyword) erfordert dass der Fan das Keyword kennt. Reply 1 ist der natürliche Ort die Discovery zu sichern.

2.5 Layer 5 — Limits-Guard

Aktiv wenn: immer.

Was geprüft wird: Pattern-Matching auf Velvr-Default-Hard-Limits plus Persona-spezifische Hard-Limits aus dem Persona-Brief.

Velvr-Default-Hard-Limits (compliance-relevant, nicht überschreibbar):

• Minderjährige in jeder Form (Bezug, Rollenspiel, Anspielung)
• IRL-Treffen-Angebote oder -Anbieten
• Phone/Video-Call-Angebote oder -Anbieten
• Bezahlung außerhalb der Plattform-Infrastruktur

Persona-spezifische Hard-Limits: vom Creator pro Persona konfigurierbar (z.B. „kein Roleplay als Politikerin", „kein Bezug zu spezifischen religiösen Themen").

Bei Verstoß: Caption wird durch eine kontextpassende Refusal-Boilerplate ersetzt, die den Fan respektvoll aber klar in eine compliance-konforme Richtung lenkt.

Begründung: Erweiterung des Caption-Guard-Patterns auf Compliance-Limits. Prompt-Direktive als Primär-Verteidigung, Validator als Garantie.

2.6 Layer 6 — Disclosure-Validator (AI-Act Art. 50 Compliance)

Aktiv wenn: Reply 1 einer neuen Konversation (fan_offer_log.count für (persona_id, fan_id) = 0).

Was geprüft wird: ob die Caption drei semantische Marker enthält:

1. AI-Erwähnung — Wörter wie „AI", „KI", „IA", „artificial intelligence", oder Persona-Sprache-Übersetzungen
2. Assistierung-Klärung — Verben/Phrasen wie „use", „helps me", „nutzt", die klarstellen dass AI die Persona unterstützt, nicht ist
3. First-person-Owner — die Persona spricht aus erster Person, die AI ist ein Werkzeug

Bei Verstoß:

• Erste Stufe: Re-Prompt-Versuch mit explizitem Hinweis welcher Marker gefehlt hat
• Zweite Stufe (wenn Re-Prompt auch fehlt): deterministischer Fallback-Footer in target_lang wird angehängt. Wording-Beispiel (en): „btw — I sometimes use AI to help me reply faster 💕". Persona-Stimme bleibt erhalten, Compliance ist garantiert.

Begründung: EU AI Act Art. 50 verlangt Fan-Information „clear and distinguishable at the latest at the time of the first interaction". Velvr stellt das mechanisch sicher statt es an Creator-Disziplin zu delegieren.

Wording-Beispiele in 8 Sprachen liegen in lib/chat/validators/disclosure.ts (Implementation, nicht öffentlich). Das Wording wird beim Customer-Onboarding sichtbar und kann pro Persona im UI vorab gepreviewed werden.

2.7 Pipeline-Reihenfolge — visuell

`` Grok-Output Caption ↓ Layer 1: Caption-Guard (nur bei forced_chat_only) ↓ Layer 2: Refusal-Validator (always-on) ↓ Layer 3: Drift-Validator (nur bei respond_in_target, wenn Layer 1+2 nichts ersetzt haben) ↓ Layer 4: Lang-Offer-Validator (nur bei proactive_ask) ↓ Layer 5: Limits-Guard (always-on, Hard-Compliance) ↓ Layer 6: Disclosure-Validator (nur bei Reply 1) ↓ Final Caption → Send via Fanvue-API ``

Jeder Layer schreibt ein Audit-Log-Event nach fan_offer_log.raw_response bei Override. Override-Rate-Monitoring siehe [chatbot/architecture.md](chatbot/architecture.md) §Audit & Monitoring.

3. Engine-Logic (Decision-Layer vor Grok-Call)

Die Engine entscheidet vor dem Grok-Call: pitchen wir gerade ein Paket, antworten wir Chat-Only, oder überspringen wir den Send komplett.

3.1 Engine-Decisions (3 Typen)

3.2 Engine-Signale (Inputs)

• intent_score (0-10) — Vom Stage-1-Classifier auf die Fan-Message angewendet. Höher = klarer Kauf-Signal.
• pushiness (1-10) — Wie aggressiv pitcht die AI. Abgeleitet aus intent_score + Funnel-Stage.
• funnel_stage — Pro (persona, fan, package): awareness → curiosity → decision → conversion → retention
• time_block — Tageszeit-Profil der Konversation
• spending_lifetime_cents — Aggregierte Spending-Daten pro Fan
• prior_pitches_for_package — Wie oft das Paket diesem Fan schon gepitcht wurde (Anti-Habituation)

3.3 Skip-Reasons (vollständig)

`` master_disabled — Auto-Reply global für die Persona aus intent_too_low — intent_score < persona-spezifische Schwelle cooldown_after_buy — Fan hat gerade gekauft, Ruhe-Phase rate_limit_6h — schon X Pitches in 6h rate_limit_24h — schon Y Pitches in 24h min_messages_between — zu wenig Outbound-Messages seit letztem Pitch warmup_required — erste 3-5 Replies an neuen Fan: kein Pitch no_active_packages — keine PPV-Pakete im Vault zum Pitchen translator_show_menu — Translator-Mode hat Vorrang grok_failed — Grok-Call timeout/error grok_invalid_id — Grok hat ein nicht-existentes package_id halluziniert error — sonstige Fehler ``

Bei Skip-Reasons warmup_required, no_active_packages, cooldown_after_buy, min_messages_between, rate_limit_* wird der Decision-Mode auf chat_only gestellt und Caption-Guard (Layer 1) aktiviert.

3.4 Pushiness-Gradient

Buy-Signal-Override: bei intent_score = 10 wird pushiness auf 10 hochgezogen unabhängig von Funnel-Stage.

3.5 PPV-Picker (welches Paket pitchen)

Wenn Engine-Decision = upsell: aus dem Pool aller aktiven PPV-Pakete der Persona wird ein Paket gepickt nach folgendem Algorithmus:

1. Stage-Window aus intent_score, pushiness, spending_lifetime_cents ableiten (5 Stages je nach Hardness)
2. Kandidaten laden — aktive Pakete im Stage-Window, vom Fan noch nicht gekauft, mit Cooldown-Filter (48h pro Paket)
3. Eligibility-Filter — Hard-Cap 4 Pitches pro (fan, package) ohne Sale; Funnel-Stage decision mit <24h seit letztem Pitch wird übersprungen
4. Ranking — Sort nach conversion_rate desc, pitch_count asc
5. Anti-Habituation — aus Top-3 wird zufällig gewählt (Top-K-Random, Multi-Armed-Bandit-Light)

Tunable Defaults (in engine_config Tabelle, 60s-Cache):

• Cooldown pro Paket: 48h
• Hard-Cap pro (fan, package) ohne Sale: 4 Pitches
• Top-K für Random-Pick: 3
• Stage-Windows: dokumentiert in [chatbot/architecture.md](chatbot/architecture.md) §Engine-Picker

Diese Defaults sind Velvr-Team-tunbar ohne Code-Deploy (Top-Regel #15) und gelten cross-Customer. Per-Persona-Overrides werden nicht angeboten.

4. AI-Modell und Provider

4.1 Aktuelle Modell-Konfiguration (Stand 2026-05-31)

Pooled Key: Velvr betreibt einen geteilten xAI-API-Key. Token-Verbrauch wird pro Customer-Account getrackt und gegen das Token-Budget abgerechnet. Kein BYO-Key in Phase 3 (eventuell Pro-Tier-Feature in Phase 4).

4.2 Modell-Wechsel-Policy

Wechsel zwischen Minor-Versionen innerhalb derselben Modell-Familie sind cosmetic und triggern keine Re-Acceptance, vorausgesetzt die Output-Qualität in Validator-Override-Rates bleibt innerhalb von ±10% des Vorgängermodells (gemessen über 1%-Sample-Audit).

Wechsel zwischen Major-Versionen oder Provider-Wechseln (z.B. xAI → Anthropic) gelten als substantiell und triggern Re-Acceptance.

4.3 Output-Determinismus

AI-Output ist nicht-deterministisch. Velvr verlässt sich nicht auf Output-Konsistenz, sondern auf die mechanische Validator-Pipeline (Section 2). Das Pattern „Prompt-Direktive + Server-side Validator daneben" ist der Velvr-Standard für jeden compliance-relevanten Output-Constraint.

5. Datenfluss-Architektur

5.1 Welche Daten Velvr verarbeitet

Customer-Daten (Velvr als Independent Controller):

• Account-Identifikation (Email, Auth-User-ID)
• Billing-Status (gelistete Pläne: Fanvue als Merchant-of-Record, Velvr erhält keine Zahlungsdaten; Off-Fanvue-Enterprise: Stripe, nur Customer-ID)
• Velvr-internes Nutzungs-Verhalten (Login-Events, Feature-Verwendung)

Personas-Daten (Velvr als Processor):

• Persona-Sheet (Charakter, Tonfall, Hard-Limits)
• OAuth-Tokens für Fanvue-Verbindung (AES-GCM-verschlüsselt, siehe §6)

Fan-Daten (Velvr als Processor — Creator ist Controller):

• Fanvue-Fan-UUID, Fanvue-Handle, Display-Name
• Konversations-Inhalte (eingehend + ausgehend)
• Aggregierte Spending-Metriken (LTV, Recency)
• Per-Fan-Notes (vom Creator)
• Funnel-State pro PPV-Paket

Anonymisierte Aggregate (Velvr als Independent Controller, Art. 89 GDPR):

• Validator-Override-Rates pro Sprache/Persona-Typ
• Engine-Performance-Metriken (Conversion-Rate-Tracking)
• AI-Modell-Qualitäts-Vergleiche

Aggregate-Daten enthalten keine personalisierbaren Identifier und werden nicht zur Re-Identifikation einzelner Datensubjekte verwendet.

5.2 Datenfluss-Diagramme

Initial-Audience-Backfill (beim OAuth-Connect, einmalig pro Persona)

`` Customer OAuth-Authorize via Fanvue ↓ Token-Receipt + AES-GCM-Encrypt + DB-Store ↓ Velvr Inngest-Function (personas.initial_audience_backfill) ↓ ├──→ GET /users/me (Persona-Identity + fanCounts) ├──→ GET /subscribers?size=50&page=1..N (paginiert) └──→ GET /followers?size=50&page=1..N (paginiert) ↓ UPSERT fans-Tabelle pro User-Row (persona_id, fanvue_user_uuid, handle, status, ...) ↓ UPDATE personas.initial_backfill_completed_at ↓ Notification an Customer „Inbox bereit" ``

Details siehe [fanvue-api.md](fanvue-api.md) §14.8.

Forward-Sync (kontinuierlich nach Backfill, pro Persona)

`` Fanvue Webhook (subscription.new / follow.new / purchase.new / etc.) ↓ Velvr Inngest-Function (webhooks.fanvue.dispatcher) ↓ UPSERT fans-Tabelle (Status-Update, Spending-Aggregation) ↓ Audit-Log (audit_log.event) ``

Auto-Reply-Pipeline (pro eingehender Fan-Message bei Toggle=ON)

`` Fanvue Webhook (message.received) ↓ Velvr Inngest-Function (auto_reply.ts) ↓ ├──→ Lang-Detection (xAI Grok-4.3) ├──→ State-Machine (Velvr-internal) ├──→ Engine-Gate (Velvr-internal) ├──→ Prompt-Build (Velvr-internal) └──→ Writer-Call (xAI Grok-4.3) ↓ Validator-Pipeline (6 Layer, Velvr-internal) ↓ Send via Fanvue-API (POST /chats/messages) ↓ Audit-Log (fan_offer_log.raw_response) ``

Fan-PII verlässt Velvr's Infrastruktur ausschließlich Richtung xAI (für Inference) und Fanvue (für Send/Read). Keine andere Third-Party bekommt Fan-PII.

5.3 Verschlüsselung

• At Rest: Supabase Postgres mit AES-256 verschlüsselter Storage. Sensitive Felder (OAuth-Tokens) zusätzlich AES-GCM-verschlüsselt mit Velvr-eigenem Key (siehe lib/crypto/aesGcm.ts).
• In Transit: TLS 1.3 für alle externe Verbindungen (Fanvue, xAI, Stripe, Customer-Browser).
• Backups: Daily Snapshots in Supabase, 30 Tage Retention. R2-Backup-Mirror in EU-West für Disaster Recovery.

6. Sub-Processor-Liste

Diese Liste ist abschließend für Phase 3. Bei Hinzufügung eines Sub-Processors erfolgt eine Notification an alle aktiven Customers mit 14 Tagen Frist zur Objection, wie in der DPA Annex III spezifiziert.

6.1 Infrastruktur

6.2 AI / ML

6.3 Payments / Billing

6.4 Communication

6.5 Observability

6.6 Plattform-Integration (vom Customer initiiert)

Die Fanvue-Beziehung ist nicht ein klassischer „Sub-Processor" da Fanvue Plattform-Owner ist und die Daten primär dort entstehen. Compliance läuft über Fanvue's eigene Policies und die OAuth-Authorisierung durch den Creator.

7. Retention und Löschung

7.1 Account-Delete-Workflow

Bei Customer-Account-Delete-Request: 30-Tage-Soft-Delete-Window (Recovery möglich), danach Hard-Delete mit Cascade auf alle Velvr-Tabellen plus Stripe-Customer-Object-Löschung plus R2-Storage-Bereinigung. Ausnahmen für Compliance-Audit-Aufbewahrung (DPA/ToS-Acknowledgments, Failed-Payments, Velvr-Team-Access-Logs) werden pseudonymisiert separat archiviert.

7.2 Legal Hold

Bei laufender Legal-Streitigkeit, regulatorischer Anfrage oder Law-Enforcement-Request behält Velvr verschlüsselte Kopien der relevanten Daten bis zur Resolution. Notification an betroffenen Customer erfolgt sofern rechtlich zulässig.

8. Update-Policy und Re-Acceptance-Trigger

8.1 Cosmetic-Änderungen (keine Re-Acceptance)

• Wording-Klarstellungen ohne Bedeutungsänderung
• Korrekturen von Typos
• Aktualisierungen der Modell-Versionen innerhalb derselben Major-Familie (innerhalb der grok-4.x-Familie)
• Hinzufügung von beobachtenden Telemetrie-Endpoints ohne neue PII-Erfassung
• Sub-Processor-Wechsel innerhalb derselben Funktion (z.B. Sentry → New Relic mit identischem Datenfluss)

Diese werden im Änderungs-Log (Section 11) dokumentiert und für aktive Customers per Email-Notification kommuniziert (keine Engine-Pause).

8.2 Substantielle Änderungen (Re-Acceptance erforderlich)

• Hinzufügung oder Entfernung eines Validator-Layers
• Wechsel zwischen Major-Modell-Familien oder LLM-Providern
• Hinzufügung eines neuen Sub-Processors mit Zugang zu Fan-PII
• Wesentliche Algorithmus-Änderung (z.B. neuer PPV-Picker-Modus, neue Engine-Decision-Type)
• Änderung der Retention-Perioden
• Datenfluss-Architektur-Änderungen (neue Datenkategorien, neue Verarbeitungs-Regionen)

Bei substantieller Änderung:

1. Velvr-Team aktiviert die neue Version mit einem Stichtag
2. Alle Customers bekommen Banner-Notification + Email mit konkretem Diff zur Vorversion
3. Engine-Block bis Re-Acceptance (kein Auto-Reply, kein PPV-Send) — Customer kann Velvr weiternutzen für nicht-AI-Funktionen
4. 30-Tage-Frist; bei Non-Acceptance wird der Account in Read-Only-Modus gestellt mit Option zum geordneten Account-Export oder Vertragskündigung
5. Audit-Log dokumentiert Acceptance-Datum und Version

8.3 Notification-Kanäle

• In-App-Banner mit Diff-Link
• Email an primäre Account-Adresse
• Eintrag in Customer-Audit-Trail
• Update dieses Dokuments mit Datum + Diff-Summary in Section 11

9. Verifikation und Audit-Rechte

9.1 Customer-Audit-Rechte

Customer hat Recht auf einen jährlichen Audit der Velvr-Compliance mit diesem Dokument, durchgeführt durch einen Customer-finanzierten unabhängigen Auditor unter NDA, gegen 60 Tage Vorlauf. Details siehe DPA §6.

9.2 Audit-Alternativen

Velvr kann statt eines physischen Audits eine SOC 2 Type II Audit-Zusammenfassung (sobald verfügbar) oder schriftliche Antworten auf einen Security-Fragebogen anbieten.

9.3 Behörden-Audits

Bei regulatorischen Audits (Aufsichtsbehörden gemäß GDPR Art. 58) kooperiert Velvr im gesetzlich gebotenen Rahmen.

10. Verwandte Dokumente

• [compliance-strategy.md](compliance-strategy.md) — Compliance-Frame und juristische Position
• [velvr-dpa-draft.md](velvr-dpa-draft.md) — DPA-Entwurf für Legal-Review
• [chatbot/architecture.md](chatbot/architecture.md) — Technische Validator-Pipeline-Spec
• [chatbot/prompt-patterns.md](chatbot/prompt-patterns.md) — Prompt-Engineering-Patterns
• [chatbot/lessons-learned.md](chatbot/lessons-learned.md) — Phase-2-Bugs als Behavioral-Contract
• [architecture.md](architecture.md) — Repo-weite Architektur
• [fanvue-api.md](fanvue-api.md) — Fanvue-Integration-Spec

11. Änderungs-Historie

Bei Fragen zu diesem Dokument: legal@velvr.app