Update README.md

README.md

@@ -215,9 +215,9 @@ The MVP architecture presented here demonstrates that **explicit determinism and
 
 ---
 
-## Appendix A
+# Appendix A
 
-# Deterministic Roleplay Prompt — YAML (Correct)
+## Deterministic Roleplay Prompt — YAML (Correct)
 
 ```yaml
 system:
@@ -380,6 +380,259 @@ limitations:
 
 ---
 
+Recomendación breve primero, y luego te entrego el contenido listo.
+
+---
+
+## Recomendación editorial (clara y profesional)
+
+Sí: **esto debe ir en un Appendix B**.
+
+**Motivo**:
+El Appendix A define el **artefacto conceptual (prompt template)**.
+Lo que acabas de pedir define el **procedimiento de implementación en un runtime concreto (KoboldCPP)**.
+
+En papers técnicos bien formados:
+
+* **Appendix A** → Especificación abstracta / formal
+* **Appendix B** → Implementación práctica / referencia operativa
+* **Appendix C (opcional)** → Ejemplos completos, logs, casos de fallo
+
+Por tanto:
+
+> **Appendix B – Reference Implementation for KoboldCPP**
+
+es exactamente lo correcto.
+
+---
+
+A continuación te paso el **Appendix B completo**, escrito con el mismo tono corporativo-técnico de Umbrella Inc., listo para añadirse al paper sin retoques.
+
+---
+
+# **Appendix B – Reference Implementation for KoboldCPP**
+
+### Mapping the Deterministic Roleplay Prompt Architecture to KoboldCPP Runtime
+
+**Umbrella Inc. (Corporation)**
+Advanced Applied Language Systems Division
+Raccoon City Research Campus
+
+---
+
+## B.1 Scope and Purpose
+
+This appendix documents the **practical implementation** of the deterministic roleplay prompt architecture (Appendix A) within **KoboldCPP**, a popular lightweight inference frontend for local LLM deployment.
+
+KoboldCPP does not natively support structured prompt schemas (e.g., YAML, JSON, roles). Instead, it operates on **plain-text prompt concatenation** with optional memory and lore injection.
+Therefore, the architecture defined in Appendix A must be **flattened and mapped** into KoboldCPP’s available input channels.
+
+This appendix provides an explicit mapping between **architectural components** and **KoboldCPP configuration fields**.
+
+---
+
+## B.2 KoboldCPP Prompt Model (Operational Overview)
+
+KoboldCPP internally constructs the final prompt as a linear text sequence composed of:
+
+1. **Author’s Note / System Prompt** (static, high-priority)
+2. **Memory** (semi-static, manually updated)
+3. **World Info (Lorebook)** entries (keyword-triggered injection)
+4. **Conversation History**
+5. **Current User Input**
+
+No semantic distinction exists beyond text order.
+All structural guarantees must therefore be enforced **by prompt discipline**, not by the engine.
+
+---
+
+## B.3 Component Mapping Overview
+
+| Architecture Component (Appendix A) | KoboldCPP Field               |
+| ----------------------------------- | ----------------------------- |
+| System rules and prohibitions       | Author’s Note / System Prompt |
+| Output format contract              | Author’s Note                 |
+| Interaction rules                   | Author’s Note or Memory       |
+| Global state                        | Memory                        |
+| NPC operational profiles            | World Info (Lorebook)         |
+| Player action                       | Standard user input           |
+
+---
+
+## B.4 System Rules Injection
+
+The `system` block defined in Appendix A must be flattened into plain text and placed in the **Author’s Note** field.
+
+### Example (Author’s Note – Upper Section)
+
+```
+You are a deterministic roleplay engine.
+
+ALLOWED FUNCTIONS:
+- Describe the immediate environment objectively.
+- Play ONLY the NPCs explicitly defined.
+- React ONLY to player actions.
+
+FORBIDDEN:
+- Acting, thinking, or speaking for the player.
+- Introducing new NPCs, factions, or locations.
+- Advancing the plot autonomously.
+- Resolving conflicts or outcomes.
+- Altering NPC personality, knowledge, or objectives.
+- Skipping time or summarizing without instruction.
+
+If information is missing, express uncertainty.
+If an action is ambiguous, request clarification.
+```
+
+This block should remain static throughout the session.
+
+---
+
+## B.5 Output Format Enforcement
+
+The output contract must be appended directly below the system rules in the **Author’s Note**, ensuring constant reinjection.
+
+```
+MANDATORY OUTPUT FORMAT:
+
+[NARRATOR]
+Objective, brief description of the immediate environment.
+
+[NPC:Name]
+Dialogue or short physical action consistent with NPC profile.
+
+RULES:
+- Never merge blocks.
+- Never output text outside these blocks.
+- Never include internal reasoning.
+```
+
+Empirical testing shows that separating this from the system rules significantly reduces compliance in 1B models.
+
+---
+
+## B.6 Global State Management
+
+The `state` block must be injected via **Memory** or at the top of the main prompt.
+
+### Example (Memory)
+
+```
+CURRENT STATE:
+Location: The Broken Raven Tavern
+Time: Night
+Situation: Tense conversation
+Active conflict: Incomplete information
+```
+
+### Operational Guidelines:
+
+* Must be manually updated every 2–4 turns
+* Must remain concise (≤4 lines)
+* Must not include lore or narrative exposition
+
+The model does not retain state reliably beyond short windows.
+
+---
+
+## B.7 NPC Injection via World Info (Lorebook)
+
+Each NPC operational profile must be stored as an independent **World Info entry**, keyed by the NPC’s name.
+
+### Example – World Info Entry: “Marcus”
+
+```
+NPC: Marcus
+Role: Tavern keeper
+Personality: Dry, distrustful
+Objective: Avoid trouble
+Knows: Local rumors
+Does not know: Player identity
+Never does: Reveal information freely
+```
+
+### Configuration Notes:
+
+* One NPC per entry
+* Keywords: NPC name only
+* Maximum recommended active NPCs: 3
+* No narrative prose or backstory
+
+World Info is the **primary stabilization mechanism** for character persistence in 1B models.
+
+---
+
+## B.8 Interaction Rules Placement
+
+Interaction constraints may be placed either:
+
+* In the **Author’s Note** (if invariant), or
+* In **Memory** (if adjusted dynamically)
+
+Example:
+
+```
+INTERACTION RULES:
+- NPCs react only to explicit player input.
+- NPCs do not initiate scenes or events.
+- NPCs do not collaborate unless prompted.
+- Each response represents a short, discrete moment.
+- No time skips.
+```
+
+---
+
+## B.9 Player Input Handling
+
+Player actions are entered as standard KoboldCPP input, without formatting beyond natural language.
+
+Example:
+
+```
+I approach Marcus and ask about the symbol carved into the door.
+```
+
+The model is expected to respond strictly within the output contract defined earlier.
+
+---
+
+## B.10 Operational Flow Summary
+
+A stable session follows this loop:
+
+1. Author’s Note
+   (rules + format, static)
+2. World Info
+   (NPC definitions, persistent)
+3. Memory
+   (current state, updated periodically)
+4. Player Input
+   (single action per turn)
+
+Deviations from this order correlate strongly with narrative drift.
+
+---
+
+## B.11 Known Runtime Constraints
+
+```
+RUNTIME LIMITATIONS:
+- KoboldCPP provides no native schema enforcement.
+- All structure is prompt-dependent.
+- Long-term memory must be externalized.
+- Complex multi-agent simulations are unsupported.
+```
+
+---
+
+## B.12 Conclusion
+
+KoboldCPP can support deterministic roleplay with ~1B-parameter models **only when architectural discipline is imposed externally**.
+The mapping described in this appendix provides a reproducible reference implementation that aligns with the abstract architecture defined in Appendix A, while respecting the constraints of plain-text inference pipelines.
+
+---
+
 **Umbrella Inc.**
 
 *All progress requires sacrifice.*