Write Better Prompts by Defining Evidence and Output

A useful prompt does not begin with a broad request such as “be accurate.” It defines what the model should do, which information it may use, what it should say when the evidence is insufficient, and what the final answer must look like. This guide turns those ideas into a practical pattern for summaries, internal reviews, research workflows, and first drafts.

The four parts of a reviewable prompt

OpenAI recommends making the task clear, providing relevant context, and specifying the desired tone or style in its prompting guidance. A practical prompt can therefore be divided into four parts:

1. Task: State the action, such as summarise, compare, classify, or extract.
2. Permitted evidence: Name the documents, links, or data the model may use.
3. Unsupported-information rule: Tell the model to state that the evidence is insufficient instead of guessing. Google’s guidance recommends restricting factual claims to supplied or authorised sources and returning an insufficiency statement when support is missing in its prompt design guidance.
4. Output format: Specify fields, order, length, tone, and any examples the answer should follow.

This structure is not a guarantee that every response will be correct. It is a way to make the scope, boundaries, and review requirements easier to inspect.

Separate instructions from context

When instructions and the material to be analysed are mixed into one paragraph, it can be harder to tell what should be followed and what should be treated as reference material. OpenAI’s prompt-engineering practices recommend separating instructions from context and describe using examples to show the desired output format in its techniques guide.

Editorial recommendation for this template: use stable labels or delimiters such as <task>, <evidence>, and <output>. Treat these labels as an organisational choice, not as a special security boundary. Their purpose here is to help the writer and reviewer distinguish the parts of the prompt.

Write an explicit rule for missing evidence

“Be accurate” does not define what accuracy means or what action to take when the available material does not answer the question. A practical rule for this article’s template is: “Use only the attached evidence or explicitly authorised sources. Tie every factual point to its location in the evidence. If the evidence does not support the answer, write: ‘Not stated in the provided evidence.’”

This approach follows the recommendation to restrict factual claims to permitted sources and to state when support is unavailable described by Google. It is an editorial design rule, not a guarantee that a model will always follow the instruction. Make evidence checking part of the final review rather than relying on the prompt alone.

Define the deliverable before sending the prompt

Instead of asking for “a good summary,” specify the number of points, fields, length, audience, and tone. For example: “Return five bullets, then a two-column table linking each claim to its evidence location, followed by a one-sentence limitations note.” Google recommends structured sections, grounding constraints, source citation, and explicit output formats in its published prompting strategies.

Practical recommendation: add a short example when the shape of the answer is important. An example shows the pattern, but it should not become an unverified fact about the source document. For instance, show “claim: … / evidence: section …” and leave the actual values to the supplied material.

When to use Structured Outputs or JSON Schema

In software workflows, you can use Structured Outputs when the feature is available. OpenAI says that Structured Outputs can make a response conform to a supplied JSON Schema in its feature announcement. The same source also states that schema compliance does not prevent mistakes in the values inside the schema in that announcement.

Keep two questions separate: did the response use the required shape, and is each value supported by evidence? A schema can address the first question; the second still requires evidence review. Design inference for this article: if the answer will feed another system, consider making a field such as evidence_location mandatory in your design, then test what happens when no suitable location exists.

A practical template for small businesses

Copy the following pattern and replace the material between the sections:

<task>
Summarise the attached policy for small-business owners.
</task>

<evidence>
Use only the document below. For every factual point, add the document section
or page. If the answer is not supported, write: “Not stated in the provided evidence.”
</evidence>

<output>
Return: 1) five bullet points, 2) a two-column table linking each claim
to its evidence location, and 3) one short limitations note. Do not add outside facts.
</output>

Editorial note: the number of bullets, field names, and insufficiency wording above are choices in this template, not universal requirements. Adapt them to the task, but keep an explicit unsupported-information rule when traceability is important.

A quick review checklist

• Does the task state the action and intended audience?
• Have you named the permitted evidence instead of simply saying “research it”?
• Is there a clear instruction for missing support?
• Does every factual claim have a reviewable evidence location?
• Are the fields, length, tone, and order easy to check?
• If you used JSON Schema, did you review the values themselves?

The central idea is simple: write a prompt as a definition of scope, evidence rules, and delivery format—not as a general request for quality. Clear boundaries make it easier to identify what needs review and what the supplied evidence does not support.