The problem
"Summarize this report in a professional manner." It seems like a reasonable prompt, but it is also a contract vague enough to fail in multiple ways: the model might summarize too aggressively and omit a critical metric, use formatting inconsistent with the broader document, or interpret "professional" in a way completely misaligned with the user's intent. None of these outcomes represent an intrinsic model failure — they stem from a prompt that failed to define what constitutes success.
A production prompt is not a polite conversational instruction relying on good faith. It is an engineering contract: explicit acceptance criteria, deterministic format definitions, and structured subtasks that form the final deliverable. Architecture scenarios test precisely this skill — not whether you can write grammatically eloquent prose, but whether you can convert ambiguous business requests into testable, verifiable contracts.
Define evaluation criteria before writing the prompt
Sequence matters: define how you will verify whether the output is correct before writing the generation instructions. If you cannot articulate the acceptance criteria upfront, the prompt will inevitably inject ambiguity into the model's response.
Actionable evaluation criteria are specific and verifiable: "the summary preserves all numerical metrics cited in the source document" is verifiable. "The summary is well-written" is not. A verifiable criterion also functions as an automated test case — allowing programmatic verification against ground truth without recurring human subjectivity.
Decompose into verifiable subtasks
An ambiguous task is rarely a single unit of work — it is multiple tasks bundled together without clear boundaries. "Analyze these sales figures and tell me what to do" bundles at least three distinct subtasks: extracting relevant figures, identifying mathematical trends across those figures, and recommending strategic actions based on the identified pattern.
Decomposing complex requests provides two major architectural benefits:
- Isolated verification: Each subtask is bounded enough to have its own independent acceptance criteria. "Extracted numbers match source records" is objectively verifiable, making the downstream recommendation easier to evaluate once the data substrate is proven sound.
- Exposing uncertainty: Decomposition pinpoints where cognitive uncertainty actually lives. Extraction is mechanical and deterministic; final strategic recommendation involves judgment requiring explicit heuristics or human review.
Concrete examples anchor judgment standards
Abstract instructions ("be concise", "use a formal tone") leave the boundary calibration to the model, which often diverges from your expectations. Including one or two representative few-shot examples demonstrating the exact output structure and reasoning standard anchors behavior far more reliably than descriptive adjectives.
Examples provide the highest leverage where qualitative nuance is difficult to formalize — demonstrating a "firm yet collaborative tone without passive-aggressive phrasing" communicates in two lines what would take paragraphs of prompt instructions to describe, while eliminating interpretive drift.
The common distractor
A classic scenario distractor suggests "rewriting the prompt with clearer phrasing" when the actual root cause is missing source data or the absence of automated assertion checks. Polishing prompt phrasing cannot fix missing reference context or non-verifiable specifications. Before modifying prompt text, diagnose whether the failure stems from instruction clarity, data availability, or an underspecified contract.
Put it into practice
This lesson's lab implements a prompt contract validator: given a set of acceptance criteria and candidate model completions, it evaluates passing assertions and flags when task decomposition leaves critical requirements unverifiable — the exact mental framework you will apply when converting ambiguous scenario requirements into robust prompt contracts.