# Story Mode Story Mode is an optional entry path for Domain Context Modeling. Use it when a product idea is easier to understand through a concrete situation than through abstract domain mapping. The purpose is not to turn product work into storytelling. The purpose is to use story as a practical sensing tool. A specific multi-actor situation can reveal actors, stakes, objects, workflows, rules, handoffs, sources of truth, failure points, and outcomes before the team knows exactly what product it should build. The working principle: > Story reveals the domain. Domain context improves the story. ## When To Use It Use Story Mode when: - The idea is still a hunch. - The team is struggling to name the real domain. - The problem sounds generic until placed in a real situation. - Multiple actors have different wants, stakes, or authority. - The product may involve agents, handoffs, review, escalation, or trust-sensitive actions. - You want to test whether a product direction is grounded in a real product world. Skip it when the team already has a clear domain, stable vocabulary, known rules, and enough context to complete the Core Brief directly. ## Story Brief Write roughly one page of prose. Use the fields as thinking prompts, not rigid slots. ```text Cast Who is involved? Include human roles, organizations, software systems, AI agents, reviewers, approvers, customers, beneficiaries, and affected parties. If there is only one actor, the story is probably too thin. Situation Where and when is this happening? What specific moment, workflow, setting, or pressure makes the story recognizable? Want What is each actor trying to accomplish? Name the progress each actor wants, not just the task they perform. Stakes What does each actor stand to gain, lose, protect, avoid, express, or become? Avoid generic stakes like "save time" unless the domain explains why time matters. Complication What currently makes progress hard? Look beyond "the current tool is clunky" toward domain friction, unclear authority, missing evidence, conflicting incentives, trust gaps, fragmented records, or risky handoffs. Desired resolution What would a good ending look like? Separate user, business or organizational, and system or agent outcomes. ``` ## Story-To-Domain Extraction After writing the Story Brief, extract domain signals before moving into Discovery Mode or the Core Brief. ```text Actors The human roles are... The organizational actors are... The software systems or AI agents are... The affected but indirect actors are... Objects The important records, artifacts, documents, places, events, tasks, decisions, or resources are... The story cannot be told without... Actions and Episodes The major episodes are... The important actions are... The handoffs are... The moments of review, approval, rejection, escalation, or exception are... Rules and Sources The rules implied by the story are... The sources of truth are... The facts that require evidence are... The authority boundaries are... States The important lifecycle states are... The state changes that alter available actions are... Language The domain terms that appeared naturally are... The ambiguous or overloaded terms are... The terms the product should avoid or translate are... Outcomes The user outcome is... The business or organizational outcome is... The system or agent outcome is... The outcomes that may be in tension are... Open Questions The story may be wrong if... The domain needs more evidence about... The riskiest assumptions are... ``` ## How It Connects Story Mode can feed Discovery Mode when the product direction is still open: ```text Story Brief -> story-to-domain extraction -> Discovery Mode -> coherent product directions -> selected concept -> Domain Context Brief ``` Story Mode can also feed the Core Brief when the product direction is already clear: ```text Story Brief -> story-to-domain extraction -> Core Brief -> spec, prototype, service, automation, agent behavior, and eval ``` Use Story Mode as a lens, not a mandate. The team should stop once the story has produced enough domain context to make the next artifact more specific, constrained, empathetic, and trustworthy. ## Quality Checks A useful Story Brief should: - Include more than one actor with distinct wants. - Name stakes that are specific to the domain. - Reveal objects, rules, states, handoffs, and sources of truth. - Make the product opportunity more concrete. - Improve the Domain Context Brief rather than creating decorative narrative. - Surface what could go wrong if a person, service, software system, or AI misunderstood the domain. A weak Story Brief usually: - Centers only one generic user. - Treats the product as the story instead of the product world. - Describes interface friction without explaining domain friction. - Uses broad stakes like speed, efficiency, or convenience without context. - Produces no new domain concepts, rules, or authority boundaries.