Twenty sessions, and what comes out of each one.

Before any tooling, we map what you actually produce: the three or four recurring work products, how each one is made today, and where the hours go. This is the session that determines what the rest of the curriculum is pointed at.

The Practicum Playbook is opened here. It is the running written record that becomes the course’s documentation, and it is handed over complete at the end.

Produces: a workflow map of your current practice, and the Playbook.

Five things about these systems explain nearly everything they get wrong: how the text is actually produced, what the model knows and when it stopped learning, how much it can hold at once, how reliably it does what it is told, and what a citation is really evidence of.

Then the part that matters more than the list. Most real failures are two of those at once, and from the outside they look identical. A long document summarised badly is a working-memory problem wearing the costume of a comprehension problem, and the fix for one is useless against the other. Being able to name which property just bit you is the difference between repairing the work and reaching for a different model in the hope that it behaves.

This comes second, before any productive use, because everything after it depends on knowing where the edges are. In regulated subject matter that is not a philosophical point.

Produces: a verification checklist and a one-page failure-diagnosis sheet, both used for the rest of the course.

Sources, grounded responses, citation behaviour, and what happens at the boundaries of a source set. You build your first real notebook from live material drawn from current work, not from a demo corpus.

Then the decision that determines whether any of this is still useful in a year: standing notebooks against per-engagement notebooks, naming conventions, source hygiene, when a notebook has grown enough to be split, and what happens to it when an engagement ends. Most people who abandon these tools do so because they skipped this part.

The hour is deliberately full. The support sessions in this week are where the rest of your source set gets loaded and the architecture gets tested against it.

Produces: a working notebook on a live topic of yours, and a written notebook architecture standard in the Playbook.

Interviews, calls and meetings are the most valuable research input most consultants have and the least systematically captured. Recording to transcript to source, tested on a real recording of yours, with the consent and confidentiality questions handled properly rather than assumed away.

Then what is honestly worth making from a source set: briefing documents, study guides, timelines, audio overviews. What each is genuinely good for, what each is bad at, and where handing one to a client would misrepresent the work underneath it.

Produces: a capture-to-notebook pipeline tested end to end, and a briefing document from your own sources, reviewed line by line against them.

Prompting for analysis rather than for answers. Structured extraction into comparison tables, testing a claim against the evidence behind it, and constructing the strongest form of a position you disagree with — which is the single most useful thing these tools do for anyone who writes about contested subjects.

Underneath all three is one move, and this is the hour where we do it slowly. Say precisely what you want, judge hard what comes back, then change the instruction rather than repeat the request. Three things can be specified and most disappointing output is a failure to specify the last two: the result you want, the method you want it reached by, and the manner you want it done in. Say it, judge it, respecify. The loop has a name — the Description–Discernment loop — and having a name for it is what makes it something you do deliberately at eleven at night rather than something that happens when you are lucky.

We take one prompt and put it through that loop, in the session, until it is reusable.

Produces: three documented analytical prompts in your library, each recorded with the specification it was built from.

Division of labour between a grounded corpus and an open reasoning tool, written up as a standing procedure you can follow when you are tired and busy, which is when procedures matter.

The unit artifact is assembled here and assessed against the outcomes it is meant to demonstrate.

Unit artifact: a written research procedure, plus a completed research brief on live subject matter produced under it.

Projects, custom instructions, reference files. Why a configured workspace beats a well-written prompt, and how to set your context up once instead of re-explaining yourself every morning.

Then the same idea in the form that travels: a skill is context written into a file the tool picks up by itself when the work matches, rather than context that lives in one workspace you have to be inside. First look here, built properly in Session 8.

Produces: two configured workspaces for live work.

Invoices, memos, proposals, engagement summaries. The usual version of this is a prompt kept in a document and pasted in every month, which decays the moment you stop being sure which copy was the good one.

So we build it properly instead. A skill is a short instruction file — your format, your rules, your worked example — that the tool loads by itself when the task matches, and that you own, version and can hand to someone else. You write one in this session for a document you actually produce. Then we break it: the awkward client, the missing field, the month the format changed. What goes wrong is most of the interesting part of this hour.

You leave with two of them and, more usefully, with the ability to write a third without me.

Produces: two working skills for your own recurring documents, each tested against a real case that breaks it.

Summarising long threads, and drafting in your own register rather than the flat corporate voice these tools default to. We build a voice reference from your own past writing, which is the part that makes the difference.

