Context Engineering: Grounded AI Systems
Design the evidence, state, memory, retrieval, and tool information that AI needs to work reliably. Build a grounded team assistant with source ownership, access boundaries, and freshness checks.
Your course plan
Study format
8-12 minutes per lesson, with a 60-90 minute capstone. Estimates include practice and assessment. Estimated total: 3-4 hours including the capstone and quiz.
Prerequisites and scope
AI 101 and introductory prompt engineering. Spreadsheet and document skills are sufficient; an optional implementation lab assumes API literacy.
Learning outcomes
- Context specification
- Source provenance and retrieval design
- Token budgeting and state management
- Permission-aware grounding
- Context evaluation
Four modules, three lessons each
- Define the information contract
- Retrieve the right evidence
- Manage state and tool boundaries
- Evaluate and hand off a grounded assistant
Completion and assessment
Complete all 12 lessons and the practice activities. Use the final-lesson rubric to review the capstone with an instructor or peer. The portal scores a separate 10-question final quiz; 80% or higher is required for the existing course-completion credential. Capstone work is not automatically graded by the portal. No academic credit or external license is implied.
Authoritative reference shelf
Technical and regulatory references reviewed October 8, 2026. Original teaching scenarios, assumptions, calculations, exercises, and rubrics are instructional examples. Verify current source requirements for an actual project or operation.
M1.1 | Context is the working information set
Learning objective
Distinguish instruction design from engineering the information needed for a task.
Core lesson
An instruction tells AI what to do; context supplies information used to do it. Context can include user input, source excerpts, conversation history, tool results, examples, and task state. Context engineering selects, structures, updates, and evaluates that information across the workflow. More information is useful only when the relevant evidence can still be found and applied. Begin with a task and identify the minimum evidence required to answer it. Define what the system should do when evidence is missing or conflicting. For a policy assistant, a polished response from an obsolete handbook is a context failure even if the instruction was clear. Organize an information contract around source, authority, version, access, relevance, and required output evidence.
Instructor teaching guidance
Begin by establishing what the learner already knows about m1.1 | context is the working information set. Teach the principle in plain language, define unfamiliar terms, then connect it to the course goal. Ask the learner to explain the idea back in their own words before moving to application.
Applied exercise
Practice: compare answering a general writing request with answering whether an employee qualifies for a benefit. List the information each requires. Draft a context contract for the benefit question, including the response when the applicable policy cannot be found.
Facilitation sequence
Guide the learner through the application in five steps: describe the present situation, identify the lesson principle, choose an action, name the evidence to review, and define how success will be measured. Use follow-up questions when an answer is vague or unsupported.
Mastery standard
A context contract identifies the required information, authority, freshness, access scope, and missing-evidence behavior.
Knowledge check
Why cannot a stronger prompt repair an answer based on the wrong policy version?
M1.2 | Inventory sources and establish ownership
Learning objective
Build a governed source inventory with provenance and update responsibility.
Core lesson
Create a source inventory before building retrieval. Record document owner, audience, topic, effective date, version, approval status, access level, retention rule, and update method. Prefer an authoritative current record over a duplicate copied into an old presentation. Source selection is an operating responsibility, not a one-time data upload. Define conflict rules appropriate to the organization: for example, an approved current policy may supersede an older FAQ, while an unresolved contradiction should be escalated. Preserve provenance so the answer can be checked. Avoid claiming authority from file names alone. Test whether the source owner can correct an error and whether that correction reaches search, cached results, and future answers.
Instructor teaching guidance
Begin by establishing what the learner already knows about m1.2 | inventory sources and establish ownership. Teach the principle in plain language, define unfamiliar terms, then connect it to the course goal. Ask the learner to explain the idea back in their own words before moving to application.
Applied exercise
Worked example: a current HR policy and an older onboarding slide disagree. Practice: inventory five synthetic documents, identify the authoritative owner, and define a contradiction response. Draw the update path from source correction to the next AI answer.
Facilitation sequence
Guide the learner through the application in five steps: describe the present situation, identify the lesson principle, choose an action, name the evidence to review, and define how success will be measured. Use follow-up questions when an answer is vague or unsupported.
Mastery standard
Success identifies authority and effective dates and keeps contradictions visible until resolved by the responsible source owner.
Knowledge check
What should the assistant report when two currently approved documents conflict?
M1.3 | Budget the context window
Learning objective
Allocate and test context resources without hiding loss of information.
Core lesson
A context window is finite. Reserve room for the instructions, question, relevant evidence, tool results, and generated output according to the model interface. Avoid filling the space with duplicate records, irrelevant conversation, or large unfiltered tables. Token counts are not identical to word counts and vary across text and other inputs. Create a budget worksheet and test with the actual tokenizer or usage reports when available. In this original illustration, a nominal 8,000-token budget might reserve 1,000 for instructions, 500 for the request, 3,500 for evidence, 1,000 for state and tool results, and 2,000 for output. These are teaching allocations, not provider limits or guarantees. When evidence is too large, retrieve selectively or split the task rather than silently truncating crucial material.
Instructor teaching guidance
Begin by establishing what the learner already knows about m1.3 | budget the context window. Teach the principle in plain language, define unfamiliar terms, then connect it to the course goal. Ask the learner to explain the idea back in their own words before moving to application.
Applied exercise
Practice: allocate an illustrative 12,000-token budget. Identify two information types safe to summarize and two that require exact values. Design an overflow rule that reports missing coverage instead of pretending the entire source collection was read.
Facilitation sequence
Guide the learner through the application in five steps: describe the present situation, identify the lesson principle, choose an action, name the evidence to review, and define how success will be measured. Use follow-up questions when an answer is vague or unsupported.
Mastery standard
The budget preserves essential evidence, acknowledges truncation, and reserves adequate output space.
Knowledge check
What could go wrong if a summary removes an exception that controls the answer?
M2.1 | Chunk by meaning and preserve metadata
Learning objective
Design retrieval units that preserve the source meaning required by real questions.
Core lesson
Retrieval often uses smaller units of source content. A useful unit keeps enough surrounding meaning to interpret the fact: headings, definitions, conditions, exceptions, table labels, and references may matter as much as the matching sentence. Fixed-length chunks are a starting configuration, not a universal rule. Preserve document ID, version, section, effective date, access scope, and a path back to the source. Consider parent sections or adjacent passages when the local excerpt depends on them. For tables, maintain row and column relationships so a number is not detached from its meaning. Evaluate chunk boundaries by the questions users will ask. A beautifully indexed collection can still fail if every exception sits in a different missing chunk.
Instructor teaching guidance
Begin by establishing what the learner already knows about m2.1 | chunk by meaning and preserve metadata. Teach the principle in plain language, define unfamiliar terms, then connect it to the course goal. Ask the learner to explain the idea back in their own words before moving to application.
Applied exercise
Practice: split a synthetic travel policy into chunks while preserving a reimbursement limit and its exception. Create metadata for each chunk. Ask a question requiring both passages and inspect whether retrieval returns the necessary context.
Facilitation sequence
Guide the learner through the application in five steps: describe the present situation, identify the lesson principle, choose an action, name the evidence to review, and define how success will be measured. Use follow-up questions when an answer is vague or unsupported.
Mastery standard
A retrieved unit retains meaning, provenance, permissions, and enough surrounding conditions to support the answer.
Knowledge check
Why can a matching reimbursement amount be insufficient evidence for eligibility?
M2.2 | Retrieve, filter, and rerank
Learning objective
Design and evaluate a retrieval pipeline using relevance, coverage, and provenance.
Core lesson
Keyword retrieval can help with exact terms, IDs, and uncommon names. Semantic retrieval can help with differently worded questions. Hybrid approaches may combine them. Filters should limit the candidate set to the correct topic, version, date, and authorized audience. A reranker can reorder candidates for relevance, but it cannot grant access or make a false source authoritative. Evaluate retrieval before judging answer generation. Track whether the needed evidence appears, whether irrelevant material crowds it out, and whether an older conflicting source outranks the current one. Use a small set of questions with known supporting sections. When evidence is absent, the assistant should say what is missing and provide a next step. Similarity scores alone are not truth scores.
Instructor teaching guidance
Begin by establishing what the learner already knows about m2.2 | retrieve, filter, and rerank. Teach the principle in plain language, define unfamiliar terms, then connect it to the course goal. Ask the learner to explain the idea back in their own words before moving to application.
Applied exercise
Practice: create ten policy questions with the source sections needed to answer them. Record retrieval success separately from answer success. Compare exact-term and paraphrased requests. Add a version filter and show how it changes the candidate set.
Facilitation sequence
Guide the learner through the application in five steps: describe the present situation, identify the lesson principle, choose an action, name the evidence to review, and define how success will be measured. Use follow-up questions when an answer is vague or unsupported.
Mastery standard
Retrieval is judged against required evidence and access boundaries, not merely a high similarity score.
Knowledge check
How would you diagnose an incorrect answer caused by missing retrieval rather than poor generation?
M2.3 | Assemble an evidence packet
Learning objective
Assemble context that supports verifiable answers and visible uncertainty.
Core lesson
Make a compact evidence packet with the user task, authorized sources, exact excerpts where needed, document identifiers, dates, and known conflicts. Separate source facts from assumptions and interpretations. Ask the assistant to cite the source that supports each material claim and to avoid inventing a citation when support is absent. Validate that citations actually support the response. An answer can cite a real document while drawing an unsupported conclusion from it. Use exact-value checks for dates, money, units, and eligibility conditions. For calculations, retain inputs and arithmetic rather than asking a model to infer missing numbers. Give the human reviewer a clear path to inspect the cited section.
Instructor teaching guidance
Begin by establishing what the learner already knows about m2.3 | assemble an evidence packet. Teach the principle in plain language, define unfamiliar terms, then connect it to the course goal. Ask the learner to explain the idea back in their own words before moving to application.
Applied exercise
Worked example: a packet contains a travel rate but no meal eligibility rule. Practice: draft an answer that states the supported rate and the unresolved eligibility question. Add a source ledger with claim, excerpt, version, and reviewer result.
Facilitation sequence
Guide the learner through the application in five steps: describe the present situation, identify the lesson principle, choose an action, name the evidence to review, and define how success will be measured. Use follow-up questions when an answer is vague or unsupported.
Mastery standard
Each material claim is supported or explicitly marked as an assumption, inference, or unresolved question.
Knowledge check
Why does the presence of a citation fail to prove that a claim is grounded?
M3.1 | Keep task state separate from conversation
Learning objective
Design a reliable state record for long-running AI work.
Core lesson
A long conversation includes decisions, discarded ideas, open questions, and completed actions. Maintain a concise state record containing the current goal, constraints, confirmed decisions, pending actions, owners, and evidence links. Preserve exact IDs and approved values. Do not promote a tentative suggestion into a confirmed decision during summarization. Compaction replaces bulky history with a shorter record; it can lose meaning if exceptions or unresolved issues disappear. Compare the summary with a checklist of critical facts. When resuming, reload sources that may have changed rather than treating the old summary as permanent truth. Define who may update state and how conflicts are resolved. State is part of the workflow, not hidden memory that nobody can inspect.
Instructor teaching guidance
Begin by establishing what the learner already knows about m3.1 | keep task state separate from conversation. Teach the principle in plain language, define unfamiliar terms, then connect it to the course goal. Ask the learner to explain the idea back in their own words before moving to application.
Applied exercise
Practice: summarize a synthetic ten-message project discussion into goal, decisions, open questions, and next actions. Include one rejected option and one conditional approval. Ask another learner to resume using only the state record and note misunderstandings.
Facilitation sequence
Guide the learner through the application in five steps: describe the present situation, identify the lesson principle, choose an action, name the evidence to review, and define how success will be measured. Use follow-up questions when an answer is vague or unsupported.
Mastery standard
The handoff preserves confirmed facts, conditions, unresolved issues, and source references without inventing agreement.
Knowledge check
What must stay visible when approval was conditional on a test that has not passed?
M3.2 | Design memory with correction and deletion
Learning objective
Define useful memory that can be reviewed, corrected, and retired.
Core lesson
Distinguish session context, task state, and longer-term memory. Store only information that serves a defined purpose and is permitted for that system. A useful memory record includes the fact, source, owner, timestamp, scope, confidence or verification status, and expiry where appropriate. Some information should be re-read from its authoritative source instead of copied indefinitely. Plan correction, deletion, and propagation across derived indexes and caches. A deleted source may otherwise survive in an embedding store or summary. Keep personal preferences separate from sensitive records and restrict use by audience and purpose. Treat recalled information as potentially stale. A system that remembers everything without an update or removal pathway is difficult to trust and maintain.
Instructor teaching guidance
Begin by establishing what the learner already knows about m3.2 | design memory with correction and deletion. Teach the principle in plain language, define unfamiliar terms, then connect it to the course goal. Ask the learner to explain the idea back in their own words before moving to application.
Applied exercise
Practice: design memory records for a project decision, a writing preference, and an employee access role. Choose which should expire or be retrieved live. Write a correction and deletion workflow covering the primary record, summaries, cache, and retrieval index.
Facilitation sequence
Guide the learner through the application in five steps: describe the present situation, identify the lesson principle, choose an action, name the evidence to review, and define how success will be measured. Use follow-up questions when an answer is vague or unsupported.
Mastery standard
Memory has a justified purpose, scope, provenance, lifecycle, and a tested correction or deletion path.
Knowledge check
Why should a previous access role never substitute for a current authorization check?
M3.3 | Treat tool output as evidence, not permission
Learning objective
Design context and tool boundaries that preserve authorization.
Core lesson
Tool descriptions define capabilities, inputs, outputs, and expected errors. Give the assistant a small relevant set and return structured, bounded results with timestamps and provenance. A retrieved page or tool result may contain instructions from an untrusted source. Such content should not be allowed to change system authority or authorize an action. Enforce permissions in the application and data layer. Separate reading information from executing a change, validate parameters, and require the workflow approval appropriate to the action. Prompt text is not an access-control mechanism. Test a source that instructs the assistant to reveal restricted records or send a message. The safe result is to preserve the evidence boundary and refuse the unauthorized action.
Instructor teaching guidance
Begin by establishing what the learner already knows about m3.3 | treat tool output as evidence, not permission. Teach the principle in plain language, define unfamiliar terms, then connect it to the course goal. Ask the learner to explain the idea back in their own words before moving to application.
Applied exercise
Practice: define a read-policy tool and a separate update-record tool. List required parameters, access checks, and failure responses. Insert an instruction to export private data into a synthetic document and describe the expected controlled behavior.
Facilitation sequence
Guide the learner through the application in five steps: describe the present situation, identify the lesson principle, choose an action, name the evidence to review, and define how success will be measured. Use follow-up questions when an answer is vague or unsupported.
Mastery standard
Untrusted content cannot grant authority; access and action checks remain enforceable outside the model.
Knowledge check
Why does placing a confidentiality instruction in a prompt fail to replace database permission checks?
M4.1 | Evaluate context failures by layer
Learning objective
Diagnose and test context reliability using layered evidence.
Core lesson
Create test cases for missing evidence, obsolete versions, contradictory sources, irrelevant retrieval, truncated exceptions, unauthorized data, inaccurate summaries, and malicious source instructions. Classify failure at the correct layer: source governance, retrieval, assembly, generation, permission enforcement, or validation. This prevents fixing the prompt repeatedly when the real problem is elsewhere. Use separate measures for retrieval coverage, claim support, answer correctness, access leakage, freshness, latency, and cost. A small original pilot might require all critical authorization tests to pass and at least 18 of 20 ordinary cases to meet a defined rubric. These are instructional acceptance targets; teams must choose thresholds based on consequences. Retain failing cases as regression tests.
Instructor teaching guidance
Begin by establishing what the learner already knows about m4.1 | evaluate context failures by layer. Teach the principle in plain language, define unfamiliar terms, then connect it to the course goal. Ask the learner to explain the idea back in their own words before moving to application.
Applied exercise
Practice: build a 20-case evaluation with five adversarial or failure cases. For each, state required evidence and expected behavior. Diagnose one stale answer and one unauthorized retrieval. Recommend the smallest corrective action for the responsible layer.
Facilitation sequence
Guide the learner through the application in five steps: describe the present situation, identify the lesson principle, choose an action, name the evidence to review, and define how success will be measured. Use follow-up questions when an answer is vague or unsupported.
Mastery standard
Evaluation identifies the failed layer and verifies the correction against ordinary and adverse cases.
Knowledge check
What metric improves when retrieval is correct but the model still ignores an exception?
M4.2 | Operate the knowledge lifecycle
Learning objective
Plan the ongoing operation of grounded AI context.
Core lesson
Document ingestion, approval, indexing, retrieval, answer generation, monitoring, corrections, and retirement as a workflow. Assign owners and update intervals by source volatility. Policy changes may need immediate propagation; stable reference material may need periodic review. Publish the source version used in each material answer where feasible. Set service expectations for corrections and a fallback if the knowledge store becomes unavailable. Review queries that frequently lack evidence, but protect user privacy when collecting them. Monitor repeated failure themes and remove redundant or low-quality sources. A knowledge system becomes useful through maintenance, evidence, and clear ownership, not through the number of documents uploaded.
Instructor teaching guidance
Begin by establishing what the learner already knows about m4.2 | operate the knowledge lifecycle. Teach the principle in plain language, define unfamiliar terms, then connect it to the course goal. Ask the learner to explain the idea back in their own words before moving to application.
Applied exercise
Practice: create a lifecycle operating sheet for an internal policy assistant. Define the source owner, update trigger, index refresh, cache invalidation, failure fallback, and correction deadline. Include a monthly review of the five most common unanswered questions.
Facilitation sequence
Guide the learner through the application in five steps: describe the present situation, identify the lesson principle, choose an action, name the evidence to review, and define how success will be measured. Use follow-up questions when an answer is vague or unsupported.
Mastery standard
The system has an accountable update and correction process from source change through answer delivery.
Knowledge check
Who should decide whether a corrected policy answer changes previous user notifications?
M4.3 | Capstone: build a grounded team assistant
Learning objective
Defend an end-to-end context design using evidence and failure tests.
Core lesson
Build a design packet for an assistant answering questions from ten synthetic policy documents. Include a source inventory, chunking plan, access rules, retrieval strategy, context budget, evidence packet, state record, memory lifecycle, and twenty-case evaluation. Use current, obsolete, conflicting, and restricted documents to test behavior. The noncoding track produces the packet and manual retrieval demonstrations. The optional coding track implements ingestion and retrieval in an approved environment. Document what the model receives for three representative questions and show how the assistant reacts when the correct source is missing. Keep source permissions enforceable independently of the prompt.
Instructor teaching guidance
Begin by establishing what the learner already knows about m4.3 | capstone: build a grounded team assistant. Teach the principle in plain language, define unfamiliar terms, then connect it to the course goal. Ask the learner to explain the idea back in their own words before moving to application.
Applied exercise
Spend 60-90 minutes on the packet and three demonstrations. Rubric: source governance 20, retrieval and assembly 25, state and lifecycle 15, authorization and failure behavior 20, evaluation evidence 20. Target 80/100 with every critical authorization case passing. The portal quiz is a separate scored assessment.
Facilitation sequence
Guide the learner through the application in five steps: describe the present situation, identify the lesson principle, choose an action, name the evidence to review, and define how success will be measured. Use follow-up questions when an answer is vague or unsupported.
Mastery standard
The assistant design produces supported answers, visible uncertainty, correct access boundaries, and a maintainable update path.
Knowledge check
Which source or workflow failure poses the greatest risk, and what control directly addresses it?