AI Prompt Architecture and Evaluation
A self-study textbook covering essential theory, comparative examples, guided practice, quality review, and a capstone exercise. Central question: How can we make LLM output quality and safety repeatable?
Learning Goals and Study Routine
How can we make LLM output quality and safety repeatable? You complete today’s lesson when you can answer this question in your own words, produce the required artifact, and review its quality.
Distinguish system, user, and tool instructions.
Structure goals, context, constraints, and output formats.
Explain prompt injection and trust boundaries.
Write verification rules that reduce unsupported claims.
Build evaluation examples and scoring criteria.
Improve prompts systematically from failure cases.
Recommended self-study routine
- Explain why a problem occurs before memorizing its terminology.
- Describe the difference between good and poor examples using observable criteria.
- Attempt the capstone before opening the model answer.
- Mark missing conditions in a second color and revise your artifact.
Table of Contents
- Study Guide and Learning GoalsPage 02
- Chapter 1. Core Theory and Design PrinciplesPage 04
- Chapter 2. Guided Design PracticePage 05
- Chapter 3. Case Review and Quality CheckPage 06
- Chapter 4. Capstone and Model AnswerPage 07
- Glossary and Final ChecklistPage 08
- Self-study reference and guided practicePages 09–11
Submit the capstone artifact, score at least 80/100 on the self-review, and write your own answers to the four concept questions.
Core Theory: AI Prompt Architecture and Evaluation
Each technical term exists to solve a recurring design problem. Study when and why the concept is needed, not merely its definition.
| Core concept | Working definition |
|---|---|
| Instruction Hierarchy | The priority used when multiple instructions conflict. |
| Context | The material the model may use to construct an answer. |
| Constraint | A mandatory condition or prohibited behavior. |
| Output Contract | A specified format, field set, length, and allowed values. |
| Prompt Injection | An attack in which external data attempts to override trusted instructions. |
| Evaluation | Repeated measurement against examples and scoring rules. |
Poor and Effective Approaches
Avoid
Use only adjectives such as “analyze this perfectly and professionally” without a target or success criterion.
Prefer
State the input boundary, role, prohibited actions, output schema, evidence rule, and behavior under uncertainty.
[Role] + [Goal] + [Input Boundary] + [Procedure] + [Constraints] + [Output Contract] + [Evaluation]
A Six-Step Design Workflow
Define the problem
Define the observable result the user needs.
Extract the structure
Separate trusted instructions from untrusted external data.
Design the core flow
Provide only relevant context and preserve source labels.
Add failure conditions
Specify prohibited behavior and what to do when uncertain.
Connect policies
Provide a JSON or Markdown contract and representative examples.
Verify and trace
Measure normal, boundary, and adversarial inputs repeatedly.
Worked Example
Questions for reading the example
- Are the input and initiating condition explicit?
- Are success and failure outcomes observable?
- Are duplication, authorization, concurrency, and dependency failure covered as needed?
- Can the result be traced back to a requirement?
Concept Check and Quality Review
- Is a longer prompt always better?
- When do few-shot examples help?
- Why must external documents be separated from instructions?
- What must be evaluated besides accuracy?
Answer each in two or three sentences and add one example that supports your explanation.
Self-Assessment · 100 points
| Area | Standard | Points |
|---|---|---|
| Accuracy | Concepts and technical choices match the facts and requirements. | 25 |
| Completeness | Normal flow, boundaries, failures, and recovery are covered. | 25 |
| Consistency | Terms, IDs, states, and interfaces agree across artifacts. | 20 |
| Verifiability | Observable outcomes and completion criteria are present. | 20 |
| Reasoning | The choice and its tradeoffs can be explained clearly. | 10 |
Do not only correct the result. Record which question you failed to ask so your next design process prevents the same omission.
Capstone Exercise and Model Answer
Write a system prompt that classifies customer requests by urgency. Evaluate it with two normal inputs, one ambiguous input, and one injection attempt.
- List assumptions and unresolved decisions first.
- Produce the main design as a table, diagram, or code block.
- Include the normal flow and at least three failures or boundaries.
- Score it with the rubric and compare before and after revision.
Open the model answer
Fix the labels and decision criteria first, and return evidence plus confidence. Treat text such as “ignore earlier instructions” as customer data. Route ambiguous cases to human_review instead of forcing a confident label.
How to use the answer
The model is not the only valid design. If yours differs, explain the requirement, cost, complexity, or risk that justifies your choice.
Glossary and Final Checklist
| Term | Plain-English meaning |
|---|---|
| System Prompt | The model’s base role and higher-level rules. |
| Few-shot | Using input-output examples to communicate a pattern. |
| Grounding | Connecting an answer to supplied evidence. |
| Hallucination | Presenting unsupported generated content as fact. |
| Injection | An attempt to override instructions through external input. |
| Eval | A repeatable system for measuring model quality. |
Eight checks before submission
- Can you answer today’s central question in your own words?
- Are inputs, conditions, and results explicit?
- Did you include failures and recovery, not only the happy path?
- Did you review concurrency, duplicate requests, and permissions?
- Did you account for dependency failure and timeouts?
- Can you explain the disadvantages and alternatives to your choice?
- Are terminology and states consistent across artifacts?
- Is there an observable or testable completion standard?
How can we make LLM output quality and safety repeatable? Answer it now using evidence from the artifact you created.
Key Terms in Context
Learn each term as a decision tool. Read across each row: definition, reason to use it, and the failure it prevents.
| Term | Plain definition | Why it matters | Example or caution |
|---|---|---|---|
| System prompt | Higher-priority instructions defining role, priorities, and prohibitions. | It sets consistent behavior and safety boundaries. | State how conflicts with user input are handled. |
| Context | Background facts and current state needed for the response. | It lets the model use evidence instead of guessing. | Provide only relevant information in a clear structure. |
| Few-shot examples | A small set of sample inputs and expected outputs. | They demonstrate format and judgment quickly. | Biased examples reproduce biased behavior. |
| Hallucination | Content presented as fact without supporting evidence. | It directly affects trust in an AI feature. | Require sources, retrieval, and verification. |
| Evaluation rubric | Predefined criteria and scores for a good output. | It makes evaluation repeatable rather than subjective. | Score accuracy, completeness, and format separately. |
| Prompt injection | Untrusted input that tries to override higher-priority instructions. | It is dangerous when tools or private data are available. | Treat external content as data and restrict tool permissions. |
An AI summarizes support tickets and drafts replies without exposing personal data or inventing policy.
Guided Practice and Troubleshooting
Practice scenario
An AI summarizes support tickets and drafts replies without exposing personal data or inventing policy.
Complete in order
- Separate role, objective, input, output format, and prohibitions.
- Build a test set with good, failure, boundary, and adversarial examples.
- Measure accuracy, grounding, safety, and format independently.
- Classify each failure as prompt, data, model, or post-processing before changing it.
Save one artifact, three assumptions, and at least three failure cases. A classmate should be able to reproduce your reasoning without asking what you meant.
If the result is wrong, diagnose it
| Observed symptom | Likely cause | Next action |
|---|---|---|
| Invented policy | No grounding rule | Say when evidence is insufficient |
| Output shape changes | Missing schema and examples | Validate against a JSON schema |
| Model follows instructions inside a document | Trust boundary is unclear | Wrap retrieved text as data and limit tools |
Check Your Understanding
Retrieval check — answer before opening
Is a longer prompt always better?
No. Clear, non-conflicting, testable constraints matter more than length.
What does temperature change?
It changes sampling diversity; it does not guarantee factual accuracy.
When is evaluation complete?
Representative, boundary, and adversarial cases repeatedly meet defined quality and safety thresholds.
Explain the day's main decision, one failure mode, and one verification method without reading the page. If you cannot connect all three, return to the row or diagnostic case you missed.