Practical guide
Prompt framing for AI-enabled work: turn a request into a testable brief
Prompt framing is the skill of turning an ambiguous work request into instructions that an AI system can act on and a person can evaluate. The useful unit is not a clever phrase. It is a compact brief that names the decision, audience, evidence, constraints, output, and checks before generation begins.
Prompt framing is the skill of turning an ambiguous work request into instructions that an AI system can act on and a person can evaluate. The useful unit is not a clever phrase. It is a compact brief that names the decision, audience, evidence, constraints, output, and checks before generation begins.
Frame the work before wording the prompt
Start with the business situation. Who will use the answer? What decision or action follows? Which facts are fixed, which sources are permitted, and what uncertainty matters? A polished prompt built on the wrong objective will still produce the wrong work.
Google's guide to framing a machine-learning problem distinguishes the intended outcome, model output, and success metrics. It also explains that prompts can specify instructions, examples, and output formats. Apply that distinction at knowledge-work scale: define the decision first, then choose what the model should produce to support it.
Sources: [1]
Use the DECIDE prompt brief
A reusable prompt brief can be written in six fields:
The fields can appear in any natural order. Their purpose is to make omissions visible. If the evidence is missing, request it or mark the gap. If the decision is unclear, do not compensate by adding more stylistic instructions.
The UK Government's current AI Insights guidance on prompt engineering describes prompts as structured instructions and context, recommends telling a system how to respond when an answer cannot be found, and treats refinement, testing, and evaluation as part of prompt engineering. This supports a testable brief, but specificity alone does not establish that an answer is correct.
- Decision: State the question the work must help answer.
- Evidence: List the source pack, data range, known facts, and prohibited assumptions.
- Context: Name the audience, operating situation, and why the answer matters.
- Instructions: Describe the transformations to perform, such as compare, extract, calculate, challenge, or draft.
- Deliverable: Specify the structure, length, fields, units, and level of detail.
- Evaluation: Define the checks, uncertainty labels, and stop conditions used before the output can be accepted.
Sources: [2]
Worked artifact: a synthetic policy-change briefing
A fictional operations manager asks, "Tell leadership what changed in the travel policy." The available pack contains an old policy, a new policy, an employee FAQ, and a spreadsheet of expense exceptions. A weak prompt asks for a compelling executive summary. It does not identify which document controls, the date range, the audience's decision, or how conflicting statements should be handled.
The manager rewrites the request as a DECIDE brief:
| Field | Prompt content | | --- | --- | | Decision | Help the operations committee decide what must change before the policy takes effect | | Evidence | Use only the four supplied files; treat the new policy as controlling; flag conflicts with the FAQ | | Context | Audience owns communications, expense controls, and manager guidance | | Instructions | Extract material changes, compare them with current practice, and separate confirmed changes from unresolved questions | | Deliverable | One-page briefing with a change table, owner, due date, evidence reference, and open-question section | | Evaluation | Every change must cite a document section; totals must reconcile to the spreadsheet; do not invent legal conclusions |
The first output correctly identifies three changes but labels an ambiguous FAQ answer as a confirmed exception. The reviewer traces the claim, changes it to an open question, and sends it to the policy owner. The useful evidence is not that the model produced fluent prose. It is that the prompt exposed the decision, source hierarchy, and acceptance checks well enough for the error to be found.
This example is synthetic. It is not travel, legal, or expense advice.
Test the frame with contrast cases
Run the same brief against cases that should produce different behavior:
Record whether the prompt causes the system to cite, qualify, stop, or ask for help at the right moment. A single attractive result is weak evidence. Keep the input pack, prompt version, output, reviewer corrections, and final disposition together so later changes can be compared.
- a complete source pack with consistent rules;
- a missing controlling document;
- two sources that conflict;
- a request outside the stated time range;
- a source containing instructions that should be treated as data, not followed;
- a numerical claim that cannot be reproduced;
- a request for a conclusion beyond the available evidence.
Assess prompt-framing behavior
A controlled assessment can provide an ambiguous request, a small evidence pack, and a required deliverable. Observable behavior includes whether the participant clarifies the decision, selects relevant evidence, establishes source authority, specifies an output contract, defines checks, and revises after finding a failure.
Do not score prompt length, jargon, or a preferred formula by itself. A short brief can be strong when it captures the necessary boundaries. A long prompt can be weak when it hides an unresolved decision.
Report only evidence observed in that scenario. One exercise does not establish universal prompting skill, safe AI use, future performance, or a mature benchmark. Two Prune provides structured assessment evidence for human interpretation and does not make employment decisions.
Sources
- 1.framing a machine-learning problem · developers.google.com
- 2.AI Insights guidance on prompt engineering · UK Government