Also the discipline of what does not get pasted into a model, which is revisited properly in Session 11.

Produces: a correspondence procedure and a written voice guide.

What “agents” honestly are: scheduled tasks, structured checklists, recurring prompts. Where automation is reliable, where it is brittle, and where a paper list is simply better. Built around your real open commitments rather than a hypothetical inbox. I will talk you out of automating some of what you want automated.

The second half turns messy input — an email thread, a set of notes, a call recording — into structured schedule data another system can accept. This is also where the raw material for the Unit 3 tool specification is gathered.

Produces: a running commitments system, a scheduling workflow, and the input material for your Unit 3 build.

What does not go into a third-party model when your work touches client material, health information or government-adjacent subject matter. Retention and provider terms, what a client is entitled to be told, and where you draw your own line — which is a decision you have to make rather than one I can make for you.

The hour produces a policy, and the policy has three parts because the question has three. What you are answerable for in the making: what gets checked, what is never delegated, what you will not put your name to unverified. What you disclose: to a client, on a deliverable, in a tender, and the cases where saying nothing would itself be a misrepresentation. And what you are willing to release: which outputs go out unread, which never do, and what you do when one turns out to be wrong after it has gone.

Written as three sections a client could read, because a policy that only exists inside your head is not one.

Produces: a written personal AI use policy in three parts — making, disclosing, releasing — that you can show a client.

Every system built so far goes up against a week of your real work. Not a demonstration week: the actual one, with the actual awkward inputs.

And marked rather than eyeballed. Before the week starts you write down what each system has to get right and what counts as failing — five or six real cases each, and the standard they have to meet. At the end you mark them against it. A system you were fond of that fails its own test is a more useful result than one you feel vaguely good about, because there is something you can do about the first.

What fails gets repaired or abandoned. Abandoning something that did not work is a legitimate result and is written down as one, with the reason, so that you do not quietly rebuild it in August.

Unit artifact: the configured system, documented, with the test set it was marked against, the marks it got, and a written account of what you tried and what you dropped.

What a single-file web tool actually is. How to read code you did not write well enough to judge whether it does what it claims. How to describe a change precisely enough that you get the change you asked for.

Produces: an annotated read-through of a working tool.

The session that decides whether the build succeeds. Turning “I need the calendar thing” into a written specification: inputs, outputs, the exact target format, the edge cases, and what the tool must refuse to do rather than guess at.

It is written as one file and it stays with the tool — the intent file, the thing that records what this was for and what it was never meant to do. Six months on, when you have forgotten, it is the only way to tell whether a proposed change is a fix or a mistake. It also settles arguments with the model: when a build drifts, you do not describe the tool again from memory, you point at the file.

Requires a real example of the target format in hand. Bring it.

Produces: the intent file and written specification for your primary tool.

Specification to something that runs and handles the common case correctly. It will be ugly. It will work.

From here to the end of the unit the support sessions carry most of the iteration. The main session sets the direction and reviews what came back.

Produces: version one, running.

The real inputs. Malformed text, ambiguous dates, multi-day and recurring events, missing fields, and the important question of what the tool should do when it cannot be certain. A tool that guesses quietly is worse than one that refuses loudly.

Produces: version two, with validation and error handling.

Making it usable by someone who is not its author: clear affordances, sensible defaults, a legible error state, and short documentation. This is the difference between a script you can run and a tool a colleague can use.

Then static hosting, deploying, and keeping versions so a change can be undone — and handing the tool to a colleague so that it survives without you.

Produces: the finished tool, live at a URL, with a handover note.

A second tool of your own choosing, specified and built inside one session. The point is not the tool. The point is establishing that the method transfers and does not depend on me sitting there.

Specification work for it happens in the support sessions of the preceding week, so the main hour is spent building rather than deciding.

Unit artifact: two working hosted tools, with the intent file and specification behind each.

Every artifact assessed against the seven outcomes. Gaps identified and closed where they can be. An honest written account of what you can now do unassisted and what you still cannot — the second half of that sentence is the useful half.

Produces: a written assessment.

A twelve-month plan: what to maintain, what will decay on its own, what to learn next, and how to keep the research corpus alive without a weekly session. The Playbook is handed over complete.

Unit artifact: the completed Practicum Playbook and a twelve-month continuation plan. Certificate of Completion issued.