The Anatomy of a High-Quality AI Request: Goal, Context, Constraints, Sources, and Success Criteria
Replace prompt folklore with a five-part request specification that makes AI work testable, source-bounded, and easier for humans to review.
A high-quality AI request states five things: the goal, the decision context, the constraints, the permitted sources, and observable success criteria. Add examples or a required process only when they clarify one of those elements. No wording technique can compensate for a missing evidence base or an undefined task. Clear requests cannot supply missing knowledge, eliminate model errors, or make an unsuitable task safe.
Prompt quality begins before the prompt
Many “prompt engineering” examples improve the sentence while leaving the work vague. “Act as a world-class strategist and give me insights” offers status language but no decision, evidence boundary, or test.
Provider guidance consistently recommends clear instructions, relevant context, and examples or structured requirements where useful. openai, anthropic, nist, helm NIST adds the missing organizational perspective: the task, context, measurement, and accountability must be mapped. nist
This article is for people using AI in research, analysis, writing, learning, or operations. It is not a catalog of product-specific syntax.
The five-part specification
1. Goal
Name the artifact or change you need, not the topic you want the model to discuss.
Weak: “Analyze our interviews.”
Stronger: “Identify the three most consequential onboarding obstacles in these twelve transcripts and produce an evidence table for a product decision.”
2. Context
Explain the intended user, decision, prior work, and definitions that change what a good answer means. Context is not an indiscriminate document dump. Include what is relevant and label its authority.
3. Constraints
State boundaries: length, format, audience, prohibited assumptions, privacy rules, tools, deadline, or when the system must stop. Constraints should protect the task, not merely decorate the output.
4. Sources
Say what evidence is permitted and what must be cited. Distinguish supplied facts from material the model may search for. For high-stakes claims, require opened primary sources and forbid invented gap filling.
5. Success criteria
Define what a reviewer can observe: complete field coverage, traceable quotations, correct calculations, explicit uncertainty, or adherence to a schema. Criteria make iteration empirical.
The request card
| Field | Example for a policy comparison | |---|---| | Goal | Produce a decision table comparing retention terms | | Context | Procurement counsel will use it to shortlist vendors | | Constraints | Do not infer absent terms; mark “not found” | | Sources | Only the six linked current policy pages | | Success | Every row has a passage, URL, access date, and uncertainty note |
Add a final behavior: “If a source is inaccessible or ambiguous, stop that row and state what a human must resolve.”
Evidence for the diagnosis: the Five-Part AI Request Specification
Official and practitioner guidance supports explicit instructions, context, examples, and evaluation. Independent evaluation research shows why performance must be measured across scenarios and metrics rather than inferred from one attractive output. The five-part anatomy is an editorial synthesis for knowledge work; no evidence shows that one universal prompt template produces reliable results across models and tasks.
openai, anthropic, nist, helmSpecify process only when process matters
Sometimes you need an outcome; sometimes you need an auditable path. For a rewrite, the output may be enough. For a research claim, require a claim-to-source table. For a calculation, require a deterministic tool and preserved inputs.
Avoid demanding hidden internal reasoning. Ask instead for inspectable artifacts: assumptions, source passages, calculations, alternatives, uncertainty, and a concise rationale. These can be checked without pretending a generated explanation reveals the model's true internal process.
A before-and-after example
Before
Write an authoritative report about whether our company should use AI.
After
Goal: produce a two-page decision brief on whether the customer-support team should pilot AI-assisted reply drafting. Context: the decision owner is the support director; no autonomous sending is in scope. Constraints: use no customer data, distinguish drafting from approval, and compare the status quo with one bounded pilot. Sources: use the attached ticket-volume table and the linked NIST framework; label any other claim as an inference. Success: include a task map, three failure modes, measurable pilot criteria, a stop rule, and unresolved questions. If the evidence cannot support a recommendation, recommend the next evidence-gathering step.
The second request does not guarantee a good decision. It creates something a reviewer can inspect.
Write the five-part specification
Take one recurring task:
- Write the decision the output will inform.
- Name the user and the artifact.
- Separate mandatory constraints from preferences.
- List approved sources and missing evidence.
- Define three pass conditions and two blockers.
- Run the request on routine and adversarial examples.
- Revise the specification based on observed failures, not stylistic taste.
Compare with Prompting for Learning when the goal is skill acquisition. Preserve the request state using Why AI Answers Change, then review with the Four-Layer Quality Model.
Prompt rituals that conceal a weak task
- Assigning an impressive persona without defining expertise or evidence.
- Asking for “no hallucinations” instead of requiring source verification.
- Supplying massive context without hierarchy or provenance.
- Requesting a confidence percentage that has not been calibrated.
- Optimizing wording before creating representative test cases.
- Treating formatting compliance as substantive accuracy.
- Asking the model to decide when the organization has not named its values.
What a better request cannot repair
A precise request cannot create inaccessible facts, reliable ground truth, lawful authority, adequate model capability, or a responsible organizational process. Models may ignore instructions, tools may fail, and supplied sources may be wrong. Product-specific prompting behavior changes, so any provider detail must be checked immediately before publication or deployment.
Good prompting is less like casting a spell and more like writing a small, falsifiable brief for a collaborator whose output must still be checked.
Named sources
Evidence and further reading
Published July 29, 2026. No substantive revision has been recorded. Evidence last verified July 28, 2026.