Lesson 3 · AI Foundations
Prompting with purpose
- Length
- 26 minutes across 7 sections
- You will be able to apply
- The Six Slots
- You will produce
- Build the Studio Assist prompt contract · Commit Statement
- You will work
- 3 gated questions
Personalize the practice
Apply this to your environment
These details adapt the application prompts and coach questions. They do not affect your score.
What is the model currently having to guess?
Core question
workbench
Build the Studio Assist prompt contract
Required practiceThe team approved a human-reviewed complaint summary, but its current prompt is only: summarize this ticket professionally. Draft the operating contract before reading the six-slot method. This work carries with the Studio Assist case.
A prompt is an instruction given to a system that will not ask you a clarifying question. Everything you leave unsaid, it fills in with the most statistically ordinary alternative it can find. That is the entire mechanism behind most disappointing outputs: not that the model was weak, but that it was guessing, and guessing plausibly.
Prompting well is therefore not a matter of phrasing or of tricks. It is a matter of removing guesses one at a time and knowing which one you removed, so that when the output improves you can say why.
The pathology: Volume Substitution
The output comes back generic. The instinct is immediate and almost universal: add more. More context, more adjectives, more emphasis, a longer description of what you want. The prompt doubles in length. The output changes, sometimes for the better, and nobody can say which addition did it.
The alternative is to treat a prompt as a structure with named slots, and to change exactly one slot at a time. That constraint feels slow for the first two attempts and is faster by the fourth.
The Six Slots
Definition
A working prompt fills six slots: the task, the context, the audience, the constraints, the evidence boundary, and the output contract. The task is the verb. The context is what the model could not know. The audience is who reads the result. The constraints are what must be true of the answer. The evidence boundary states what the model may use and, critically, what it must do when it does not know. The output contract is the shape of the response you will accept.
Iteration means changing one slot and observing. It does not mean adding a sentence and hoping.
When to Use It
Use the full six for any prompt that will be run more than once, run by more than one person, or run against work that matters. A one-off exploratory question does not need six slots: it needs a question. The moment you find yourself re-running a prompt with variations, you have crossed into work that deserves structure.
The evidence boundary slot is not optional at any level of stakes. It is the only slot that changes what happens when the model does not know something.
How to Apply It
- Write all six slots before generating anything, leaving a slot visibly empty rather than silently absent.
- State the audience as a person with a purpose, not as a category.
- Put the evidence boundary in the imperative: use only what is supplied, and mark anything you cannot support rather than filling it in.
- Change exactly one slot per iteration and keep the previous version, so an improvement can be attributed.
Determine which slot the model is currently guessing.
- Identify the empty slot
- Determine which slot the model is currently guessing.
- Fill one slot
- Write the specification for that slot only.
- Generate and observe
- Run the prompt and note what changed in the output.
- Attribute the change
- Record which slot carried the improvement or revealed a new gap.
| Slot | Guessed when absent | What to write instead |
|---|---|---|
| Task | A generic version of the verb | Summarise, compare, classify, draft, extract, with the object named |
| Context | A plausible industry default | The specific situation, product and constraint the model cannot infer |
| Audience | A general adult reader | The one person who reads it and the decision they make next |
| Constraints | Whatever length looks conventional | Length, tone, what must appear, what must not appear |
| Evidence boundary | Anything from training data, presented as fact | Use only the supplied material and mark unsupported statements |
| Output contract | Prose of arbitrary shape | The exact sections, fields or format you will accept |
Worked example 1 of 3
Jo Halvorsen at OmniCorp Studio needs a launch email for a client. The first attempt is a single line: write a launch email for our client's new booking feature. What comes back is competent, empty and unusable.
- Jo Halvorsen
- Do not add anything yet. Which slot is empty?
- Designer
- Audience. We never said who reads it.
- Jo Halvorsen
- Then change only that. Existing customers who already book by phone and have never used the app.
- Designer
- Better. It is speaking to someone now. Still too long and it invented a discount.
- Jo Halvorsen
- Two slots left, one at a time. Constraints first: one hundred and twenty words, one call to action. Then the evidence boundary: use only the three features on the brief, and mark anything you cannot support instead of writing it.
Four iterations, four attributable changes, one prompt the practice could reuse for the next client. The invented discount disappeared when the evidence boundary was added, which told Jo something useful: the model had not been careless, it had been unconstrained.
Why This Works
One change per iteration makes the prompt a controlled experiment rather than a negotiation. You learn which slot was carrying the failure, and that knowledge transfers to the next prompt you write. Volume Substitution teaches you nothing, because every attempt confounds several changes at once.
The evidence boundary works for a different reason: it changes the model's default behaviour under uncertainty from invention to flagging. It will not eliminate fabrication, and it is not a substitute for verification. It does make the gaps visible, which is where verification starts.
Worked example 2 of 3Optional depth
Dr. Naomi Ellery at OmniCorp Health needed patient-facing explanations of three procedures. Her first prompts produced readable text at roughly a college reading level, which was useless. The empty slot was not context or constraints: it was the output contract. She specified four sections in fixed order, each under seventy words, no sentence containing more than one clause, and a final section listing every clinical term she would need to replace. The last requirement did the most work, because it turned the model into an instrument for finding its own inaccessible language.
Worked example 3 of 3Optional depth
Alan Brixmoor at OmniCorp Public was drafting responses to benefits queries. His prompts kept producing confident answers about eligibility thresholds that the model could not possibly know. He filled the evidence boundary slot with one sentence: use only the eligibility table supplied below, and where the table does not answer the question, write that the answer requires a caseworker rather than estimating. Fabricated thresholds stopped appearing. The number of responses requiring a caseworker went up, which was the correct outcome and had previously been hidden.
Edge Cases and NuancesOptional depth
Some tasks resist the output contract, because the useful shape is not known in advance; for those, ask for three differently shaped options and specify only the constraint that they must differ. Some contexts cannot be supplied because the material is confidential, and the correct move is to restructure the task rather than to leak the context. And a prompt that has been tuned to one model version is a dependency, not an asset: when the version changes, re-run the slot that was carrying the most weight before assuming the prompt still holds.
Structured and maintainable, but review whether every sentence belongs to a slot.
- Long and precise
- Structured and maintainable, but review whether every sentence belongs to a slot.
- Short and precise
- The ideal working prompt: every word fills a named slot.
- Long and vague
- Volume Substitution in its mature form; cannot be debugged or handed over.
- Short and vague
- An exploratory question, appropriate only when nothing depends on the output.
Knowledge check
A colleague's prompt produces excellent product descriptions, but when another person runs the same prompt they get fabricated specifications. Which slot is most likely missing, and why?
Common Failure Modes
The slots end to end
Marisa Delgado at OmniCorp Financial needed a prompt her whole servicing team could run: turn a call recording transcript into a servicing record entry. She wrote the six slots on one page before touching a tool.
Task: extract and summarise. Context: a servicing call about an existing loan, transcript supplied. Audience: the next agent who opens this record, who has thirty seconds before the customer is on the line. Constraints: under one hundred and fifty words, no speculation about customer intent, every commitment stated with the agent's exact words. Evidence boundary: use only the transcript, and mark anything inaudible rather than inferring it. Output contract: four fields, in order, reason for call, actions taken, commitments made, follow-up required.
The first version failed on one slot. Commitments made was being populated with things the customer requested rather than things the agent agreed to. Marisa changed only that slot, specifying that the field records only statements made by the agent, and left the other five alone. The next version held. When the team adopted the prompt, nobody had to guess what a good entry looked like, because the output contract already said.
Decision point
Trevor Okafor at OmniCorp Retail has a prompt that produces excellent product descriptions. A colleague copies it, changes the product, and gets descriptions that invent fabric compositions the company does not use. Trevor's version never did this. What is the most likely cause, and what do you change?
Self-check
Mark the level that describes you today. Nothing is submitted.
| Behaviour | Ready | Developing | Not yet |
|---|---|---|---|
| Diagnosing a weak output | |||
| Iterating attributably | |||
| Writing a transferable prompt |
Commit
Commit Statement
Complete every line in your own words, then sign and date it. Test the commitment by handing your best prompt to a colleague and watching them run it.
| Window | Field application |
|---|---|
| Days 1 to 7 | Rewrite one prompt you use regularly as six labelled slots. Note which slot was empty. |
| Days 8 to 21 | Add an explicit evidence boundary to every prompt whose output someone else acts on, and record what stops appearing. |
| Days 22 to 30 | Hand your best prompt to a colleague without explanation. Fix whatever they had to ask you about. |
Six slots will make your own prompts reliable and transferable. They will not tell you how to review, version, approve and retire prompts across a team, or how to evidence that the prompt in production is the one that was approved. That control layer is the capability the paid programs develop next.
Learner feedback