Not recorded yet. The lesson below is complete and runnable today — the video is added later without touching this page.
recordings/F1.12.mp4The handoffs fail, not the functions: privacy assessment into control design, legal position into system prompt, MRM validation into security evidence.
Joint runbooks for the seams — one artefact, many consumers, one owner.
Trace one artefact across three functions and find the consumer who never received it.
The seams are where this function fails: privacy assessment into control design, legal position into system prompt, MRM validation into deployment approval. Each handoff has two owners, which usually means none.
delivered() goes and looks. Both sides agreed every one of these in a meeting and neither had a deliverable, which is why the artefact column exists rather than a status column.Tracing each handoff to the artefact the receiving function should now be holding, because a handoff is nobody's deliverable and therefore nobody's deadline.
The functions work and the handoffs leak, and both sides are usually right about their own scope.
Write a joint runbook per seam: one artefact, one owner, named consumers.
Seams with an owned artefact. An indicator with two consumers and no owner gets computed twice, differently.
Measure this
| what to measure | denominator or target |
|---|---|
| seams with an owned artefact | share of seams; an indicator with two consumers and no owner gets computed twice, differently |
the handoffs that fail, and the runbook each one needs privacy assessment ----> control design legal position ----> system prompt wording MRM validation ----> deployment approval security finding ----> product backlog two owners per arrow usually means none
Everything in this chapter has pointed at the same conclusion: the functions work, and the handoffs are where the programme leaks.
A seam is not a disagreement. Both sides are usually competent, usually right about their own scope, and usually assuming the other side has the piece in the middle. Nobody is wrong, and the gap is real.
The control is a joint runbook per seam, and it has exactly three properties:
The three seams below are the ones that fail most often, and each is traced here from producer to consumer to see exactly where it stops.
Anchor → F1.1. The seams are where an indicator has two consumers and no owner, so it is computed twice, differently, and the two numbers are used to argue with each other rather than with the estate.
Three joint runbooks, and three handoffs that were agreed and never delivered. The skill asks the consumer rather than the owner, and records the specific consequence of each — model risk computing a tier without the privacy input.
The skill — skills/programme/handoff-delivery-check/SKILL.md
name: handoff-delivery-check
description: >-
Trace each joint runbook from the function that owns it to the function that
consumes it, and find the handoffs that were agreed and never actually
delivered. Use when two teams both believe the other has something.
allowed-tools: Read, Grep, GlobA joint runbook has an owner and a consumer, and closing the seam between two functions means the consumer actually receives the artefact. The common failure is that everyone agrees the handoff exists, the runbook says so, and nothing has ever been sent — which is invisible until somebody asks the consumer.
After designing cross-functional runbooks, and periodically — this decays.
1 — List the joint runbooks. For each: the owning function, the consuming function, the artefact, and the trigger that should produce it.
2 — Ask the consumer, not the owner. "Have you received this, and when?" Owners report intent accurately and delivery optimistically. The consumer's answer is the measurement.
3 — Record the consequence of each undelivered handoff. Model risk never receiving the privacy assessment means the tier is computed without a data input. Name the specific consequence, not "reduced coverage".
4 — Check the trigger, not the document. A handoff triggered by a person remembering is not a handoff. Look for the mechanism: a ticket transition, a pipeline step, a scheduled export.
5 — Close by making the trigger automatic or naming a date. Anything else recreates the same state, and the check will find it again next time.
Input — the fixture committed at the top of scripts/handoff_delivery_check.py. Edit it and re-run: the buckets, counts and verdicts below are derived from it, not hard-coded.
Output — the opening lines of a real run:
MRM validation -> security evidence
artefact : validation report with tool surface and autonomy
owner : model_risk
consumers : cyber, compliance, internal_audit
legal position -> system prompt
artefact : approved language and refusal set
owner : legalThe run continues past this. test_skills.py executes the script on every build, with no model configured — so what CI proves is that it runs and refuses legibly, not that it prints these lines. The output above is a recorded run against a real model, and nothing re-diffs it: a model's answer is not reproducible, and this repository does not claim otherwise anywhere it can be checked.
{
"runbooks": [{"name": "str", "owner": "str", "consumer": "str", "artefact": "str",
"trigger": "str", "trigger_automatic": false}],
"delivery": [{"runbook": "str", "consumer_confirms": false, "last_received": "str|null"}],
"undelivered": [{"runbook": "str", "consequence": "str"}],
"closure": [{"runbook": "str", "action": "automate|scheduled", "due": "str"}]
}Three ways to do this lesson. Pick one. They run the same procedure against the same code — what changes is who drives it, and how much you see.
The agent reads the lesson, explains the idea, fetches the code, runs the check and answers your questions as you go. This is the one to take if you are here to learn.
Install it, once. From the folder you cloned. --all does every agent it finds on your machine:
python3 scripts/install_skills.py --all --lessons F1.12Then restart your agent and open it in that folder. On Windows, if python3 says Python was not found, use python instead.
Then pick f1-12-working-the-seams:
| agent | install just for this agent | start it |
|---|---|---|
| Claude Code | python3 scripts/install_skills.py --tool claude --lessons F1.12 | type /f1-12-working-the-seams |
| GitHub Copilot (VS Code) | python3 scripts/install_skills.py --tool copilot --lessons F1.12 | type /f1-12-working-the-seams in Chat |
| Cursor | python3 scripts/install_skills.py --tool cursor --lessons F1.12 | type / in Agent chat and search for it |
| Codex | python3 scripts/install_skills.py --tool agents --lessons F1.12 | type $f1-12-working-the-seams, or run /skills |
No agent, no conversation. The same lesson executes and prints the same readback. Take this one if you have no assistant, if you are reviewing rather than learning, or if you want the result without the teaching around it.
python3 scripts/lesson.py F1.12Neither of the above, and no model needed. The first command writes CyberTravels exactly as it stood at the end of this lesson; the second prints the diff — the lines this lesson added or changed, and nothing from any later one.
python3 scripts/checkpoint.py --at F1.12 --out work/cybertravels
python3 scripts/checkpoint.py --at F1.12 --diffOn Windows, type python wherever these say python3 — and use \ instead of / in the paths. Everything else is identical. A0.0 step 2 explains why.
Ways 1 and 2 need a model; way 3 does not. A signed-in Claude Code CLI needs no API key, and any OpenAI-compatible endpoint works too. With neither, the audit exits 2 and says so rather than inventing an answer. A0.0 sets this up.
Ways 1 and 2 both end with the same readback: What I did, What changed, The number and Read this next. A step that was skipped or refused is reported as exactly that, never as a pass.
If you did the last lesson’s challenge, expect this to stop. Most challenges ask you to edit the code, and ways 1 and 2 will not overwrite your edits: you get stopped, not a failure, with two options — --out for a fresh folder that keeps your work, or --force to discard it and start this lesson clean.
Three joint runbooks are traced from owner to consumer, and three handoffs turn out never to have been delivered — model risk never receives the privacy assessment, and neither security nor internal audit receives the validation report. Each undelivered handoff is a control that was built, works, and is invisible to the function whose decision depends on it. A four-property check runs over the seams and goes from several problems to zero.
Pick the artefact your function produces for someone else and ask the recipient when they last received it. The gap between 'we produce that' and 'we receive that' is the seam, and it is usually measured in quarters.
Tools used
Skill source: skills/programme/handoff-delivery-check