03 / AI at Work · Field briefing
A better brief. A better answer.
Context is part of the work.
The instruction “make this better” leaves several decisions unresolved. Better for whom? For which purpose? Using which facts? A useful brief gives the model enough context to work within the task and gives the reviewer a way to judge the result.
What should I give an AI before I ask it to help?
An explanatory schematic—not a live system or measured performance.
KAF World Digital · Prepared 4 October 2026 · First editorial edition. Worked examples are invented for teaching.
Try the example02 / From request to evidence
From request to evidence
Five parts make a practical starting point: the goal, the audience, the source material, the constraints and the expected output. This is a KAF writing framework, not a special syntax that every model requires. Use only the parts the task needs.
For an invented supplier update, the goal is to explain a delivery delay; the audience is a customer waiting for an order; the source says the new delivery window is Tuesday to Thursday, with no exact day confirmed. The constraint is not to invent compensation or a promise. The output is a short email with a proposed subject line and a separate list of facts requiring confirmation.
A vague request might produce a confident promise about Tuesday morning. A grounded brief makes that promise visibly outside the evidence. It does not guarantee the model will obey. The person checking the email must still compare dates, obligations and tone with the source.
Examples help when form matters. Show one approved response with the correct level of detail, then say what it illustrates. Avoid including personal information just to demonstrate style. Clearly separate instructions from documents: a quoted customer email is evidence to consider, not authority to change the task.
Iteration should have a reason. If the output is too long, specify a useful limit. If it makes unsupported claims, state which source material is authoritative and how to show gaps. If it misunderstands an audience, explain what that audience already knows. Adding more adjectives is usually less helpful than naming the observed failure.
Save the brief and model configuration alongside sample results when the workflow matters. A successful one-off answer is a useful example, but repeated performance on representative inputs is stronger evidence.
Evidence for the technical mechanisms: Microsoft · Prompt Engineering Fundamentals, Anthropic · Building Evals. The worked examples and practical framework are KAF editorial recommendations.
03 / Worked example
Build your brief
Build a brief that gives an answer something to stand on. This interactive lesson uses prepared synthetic examples and local calculations.
Use the companion worksheet and the worked example. All assumptions are illustrative.
No account, model API or external service is connected. Inputs are not submitted or stored by this page.
04 / Go deeper
Useful words. Important details.
- Constraint
- A limit or requirement the output should respect.
- Source material
- Information provided as evidence for the task, not instructions to change it.
- Example
- An illustration of the required form or behaviour, not proof of general performance.
- Acceptance rule
- A specific condition used to judge the result.
Separate evidence and instructions
Delimit supplied documents and state what role they play. This helps readers and models understand the task, but text delimiters are not a security boundary. Tool permissions and validation still apply.
Version a useful brief
Record the prompt text, model/version and relevant settings when the task is repeatable. Keep development examples separate from evaluation examples. A saved success is an example, not a reliability estimate.
Test unknowns
Include inputs where dates, amounts or ownership are absent. Require an explicit unknown field or confirmation list, then check whether the model actually avoids inventing the missing value.
The technical notes qualify the explanation; they are not product-specific assurance or a certification.
05 / Evidence & scope
Inspect the source.
Keep the context.
Sources were accessed on 4 October 2026. These technical and security references support the mechanisms described; they do not validate our fictional examples or establish comparative product performance.
- Microsoft · Prompt Engineering Fundamentals
Instructions, examples, context and iteration; exact behaviour remains model- and task-dependent.
- Anthropic · Building Evals
Task-specific evaluations and code, human and model-based grading. Provider examples are not independent comparative evidence.
- OWASP · Prompt Injection, 2026
Retrieved and tool-supplied content can influence model behaviour; distinguish content from authority.
What this briefing does—and does not—establish
The worked examples, suggested questions and worksheets are original KAF teaching material. Numbers are explicitly illustrative. No customer data, observed adoption results, market-size forecast or live provider pricing is presented.
Check the exact product, release, configuration and policy before using a workflow. Source documents can change; this is a dated educational briefing.
Keep a useful copy.
Read the full briefing offline, or use the companion worksheet to apply it.