You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
- Continuous tuning of Director heuristics and Writer prompts based on production telemetry.
201
202
202
203
### Quality gates / definition of done
203
204
- Proposal schema defined, documented, and validated with at least 10 example proposals.
@@ -211,4 +212,136 @@ Players on desktop/mobile browsers who will experience emergent story branches d
211
212
212
213
### Risks & mitigations
213
214
214
-
The file write succeeded. Now proceed to create the new PRD for ge-hch.5.16. The prior attempt to write earlier failed due to modification; this write restored content. Now create new PRD file. Would you like the new PRD to be at `docs/prd/ge-hch.5.16.md`? If yes I'll write it and commit.
215
+
#### Risk: AI Director fails to return to scripted path within the window
216
+
- Impact: player gets stuck in an infinite or dead-end unscripted loop; breaks immersion and breaks the story.
217
+
- Mitigation: implement a deterministic fail-safe that forces a return to scripted content after the window expires; log the event with high priority (alert operators).
218
+
- Mitigation: test the Director's return-path logic exhaustively during Phase 1–2; profile common failure modes.
219
+
220
+
#### Risk: AI Writer produces content that drifts off-theme or contradicts LORE
221
+
- Impact: player experiences an incoherent or jarring branch; reduces trust in emergent storytelling.
222
+
- Mitigation: enforce strong LORE and character constraints in the Writer's prompt; include embeddings or semantic similarity checks in the validation suite.
223
+
- Mitigation: add style/content tests that flag branches differing >N% from the original story's tone; collect examples from playtesters.
224
+
225
+
#### Risk: Policy pipeline is over-restrictive or under-restrictive
226
+
- Impact: either rejects too many valid branches (reduces emergent variety) or allows policy violations (safety breach).
227
+
- Mitigation: keep ruleset configurable and provide diagnostics for each rule (why was this branch rejected?); gather feedback from producers in Phase 1.
228
+
- Mitigation: start with a conservative policy and loosen it iteratively based on playtest feedback.
229
+
230
+
#### Risk: Performance bottleneck in Director decision latency
231
+
- Impact: branch integration is delayed; player sees a stall or "thinking" state; breaks immersion.
232
+
- Mitigation: profile Director decision-making during Phase 2; optimize hot paths (risk scoring, return-path search).
233
+
- Mitigation: consider pre-computing Director decisions for likely player choices (offline analysis).
- Impact: players explore unscripted content that diminishes the story's themes or message.
237
+
- Mitigation: include thematic alignment as a Director risk metric; require branches to include explicit narrative intent statements.
238
+
- Mitigation (post-M2): future phases may add producer tools to review and disable problematic branches based on post-launch analysis.
239
+
240
+
## Resources
241
+
242
+
### M2 Design Documents
243
+
244
+
#### Core Design Specs
245
+
-**[Director Algorithm](../dev/m2-design/director-algorithm.md)** — Complete 5-step real-time governance algorithm with risk-scoring metrics, return-path feasibility validation, and fail-safe mechanisms.
246
+
-**[Policy Ruleset](../dev/m2-design/policy-ruleset.md)** — Validation rules across 5 categories (content safety, narrative consistency, structure, format, return path) with severity levels and tuning parameters.
247
+
-**[Sanitization Transforms](../dev/m2-design/sanitization-transforms.md)** — Deterministic content transformation algorithms (profanity redaction, HTML stripping, whitespace normalization) with test cases.
248
+
-**[Proposal Lifecycle](../dev/m2-design/proposal-lifecycle.md)** — Multi-stage process from Outline through Detail, Placement, Runtime, and Terminal states with key insights on late content generation.
249
+
250
+
#### AI Writer Design
251
+
-**[LORE Data Model](../dev/m2-design/lore-model.md)** — Complete specification of runtime context (player state, game state, narrative context, player behavior) that feeds Writer generation.
252
+
-**[Writer Prompts](../dev/m2-design/writer-prompts.md)** — 4 prompt templates (dialogue, exploration, combat, consequences) with constraint enforcement mechanisms and latency targets.
253
+
-**[Writer Examples](../dev/m2-design/writer-examples.md)** — 5 detailed proposal examples across branch types showing quality metrics and Writer capabilities.
254
+
-**[Determinism Specification](../dev/m2-design/determinism-spec.md)** — Reproducibility framework via input hashing and LLM seed management with fallback strategies.
255
+
256
+
#### Runtime & Integration
257
+
-**[Runtime Integration Hooks](../dev/m2-design/runtime-hooks.md)** — 5 safe hook point categories (scene boundaries, choice points, quests, rest/load, combat) with 12-state integration state machine and automatic rollback semantics.
258
+
-**[Telemetry Schema](../dev/m2-design/telemetry-schema.md)** — 6 event types spanning generation, validation, Director decision, presentation, choice, and outcome with 5 observability dashboards and post-launch analysis workflow.
259
+
260
+
#### Ink Language Integration
261
+
-**[Ink Validation Review](../dev/m2-design/ink-validation-review.md)** — Comprehensive validation of M2 design against Ink language capabilities, terminology consistency review, and implementation recommendations.
262
+
263
+
### M2 Schemas
264
+
-**[Branch Proposal Schema](../dev/m2-schemas/branch-proposal.json)** — JSON Schema definition with all required fields for proposal submissions.
-**[Example Proposals](../dev/m2-schemas/examples/)** — 10 detailed proposal examples across different narrative scenarios.
267
+
268
+
### Schema Documentation
269
+
-**[Schema Docs](../dev/m2-design/schema-docs.md)** — Field-by-field explanation of branch proposal schema with integration guidance.
270
+
271
+
---
272
+
273
+
## Design Decisions
274
+
275
+
The following decisions have been finalized for M2 implementation:
276
+
277
+
### Runtime Constraints
278
+
279
+
| Decision | Value | Rationale |
280
+
|----------|-------|-----------|
281
+
|**Return window**| 3–5 player choice points | Balances emergent exploration with narrative coherence; prevents infinite loops while allowing meaningful detours |
282
+
|**Director latency target**| < 500ms | Player-facing decision must feel instantaneous; validation happens on pre-approved structures |
283
+
|**Writer latency target**| 1–3s per beat | Acceptable for background/async generation; masked by player reading time during execution |
284
+
285
+
### AI Writer and LORE
286
+
287
+
| Decision | Value | Rationale |
288
+
|----------|-------|-----------|
289
+
|**LORE capture method**| Hybrid (auto-extracted + manual annotations) | Auto-extract player actions, inventory, relationships; manual annotations for narrative themes and character arcs |
290
+
|**Minimum LORE context**| 5–15 KB compressed | Sufficient for coherent generation; fits in LLM context windows; see lore-model.md for field specifications |
291
+
|**Creativity parameter mapping**| 0.0 = temperature 0.0 (deterministic); 1.0 = temperature 1.5 (high variance) | Linear mapping provides intuitive control; clamped to prevent incoherent outputs |
292
+
|**Proposal caching**| Yes, by context hash | Avoid redundant generation for identical contexts; cache invalidated when LORE changes |
293
+
|**Embedding model**| text-embedding-ada-002 (or equivalent) | Industry standard for semantic similarity; used in validation and Director risk scoring |
294
+
295
+
### Policy and Safety
296
+
297
+
| Decision | Value | Rationale |
298
+
|----------|-------|-----------|
299
+
|**Policy rule categories**| Content safety (profanity, explicit, hate speech), Narrative consistency (LORE, character voice, theme), Structural (length, format, Ink syntax), Return path validation | Comprehensive coverage; see policy-ruleset.md for full specification |
300
+
|**Policy scope**| Global defaults + story-specific overrides | Global rules ensure baseline safety; story-specific rules allow genre-appropriate content (e.g., darker themes in horror stories) |
301
+
302
+
### Storage & Access
303
+
304
+
| Decision | Value | Rationale |
305
+
|----------|-------|-----------|
306
+
|**Proposal retention**| 2 years for audit logs; 6 months for raw proposals with content | Compliance requirement; enables post-launch learning; older proposals archived |
307
+
|**Data handling**| Encrypt at rest; redact PII before storage; access limited to analytics roles | Privacy by design; GDPR-compatible |
|**AI transparency**| Seamless by default (no indication); opt-in transparency mode in settings | Prioritizes immersion; respects player choice for those who want to know |
315
+
316
+
### Validation UX
317
+
318
+
| Decision | Value | Rationale |
319
+
|----------|-------|-----------|
320
+
|**Authoring validation**| Asynchronous for proposals > 1000 tokens; synchronous for smaller proposals | Responsive UX for quick edits; background processing for large content |
321
+
|**Sanitization visibility**| Sanitized diffs logged but not auto-exposed; available on request | Reduces noise; diffs available for debugging when needed |
322
+
323
+
## Remaining Open Questions
324
+
325
+
The following questions require stakeholder input before Phase 1 implementation:
326
+
327
+
### Story-Specific Configuration
328
+
- What story-specific policy overrides are needed for the initial pilot story?
329
+
- Which characters have custom voice profiles that need explicit constraints?
330
+
331
+
### Operational Readiness
332
+
- What alerting channels should receive fail-safe notifications (Slack, PagerDuty, email)?
333
+
- Who is the on-call contact for Phase 2 pilot issues?
334
+
335
+
### Player Research
336
+
- Should we conduct A/B testing with AI-branches enabled vs. disabled?
337
+
- What is the target sample size for coherence perception surveys?
338
+
339
+
## Clarification: No Human-in-Loop in M2
340
+
341
+
**M2 is designed with fully automated validation and approval.** The PRD explicitly states (Non-goals, line 19) that "This PRD does not require human-in-loop approval for every branch proposal." All runtime acceptance decisions are made by the policy/sanitization pipeline and AI Director—no human approval or intervention is required.
342
+
343
+
**M2 has no operator disable/revert mechanism at runtime.** Operators observe telemetry to understand system behavior and detect issues, but cannot disable or revert branches once approved. All acceptance/rejection decisions are automated; there is no human gate at runtime.
344
+
345
+
**Human involvement is limited to between-phase improvements**:
346
+
- Producers analyzing telemetry and player feedback to refine policy rules and Director heuristics
347
+
- Future phases (Phase 3+) may introduce human-in-loop oversight if safety concerns emerge at scale
0 commit comments