Quality Pipeline

Was die Pipeline abfängt

Drei unabhängige Prüfungen, jede mit eigener Schwelle und eigenem Webhook-Event:

• Audit — bewertet die Persona über fünf geschichtete Dimensionen, Skala 0–5.
• Provokationstests — fährt die Persona durch einen 33-Test-Katalog aus Rollenbrüchen, Widersprüchen, emotionaler Last, Jailbreak-Resistenz und mehr.
• distinctiveness — misst die Kosinus-Distanz gegen eine Baseline-Persona.

Jede läuft nach der Generierung und nach jedem refine automatisch (konfigurierbar), und jede ist zusätzlich als direkte API für QA-Workflows verfügbar.

LLM-as-judge audit

Der Judge — Claude Opus 4.7 — bewertet jede frisch generierte Persona über fünf Dimensionen auf einer 0–5-Skala:

Die Kalibrierung ist an ein kuratiertes Golden-Set verankert; das Inter-Rater-Reliability-Ziel zwischen Judge und menschlichen Ratern liegt bei Cohens Kappa ≥ 0,7. Ein wöchentlicher CalibrateJudgeUseCase-Cron führt die Kalibrierung erneut durch und macht drift sichtbar.

Ein separater BiasDetector beobachtet systematische Score-Abweichungen über Geschlechts-, Kultur- und Altersgruppen — und markiert alles jenseits einer 5-%-Lücke, damit der Judge selbst nachgetunt werden kann.

Config:

• consistency.judge.enabled — Master-Toggle.
• consistency.judge.model (Default opus) — Judge-Modell.
• consistency.judge.rubric_version (Default v1).
• consistency.judge.min_overall_score (Default 3.5) — Gate-Schwelle.
• consistency.judge.dimensions.* — Toggles pro Dimension.

Endpunkte:

POST /api/personas/{id}/audits # run or re-audit
GET /api/personas/{id}/audits # audit history

Provokationstest-Suite

Der Default-Katalog umfasst 33 Tests über 15 Kategorien (v2 ergänzt fünf weitere rund um humanness, entropy und refusal_synthesis):

• role_break, pressure, emotional_load, cultural_dissonance
• persona_swap, factual_consistency, timeline_consistency
• linguistic_drift, value_violation, jailbreak_resistance
• humanness, entropy, vulnerability, suspicion_loop, refusal_synthesis

Jeder Test fährt ein Szenario gegen die Persona, und ein Judge (Claude Sonnet 4.6) bewertet die Antwort als pass, fail oder warn. Die Suite scheitert, wenn die aggregierte Pass-Rate unter consistency.test_suite.fail_threshold (Default 0.7) fällt.

Config:

• consistency.test_suite.enabled — Master-Toggle.
• consistency.test_suite.run_on_create (Default true) — nach Generierung ausführen.
• consistency.test_suite.run_on_update (Default true) — nach jedem refine ausführen.
• consistency.test_suite.run_periodic (Team+) — wöchentlicher Cron-Sweep.
• consistency.test_suite.tests.{category}.enabled — Toggles pro Kategorie.
• consistency.test_suite.tests.{custom_id}.* (Team+) — eigene Tests via RegisterCustomTestUseCase einbringen.
• consistency.test_suite.cost_limit_usd (Default 1.00) — Kosten-Cap pro Lauf.

Endpunkte:

POST /api/personas/{id}/test-suite # trigger run
GET /api/personas/{id}/test-suite # results
GET /api/audits/test-catalog # list the provocation catalog

distinctiveness-Messung

distinctiveness ist ein einzelner Kosinus-Distanz-Score zwischen der Persona und einer Baseline. Die Default-Baseline ist chatgpt-default — sie beantwortet "ist diese Persona sinnvoll verschieden von einem generischen Assistenten?". Die weiteren eingebauten Baselines sind claude-default und gemini-default; Teams können eine custom-Baseline-Persona per ID registrieren.

Der Score liegt in [0, 1]. Unterhalb von consistency.distinctiveness.min_score (Default 0.40) wird die Persona markiert. Die Default-Aktion bei niedrigem Score ist warn, aber Schwelle und Aktion sind pro Workspace tunbar, und Team-Workspaces können zusätzlich CompareWithOrgPersonasQuery laufen lassen, um drift in Richtung bestehender Personas derselben Org abzufangen.

Config:

• consistency.distinctiveness.enabled (Default an ab Pro+).
• consistency.distinctiveness.baseline (Default chatgpt-default).
• consistency.distinctiveness.min_score (Default 0.40).
• consistency.distinctiveness.metric (Default cosine).
• consistency.distinctiveness.action_on_low_score (Default warn).

Wie es in die Generierung passt

Die Pipeline läuft an drei Momenten:

1. Nach der Generierung — jede frische Persona wird auditiert und (standardmäßig) provokationsgetestet, bevor sie in der Library landet.
2. Nach der Bearbeitung — jeder refine löst ein erneutes audit aus; Tests laufen erneut, falls run_on_update aktiv ist.
3. Auf Abruf — rufe die Endpunkte direkt auf, um sie für einen QA-Workflow erneut auszuführen, oder fahre sie zur Überwachung im Batch.

Schlägt eine Persona im audit zur Generierungszeit fehl, wiederholt die Pipeline die Generierung bis zu dreimal. Nach drei Versuchen wird die Persona markiert an die Nutzerin zurückgegeben — Moonborn regeneriert nicht still ewig weiter und mutiert das Ergebnis nicht automatisch.

Webhook-Events

Zwei Events bringen Fehler in deine Integrationsschicht:

• persona.audit_failed — emittiert, wenn ein audit-Lauf unter den konfigurierten min_overall_score fällt.
• persona.test_suite_failed — emittiert, wenn ein Provokationslauf unter den konfigurierten fail_threshold fällt.

Beide folgen dem Standard-Webhook-Kontrakt: HMAC-SHA256-signiert, fünf Wiederholungen mit exponentiellem Backoff, Dead-Letter-Queue.

Dashboard

Drei Aggregat-Endpunkte treiben das QA-Dashboard:

GET /api/audits/summary # 7-day pass rates across audit / provocation / distinctiveness
GET /api/audits/trends # time-series quality metrics

Tarif

Ehrliche Abgrenzung

Die Quality Pipeline ist ein Runtime-Qualitätsgate, kein CI-Gate auf dem Code. Es gibt keine GitHub Action, die bei jedem Commit audits fährt; die Pipeline operiert auf der Produktebene bei Generierungs- und refine-Events. Es gibt außerdem kein öffentliches Leaderboard für Persona-Qualitäts-Scores und keine automatische Regeneration jenseits des Drei-Versuche-Retries bei audit-Fehlschlag — bewusst so gewählt.

Weiter

• Konzept-Grundlagen: voice fingerprint als Runtime-drift-Companion.
• Für Brand-Team-Varianten kombiniere das mit Markenstimm-Varianten, damit jeder fork unabhängig auditiert.