Decision Options Enumeration Prompt

This prompt is for architects and technical leads who are facing a significant design decision and need to generate a comprehensive, unbiased catalog of possible paths forward before any evaluation begins. The core job-to-be-done is preventing premature convergence—the common failure mode where a team anchors on the first or most obvious solution without considering alternatives that might be cheaper, simpler, or more aligned with long-term goals. The ideal user has a well-defined problem statement, a set of known constraints (e.g., latency budget, team skills, compliance requirements), and a need for structured, traceable decision documentation that will feed into a formal Architecture Decision Record (ADR).

Use this prompt when the decision space is complex enough that a single person cannot easily enumerate all options from memory, or when team dynamics risk advocacy-driven selection before alternatives are surfaced. It is particularly valuable for build-vs-buy decisions, technology selection, service decomposition boundaries, and data architecture choices. The prompt requires a clear [PROBLEM_STATEMENT] and [CONSTRAINTS] block as input. Without these, the model will generate generic options that lack practical relevance. You should also provide a [CONTEXT] block with relevant system details, existing architecture, and stakeholder concerns to ground the enumeration in reality. The output is a structured catalog of options, each with a brief description, that can be directly fed into a trade-off analysis or ADR generation workflow.

Do not use this prompt when the decision is trivial, already made, or when you are deep into implementation and need a quick tactical fix rather than a strategic options review. It is also the wrong tool when you lack a clear problem statement—garbage in, garbage out applies here with force. If you skip directly to evaluation without first enumerating options, you risk missing the status-quo option (do nothing), the partial-adoption option, or novel combinations that don't fit neatly into existing categories. After generating the options catalog, the next step is typically to feed the output into an ADR Comparison Prompt for trade-off analysis or to use the catalog as the "Options Considered" section of a full ADR. Always review the generated options for coverage gaps—the model may miss domain-specific alternatives that require your team's specialized knowledge.

The prompt below is designed to be dropped into your AI harness with minimal adaptation. It forces the model to enumerate options across multiple categories—including the status quo, non-obvious alternatives, and composite approaches—before any evaluation begins. This prevents the common failure mode where a team converges on the first plausible solution without considering the full solution space.

textCopy
You are an experienced software architect helping a team enumerate architectural options before making a decision.

## CONTEXT
[CONTEXT]

## PROBLEM STATEMENT
[PROBLEM_STATEMENT]

## CONSTRAINTS
[CONSTRAINTS]

## INSTRUCTIONS
Generate a comprehensive catalog of architectural options for the problem described above. Your goal is breadth and coverage, not evaluation. Do not rank, score, or recommend any option.

For each option, provide:
- **Option Name**: A short, descriptive label.
- **Category**: One of [Status Quo, Established Pattern, Emerging Pattern, Non-Obvious, Composite, Do Nothing].
- **Description**: 2-4 sentences explaining the approach and how it addresses the problem.
- **Key Assumptions**: 2-4 assumptions this option depends on to be viable.
- **Novelty**: Whether this is a standard approach the team likely considered, or a less obvious alternative.

## COVERAGE REQUIREMENTS
You must include at minimum:
- The "Do Nothing" or "Defer" option.
- The status quo or "Continue Current Approach" option.
- At least one option that changes process rather than technology.
- At least one option that changes organizational boundaries or team structure.
- At least one option that the team is unlikely to have considered.

## OUTPUT FORMAT
Return a JSON object with this schema:
{
  "problem_summary": "One-sentence restatement of the problem.",
  "options": [
    {
      "name": "string",
      "category": "string",
      "description": "string",
      "key_assumptions": ["string"],
      "novelty": "Standard | Non-Obvious"
    }
  ],
  "coverage_check": {
    "do_nothing_included": true,
    "status_quo_included": true,
    "process_change_included": true,
    "org_change_included": true,
    "non_obvious_included": true
  },
  "missing_categories": ["List any coverage categories not met, or empty array if all met."]
}

## RISK LEVEL
[RISK_LEVEL]

If RISK_LEVEL is "high", add a "caution" field to each option noting what could go wrong if this option is chosen without further analysis.

To adapt this prompt, replace the square-bracket placeholders with your specific inputs. The [CONTEXT] field should include relevant system diagrams, existing ADRs, team structure, and any prior decisions that constrain the solution space. The [PROBLEM_STATEMENT] should be a crisp description of what needs to be decided, not a solution proposal in disguise. The [CONSTRAINTS] field should capture hard constraints like budget, timeline, regulatory requirements, team skills, and platform standards. Set [RISK_LEVEL] to "high" when the decision involves data integrity, security, availability, or compliance—this adds caution notes to every option. Before running this in production, validate the output JSON against the schema and check that coverage_check fields are all true. If any are false, re-prompt with explicit instructions to fill the missing categories. For high-risk domains, route the output to a human architect for review before it feeds into an ADR drafting workflow.

The Decision Options Enumeration Prompt is designed to be called early in an architecture decision process, before the team converges on a single path. In an application harness, this prompt should be triggered when a problem statement or decision context is submitted—typically from a design document, an ADR draft, or a structured form. The harness must supply the [PROBLEM_STATEMENT] and [CONSTRAINTS] placeholders from validated input fields. Do not call this prompt with vague one-liners; the quality of the enumeration depends directly on the specificity of the context provided. If the input is too thin, the harness should reject the request and prompt the user for more detail before invoking the model.

Wire the prompt into a pipeline that includes pre-validation, model invocation, output parsing, and coverage checks. Pre-validation should confirm that the problem statement exceeds a minimum length (e.g., 200 characters) and that constraints are explicitly listed. After the model returns the enumerated options, parse the structured output—expect a JSON array of option objects, each with name, description, category (e.g., build, buy, adopt, status-quo, hybrid), and non-obvious flag. Run a coverage validator that checks for at least one option in each relevant category and flags if the status-quo option is missing. If coverage is insufficient, trigger a single retry with a more explicit instruction to include overlooked categories. Log every invocation, the parsed option count, coverage gaps, and retry decisions for auditability.

For high-stakes architectural decisions, insert a human review gate after the enumeration is generated but before it feeds into downstream ADR drafting or comparison prompts. The review interface should display the full option catalog with category tags and allow the architect to add, remove, or reclassify options. Do not treat the model output as authoritative; it is a brainstorming accelerator. Avoid wiring this prompt directly into automated decision-making pipelines without review. The harness should also enforce a rate limit—architects should not re-run enumeration repeatedly on the same input without modifying the context, as this indicates either input quality issues or premature convergence pressure that the prompt alone cannot fix.