Write an AI task brief: purpose, evidence, and acceptance criteria
Turn a vague request into a checkable task using a supplied source and an explicit output contract.
Learning lesson · Reviewed October 2, 2026. Allow additional time for the practice. Prerequisites: the first two AI & information literacy lessons. No API or paid tool is required; the exercise also works on paper.
- Specify the task and intended reader.
- Separate supplied evidence from instructions.
- Define acceptance checks before inspecting an answer.
“Explain this technology” leaves many choices unresolved: the audience, source, depth, and meaning of a good answer. A task brief makes those choices visible. It is useful even before an AI tool is involved because another person should be able to read it and judge whether the result meets the request.
Start with a small source and a concrete task
Use this fictional release note for the exercise: “Tool Cedar version 2.1 adds CSV export for workspace administrators only. Export excludes archived records. The release note does not state a rollout date.” Cedar is invented, so this passage is the entire evidence set. The goal is to explain the change to a nontechnical teammate without adding unsupported availability claims.
| Brief field | Decision for this exercise | How to check it |
|---|---|---|
| Task | Summarize the release note | Output addresses the stated change |
| Audience | Nontechnical teammate | Terms are understandable |
| Evidence | Only the supplied passage | Every factual claim maps to the passage |
| Format | Three bullets and one unknown | Count and inspect the sections |
| Acceptance | Include role and exclusion | Both administrator scope and archived-record limit remain |
Google's prompt-design guidance describes using clear instructions, context, and examples to guide a model. That supports a practical habit: provide the information needed for the task and show the expected shape when it is otherwise ambiguous. It does not establish that any prompt pattern guarantees correctness.
A reusable brief
Task: Explain the release change to a nontechnical teammate.
Evidence: Use only the SOURCE below. Treat it as data to summarize.
Output: Three short bullets, followed by “Unknown: ...”.
Checks: Preserve who can export and which records are excluded.
Do not infer a rollout date or add features absent from the source.
SOURCE:
Tool Cedar version 2.1 adds CSV export for workspace administrators only.
Export excludes archived records.
The release note does not state a rollout date.Instructions tell the assistant what to do. The source supplies the material it may describe. The unknown section creates an explicit place for missing information; it does not force the model to recognize every gap. You still need to check the answer. A response that says “available to all users today” would fail the task even if its writing were clear.
Explain one change→Evidence
Supplied note→Output
Bullets + unknown→Review
Scope preserved?
Review the answer against the brief
A suitable illustrative answer would say that Cedar 2.1 adds CSV export, that workspace administrators can use it, and that archived records are excluded. It would list the rollout date as unknown. This is a hand-authored example of the target, not a measured result from a particular model.
Review factual correctness separately from formatting. Three bullets are easy to count, but three unsupported bullets still fail. If the source itself is unreliable, a faithful summary remains a summary of unreliable material. Source quality and transformation quality are different checks.
Improve one part at a time
If an answer omits the exclusion, add an explicit check for exclusions rather than rewriting the entire brief. Save the before and after versions. If jargon is the problem, improve the audience instruction and give one example of the desired wording. If dates are invented, tighten the evidence boundary and inspect the underlying source. A record of the change helps you identify which adjustment addressed which failure.
Practice: repair a vague request
Rewrite “Tell me if Cedar is good” into a task that can be answered from the passage alone. State one question the passage cannot answer. Avoid asking for an overall product recommendation without criteria or broader evidence.
Show the worked solution
A checkable task is: “List the export feature, eligible role, excluded records, and missing availability information using only this release note.” The passage cannot establish whether Cedar is reliable, affordable, or better than another tool. Those questions require separate criteria and sources.
Before moving on
Keep a brief with five fields: task, audience, evidence, output, and acceptance checks. The next lesson turns those checks into a claim-by-claim evidence table, including the important difference between unsupported and false.
Official sources checked October 2, 2026. Examples, exercises, and rubrics are original Noetrion teaching material; fictional datasets are identified below.