Un examen forensique du système narratif en production · ce qu'il prouve qui fonctionne à l'échelle, là où l'architecture crée les plafonds qu'il nous faut maintenant crever, et ce que huit lacunes structurelles nous enseignent sur le moteur qu'il nous reste à construire.
Chaque autre document de cette série de recherches s'appuie sur des sources externes : modules de jeu de rôle publiés, théorie académique des beats, recherche en narration IA, pédagogie de l'improvisation. Celui-ci est différent. EV2090 est un système en production. Il fonctionne en continu. Il génère des arcs narratifs toutes les cinq heures et demie. Il exécute des beats en temps réel, gère des conversations de PNJ en direct, traite des signaux économiques et persiste l'état du monde d'une session à l'autre. Ce n'est pas un prototype.
Cette distinction compte énormément. La recherche théorique nous dit ce qui devrait fonctionner. Le code en production nous dit ce qui fonctionne réellement · et, tout aussi important, quel est le coût de chaque décision architecturale une fois que le système a tourné suffisamment longtemps pour révéler ses propres limites. Une conception qui paraît élégante sur un tableau blanc développe souvent des points de friction qui n'émergent que sous charge, sous pression temporelle, ou quand le domaine du problème s'avère légèrement plus grand que ce que le périmètre original supposait.
Le moteur narratif d'EV2090 a été construit pour résoudre un problème précis pour un jeu précis. Il n'a pas été conçu comme une plateforme narrative généraliste. Lire son code n'est donc pas principalement un exercice de critique · c'est un exercice d'archéologie. Nous lisons les traces de vraies décisions prises sous de vraies contraintes, et nous en extrayons à la fois les patterns qui se sont prouvés et les limitations qui définissent désormais le périmètre de ce que nous devons construire différemment.
Les fichiers centraux sont narrative-engine.ts (le Durable Object gérant le cycle de vie des arcs et l'exécution des beats), narrative/prompts.ts (tous les prompts LLM), narrative/types.ts (le système de types), narrative/validation.ts (la validation des outputs), bounty-generator.ts (le pipeline de missions séparé) et bounty-npc-chat.ts (le système de chat de personnages interactifs). L'architecture se lit comme un système construit par couches, où chaque couche a résolu le problème le plus urgent devant elle au moment de sa construction.
La décision structurelle la plus importante du moteur narratif d'EV2090 est le pipeline multi-phases. Plutôt que de générer un arc complet en un seul appel, le système décompose la génération narrative en cinq opérations cognitives distinctes, chacune avec sa propre configuration de modèle, son budget de tokens et sa température. Ce n'est pas une optimisation de performance. C'est une architecture de qualité.
L'intuition qui la sous-tend est que différentes étapes de la construction narrative requièrent des modes cognitifs fondamentalement différents. Générer une idée d'histoire à partir de rien (haute température, non contraint, créatif) est une tâche complètement différente de l'audit de cette idée pour la continuité par rapport aux arcs précédents (température plus basse, analytique, comparatif). Mélanger ces deux modes dans un seul prompt produit des outputs qui ne sont ni particulièrement créatifs ni particulièrement rigoureux · le modèle fait la moyenne entre les deux pressions et ne satisfait aucune des deux. Les séparer laisse chaque phase faire exactement une chose bien.
Les cinq phases : Concept (Sonnet, temp 0,85, 2000 tokens) → Audit (Sonnet, temp 0,7, 2500 tokens) → Chorégraphie + Audit temporel (Sonnet, temp 0,8, 5000 tokens) → Rédacteurs par beat (Haiku × N, temp 0,8, 400 à 800 tokens par beat). Chaque phase a un rôle cognitif distinct, reçoit seulement le contexte dont elle a besoin, et produit un output validé qui conditionne la phase suivante.
La phase Concept à température 0,85 est l'imagination créative du moteur. Elle reçoit le contexte le plus riche · un instantané de l'économie, l'historique des arcs, des notes sur l'état du monde, des signaux de cadence temporelle et le registre des personnages récurrents · et à partir de cela produit une idée d'histoire brute : titre, thème, prémisse, personnages (trois ou quatre, avec nom, rôle, faction, lieu, voix et motivation), planètes et marchandises affectées, et une déclaration de changement du monde. La haute température est délibérée. C'est là que vit la nouveauté. La contraindre trop fortement produit de la répétition ; la relâcher trop produit de l'incohérence. 0,85 est une valeur calibrée, pas arbitraire.
La phase Audit à température 0,7 est la conscience de continuité du moteur. Elle reçoit l'output du concept aux côtés de l'historique complet des arcs et effectue une révision structurée : ce thème répète-t-il quelque chose récemment résolu ? Les références économiques sont-elles ancrées dans l'état réel du jeu ? Les enjeux des personnages sont-ils suffisamment spécifiques pour compter ? La température légèrement plus basse reflète la nature analytique de la tâche · le modèle n'invente pas, il évalue. Cette phase fonctionne comme une porte de qualité intégrée qui attrape le mode d'échec le plus courant dans la génération narrative LLM : la répétition thématique qui érode le sens des conséquences du monde.
La phase de Chorégraphie à température 0,8 et 5000 tokens est là où l'arc devient concret. Elle conçoit dix à quatorze beats distribués sur 330 minutes, assigne à chaque beat un canal de livraison, établit des liens de causalité entre les beats (chaque beat doit déclarer ce à quoi il réagit et ce qu'il préfigure), et spécifie les exigences d'injection de données · quels champs économiques le rédacteur du beat aura besoin au moment du rendu. L'Audit Temporel combiné dans cette phase vérifie que la séquence de beats a du sens comme chronologie : que les causes précèdent les effets, que le rythme varie de manière appropriée, que l'arc a un vrai début, milieu et fin plutôt qu'une séquence plate d'événements.
Les Rédacteurs par Beat sont Haiku au moment de l'exécution. Non pas au moment de la génération · au moment de l'exécution. L'arc est chorégraphié à l'avance, mais le contenu du beat est rendu quand le beat se déclenche. Cela signifie que chaque appel Haiku reçoit des données en direct : valeurs économiques actuelles, état du monde actuel, les beats qui se sont déjà déclenchés, et la spécification de rendu complète du beat. Le résultat est un contenu cohérent narrativement avec la conception de l'arc mais ancré économiquement dans le moment présent.
Le choix d'infrastructure qui sous-tend tout ceci est celui des Cloudflare Durable Objects avec une planification basée sur des alarmes. Le Durable Object NarrativeEngine est une instance unique globalement unique avec son propre stockage persistant basé sur SQLite. Il se réveille lui-même sur une alarme de cinq minutes pour vérifier si un beat doit se déclencher, faire avancer la chronologie de l'arc, ou générer un nouvel arc quand le courant expire. Le système d'alarmes garantit une exécution au moins une fois avec un retry à backoff exponentiel · ce qui signifie qu'un beat qui échoue à se rendre ne disparaît pas silencieusement de la chronologie, il réessaie automatiquement jusqu'à réussir ou épuiser ses tentatives.
L'intervalle de cinq minutes est un choix de conception réfléchi. Il est suffisamment court pour maintenir la dynamique narrative · un joueur qui vérifie régulièrement verra le monde bouger · mais suffisamment long pour absorber la latence d'un appel LLM sans créer de pression à sauter des phases. Cela signifie aussi que le système peut gérer les fenêtres de beat avec grâce : si un beat était planifié pour la minute 47 et que l'alarme se déclenche à la minute 50, le beat est quand même déclenché plutôt que raté. La durée d'arc de 5h30 (330 minutes) sur 10 à 14 beats produit un espacement moyen de beat d'environ 25 à 33 minutes, ce qui correspond au rythme que les MJ humains adoptent naturellement lors de sessions en direct.
La couche de rendu d'EV2090 utilise trois canaux de livraison distincts, chacun instancié comme un rédacteur séparé : le Rédacteur Feed (diffusions de station, 150 à 400 caractères, voix institutionnelle), le Rédacteur Chat (COMMS radio de PNJ, 3 à 6 lignes, voix personnelle en personnage), et le Rédacteur Board (notices de tableau en liège, 60 à 180 caractères, toucher écrit à la main). Ce ne sont pas des variations stylistiques du même prompt. Ce sont de véritables instances de rédacteur séparées avec des prompts système séparés, des listes d'anti-patterns séparées et des critères de succès séparés.
La différence de qualité que cela produit n'est pas subtile. Un rédacteur généraliste unique auquel on donne des instructions de canal comme paramètre produit un contenu qui fait la moyenne des styles · légèrement trop formel pour le chat, légèrement trop personnel pour la diffusion. La charge cognitive de maintenir un style tout en évitant un autre crée une sorte d'interférence de prompt. Des instances séparées éliminent totalement cette interférence. Le Rédacteur Feed ne sait pas que le Rédacteur Chat existe. Il sait seulement à quoi ressemble une diffusion de station et à quoi elle ne doit jamais ressembler.
150 à 400 caractères. Institutionnel, impersonnel, déclaratif. La voix des systèmes et de l'infrastructure · pas des personnes. Anti-patterns : pas de première personne, pas de registre émotionnel, pas de spéculation. Succès : se lit comme une communication officielle d'une autorité qui ne se soucie pas de vos sentiments.
3 à 6 lignes. Personnel, en personnage, présent émotionnellement. La voix d'un être humain spécifique dans une situation spécifique. Anti-patterns : pas d'omniscience, pas d'exposition nette, pas d'information que le PNJ n'aurait pas réellement. Succès : on a l'impression d'avoir surpris une vraie transmission.
60 à 180 caractères. Bref, pratique, écrit à la main sous une certaine pression. Anti-patterns : pas de phrases complètes avec sujets et verbes, pas de grammaire formelle, pas de cadrage de narrateur. Succès : se lit comme si quelqu'un avait épinglé ça et était reparti.
L'intégration ElevenLabs v3 impose une discipline qui améliore tous les canaux : phrases courtes, pas de mise en forme visuelle, balises d'émotion si nécessaire. La contrainte d'écrire pour les oreilles plutôt que pour les yeux produit une prose plus serrée et plus active. Une règle de design adoptée pour la qualité audio finit par bénéficier à la qualité textuelle comme effet secondaire.
Le pipeline de génération en 4 passes du système de missions étend cette logique à l'audio. Après que la narrative centrale de mission est générée par Sonnet (température 0,9, 4096 tokens · plus de créativité pour les scénarios de mission), une passe Haiku génère des entrées Feed atmosphériques pour le monde du jeu, puis ElevenLabs synthétise des fichiers audio de briefing et de conclusion stockés dans R2 aux côtés des données de mission structurées. Le pipeline traite l'audio comme un canal de livraison de premier ordre, pas comme une étape de post-traitement. La contrainte d'écriture consciente du TTS · phrases courtes, pas de clauses imbriquées, balises d'émotion intégrées dans le texte · est appliquée au moment de la génération, pas éditée après coup.
C'est une leçon architecturale significative. Quand une contrainte de rendu est appliquée au point de génération plutôt qu'au point de livraison, elle améliore le contenu sous-jacent plutôt que de patcher sa présentation. Écrire pour le système de balises d'émotion d'ElevenLabs v3 produit une prose naturellement plus rythmique et expressive, parce que cela force le rédacteur (en l'occurrence, le modèle) à être explicite sur le registre émotionnel plutôt que de s'appuyer sur le lecteur pour l'inférer.
La conception des prompts d'EV2090 reflète un ensemble de principes durement acquis qui ne sont pas immédiatement évidents à partir des premiers principes. Ils ont émergé en faisant tourner le système, en observant les modes d'échec et en les corrigeant. Chaque principe traite une classe spécifique de dégradation de l'output. Ils méritent d'être examinés individuellement.
La règle la plus contre-intuitive du système. Les exemples sont pédagogiquement efficaces pour les apprenants humains. Dans les prompts LLM, ils fonctionnent différemment : ils deviennent simultanément le plancher et le plafond. Le modèle s'ancre sur l'exemple fourni et produit des variations de celui-ci plutôt que de générer librement à l'intérieur des contraintes définies. Le résultat est une sorte de monoculture narrative · des outputs techniquement acceptables mais structurellement identiques. Supprimer les exemples et les remplacer par des contraintes (ce qui doit être présent) et des anti-patterns (ce qui ne doit jamais apparaître) produit des outputs avec une variance plus élevée, ce qui dans un système de génération d'histoires revient à dire une qualité plus élevée.
Chaque prompt de rédacteur dans EV2090 contient une section « NE JAMAIS faire ceci ». La liste est spécifique et dérivée empiriquement : pas « évitez les clichés » mais « ne commencez jamais une diffusion de station par le nom d'une personne. » Pas « écrivez naturellement » mais « n'utilisez jamais le mot 'soudainement' dans une notice de tableau ». Cette spécificité compte. Une orientation négative vague (« évitez d'être trop formel ») donne peu de contrainte actionnable au modèle. Des anti-patterns spécifiques (« ne commencez jamais une ligne COMMS par un personnage qui explique sa situation actuelle à quelqu'un qui le saurait déjà ») ferment des brèches précises. La liste d'anti-patterns est un artefact diagnostique · chaque entrée représente un mode d'échec observé en production et corrigé.
Aucun prompt dans le système n'est statique. Chaque appel assemble son prompt système au moment de la génération à partir de l'état du monde actuel, des données économiques actuelles, de l'historique des arcs et du registre d'entités pertinent. Cela signifie que le modèle n'opère jamais sur un contexte obsolète. Cela signifie aussi que les prompts eux-mêmes sont des fonctions · leur output est une propriété de leur état d'entrée, pas un artefact fixe. C'est architecturalement solide pour un système qui tourne longtemps et où le monde change continuellement. Les prompts système codés en dur qui font référence à des faits de jeu spécifiques deviennent incorrects à mesure que le monde évolue ; l'injection dynamique garantit que le contexte du modèle sur « ce qui est vrai maintenant » est toujours exact.
Chaque beat dans la chorégraphie doit déclarer à la fois une valeur reactsTo (l'ID de beat ou l'événement auquel il répond) et une valeur foreshadows (le beat ou la conséquence qu'il met en place). Ce n'est pas appliqué par un validateur · c'est appliqué par la structure du prompt elle-même, qui traite ces champs comme obligatoires plutôt qu'optionnels. L'effet pratique est que le modèle est forcé de penser de manière relationnelle plutôt que séquentielle. Il ne peut pas générer un beat qui existe de manière isolée. Chaque unité narrative doit être tissée dans le tissu causal de l'arc. Le résultat est des arcs qui se sentent comme des histoires plutôt que des journaux d'événements.
Pendant la chorégraphie, le modèle Sonnet ne génère pas de contenu économique · il spécifie quels champs économiques chaque beat aura besoin quand il se déclenche. Le rédacteur du beat (Haiku) reçoit ensuite ces valeurs réelles en direct au moment de l'exécution. Cette séparation signifie que la structure narrative (planifiée bien en avance) et l'ancrage économique (nécessairement actuel) ne s'opposent jamais. Un beat sur une envolée du prix d'une marchandise est conçu comme un moment narratif pendant la génération de l'arc, mais les prix spécifiques dans le contenu rendu reflètent ce que le marché dit réellement quand le beat se déclenche, pas ce que le marché disait 5 heures plus tôt quand l'arc était planifié.
Le composant le plus sophistiqué du système narratif d'EV2090 est aussi le moins visible : le gestionnaire de chat d'informateurs PNJ dans bounty-npc-chat.ts. Il est suffisamment sophistiqué pour que son architecture mérite d'être examinée en détail, parce qu'il résout un problème que le système dans son ensemble ne résout pas · le problème de la cohérence durable d'un personnage à travers un dialogue multi-tours avec un joueur en direct.
Le système utilise Haiku à température 0,8 avec un maximum de 120 tokens par réponse. La limite de tokens est délibérée : elle empêche les PNJ de devenir exposifs, force les réponses à rester conversationnelles et en personnage, et maintient les coûts par échange suffisamment bas pour qu'un joueur puisse avoir un dialogue d'investigation complet sans que le modèle de coût devienne prohibitif. La limitation de débit à 10 requêtes par minute et un plafond de 40 échanges par session prévient les abus tout en donnant aux vrais enquêteurs suffisamment de latitude.
L'architecture mémoire est une fenêtre glissante de 8 échanges stockée dans R2. C'est un choix pragmatique qui résout un vrai problème : la fenêtre de contexte nécessaire pour contenir un historique de conversation complet grandit sans limite, mais les 8 derniers échanges contiennent pratiquement toutes les informations dont un PNJ a besoin pour maintenir la cohérence conversationnelle. Les échanges antérieurs sont compressés dans la fiche de personnalité du PNJ et le registre de faits plutôt que retenus verbatim. La fenêtre glissante est la différence entre un système où les PNJ se souviennent de ce que vous venez de dire et un système où ils se souviennent de tout, ce qui est à la fois plus cher et pas nécessairement plus cohérent.
Chaque session de chat d'informateur PNJ dispose d'une fiche de personnalité (trait, voix, faction, périmètre de connaissance, ce qu'ils veulent du joueur, ce qu'ils ne révèleront jamais), d'une fenêtre de mémoire glissante (8 derniers échanges), d'une passe d'extraction de faits (après chaque échange, les déclarations clés sont extraites vers l'état du monde), et d'une frontière de connaissance (le modèle est explicitement dit ce que le PNJ ne sait pas, pas seulement ce qu'il sait). C'est la bonne architecture pour la cohérence de personnage à l'échelle.
La passe d'extraction de faits est l'élément architecturalement le plus intéressant. Après chaque échange, le système lance un second appel Haiku qui lit la réponse du PNJ et extrait toutes les déclarations factuelles que le PNJ a faites · prix mentionnés, lieux révélés, noms cités · et les stocke dans l'état du monde. Cela signifie que le chat PNJ n'est pas seulement du contenu interactif ; c'est de la génération d'état du monde. Un joueur qui interroge correctement un informateur change l'état du monde de manière petite mais significative. Le moteur sait ce qui a été révélé, à qui, et quand.
Ce qui rend cette conception véritablement impressionnante c'est qu'elle a été construite pour résoudre un problème du système de missions · mener les joueurs vers des indices · et a finalement produit un modèle d'interaction de personnage suffisamment sophistiqué pour alimenter le moteur plus large que nous concevons maintenant. La tragédie est qu'il est enterré dans le système de missions. Les personnages d'arc dans EV2090 ne peuvent pas être engagés en conversation. L'infrastructure de chat PNJ n'existe que pour les informateurs de missions, qui sont conçus pour une seule mission et abandonnés ensuite. La généralisation de cette architecture à tous les personnages d'arc est l'une des choses les plus précieuses que le Narrative Engine puisse faire.
Une lacune structurelle n'est pas un bug. Un bug est une erreur d'implémentation · quelque chose que le système était censé faire mais ne fait pas. Une lacune structurelle est une frontière de design · un endroit où l'architecture telle que conçue ne peut pas faire quelque chose, non pas parce qu'elle a été mal implémentée, mais parce qu'elle n'a jamais été conçue pour ça. Comprendre la cause profonde de chaque lacune est plus important que cataloguer le symptôme, parce que les causes profondes révèlent ce qui doit être repensé au niveau architectural plutôt que patché au niveau de l'implémentation.
NarrativeEngine et le DO BountyRegistry sont des pairs, pas des collaborateurs. Un personnage d'arc qui témoin d'un crime ne peut pas devenir la cible d'une mission. Le résultat d'une mission ne peut pas faire avancer un front d'arc. Les systèmes qui devraient être les plus étroitement couplés sont complètement isolés l'un de l'autre.
NarrativeEngine fait avancer la chronologie en fonction des minutes écoulées, pas des actions du joueur. Il n'y a pas de surface d'API à travers laquelle le comportement du joueur entre dans le système narratif. Les joueurs observent l'histoire ; ils ne peuvent pas la modifier. L'architecture n'a aucun concept de décision de joueur qui change le résultat d'un beat, fait avancer prématurément un front, ou embranche l'arc.
locate_* · trouver un vaisseau, trouver une personne. La structure des indices, le modèle d'informateur PNJ et la logique de résolution supposent tous que la tâche du joueur est la découverte plutôt que l'action. Les types de missions qui nécessitent de faire quelque chose (intercepter un convoi, récupérer du fret, escorter une cible, gagner un combat) requièrent des structures de schéma fondamentalement différentes. Le schéma actuel ne peut pas les représenter, ils n'ont donc jamais été implémentés.
system-context.ts. Le système Sol avec quatre planètes n'est pas une configuration · c'est une constante. Malgré une infrastructure pour un jeu multi-systèmes partiellement construite ailleurs dans le code, le moteur narratif se rabat sur Sol parce que le contexte qui façonne la génération d'arc n'est pas configurable. Les noms des planètes, leurs économies, leur caractère politique · tout est dans un fichier, pas dans un schéma qui pourrait être rempli avec la géographie de n'importe quel univers.
persistent_facts, mais ces faits ne sont jamais surfacés aux joueurs. Ils existent pour informer la phase Concept du prochain arc · pour donner à Sonnet un contexte de continuité quand il génère la prochaine histoire. Le mécanisme pour maintenir les joueurs qui ont raté des beats au courant du récit n'existe nulle part dans le système. Les faits sont là ; la couche de rendu de ces faits ne l'est pas.
trigger_disruption, adjust_stock, post_board_note · qui se déclenchent et sont oubliés. Ils produisent des événements économiques transitoires mais pas des mutations économiques persistantes. Un beat sur l'effondrement d'une route commerciale ne modifie pas réellement le modèle économique sous-jacent de manière durable que les arcs futurs héritent. Le récit et l'économie se déroulent en parallèle plutôt que de s'influencer bidirectionnellement.
bounty-npc-chat.ts est instancié par mission. C'est une fonctionnalité de mission, pas une fonctionnalité narrative. Les personnages d'arc · les protagonistes, antagonistes et témoins de l'histoire principale · sont du contenu rendu ponctuel. L'architecture riche fiche de personnalité + mémoire glissante + extraction de faits existe, mais elle n'a pas d'équivalent au niveau de l'arc. Le système qui pourrait alimenter les interactions les plus intéressantes avec les joueurs n'est câblé qu'au système de missions qui génère le contenu le plus autonome.
À lire les lacunes ensemble, un schéma émerge. La plupart partagent la même cause profonde : le système a été construit comme deux pipelines séparés (arcs et missions) qui partagent un environnement d'exécution mais pas une architecture. Les décisions qui ont fait fonctionner chaque pipeline en isolation · des Durable Objects séparés, un état séparé, des modèles d'entités séparés · sont exactement les décisions qui les empêchent de fonctionner ensemble. Le Narrative Engine n'a pas besoin de corriger ces lacunes individuellement. Il doit traiter la séparation architecturale qui les a produites.
Le modèle de coût du pipeline EV2090 est simple en principe : les appels Sonnet sont chers et rares (une fois par arc de 5,5 heures, environ 4 à 5 appels pour le pipeline complet), et les appels Haiku sont bon marché et fréquents (un par beat, 10 à 14 par arc). L'économie favorise fortement cette architecture. Un cycle complet de génération d'arc coûte une fraction de ce qu'une approche naïve · un appel Sonnet par beat · coûterait, tout en produisant un output de meilleure qualité parce que les responsabilités de planification et de rendu sont clairement séparées.
Le système de missions ajoute la synthèse ElevenLabs à ce modèle, ce qui introduit une structure de coût différente : la génération audio est tarifée par caractère de texte, faisant de la longueur du contenu de briefing et de conclusion un vrai facteur de coût. C'est pourquoi la contrainte d'écriture consciente du TTS · phrases courtes, pas de rembourrage · n'est pas simplement une préférence esthétique. C'est une discipline de coût. Chaque mot qui n'a pas besoin d'exister dans un texte de briefing coûte de l'argent à synthétiser. La contrainte qui améliore la qualité audio la rend aussi moins chère.
Le wrapper claude-client.ts révèle quelque chose d'important sur la fiabilité en production. Il implémente une logique de retry avec backoff exponentiel et maintient des comptes de tentatives de génération par phase. Le pattern de retry n'est pas de la programmation défensive · c'est le reflet de la réalité observée. Les appels API LLM échouent. Ils expiration, renvoient du JSON malformé, ou produisent des outputs qui échouent la validation. Dans un système où un échec de génération d'arc signifie cinq heures de silence dans le monde du jeu, ce n'est pas une préoccupation académique. La couche de validation dans validation.ts est le vrai facteur de coût quand la génération échoue : un échec de validation à la phase de Chorégraphie signifie que les trois appels Sonnet qui la précèdent sont du coût immobilisé, et la phase doit être régénérée.
Cela fait de l'architecture de validation une architecture de coût. Plus précisément la couche de validation peut identifier et rejeter les échecs partiels · en conservant les bonnes parties d'une génération tout en relançant seulement la phase qui a échoué · plus le coût de la récupération de cohérence est faible. Le système actuel n'a pas de récupération partielle ; un échec de validation à la phase 4 repart depuis la phase 1. C'est acceptable aux volumes d'arcs actuels mais deviendrait coûteux à l'échelle.
La vraie leçon de coût d'EV2090 est que l'unité de coût n'est pas l'appel API · c'est l'arc cohérent. Un système qui génère cinq arcs bon marché avec des taux d'échec et de retry élevés peut coûter plus qu'un système qui génère trois arcs plus chers avec des taux d'échec quasi-nuls. Concevoir pour la qualité de génération, c'est aussi concevoir pour le coût de génération, parce que la qualité réduit les modes d'échec qui nécessitent une récupération coûteuse.
Passer de 0,85 (Concept) à 0,7 (Audit) à 0,8 (Chorégraphie) n'est pas un ensemble de choix de réglage arbitraires · c'est un modèle de ce que devrait ressentir la construction narrative à chaque phase. Haute température pour le saut créatif, plus basse pour la révision critique, intermédiaire pour la conception structurelle qui doit être à la fois inventive et cohérente. Ce gradient mérite d'être formalisé dans la spécification de design du Narrative Engine plutôt que laissé comme connaissance implicite dans un fichier de configuration.
La décision de limiter les réponses de chat PNJ à 120 tokens ressemble à une contrainte de coût. C'est en réalité une contrainte de design de personnage. À 120 tokens, une réponse de PNJ fait environ 2 à 4 phrases. C'est suffisant pour être en personnage, transmettre une pièce d'information et créer de l'intrigue pour l'échange suivant. À 400 tokens, les PNJ deviennent des monologues. Ils sur-expliquent, sortent du personnage par le seul volume des mots, et donnent tout au joueur en un tour plutôt que de récompenser l'engagement continu. Le plafond améliore les personnages, pas seulement leur coût.
Quand les échanges des joueurs avec les informateurs PNJ produisent des faits extraits qui entrent dans l'état du monde, le système de chat PNJ cesse d'être un mécanisme de livraison de contenu et devient un mécanisme de construction du monde. Le joueur ne fait pas que recevoir de l'information · il en génère, dans le sens où ses choix d'investigation spécifiques déterminent quels faits deviennent canoniques dans l'état du monde. C'est une capacité significative qu'EV2090 possède mais n'exploite pas pleinement, parce que les faits extraits sont limités à la mission plutôt que promus vers le contexte d'arc et de monde plus large.
EV2090 est l'histoire de deux systèmes construits en parallèle qui avaient besoin d'être un seul système construit sur un noyau partagé. La sophistication du système de chat PNJ de mission et la sophistication du pipeline de génération d'arc sont à peu près comparables · mais ils ne partagent rien. Pas de registre d'entités, pas de protocole d'état du monde, pas de modèle de causalité partagé. La chose la plus coûteuse dans le projet Narrative Engine n'est pas les coûts LLM. C'est le coût de la conception d'une architecture unifiée dès le départ, plutôt que de payer le coût de refactoring de la fusion de deux systèmes matures qui n'ont jamais été conçus pour se parler.
La valeur de cette analyse ne réside pas dans le catalogage de ce qu'EV2090 fait mal. Elle réside dans la traduction de ce que nous avons appris en décisions architecturales concrètes pour le Narrative Engine. Chaque conclusion ci-dessous est directement traçable aux preuves du code en production.
La structure du pipeline en 5 phases est prouvée · nous l'évoluons, nous ne la remplaçons pas. La séquence Concept → Audit → Chorégraphie → Rendu par Beat est validée par la production. Le Narrative Engine étend cette structure (en ajoutant une phase de Traitement des Conséquences et une phase d'Assemblage de Contexte avant le Concept) mais ne la repense pas. La séparation cognitive des phases, le gradient de température et la division Sonnet/Haiku sont tous conservés.
Le modèle à trois canaux devient cinq canaux de livraison. Feed, Chat et Board sont prouvés. Le Narrative Engine ajoute le Dialogue PNJ (conversation directe en personnage, la généralisation du modèle d'informateur de mission) et l'Environnemental (documents diégétiques, transmissions interceptées, objets trouvés). Chaque canal conserve sa propre instance de rédacteur, sa liste d'anti-patterns et sa spécification de rendu. Pas de rédacteur généraliste. Pas de paramètres de canal.
L'architecture de chat PNJ devient le pattern standard pour toutes les interactions PNJ. Fiche de personnalité + fenêtre de mémoire glissante + extraction de faits n'est pas une fonctionnalité de mission · c'est le modèle fondamental d'interaction PNJ. Chaque personnage d'arc avec lequel un joueur peut interagir bénéficie de cette architecture. La seule variation est le périmètre : les informateurs de missions ont une connaissance étroite, les personnages d'arc ont une connaissance à portée d'arc, les personnages récurrents du monde ont une connaissance de l'état du monde. Le mécanisme est identique.
La génération d'arc et de mission partage le même pipeline · ce sont des modes, pas des systèmes séparés. Il y a un registre d'entités, un état du monde, un modèle de causalité. Les arcs et les missions sont tous deux des structures narratives qui référencent des entités, déclenchent des beats, modifient l'état du monde et produisent du contenu orienté joueur. La distinction entre eux est une question de périmètre et de durée, pas d'architecture. Les construire sur le même pipeline élimine la Lacune 1, la Lacune 3, la Lacune 8 et la plupart de la Lacune 6 simultanément.
L'état du monde devient l'unique source de vérité. Descriptions de planètes, état économique, positions des entités, historique des arcs, état du joueur · tout vit dans l'état du monde, versionné et consultable. Rien n'est codé en dur dans un fichier de contexte. L'assemblage de contexte au début de chaque pipeline de génération lit depuis l'état du monde ; le traitement des conséquences à la fin y écrit. La boucle est fermée.
Les portes de validation sont des phases explicites du pipeline, pas des gestionnaires d'erreurs. Le système actuel traite la validation comme un try-catch autour de la génération. Le Narrative Engine traite la validation comme une phase de pipeline nommée avec des inputs, outputs et sémantiques de récupération partielle définis. Une chorégraphie qui passe la validation du concept mais échoue l'audit temporel déclenche une relance partielle depuis la Phase 3, pas un redémarrage complet depuis la Phase 1. Cela réduit à la fois la latence et le coût pour les modes d'échec les plus courants.
EV2090 a convergé vers la spine fixe / chair variable, les fiches de personnalité de PNJ et les réseaux de nœuds d'indices sans étudier le design tabletop · il les a découverts en construisant et en échouant. Cette convergence valide la recherche : EV2090 n'est pas seulement une base de code à améliorer ; c'est une confirmation indépendante que ces principes structurels sont nécessaires.
La phase de chorégraphie d'EV2090 génère une séquence typée de beats (arc_start, development, climax, resolution) mais le signal de type n'atteint jamais le moteur de rendu. Haiku reçoit le brief du beat mais pas le type de beat · donc un beat Character et un beat Story sont rendus avec le même registre. La théorie des beats nomme la lacune et fournit la correction : le champ de type appartient au brief de rendu.
EV2090 n'a pas de Fronts, pas d'application de la règle des trois indices, et pas de chronologie passive. L'arc se déclenche sur une minuterie ; le monde ne bouge pas. La recherche sur le MJ improvisateur décrit exactement ces trois mécanismes comme non négociables pour la cohérence narrative. Leur absence explique pourquoi les arcs EV2090 ressemblent à des diffusions planifiées plutôt qu'à des histoires vivantes.
Les 5 modes d'échec catalogués dans l'étude ACL · effondrement de cohérence, incohérence des personnages, échec du rythme, génération aveugle au contexte, illusion d'agentivité · correspondent directement aux 8 lacunes structurelles d'EV2090. La génération aveugle au contexte est le problème de la couche de rendu. L'incohérence des personnages est le modèle de personnalité manquant. L'illusion d'agentivité est l'absence de vraies boucles de feedback du joueur.