Track 01 · Models & contextLesson 09 of 10
Treat prompts like releases
Versions, changelogs and staged rollout, so a prompt edit never surprises production.
- Lesson library · reference
- 35 min read
- 60 min hands-on
- Northvale Bank
- Pro
What you'll be able to do
01- Explain why a prompt change is a production deploy, and what belongs in a prompt release unit.
- Choose between repo-based and managed prompt registries for a given customer and team.
- Apply semantic versioning, content hashing and labels so that any production answer can be traced to an exact prompt, model and parameter set.
- Design an eval-driven optimisation loop, and decide when automatic optimisation (for example DSPy's optimisers) is worth its cost.
- Implement label-based resolution, per-tenant pinning and rollback, and defend the change log to a model-risk reviewer.
Before you start
- System prompts that survive a regulated rollout: what a production system prompt contains.
- Typed output: schemas, validation and tool calls: the output schema version is part of the release.
- Context on a budget: what to keep, compress and cut: a prompt release changes the cached prefix.
- Git, pull requests and CI on a real project.
The short version
A prompt defines behaviour as surely as code does, but it is usually edited like a document: in a console, by whoever has access, with no review, no test run and no record. That is how a one-word change on Friday misroutes complaints on Monday. Treat the prompt as a versioned artefact. The release unit is the template plus the model snapshot, sampling and reasoning parameters, tool definitions and output schema version, hashed together, because changing any one of them changes behaviour. Store releases immutably (in git, a managed registry, or both), give them semantic versions and content hashes, review them as diffs with eval results attached, and point environment and tenant labels at them. Rollout is moving a label; rollback is moving it back. Optimisation, manual or automatic, is a loop against an eval set, and its output is just another release.
- The release unit is prompt + model + parameters + schema + tools, hashed as one.
- Versions are immutable; labels move. Never edit a version in place.
- Every change gets a diff, an eval result and a reason in an append-only log.
- A model upgrade is a prompt release. Re-evaluate it like one.
- Automatic optimisers produce artefacts, not magic. Version, review and gate their output like any other change.
Pro lesson
The rest of this lesson is in Pro.
The mental model, worked example, field note, failure table, exercise and self-check, with the voice tutor.
- Every stage and specialisation, in full
- Every lab and every role project
- Halden weeks 2–10, on your record
- Every drill, live in the playground
- All solutions, plus the server judge
- Lab Assistant and every Teach with AI