Loose hunch
Copy Discovery Prompt
Discovery Mode
Use when the idea is not mature yet. Map the terrain, mine concepts, and generate several product directions before committing.
A field guide for AI-assisted product work
Domain Context Modeling
Give AI the product world before it builds. Map the concepts, rules, sources of truth, user values, and human authority boundaries that make generated product work coherent.
Product
Sharper concepts, workflows, risks, outcomes, and tradeoffs.
UX
Interfaces that speak the domain without exposing the whole model.
Engineering
States, rules, sources, and object boundaries that survive implementation.
Agents
Clear permissions, evidence requirements, escalation points, and review gates.
Start Here
Use the lightest path that fits the moment.
Start with a prompt, produce a brief, then use that brief as context for specs, prototypes, interface critique, code planning, or agent behavior. The goal is better shared understanding before generation begins.
Concrete situation
Copy Story Prompt
Story Mode
Use when the product world is easier to understand through actors, stakes, handoffs, complications, and desired resolution.
Promising direction
Copy Core Brief
Core Brief
Use when you know what you are exploring and need enough structure to make AI output more specific, careful, and useful.
Copyable Prompts
Start by giving AI better context.
These prompts help turn rough domain knowledge into reusable context. Use them in any AI tool before asking for product strategy, UX flows, prototype screens, implementation plans, or agent behavior.
Discovery prompt
Use this when you have a rough idea and want the domain to reveal possible product shapes.
I have a rough idea for an AI-assisted product: [Describe the hunch, audience, situation, or problem] Help me explore the product world before choosing a product shape. Map: - adjacent domains this idea touches - people, organizations, roles, and affected parties - important objects, records, documents, events, decisions, and handoffs - rituals, workarounds, tensions, and sources of truth - places where trust, craft, taste, risk, or authority matter Then propose five coherent product directions that could only emerge from understanding this domain. For each direction, identify: - core object - main user - main workflow - AI advantage - source of truth - main risk - why it is stronger than a generic product idea End by recommending the direction that should move into a Domain Context Brief.
Story prompt
Use this when a real moment, workflow, or situation will reveal the domain better than abstract mapping.
I have a rough idea for an AI-assisted product: [Describe the hunch, audience, situation, or problem] Write a one-page Story Brief that captures: - cast: who is involved - situation: where and when this happens - want: what each actor is trying to accomplish - stakes: what each actor may gain, lose, protect, avoid, express, or become - complication: what currently makes progress hard - desired resolution: good endings for the user, organization, and system or agent Then extract the domain signals: - actors - objects, records, documents, events, tasks, and decisions - episodes and handoffs - rules and sources of truth - lifecycle states - natural domain language - user outcome - business or organizational outcome - system or agent outcome - riskiest assumptions
Core brief template
Use this when a concept is ready for specs, prototypes, design critique, implementation planning, or agent behavior.
# Domain Context Brief ## 1. Domain and Boundaries 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 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 [Concept] states are... Always... Never... Before [action], verify... For [fact/status/rule], trust... If sources conflict, prefer... ## 4. AI Actions and Human Authority 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...
Use the brief downstream
Paste a completed brief into your AI tool when asking for product, UX, engineering, or agent work.
Help me design an AI-assisted [product concept]. Use this domain context: [Paste completed Domain Context Brief] Create a product spec including: - product framing - key features - user flows - object model - important states and rules - sources of truth - AI assistant behavior - human review gates - failure modes and risks If creating screens or prototypes, translate the domain context into user-facing language, workflows, evidence, disabled states, review moments, and exception handling. Do not surface framework labels unless they would make sense to actual users.
What Changes
The model should improve the product without making users operate the model.
The strongest proof is contrast: generic AI output may look polished, but domain context changes the objects, labels, states, evidence, and authority boundaries.
Plausible but generic
- Broad objects like tasks, documents, assets, or status.
- Confident assistant language without source handling.
- Risky actions available before readiness is proven.
- User values and domain-specific stakes are easy to miss.
Specific and product-shaped
- Objects and states match the real workflow.
- Evidence appears where decisions happen.
- AI permissions are bounded by authority and review rules.
- Complexity is translated into usable product behavior.
Go Deeper
Use the full framework when the domain needs more care.
The core brief is intentionally lightweight. The supporting materials add examples, evaluation criteria, positioning, and future-facing notes for teams that need a stronger shared model.
Core framework
Use these materials to create a brief, compare AI outputs, and see how the method applies to concrete product worlds.
Positioning and direction
These notes explain where Domain Context Modeling sits relative to adjacent disciplines and how the framework may evolve.
Put It To Work
Turn the brief into better product output.
A Domain Context Brief becomes useful when it travels downstream: into product specs, interface design, implementation planning, agent instructions, and review criteria.
Write the brief before the spec.
Clarify the domain, important concepts, rules, sources of truth, and AI authority boundaries before asking for product output.
Use it as persistent context.
Keep the brief close to the work so product, design, engineering, and AI agents share the same vocabulary and constraints.
Translate it by audience.
Turn the same domain model into user-facing labels, admin controls, engineering models, agent rules, and review gates.
Evaluate the output.
Compare conventional AI output against domain-context output for concept clarity, source handling, action safety, product usefulness, and domain empathy.