# Domain Context Brief v0 Use this brief when a product idea needs to become clear enough for humans and AI agents to design, build, evaluate, or act on it. The Domain Context Brief is the upstream source for persistent AI context files, specs, implementation plans, critique prompts, evaluation rubrics, and human review gates. It should define the product world once so downstream artifacts do not each invent their own version of the domain. The brief should be short enough to complete quickly, but specific enough to prevent shallow product generation. Start with Discovery Mode when the idea is still a hunch. Use optional Story Mode when a concrete multi-actor situation would reveal the domain more clearly than abstract mapping. Start with the Core Brief when you have a promising direction and need momentum. Expand into the full brief when the product has multiple roles, important rules, source-of-truth concerns, or AI actions that need clear authority boundaries. ## Optional Story Mode Use Story Mode before or inside Discovery Mode when the product world is easier to understand through a concrete situation than through abstract domain mapping. The goal is not narrative polish. The goal is to use story as a sensing tool. A specific story can reveal actors, stakes, objects, workflows, handoffs, rules, sources of truth, states, failure points, and outcomes before the team knows exactly what product it should build. Story Mode uses a short Story Brief: ```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. ``` Then extract: ```text The actors are... The important objects, records, documents, events, tasks, or decisions are... The major episodes and handoffs are... The rules and sources of truth are... The important lifecycle states are... The natural domain language is... The user outcome is... The business or organizational outcome is... The system or agent outcome is... The riskiest assumptions are... ``` Use the extraction to complete Discovery Mode or move directly into the Core Brief. More detailed Story Mode guidance lives in [Story Mode](./story-mode.md). ## Discovery Mode Use this pre-brief when the product idea is still loose, exploratory, or vibe-coded. The goal is not to produce a build-ready spec yet. The goal is to turn a rough hunch into several coherent product directions that could only emerge from understanding the product world. Discovery Mode should help a builder ask: - What worlds does this idea touch? - What people, artifacts, rituals, tensions, decisions, and handoffs already exist there? - What concepts are easy to miss from a generic product prompt? - What could AI or software make newly possible? - Which product directions feel coherent, useful, differentiated, and buildable? ### 0. Starting Hunch ```text I am interested in helping... The messy situation is... The current behavior, workaround, or pain is... AI or software might help by... I am not yet sure whether this should become... If using Story Mode, the concrete situation is... ``` ### 1. Domain Terrain Map the adjacent worlds the idea touches before choosing a product shape. ```text This idea touches the worlds of... The people or organizations involved are... The important situations are... The informal rituals or workarounds are... The existing tools, documents, systems, or services are... The sources of truth are probably... The places where trust, taste, craft, risk, or authority matter are... ``` ### 2. Concept Mining List the nouns, events, states, and decisions that seem important, even if the final product is not clear yet. ```text Important people or roles include... Important objects or records include... Important events or moments include... Important decisions include... Important handoffs include... Important states might include... Important tensions include... Concepts that outsiders might miss are... Concepts that are often confused are... ``` ### 3. Opportunity Shapes Generate multiple product directions from the same domain terrain. ```text This could become a workspace for... This could become an assistant for... This could become an operating system for... This could become a review or QA layer for... This could become a marketplace or network for... This could become a memory, archive, or knowledge layer for... This could become a planning or coordination tool for... This could become a creative, analytical, compliance, or safety layer for... The most domain-specific opportunities are... The most AI-native opportunities are... The opportunities to avoid for now are... ``` ### 4. Coherence Check For each promising direction, test whether it has a real product center. ```text The core object would be... The main user would be... The main job or workflow would be... The product would feel native to this domain because... AI would help by... AI should not... The important source of truth would be... The main risk or failure mode would be... This direction is stronger than a generic product idea because... This direction may be weak if... ``` ### 5. Concept Selection Choose the strongest direction or keep a small set for comparison. ```text The strongest direction is... The second strongest direction is... The most surprising direction is... The direction that feels most buildable is... The direction with the strongest user urgency is... The direction with the clearest AI advantage is... The direction that should move into the Core Brief is... ``` Discovery Mode can produce a short opportunity memo, a set of concept cards, a relationship sketch, or a ranked list of product directions. Once a direction is selected, move into the Core Brief. Story Mode can produce a Story Brief and story-to-domain extraction. Use it when narrative specificity helps reveal domain concepts, actor motives, stakes, handoffs, rules, and outcomes. ## Core Brief Use this version in a working session before asking AI to generate product specs, flows, prototypes, object models, tools, or agent behavior. ### 1. Domain and Boundaries ```text This product operates in the domain of... It helps... The main people or organizations are... It does not attempt to... ``` ### 2. Core Concepts and Relationships ```text The core concepts are... A [Concept] is... It is not... A [Concept] belongs to... A [Concept] depends on... A [Concept] must trace back to... ``` ### 3. Rules, States, and Sources of Truth ```text [Concept] states are... Always... Never... Before [action], verify... For [fact/status/rule], trust... If sources conflict, prefer... ``` ### 4. AI Actions and Human Authority ```text Users can... AI may suggest... AI may draft... AI may inspect... AI may update only when... AI must ask before... AI must cite evidence when... AI must not... AI should escalate when... ``` ## Extended Brief Use the full version when you need stronger product architecture, future opportunity thinking, audience translation, implementation context, or evaluation criteria. ## 1. Domain What world are we modeling? Include: - The product domain - The main people or organizations involved - The situation where the product creates value - The boundaries of what is in scope Prompt: ```text This product operates in the domain of... It helps... It does not attempt to... ``` ## 2. Domain Inheritance And Innovation What existing domains does this product borrow from, transform, recombine, or invent beyond? Not every domain is already settled. Some products need to preserve established domain reality, while others create a new product category by changing how familiar concepts relate to each other. Make the inherited and novel parts explicit so the product can use familiar language where it helps, introduce new concepts where needed, and teach the new mental model without becoming vague. Classify important ideas as: - Existing: borrowed from a domain users already understand - Adapted: familiar term with changed meaning - Combined: created by joining concepts from multiple domains - Novel: new to this product or category - Internal: important to the system but not user-facing Prompt: ```text This product inherits from... Users will already understand... This product changes the meaning of... This product combines... This product introduces... Users may need to unlearn... The product should teach... The product should borrow familiar language for... The product should introduce new language for... ``` ## 3. Domain Affection Why is this world worth caring about? A useful product should not only model the domain correctly. It should help the team understand what people in the domain value, protect, notice, fear, enjoy, and take pride in. This section helps product teams design with empathy and taste instead of treating the domain as raw material for generic AI output. Prompt: ```text What makes this domain worth caring about? What do skilled people in this domain notice that outsiders miss? What are users trying to protect, improve, express, avoid, or become? Where does the domain contain craft, judgment, risk, pride, frustration, or delight? What would a careless product misunderstand about this world? What should the product help users feel? ``` ## 4. Domain Opportunity What does this domain make possible? A domain model should help teams notice opportunities, not just avoid mistakes. This section identifies product enhancements, service possibilities, rituals, workflows, business models, and innovation paths that become visible once the product world is understood. The goal is not to commit to these opportunities immediately. The goal is to avoid missing obvious or meaningful possibilities because the team started from a generic feature prompt instead of the domain itself. Prompt: ```text What does this domain make possible beyond the first product version? Which concepts naturally suggest future features, services, rituals, or business models? What relationships in the domain are currently underserved? What user behaviors already exist informally that the product could support intentionally? What opportunities are obvious once the domain is modeled, but easy to miss in a generic product prompt? Which opportunities should be explored now, later, or deliberately avoided? ``` ## 5. Domain Outcomes What outcomes should the product create, improve, or protect? Tie product opportunity back to the domain's human, operational, organizational, and business stakes. Outcomes should clarify what success means in this world, where tradeoffs exist, and which outcomes should remain protected as the product evolves. Prompt: ```text What user outcomes matter in this domain? What organizational or business outcomes matter? What trust, safety, quality, creative, operational, or emotional outcomes matter? Which outcomes are in tension with each other? Which outcomes should the product optimize for now? Which outcomes should the product protect even when adding future capabilities? ``` ## 6. Metaphor And Medium Translation What carries over from the real-world model, and what changes because of the product medium? Many products borrow from real-world domains, but the product should not copy the real world uncritically. Preserve the parts of the domain that help users understand, trust, or care about the product. Adapt or discard the parts that create friction, false expectations, or unnecessary nostalgia. Then identify what becomes possible because the product is digital, AI-assisted, networked, persistent, personalized, programmable, spatial, physical, or otherwise different from the original domain. Prompt: ```text Which real-world concepts should transfer directly? Which should be adapted because the product medium changes the behavior? Which should be left behind because they add friction, nostalgia, or false expectations? Which digital-native, AI-native, networked, persistent, or programmable concepts should replace or extend the real-world model? Where could the metaphor help users understand the product? Where could the metaphor limit the product? What becomes more powerful, scalable, personal, collaborative, or measurable because of the product medium? ``` ## 7. Core Concepts What are the important nouns? List the durable things users, systems, and agents need to reason about. These may be people, places, objects, records, tasks, documents, events, or decisions. Prompt: ```text The core concepts in this domain are... ``` ## 8. Concept Definitions What does each concept mean, and what is it not? For each core concept, define: - Meaning - Non-examples or nearby concepts it should not be confused with - Why it matters Prompt: ```text A [Concept] is... It is not... It matters because... ``` ## 9. Relationships How do the concepts connect? Capture ownership, containment, dependency, sequence, traceability, and source relationships. Prompt: ```text A [Concept] belongs to... A [Concept] contains... A [Concept] depends on... A [Concept] is created from... A [Concept] must trace back to... ``` ## 10. States What lifecycle stages matter? Define the states that change what users or agents can do. Prompt: ```text [Concept] states: - Draft - Submitted - Approved - Rejected ``` ## 11. Actions What can humans do? What can agents do? Separate actions by actor and authority. Be explicit about which actions change records, trigger external consequences, or require confirmation. Prompt: ```text Users can... Agents can suggest... Agents can draft... Agents can inspect... Agents can update... Agents cannot... ``` ## 12. Rules What must always be true? Rules should constrain product behavior, AI behavior, or both. Prompt: ```text Always... Never... Before [action], verify... If [condition], then... ``` ## 13. Language What terms should be used, avoided, or handled carefully? Capture preferred names, synonyms, overloaded terms, and terms that mean different things in different contexts. Prompt: ```text Use the term... Avoid the term... Do not confuse... In this context, [term] means... ``` ## 14. Audience Translation How should the same domain model be represented differently for different audiences, roles, or levels of expertise? A domain model can be canonical while its UX representations are audience-specific. A technical admin, operational teammate, executive reviewer, agent, and end user may need different language, defaults, controls, detail levels, and explanations for the same underlying concepts. For each important audience or role, decide: - What they are trying to accomplish - What domain concepts they need to see directly - What concepts should be simplified, hidden, renamed, or gradually revealed - What language they naturally use - What actions they can safely take - What decisions require explanation, confirmation, or escalation - What level of detail they need by default - What expert controls, raw data, or diagnostics they may need Prompt: ```text For [audience/role], the goal is... They should see... They should not need to see... Use the term... Avoid the term... They can safely... They need confirmation before... Reveal more detail when... Provide expert controls for... ``` ## 15. Experience And Brand Translation How should the domain model and domain affection become a human-centered product experience? Do not assume every concept, rule, source, value, or boundary should appear as explicit interface language. Some domain context should shape the system behind the scenes, some should structure navigation or workflows, and some should be revealed only when a user is making a risky or ambiguous decision. Use the domain affection and audience translations above to decide which representation fits each role and moment. For each important concept, rule, source, domain value, or agent boundary, decide: - Whether users need to see it directly - Whether it should guide labels, navigation, grouping, or task flow - Whether it should become system logic, validation, or agent instructions - Whether it should appear only at decision points, review moments, exceptions, or conflicts - What plain-language user-facing label should replace internal framework language - What the product should feel like because of the domain - What the product should never make light of or flatten into generic software language Prompt: ```text Users should see... Users should not need to see... The system should track... AI should use behind the scenes... Reveal [concept/rule/source/boundary] when... Use the user-facing label... Avoid exposing the internal label... The product should feel... The product should never make light of... Domain values should show up in... Users should feel that the product understands... ``` ## 16. Sources of Truth Where should humans or agents verify information? List authoritative sources for facts, rules, status, eligibility, permissions, and historical decisions. Prompt: ```text For [fact type], trust... For [status], trust... For [requirements], trust... If sources conflict, prefer... ``` ## 17. Agent Boundaries What can AI safely suggest, draft, decide, or execute? This section turns domain understanding into operational guidance. Prompt: ```text AI may... AI must ask before... AI must cite evidence when... AI must not... AI should escalate when... ``` ## 18. Failure Modes What misunderstandings would create bad product decisions or unsafe AI behavior? Prompt: ```text The product or agent may fail if it... The most dangerous concept confusions are... The most likely hallucinations are... The highest-risk actions are... ``` ## Optional Outputs After Discovery Mode or the completed brief, ask an AI collaborator to generate: - Story Brief - Story-to-domain extraction - Product direction options - Opportunity memo - Product spec - Object model - User flows - IA model - State machine - Agent instructions - Tool schema notes - Design-system implications - Opportunity map - Outcome map - Metaphor and medium translation notes - Audience translation map - Experience translation checklist - Domain concept cards - Domain guidebook - Domain map or relationship diagram - World vision brief - Evaluation checklist