The Holistic Prompt & Context Canvas (HPC-10)
A structured, 10-element framework — Three Layers, Ten Elements — for designing a single AI request: what you want, what the AI needs to know, and how you know it worked. The deliberate, smaller sibling of the Holistic Agent Canvas (HAC-20).
Three Layers. Ten Elements.
Before the first module, meet the framework the whole course is built around. You'll use it diagnostically from Module 3 onward, so it's worth reading once now and returning to as a reference — many learners print it.
HPC-10 is the deliberate, smaller sibling of the Holistic Agent course's own HAC-20 framework (Five Planes, Twenty Elements), which governs full agent systems. HPC-10 covers the ten elements that determine whether a single AI interaction — a prompt, a request, a task given to an assistant — succeeds. Master this, and HAC-20 will feel like an extension of something you already know, not a new framework to learn from zero.
Layer 1 — INTENT: what you want
| # | Element | The question it answers | Failure if unanswered |
|---|---|---|---|
| 1 | Purpose | What outcome are we actually trying to achieve — stated as an outcome, not an activity? | The AI optimises for a plausible-sounding answer instead of your actual goal |
| 2 | Instructions | What, specifically, should the AI do — and in what order, if sequence matters? | Vague requests get vague or arbitrarily-shaped output |
| 3 | Constraints | What rules, boundaries, or exclusions must the output respect? | Technically-responsive output that's unusable — wrong tone, wrong length, non-compliant |
Layer 2 — INFORMATION: what the AI needs to know
| # | Element | The question it answers | Failure if unanswered |
|---|---|---|---|
| 4 | Context | What must be in view right now — background, prior turns, your actual situation? | A generic answer to a generic version of your question |
| 5 | Knowledge | What facts, documents, or data should this be grounded in? | Hallucination — fluent, confident, ungrounded output |
| 6 | Resources | What examples, references, tools, or systems can the AI draw on or use? | The AI guesses at a format or capability instead of using what's actually available |
Layer 3 — ASSURANCE: how you know it worked, and how it gets better
| # | Element | The question it answers | Failure if unanswered |
|---|---|---|---|
| 7 | Output | What should the result look like — format, structure, length, audience? | Correct content in a shape nobody can actually use |
| 8 | Evaluation | How do you determine whether the result is actually good? | You can't tell improvement from noise — every judgement is a vibe |
| 9 | Verification | How are specific claims or actions checked before you rely on them? | A confident wrong answer reaches a decision unchecked |
| 10 | Iteration | What did you learn, and what changes next time? | The same failure recurs indefinitely; nothing compounds |
Using HPC-10 diagnostically
Almost every disappointing AI response maps to one missing element. Once you know the mapping, fixing a bad result stops being guesswork.
| Symptom | Missing element | Fix |
|---|---|---|
| Confident, plausible, wrong answer | 5 Knowledge or 9 Verification | Ground it in sources; check the claim before trusting it |
| The AI did a different task well | 1 Purpose or 2 Instructions | Restate the outcome in one sentence; make the task explicit |
| Right content, wrong shape | 7 Output | Specify format, audience, and length before generating |
| Worked once, fails on the next similar case | 8 Evaluation | You had a demo, not a test |
| Same mistake keeps happening | 10 Iteration | Nothing is capturing what you learned last time |
| Generic, textbook-sounding answer | 4 Context | The AI never received your actual situation |
| The AI invents a tool, fact, or format that doesn't exist | 6 Resources | It was never told what's actually available |
| Response ignores an obvious rule | 3 Constraints | The rule was assumed, never stated |
The Prompt–Context Cycle
The companion to the canvas — what you actually do, in order, each time:
DESIGN → TEST → OBSERVE → DIAGNOSE → MODIFY → RETEST → EVALUATE → STANDARDISE
Design against the ten elements. Test on real inputs, not one lucky example. Observe what actually came back — not what you expected. Diagnose which element was missing, using the table above. Modify only that element. Retest before declaring victory. Evaluate against a standard, not a feeling. And once it holds, standardise it into a reusable template — Module 4's exercises and the Prompt Library later in this course exist because re-deriving a good prompt from scratch every time is wasted effort.
Two rules the rest of this course keeps coming back to:
More context is not automatically better context. The smallest set of high-signal information beats the largest set of possibly-relevant information — a finding with real architectural grounding, covered in Module 5.
A prompt that works once is a demonstration. A prompt that works reliably is engineered. Covered fully in Module 11.