Core Domain Identification and Prioritization Prompt

This prompt is designed for technical leaders, principal engineers, and domain architects who need to move beyond intuition when allocating scarce engineering resources. It takes a list of candidate domains and your business strategy context, then produces a ranked, evidence-backed prioritization with complexity scores, differentiation assessments, and build-vs-buy signals. The output is a decision artifact you can take into a funding conversation or architecture review, not a vague suggestion. Use this before committing a team to a multi-quarter domain investment, during architecture modernization planning when you need to separate core from supporting work, or when aligning technical investment with an updated business strategy. This is a strategic analysis prompt, not a code-level review tool. It assumes you already have a working understanding of Domain-Driven Design concepts such as Core, Supporting, and Generic subdomains.

The prompt works best when you provide concrete, honest inputs. Vague strategy statements like 'we want to be the best' produce vague rankings. Instead, supply specific differentiators your business actually invests in—speed of onboarding, regulatory compliance depth, pricing model innovation, supply chain visibility—and list the candidate domains with a sentence of context each. The prompt will cross-reference each domain against your strategy, assess whether the domain is truly differentiating or just necessary table stakes, estimate implementation complexity, and flag domains where buying or adopting open-source is the rational choice. The output schema enforces a structured ranking with explicit rationale per domain, so you can trace every recommendation back to the evidence you provided. If you cannot articulate your business strategy clearly enough to fill the [BUSINESS_STRATEGY] placeholder, stop and resolve that ambiguity before using this prompt—the model cannot invent your strategy for you.

Do not use this prompt when you need a detailed technical design of a single domain, when you are reviewing code-level implementation quality, or when the list of candidate domains is already narrowed to one. This prompt is for comparative prioritization across multiple domains. After you receive the ranked output, validate it against your own knowledge: if the top-ranked domain surprises you, investigate whether the prompt surfaced a blind spot or whether your strategy input was incomplete. The next step is typically a deeper bounded context design review or a build-vs-buy decision memo for the highest-priority domains. Avoid the temptation to accept the ranking without scrutiny—this prompt accelerates judgment, it does not replace it.

The following prompt template is designed to be pasted directly into your AI workspace. It instructs the model to adopt the role of a domain architect and produce a structured, ranked analysis of business domains based on competitive differentiation, complexity, and strategic value. Replace every square-bracket placeholder with your specific business context, strategic goals, and known domain inventory before execution. The prompt enforces a strict output schema, requires evidence for each ranking decision, and includes explicit constraints to prevent generic or unsupported recommendations.

textCopy
You are a domain architect specializing in Domain-Driven Design and strategic portfolio analysis. Your task is to identify, classify, and prioritize the business domains for the following organization, producing a ranked list that distinguishes core domains (source of competitive advantage) from supporting and generic domains.

## INPUT
[ORGANIZATION_DESCRIPTION]
[STRATEGIC_GOALS]
[KNOWN_DOMAINS_OR_CAPABILITIES]
[COMPETITIVE_LANDSCAPE]

## OUTPUT_SCHEMA
Return a valid JSON object with the following structure:
{
  "analysis_summary": "string (2-3 sentence executive summary)",
  "domains": [
    {
      "domain_name": "string",
      "classification": "Core | Supporting | Generic",
      "differentiation_score": number (1-10),
      "business_impact": "High | Medium | Low",
      "complexity_score": number (1-10),
      "investment_recommendation": "Build | Buy | Outsource | Partner",
      "rationale": "string (evidence-based justification)",
      "key_capabilities": ["string"],
      "risks_if_neglected": ["string"]
    }
  ],
  "strategic_recommendations": ["string"],
  "confidence_assessment": {
    "overall_confidence": "High | Medium | Low",
    "areas_requiring_validation": ["string"]
  }
}

## CONSTRAINTS
- Classify each domain strictly as Core, Supporting, or Generic. Core domains provide direct competitive differentiation. Supporting domains enable core domains but are not differentiating. Generic domains are commodity capabilities.
- Assign differentiation scores based on how uniquely the organization performs this capability versus competitors, not on how important the capability is.
- Investment recommendations must consider build-vs-buy trade-offs: recommend "Build" only for true core domains where off-the-shelf solutions would erode competitive advantage.
- Every rationale must reference specific evidence from the provided inputs. Do not invent capabilities or market positions.
- If the provided inputs are insufficient to classify a domain confidently, flag it in `areas_requiring_validation` and assign a lower confidence score.
- Rank domains by strategic priority: core domains first, then supporting, then generic.
- Do not recommend outsourcing or partnering for domains classified as Core unless the organization explicitly lacks the capability to build and cannot acquire it within the strategic timeframe.

## EVALUATION CRITERIA
A valid output must satisfy all of the following:
1. Every domain in the input is addressed or explicitly noted as excluded with a reason.
2. No two domains share identical rationale text.
3. Differentiation scores correlate with classification: Core domains must score 7 or higher.
4. At least one domain is classified as Core unless the organization description explicitly describes a commodity business.
5. Investment recommendations are consistent with classification: no "Buy" recommendation for a Core domain without explicit justification.

After pasting this template, replace each placeholder with concrete, specific information. The [ORGANIZATION_DESCRIPTION] should include the company's industry, size, product lines, and revenue model. The [STRATEGIC_GOALS] should capture the 12-24 month strategic priorities. The [KNOWN_DOMAINS_OR_CAPABILITIES] should list existing business capabilities, departments, or systems you are aware of. The [COMPETITIVE_LANDSCAPE] should describe key competitors and how they differentiate. The more specific your inputs, the more actionable the output. Avoid vague descriptions like "we are a tech company" — instead describe what you build, who you serve, and how you win deals. If you lack complete information for any section, note what is missing rather than omitting the section; the model will flag gaps in the confidence assessment.

This prompt is not a one-off brainstorming tool. It is a decision-support instrument that should be wired into an architecture review workflow where outputs are versioned, compared, and challenged. The implementation harness must treat the model output as a draft recommendation, not a final decision. The prompt expects structured inputs about business strategy, current system landscape, and team capabilities. Before calling the model, assemble these inputs from source documents (strategy memos, architecture diagrams, team surveys) rather than relying on a single person's recollection. The harness should log every input snapshot alongside the output so that domain prioritization decisions remain traceable six months later when strategy shifts.

Validation and retry logic is critical because the output schema includes ranked lists, numeric scores, and structured justifications. Implement a post-generation validator that checks: (1) all domains in the input appear in the output with no additions or omissions, (2) complexity and differentiation scores fall within the declared ranges, (3) investment recommendations use only the allowed enum values, and (4) the ranking is internally consistent with the scores. If validation fails, retry with the error details injected into [CONSTRAINTS] as a correction instruction. Set a maximum of two retries before flagging for human review. For model choice, prefer a model with strong reasoning capabilities (such as Claude 3.5 Sonnet or GPT-4o) because the task requires trade-off analysis across multiple dimensions. Avoid small or fast models that may produce plausible-looking but logically inconsistent rankings.

Human review gates should be mandatory before any domain investment decision is made. The harness should present the ranked output alongside the input context in a review interface that allows architects to adjust rankings, override scores, and annotate rationale. Log every human modification separately from the model output so that the provenance of each decision is clear. For teams running this analysis quarterly or during strategy cycles, store each run as a versioned artifact and diff the results against the previous run to surface shifts in domain priority. Avoid wiring this prompt directly into automated resource allocation or budgeting systems. The output is a decision aid, not a decision engine, and the gap between a ranked list and a funding commitment requires human judgment about organizational readiness, market timing, and team morale that no prompt can capture.