The capstone is an end-to-end Cowork workflow: gather source files, prepare the workspace, write the brief, review the plan, generate the packet, verify it, write the audit note, and build the workflow card. Every step requires a human decision, not just a human presence. The output you deliver is the packet. The evidence you keep is the brief, the plan, the verification checklist, the audit note, and the workflow card.

It is Friday afternoon. Your operations director needs the weekly packet by end of day: status on each active project, a metrics table, a list of action items with owners and due dates, an open-questions section, and a risk flag if anything needs escalation. You have a folder of team notes from the week, a metrics CSV from the database export, and forty-five minutes. In earlier weeks, this took two hours.

This capstone is designed to be an authentic task, not an abstract exercise. Brown, Collins, and Duguid (1989) argued that learning situated in real work produces knowledge that transfers to new contexts; exercises designed to look like work but avoid its constraints transfer much less reliably. Whether you use a real source packet or the synthetic one provided below, the workflow is the same. The skills are the same. The judgment calls are the same.

Create a dedicated folder for this workflow run. Copy the source files into it. Do not work in the shared drive or the live notes folder. Workspace boundary note (write this now, before touching Cowork):

The packet carries your name. That is not a formality. Every number in the metrics table being accurate as of the source file you used. Every action item having the right owner and a stated (not inferred) due date. Every escalation flag being a real risk, not a Cowork interpretation of what a risk might be. The packet not containing any content from outside the approved source files. Knowing what Cowork did and did not do.

After the audit note is complete, build the workflow card for this workflow using the template from Chapter 11. Fill in every field. The first time you fill it in, the "last reviewed" date is today and the "revision notes" field says "initial version." The card is the difference between a capstone you did once and a workflow you can run every week.

Perkins and Salomon (1992) distinguish near transfer (applying a skill to a nearly identical task) from far transfer (applying the underlying structure to a different domain). The goal of this capstone is far transfer. The sequence , workspace boundary, task brief, plan review, execution, verification checklist, audit note, workflow card , applies to:

This capstone has been deliberately supervised: you write the brief, you review the plan, you work through the checklist, you write the audit note. Chapter 10 covered the full scope of what not to delegate. A few reminders specific to operations workflows: Do not automate the audit note. Asking Cowork to write its own audit note defeats the purpose. The audit note is your account of what happened, written from your review , not Cowork's self-report.

Treating the capstone as a test of Cowork's output quality. The capstone tests your ability to design, supervise, verify, and document a complete workflow , not whether Cowork writes a good executive summary. Skipping the workspace boundary note. The boundary note is the first human decision. Without it, everything that follows is on shakier ground.

You started this book with a polished artifact. The central question was whether it was trustworthy. The weekly operations packet you just built is polished. You know whether it is trustworthy, because you made the decisions that made it so: you named the sources, scoped the workspace, reviewed the plan, checked every action item against the meeting notes, wrote the audit note in your own words, and built a card that will let you run this workflow again next Friday.

Donald Schön (1930, 1997) was an organizational theorist and educator who argued that professional knowledge is not primarily transmitted in classrooms , it is built through what he called "reflection-in-action": the capacity to think about what you are doing while you are doing it, and to revise your practice based on what you notice. Schön was skeptical of the idea that professional work could be reduced to technical application of established knowledge.

Donald Schön (1930, 1997) was an organizational theorist and educator who argued that professional knowledge is not primarily transmitted in classrooms , it is built through what he called "reflection-in-action": the capacity to think about what you are doing while you are doing it, and to revise your practice based on what you notice. Schön was skeptical of the idea that professional work could be reduced to technical application of established knowledge.