Product Digest Prompt and Context Engineering Certification

A certification for anybody building a feature on a language model. Six modules covering how a model reads a prompt, how a context window is assembled and budgeted, how to get output a program can rely on, how tools and agents are held together, and how any of it is tested. Ninety questions.

At a glance
Cost
Free There is no examination fee and no course fee.
Format
Six modules and a single assessment of 90 questions covering all of them. The reading is open to anyone. The assessment requires an account.
Pass mark
70 per cent, or 63 of 90, measured across the whole assessment rather than per module.
Prerequisites
None, and the material assumes no machine learning background. It does assume the reader has used a language model and wants to ship something built on one. Engineers, product managers, designers and analysts are all in scope, and the depth is set by the subject rather than by a job title.
Renewal
None. A result records the syllabus as it stood at the time of assessment.
Based on
The a syllabus developed by Product Digest, drawing on the published research on context and evaluation and on the patterns that have survived contact with production systems
What it covers

What it covers. Product Digest issues this certification. No external body accredits it and the assessment is not proctored. It gives a structured route through the material and a record that a candidate has completed the reading.

The title carries both terms on purpose. Prompt engineering is what most people search for and what most material still teaches. Context engineering is the name the work took once a single prompt stopped being enough, and it is where the difficulty actually sits. The course treats the first as a component of the second.

Two modules cover ground that prompting guides skip. Engineering the context takes the context window as a budget, sets out the four things a team can do with it, and names the ways a long context degrades rather than fails. Evaluating and testing treats a language model feature as something that cannot be tested like ordinary software and shows what replaces the unit test.

The material is vendor neutral. Model providers, their interfaces and their limits change faster than a syllabus can, so the pages teach the mechanism and name a vendor only where a specific behaviour is the vendor's own.

The syllabus6 domains · free

Product Digest’s own domains. Each opens its own page listing the concepts beneath it, and each concept has a page of its own.

01How a Model Reads a PromptThe mechanism underneath every technique that follows. Tokens and why position in the window matters, the instructions and examples a model is given, the sampling settings that decide how much the same prompt varies, and the prompt patterns that survive contact with a real workload.How a language model reads a prompt · Prompt engineering · Instructions, examples and output format · Sampling and determinism · Prompt patterns that hold5 concepts
~15%
02Engineering the ContextThe work that begins once one prompt stops being enough. What changed when the field renamed itself, the context window as a budget with competing claims on it, the four things a team can do with that budget, the ways a long context degrades rather than fails, and retrieval as the main way relevant material gets in.Context engineering · The context window · Write, select, compress and isolate · Context rot and long context failure · Grounding and retrieval · Retrieval Augmented Generation6 concepts
~18%
03Getting Usable OutputTurning generated text into something a program can depend on. The three ways to ask for structure and how reliable each one actually is, schemas and what to do when validation fails, refusals and edge cases, splitting one prompt into several steps, and what all of it costs in tokens and in time.Structured output · Schemas and validation · Refusals and edge cases · Chaining and decomposition · Cost and latency5 concepts
~14%
04Tools and AgentsLetting a model act rather than only answer. Function calling and the contract a tool presents, the loop that reasons and acts in turn, what persists between steps, giving a subtask its own clean context, and the failure modes a loop introduces that a single call never had.Tool use and function calling · Agents and their tools · The agent loop · Memory and state · Multiple agents and context isolation · Agent failure modes6 concepts
~18%
05Evaluating and TestingWhat replaces the unit test when the same input can produce a different output. Writing an eval, building a set from real traffic rather than from imagination, using a model to grade a model and checking the grader, catching a regression before a release, the traces that make any of it possible, and judging an agent on its trajectory as well as its answer.Writing an eval · Building an eval set · Using a model as a judge · Regression testing a prompt · Tracing and observability · Evaluating an agent6 concepts
~20%
06Running It in ProductionEverything that starts once real users arrive. Instructions that arrive inside the data, the guards around an untrusted output, shipping a prompt change safely, watching quality rather than only errors, what happens when the provider changes the model underneath, and the practice that keeps all of it from decaying.Prompt injection · Defending a language model feature · Versioning and deploying prompts · Monitoring a language model feature · Model migration · Building a prompt and context practice6 concepts
~15%
Try a question

A housing association holds 200 support policies, each running to about 1,500 words. An engineer proposes placing all of them in the window of a model that accepts 200,000 tokens, on the grounds that 300,000 words of policy is a small library and the window is large. Working from the published ratio of about four characters of English to a token, what does the arithmetic show?

  • AAbout 225,000 tokens, since a token is about three quarters of a word and three quarters of 300,000 words is 225,000, so the policies overflow by roughly an eighth.
  • BAbout 400,000 tokens, since 1,500 words is roughly 2,000 tokens and 200 policies at 2,000 tokens each is 400,000, which is twice the whole window before anything else is counted.
  • CAbout 300,000 tokens, since English runs to roughly one token a word once punctuation and spacing are counted in, so the policies overflow by half.
  • DThe policies fit, since the input and the generated answer are counted against separate limits and only the answer has to stay inside the 200,000.
90 questions across the 6 domains.

One per page, with a worked explanation.

Start the set