Prompt engineering is easy to demonstrate and harder to operationalise. A polished response to one ideal input can conceal failures on missing context, conflicting instructions or sensitive data. Training should make those cases visible before a prompt reaches production.
For a Dubai or UAE team, the practical outcome is a small, documented asset: a task definition, approved examples, a versioned prompt, acceptance criteria and a human escalation rule. None of those require uploading live customer records during class.
Evidence the course or workflow should provide
A measurable task definition
The learner should replace vague goals such as 'high quality' with observable requirements for audience, content, format and prohibited behaviour.
Observable evidence: A one-page task card reviewed before prompt drafting.A representative test set
Normal, edge and invalid inputs reveal whether the prompt is robust. At least one test should check insufficient context rather than reward confident guessing.
Observable evidence: A versioned set with expected properties for each case.A scoring rubric
Accuracy, coverage, structure, tone and safety need separate scores. A single preference vote does not locate the defect.
Observable evidence: A reusable rubric with pass thresholds.An experiment log
Changing examples, instructions and model settings at once destroys the explanation for improvement.
Observable evidence: Prompt version, model, settings, test input, score and reviewer note.A deployment boundary
The course should teach when the output needs a source check, domain review, privacy review or no automation at all.
Observable evidence: A written escalation matrix tested with a failure case.Ten-point output acceptance score
Score each dimension from zero to two. Treat eight as a candidate for human review, not a universal production guarantee.
| Dimension | 0 | 1 | 2 |
|---|---|---|---|
| Accuracy | Known error | Unverified claim | Matches approved evidence |
| Coverage | Core need missed | Partial response | Required elements complete |
| Format | Unusable | Manual repair needed | Contract followed |
| Voice | Off-brand | Inconsistent | Voice guide followed |
| Safety | Boundary breached | Ambiguous | Safe refusal or escalation |
How to apply this guide
- Capture a baselineRun five cases with a minimal instruction and record the defects before optimising.
- Change one variableState a hypothesis, such as an example reducing format errors, and test that change alone.
- Promote failures into regression testsA bad output is useful when it becomes a permanent test rather than a discarded anecdote.
- Separate prompt done from work doneSource checks, privacy review and accountable approval still belong to the surrounding workflow.
Failure modes to avoid
- Template collectingA copied prompt is an untested hypothesis in a new context.
- Taste-only gradingPreference without criteria does not make quality reproducible.
- Model driftA prompt that passed once should be rechecked after material model or workflow changes.
Official and primary sources
Practise the full loop, not just the wording
Review the AI Foundations path and judge its exercises with this acceptance score before enrolling.
Review AI Foundations