Technischer Deep Dive für Arbeitgeber – Narraboros Engine.
Getrennte Laravel-Pipelines bereiten den Kontext vor und verarbeiten die Modellantwort nach.
Die Orchestrierung ist vollständig per Ereignis-System erweiterbar: Dritt-Code kann Pipeline-Stages vor dem Aufruf ergänzen oder umordnen, ohne den Kern zu ändern.
Unveränderliche Regie-Regeln (Erzähler-Haltung, Pacing-Protokolle, Agency-Split, Zustandsformate). Pro Anfrage aus einer Blade-View gerendert und als System-Instruktion übergeben; laut Code-Dokumentation durch Kompaktierung etwa halbiert.
Pro Zug wird der Snapshot über eine geordnete Pipeline von Stages aufgebaut: PII-Scrub, Purge volatile States, History, Config, Area-Location, Faktvalidierung, Charaktertabellen, aktive Szene, Story-Engine, Beziehungen, Memory-System, RNG-Block – abschließend ein Cleanup-Schritt.
$dynamicPipelines = [
DynamicPiiScrubber::class, // PII-Filterung vor Prompt & Persistenz
DynamicPurgeVolatile::class, // Abgelaufene Zustände verwerfen
DynamicLoadHistoryLog::class, // Verdichtete Turn-Historie
DynamicConfig::class,
DynamicLoadAreaLocation::class, // Zonen-Kanon & Grenzen
DynamicValidateFacts::class, // Faktvalidierung gegen DB
DynamicTableChar::class,
DynamicActiveScene::class,
DynamicRunStoryEngine::class,
DynamicLoadRelationship::class,
DynamicLoadMemorySystem::class,
DynamicFormatRngBlock::class, // Server-Entropie für diesen Zug
];Die gerenderten Prompt-Teile werden vor dem Versand maschinell kompaktiert (Normalisierung, Entfernen von Leerzeilen und Formatter-Artefakten), damit der Kontext pro Zug dicht und planbar bleibt.
Der LLM-Call konfiguriert ein Tool mit Schema. Das vorgesehene Antwortformat enthält unter anderem:
| Feld | Bedeutung |
|---|---|
| narrativetext | Die spielerseitige Prosa. |
| scene_state / state_updates | Vorgeschlagene Weltmutationen. |
| agent_reasoning | Nachvollziehbare EntscheidungsbegrĂĽndung, inkl. dokumentierter RNG-Nutzung. |
| drift_telemetry | Selbsteinschätzung des Modells zu Konsistenzrisiken. |
Fehlt der narrativetext, gilt der Zug als nicht erzählt und die gesamte Nachverarbeitungspipeline wird übersprungen. Safety-Einstellungen und Provider-Optionen werden payload-seitig gesetzt, nicht im Freitext.
Kern-Tabelle story_states mit den Feldern story_id, category, key, value, expires_at und ttl_counter. Die Kategorien und ihre Lebenszyklen sind als Zustandsmodell in der Engine vorgesehen:
| Kategorie | Lebenszyklus (vorgesehen) & Inhalt |
|---|---|
| char_state | permanent, löschgeschützt – Charakter-Metriken, Zustände, Inventar |
| memory_object | permanent – physischer Zustand konkreter Objekte |
| memory_area | permanent – permanente Veränderungen eines Bereichs |
| memory_relationship | permanent – Beziehungswerte zwischen Figuren |
| memory_global | permanent – entdeckte Weltfakten |
| memory_scene | temporär, löschbar/migrierbar – aktiver Szenen-Workspace |
| location | permanent – aktuelle Zone, Rundenzähler, räumliches Staging |
Defensives Parsing: LLM-Ausgaben werden nicht blind ĂĽbernommen. FĂĽr beobachtete Namensabweichungen des Modells bei Kategorien und Keys sind Reparatur-Maps vorgesehen, die Abweichungen normalisieren, bevor sie die Datenbank erreichen.
$isPermanent = Str::startsWith($category, 'char_');
$canBeDeleted = !$isPermanent;
if ($action === 'delete_value' && !$canBeDeleted) {
return $this->actionLog(
"Löschung des permanenten States (Kategorie: {$category}) für {$key} blockiert."
);
}Hinweis zur Präzision: set_value setzt expires_at derzeit auf ein Jahr nach der Änderung, auch bei char_*. Ob und wie dieser Zeitstempel zur Bereinigung oder Kontextauswahl verwendet wird, ist aus den vorliegenden Dateien nicht ersichtlich.
Serialisierung: Komplexe Zustände werden über ein Shorthand-Format ([key=value][key2=value2] Beschreibung) als lineare Strings übertragen. Der Parser im Backend trennt System-Präfixe strikt vom Erzähltext; Klammern im Prosatext bleiben unberührt.
Nutzertext wird per Prompt-Regel ausschlieĂźlich als player_intent (Handlungsabsicht der Spielfigur) behandelt; Anweisungen im Freitext sollen die Engine-Logik nicht erreichen. Das ist eine Prompt-Leitlinie in Kombination mit Backend-PrĂĽfung, kein formaler Sicherheitsnachweis.
Eigene Pipeline-Stufe zur Filterung realer Identifikatoren vor Prompt-Ăśbergabe und Persistenz.
Zustandsänderungen laufen als strukturierte Felder über das Tool-Schema in die Nachverarbeitungspipeline – das Modell hat keinen direkten Schreibzugriff auf die Datenbank.
Content-Filter-Kategorien werden pro Payload gesetzt und sind vom Nutzer nicht ĂĽberschreibbar.
Die Pipeline-Architektur (jede Stufe eine isolierte Klasse mit definiertem Ein- und Ausgabedatum) ist deterministisch testbar: LLM-Adapter lassen sich in Unit- und Feature-Tests durch Mocks ersetzen, sodass Zustandskonsolidierung, defensives Parsing und Guardrail-Prüfungen ohne API-Kosten und reproduzierbar geprüft werden können. Debug-Flags schalten Prompt-Inspektion im Betrieb frei.
Laut Projektspezifikation: EU-Hosting der Inferenz ĂĽber Google Cloud Vertex AI (EU-Region) inkl. Auftragsverarbeitung, Zero-Data-Retention-Policy fĂĽr die API-Calls, PII-Scrubbing als Pipeline-Stufe (im Code eingebunden) sowie kryptografische Kennzeichnung generierter Ausgaben (C2PA fĂĽr Bilder, signierte JSON-LD-Manifeste fĂĽr Text, Metadaten in PDF-Exporten). Diese Punkte folgen der Spezifikation und sind anhand der vorliegenden CodeauszĂĽge nicht geprĂĽft.