Module 7 of 16 · 28 min

Prompt Anatomy and Success Criteria

Turn an ambiguous request into a clear, testable working agreement with an AI system.

Core concept

By the end

You will be able to

  • Separate a prompt's purpose, inputs, instructions, constraints, deliverable, and verification.
  • Define observable success criteria before generating an answer.
  • Distinguish hard requirements from preferences and examples.
  • Rewrite an ambiguous request as a reusable prompt template.
01

Start with the outcome and its user

A prompt is easier to follow when it names the outcome, the person who will use it, and the decision or action it should support. A topic such as “customer feedback” is not yet a task; “group these comments so the support lead can choose three fixes” is.

Purpose helps the model choose relevant detail, but it also helps the learner decide whether AI is appropriate. If the intended use is high impact, private, or irreversible, the prompt must include stronger evidence and review boundaries.

02

Name trusted inputs and explicit instructions

Identify the material the response may rely on and label its boundaries. Separate instructions from source text, examples, and user-supplied data so quoted material is not mistaken for a command.

Use ordered steps when sequence matters. State what to do with missing or conflicting inputs rather than allowing the system to silently invent a resolution.

Purpose-first prompt template
text
Purpose: [OUTCOME AND USER]
Inputs: [TRUSTED MATERIAL AND BOUNDARIES]
Instructions:
1. [FIRST REQUIRED ACTION]
2. [NEXT REQUIRED ACTION]
Constraints: [MUST, MUST NOT, PRIVACY, SCOPE]
Deliverable: [FORMAT AND DETAIL]
Verify: [CHECKS AND EVIDENCE]
If information is missing: [ASK, FLAG, OR STOP]
03

Make success observable

Success criteria describe what a reviewer can inspect: required fields are present, claims map to supplied evidence, calculations reproduce, links resolve, or a stated rubric is satisfied. “Make it excellent” does not identify an observable result.

Separate hard requirements from preferences. A hard requirement can fail the result; a preference guides style when it does not conflict with the required outcome.

04

Design for missing information and uncertainty

A useful prompt tells the system when to ask a question, state an assumption, identify uncertainty, or stop. This prevents a polished response from hiding an unsupported choice.

Prompting improves the odds of a useful response, but it does not guarantee truth. The prompt should name the verification that happens after generation.

Practice activity

Rewrite an ambiguous request

  1. Choose a vague request such as “summarize this,” “make a plan,” or “compare these tools.”
  2. Identify its user, intended decision, trusted inputs, hard constraints, and observable success criteria.
  3. Rewrite it with the purpose-first template and include behavior for missing or conflicting information.
  4. Ask another person to identify anything they would still have to guess.

What to produce

  • The original request and a completed prompt containing purpose, inputs, instructions, constraints, deliverable, verification, and missing-information behavior.
  • A short review listing at least one ambiguity removed and one remaining assumption.

Reflect before continuing

Which missing detail changed the task most when you made it explicit?

Evidence

Sources and verification

Knowledge check

Make it stick.

Pass at 80%

Choose the strongest answer for each question. Your attempts become part of your device-local transcript.

01Which request states the clearest purpose?
02Why should source text be separated from instructions?
03Which is an observable success criterion?
04What should a prompt do when required context is missing?
05Which statement about prompting is accurate?