Moonborn — Developers

Generation-Pipeline

Die sechsstufige Pipeline, die einen `intent` in eine vierschichtige Persona verwandelt — Intent parse → Soul draft → Self+Mask enrich → Surface ground → Audit → Fingerprint + Test.

Wenn du POST /v1/personas mit einem intent aufrufst, fragt Moonborn nicht ein einzelnes LLM, einen Charakter zu erfinden. Es führt eine sechsstufige Pipeline aus, deren Ausgabe der persistente Zustand der Persona ist. Jeder Schritt ist konfigurierbar — Modell, Provider, Temperatur, Fallback-Kette — über den Config-Baum unter engine.pipeline.<step>.*.

Die Schritte

#	Schritt	Zweck	Standard-Modell
1	`intent_parse`	Brief lesen; Genre, Locale, Achsen-Hinweise extrahieren	`claude-sonnet-4-6`
2	`soul_draft`	Soul schreiben (desire, fear, wound, growth arc)	`claude-opus-4-7`
3	`self_enrich`	Big Five + Archetyp + Werte + Bindung	`claude-sonnet-4-6`
4	`mask_build`	Stimme, Ton, Signature-Phrasen, soziale Rolle	`claude-sonnet-4-6`
5	`surface_ground`	Name, Alter, Ort, Beruf, Erscheinung	`claude-sonnet-4-6`
6	`audit`	Schicht-übergreifende Kohärenz + LLM-as-judge	`claude-opus-4-7`

Hinweis — diese Standards werden aus engine.pipeline.<step>.model Config-Items gelesen. Die obigen Werte sind System-Scope-Standards; Org/Workspace-Overrides gelten.

Nach den sechs sichtbaren Schritten startet die Runtime zwei Post-Generation-Jobs:

Voice Fingerprint — fünfzig kurze Szenario-Completions, in eine Per-Persona-Signatur eingebettet (Voice Fingerprint).
Test Suite — der konfigurierbare Provokationskatalog läuft gegen die neue Persona (Audit + Provokationstests).

Warum von innen nach außen

Surface (Name, Alter, Beruf) ist der letzte Schritt — mit Absicht. Schrieben wir Surface zuerst, würde das Modell sich am demographischen Klischee verankern und Soul rückwärts auffüllen, um zu passen. Mit der Reihenfolge Soul → Self → Mask → Surface beschränkt jede Schicht die nächste: die Ruhelosigkeit der Gründerin kommt aus ihrer Wunde, nicht aus einer Standardvorlage.

Streaming

Übergib stream: true an POST /v1/personas und die Antwort wird text/event-stream. Jedes Event ist eines von:

event: step.started      { step: "soul_draft" }
event: step.completed    { step: "soul_draft", durationMs: 4210 }
event: step.failed       { step: "audit", error: { code, message } }
event: pipeline.completed { id, status, pipelineRunId }

Die in der finalen Event-ID zurückgegebene Pipeline-Run-ID erlaubt es dir, die volle Spur (Provider-Latenzen, Retries, Kosten-Aufschlüsselung) später abzurufen — siehe Audit-Log-Endpoints in der API-Referenz.

Retries + Fallback

Wenn ein Schritt fehlschlägt (LLM-Provider-Fehler, Audit unter Schwellwert), wiederholt Moonborn bis zu engine.pipeline.<step>.max_retries (Standard 3) mit der konfigurierten Fallback-Kette (Standard: Anthropic → OpenAI → Google). Nach dem Limit wird die Persona im flagged-Status ausgeliefert — der Nutzer sieht sie, sie ist aber für Review markiert.

Ehrlicher Scope

Das ist die Server-Side-Pipeline. Es gibt keine Client-Side-Step-Implementierung; du kannst keinen isolierten Schritt vom SDK aus laufen lassen. Die Client-Oberfläche ist POST /v1/personas (volle Pipeline) und POST /v1/personas/{id}/regenerate (Neulauf ab gewähltem Schritt).