Lab 8 · Capstone · All Domains

Capstone — Ship a Real Project

Seven labs taught you the parts. This one asks you to assemble them into something real: a single, working, documented Claude Project that a colleague could pick up and use tomorrow, plus a short handoff document that lets them do so safely. The exam tests whether you can do this. Here you actually do it, on your own work, with your own inputs, against a standard you'd be willing to put your name on.

Domains exercised

Domain 1 — Prompting & Task Execution · 14%
Domain 2 — Output Evaluation & Validation · 21%
Domain 3 — Product & Model Selection · 12%
Domain 4 — Workflow Integration & Solution Design · 16%
Domain 5 — Configuration & Knowledge Management · 12%
Domain 6 — Governance, Risk & Responsible Use · 15%
Domain 7 — Troubleshooting & Optimization · 10%

What you need: a Claude account (claude.ai) with Projects, about 90 minutes, and (this is the important part) a real task from your own job that you would genuinely delegate to a colleague. No installation, no API key, no code. The whole capstone happens inside the Claude product.

The deliverable is not a document about a Project. It is a Project, built and configured in Claude, that produces real outputs you have checked, accompanied by one short handoff page. If at the end a coworker could open your Project, read your handoff, and produce a usable result without asking you a single question, you have passed the capstone. That is also, not coincidentally, what the exam is measuring.

Choose Your Scenario

Pick the track closest to your actual job. If none fit, substitute your own; the seven stages apply to any of them. The point is that the work be real, because a made-up scenario lets you skip the judgment calls the exam is testing.

Track	Input → Output	The rule that makes it non-trivial
Marketing	Campaign briefs in → on-brand drafts out	A brand-voice standard, plus a claims-substantiation rule: no product claim ships unless the knowledge base supports it.
Operations	Vendor / contract documents in → structured risk summaries out	An escalation rule: anything above a defined risk threshold is flagged for a human, never quietly resolved.
Project management	Raw status updates in → a consistent weekly executive summary out	A milestone rule: any slipping or at-risk milestone must be surfaced explicitly, not buried in prose.

Commit to one now and keep it for the rest of the lab. Everything below refers back to "your scenario."

The Build, in Seven Stages

Each stage maps to one exam domain and produces one concrete artifact. Do them in order: each stage's output is the next stage's input, exactly like the decomposition discipline from Lab 1. Skipping a stage is how you end up with a Project that works in the demo and fails in the wild.

Stage	Domain	What you produce
1. Frame the use case	Domain 4 · Workflow Integration	A one-paragraph fit justification
2. Design the prompts	Domain 1 · Prompting	A core prompt with a failure instruction
3. Choose surface & model	Domain 3 · Product & Model Selection	A written surface-and-model justification
4. Configure the Project	Domain 5 · Configuration	Custom instructions + curated knowledge
5. Govern it	Domain 6 · Governance & Risk	Data classification + guardrails
6. Validate the outputs	Domain 2 · Output Evaluation	Three checked runs + a findings note
7. Diagnose and tune	Domain 7 · Troubleshooting	One named fix + the before/after delta

Stage 1 — Frame the Use Case (Domain 4)

Before you build anything, decide whether you should. The fit test is four questions, and if your scenario fails them, the right move is to pick a different one, not to force it. This is the judgment the workflow-design domain rewards: knowing what is a good fit for Claude and what is not.

Volume & repetition. Does this task recur often enough that a configured Project beats a one-off chat? A thing you do once a year is not worth a Project.
Consequence. What happens if an output is wrong and slips through? The higher the stakes, the heavier the human review you'll design in Stage 5 and 6.
Reversibility. Can a bad output be caught and corrected before it does harm, or does it go straight to a customer, a regulator, or a signature?
Accountability. Who owns the result? A Project never becomes the accountable party. A named human does. If you cannot name them, stop.

Try it in Claude

Open a chat and describe your scenario in three sentences: the input, the output, and who consumes it.
Ask Claude to pressure-test the fit against volume, consequence, reversibility, and accountability, and to name the single biggest risk of automating it.
Read the answer critically. You are the judge, not Claude. Write your own one-paragraph fit justification: why this task suits a Project, where the human stays accountable, and what you will not let it decide.
If the honest answer is "this shouldn't be a Project," pick another scenario now. That decision is a passing answer, not a failure.

The fit paragraph is load-bearing. Everything downstream inherits from it. A Project framed around a low-consequence, high-volume, reversible task can run light on guardrails. One that touches contracts or public claims cannot. Get this wrong and every later stage is calibrated to the wrong risk level.

Stage 2 — Design the Prompts (Domain 1)

Now write the core prompt that will become the heart of the Project. Use the four elements from Lab 1 (task, context, format, criteria) and add the fifth thing that separates a Project you can trust from one you can't: a failure instruction telling Claude exactly what to do when it cannot answer confidently.

If your scenario is compound (extract, then assess, then draft), decompose it. A contract-review Project should pull the clauses, let you verify the pull, assess risk, and only then summarize. A status Project should gather the updates, flag the slipping milestones, and then write the executive summary from the flagged set. Each handoff is inspectable.

Try it in Claude

Draft the core prompt for your scenario with all four elements present. Name the reader, the format of the output, and the standard for "good."
Add the failure instruction in plain words, for example: "If the source material does not support a claim, a risk rating, or a status, say so explicitly and flag it for a human rather than guessing."
If the task has more than one verb, split it into sequential steps and confirm you can inspect each handoff.
Run the prompt once on a real input. Save the prompt that produced the best result; it goes into the Project's custom instructions in Stage 4.

Stage 3 — Choose the Surface and Model (Domain 3)

A recurring task with a stable standard and a curated set of reference materials is the textbook case for a Project rather than a fresh chat each time. Chat is for one-offs; a Project carries its instructions and knowledge across every conversation so the standard doesn't have to be re-explained. Write down, in one or two sentences, why your scenario earns a Project.

Then choose the model family against the shape of the work. The trade-off is cost, speed, and depth of reasoning:

High-volume, well-defined, low-consequence work (routine drafting, straightforward summarizing) favors a faster, lighter model. Speed and cost matter more than deep reasoning.
High-consequence or genuinely analytical work (contract risk, nuanced judgment, anything a mistake in would be expensive) favors the most capable model. The quality is worth the cost.
The everyday middle (most business tasks) is served by a balanced model that trades a little depth for responsiveness.

Match the model to consequence, not to ambition. The most common mistake is reaching for the heaviest model out of habit. If your task is high-volume and low-stakes, a lighter model that's faster and cheaper is the correct engineering choice, and the exam rewards that reasoning, not maximalism.

Try it in Claude

Write one sentence justifying Project over chat for your scenario.
Classify your task on two axes: volume (high/low) and consequence (high/low).
Name the model family that fits, and write one sentence on why, in terms of cost, speed, and quality, not brand preference.
Keep this justification. It goes verbatim into your handoff document.

Stage 4 — Configure the Project (Domain 5)

Now build the actual Project in Claude. Configuration is where the reusable prompt from Stage 2 becomes a standing instruction, and where you decide what Claude is allowed to treat as ground truth.

Custom instructions. Promote your winning prompt into the Project's instructions: the standard, the format, and the failure instruction, so every conversation inherits them without you retyping.
Curated knowledge. Add only the sources that represent your standard: the brand guide, the approved-claims list, the contract-risk rubric, the executive-summary template. Curated, not dumped. Irrelevant material dilutes the good stuff.
Uploads vs. connectors. Decide how knowledge gets in. A stable, curated document set is best uploaded; you control exactly what's there. A live, frequently changing source that you're permitted to connect may justify a connector. Choose deliberately; don't default.
Source precedence. State the order of authority in the instructions: which source wins when two disagree, and that curated knowledge outranks the model's general training for anything factual about your organization.

Try it in Claude

Create a new Project. Paste your Stage 2 prompt into the custom instructions.
Upload two to four curated sources that define your standard. Resist the urge to add "everything, just in case."
Add one line to the instructions stating source precedence, e.g. "When the brand guide and a general suggestion conflict, the brand guide wins. Never invent product claims not present in the approved-claims document."
Run one real input through the configured Project and confirm it behaves differently (and better) than the bare chat did in Stage 2.

Stage 5 — Govern It (Domain 6)

This is the stage people skip, and it is 15% of the exam for a reason. Before your Project touches real data, govern it.

Classify the data. What sensitivity level does the input carry: public, internal, confidential, regulated? A campaign brief and a signed vendor contract are not the same risk class, and they don't get handled the same way.
Anonymize before upload. Anything that must not be in the Project (personal data, customer identifiers, pricing you're not cleared to expose) gets removed or masked before it goes in. You cannot un-upload a document from someone's memory of it.
Write the responsible-use guardrails. In plain language: what this Project is for, and the categories of use that are off-limits. A marketing Project must not fabricate testimonials; an ops Project must not issue a final legal determination.
Define the never-without-review line. Name the specific actions that may never happen on this Project's output without a human checking first: sending to a customer, filing externally, making a claim publicly, escalating or closing a risk.

Governance is a design input, not a disclaimer. The data classification you assign in this stage should change what you built in Stage 4: if the input is regulated, some of it shouldn't be uploaded at all. If your governance step doesn't send you back to revise an earlier stage at least once, you probably weren't honest about the data.

Try it in Claude

Write the data-sensitivity classification for your typical input in one line.
Take one real input and anonymize it (mask names, identifiers, and anything regulated) before it ever enters the Project. Do this outside Claude, then upload the clean version.
Write three responsible-use guardrails and one explicit "never without human review" rule into the Project instructions or your handoff doc.
If the classification revealed that some knowledge shouldn't be in the Project at all, go back to Stage 4 and remove it. That round trip is the point.

Stage 6 — Validate the Outputs (Domain 2)

The heaviest domain on the exam, and the one that separates a demo from a deliverable. A Project that produces confident, fluent, wrong output is worse than no Project, because it earns trust it hasn't verified. Validation is how you find out which you have.

Run three real inputs. One typical, one edge case, one deliberately incomplete. A Project that only works on the clean example isn't ready.
Fact-check the outputs. Verify claims against the curated sources. Does every brand claim trace to the approved list? Does every risk rating follow the rubric? Does the status summary match the raw updates?
Test the decline. Deliberately ask a question the knowledge base cannot answer, and confirm the Project says so instead of inventing. This is the failure instruction from Stage 2, earning its keep. If it fabricates, the guardrail isn't working.
Record what you found. A short findings note: what held up, what didn't, and what you had to correct by hand.

Try it in Claude

Run three real inputs through the Project: typical, edge, and incomplete.
Fact-check each output line by line against your curated sources. Mark anything unsupported.
Ask one question the sources genuinely can't answer. Confirm the Project declines and flags it rather than guessing. If it guesses, tighten the instruction and rerun.
Write a five-line findings note. It becomes the "known failure modes" section of your handoff doc.

Stage 7 — Diagnose and Tune (Domain 7)

Your validation runs surfaced at least one thing that went wrong. Good. Now fix it the disciplined way. Change one variable, observe the delta, and keep it only if it helped. Shotgun-editing five things at once teaches you nothing about which one mattered.

Name the symptom precisely. Not "it's bad" but "it invents a confidence level the rubric doesn't define" or "it buries the slipping milestone in the third paragraph."
Hypothesize the cause. Missing instruction? Ambiguous format? A knowledge gap? Contradictory sources?
Apply exactly one fix. Tighten one instruction, add one missing source, clarify one format rule. Then rerun the same input.
Record the delta and promote the fix. If a correction you keep making by hand works, move it into the standing instructions so you never make it again. That is how a Project improves instead of just aging.

Try it in Claude

Pick the single worst failure from Stage 6 and write its symptom in one precise sentence.
Form one hypothesis about the cause and apply exactly one fix to the Project instructions.
Rerun the same input and compare. Record the before/after delta in plain terms.
If you'd been correcting the same thing manually each run, promote that correction into the standing instructions now.

The Handoff Document

This is the final deliverable, and it's what makes the difference between an asset and a liability. A configured Project with no handoff doc is fine right up until you change teams; then it becomes an unlabeled black box nobody dares touch or turn off. Write the page a competent colleague needs to use it safely without you in the room.

Fill in this outline:

Section	What goes in it
Purpose	What this Project does, in two sentences, and the fit justification from Stage 1.
Who it's for	The intended users and the named accountable owner.
What it does well	The inputs and outputs it's been validated on, the tested happy path.
What it must not be used for	The explicit off-limits uses. Be specific; this is the section that prevents misuse.
Data-sensitivity rules	The classification and the anonymize-before-upload rule from Stage 5.
Review requirement	Exactly what a human must check before any output leaves the building.
Maintenance cadence & triggers	When to review the Project on a schedule, and what events force an off-cycle update (new brand guide, changed rubric, new regulation).
Known failure modes	The findings note from Stage 6, where it's weak and what to watch for.

Say it plainly in the doc: a Project without a handoff document is a liability the moment you change teams. The doc is not paperwork; it is the thing that lets the Project outlive your involvement.

When to escalate. Your finished Project runs when a person opens it and checks the output. That is the Associate's lane. The moment the requirement becomes "run it on a schedule," "integrate it with our internal systems," "let it act without a human in the loop," or "deploy it to hundreds of users with governed, role-based access," you have crossed into Claude Architect or Developer territory. The Associate's job is not to build that; it is to recognize the line and hand off cleanly, with a Project and a handoff doc solid enough that the next person can build on them. Knowing where your responsibility ends is itself an exam objective.

Self-Assessment Rubric

Before you sit the exam, score your capstone against the blueprint. For each domain, point to the specific evidence in what you built, then mark yourself honestly. A row you can't fill is a domain to revisit, not a box to tick anyway.

Domain	Evidence in your capstone	Ready	Needs work
1. Prompting	Core prompt has task, context, format, criteria, and a failure instruction; compound tasks decomposed.	□	□
2. Output Evaluation	Three real inputs run and fact-checked; the decline test passed; findings recorded.	□	□
3. Product & Model	Written justification for Project-over-chat and for the chosen model family.	□	□
4. Workflow Design	One-paragraph fit justification naming volume, consequence, reversibility, accountability.	□	□
5. Configuration	Custom instructions set, knowledge curated, uploads-vs-connectors decided, precedence stated.	□	□
6. Governance	Data classified, inputs anonymized, guardrails written, never-without-review line drawn.	□	□
7. Troubleshooting	At least one named failure fixed with one change; delta recorded; repeat fixes promoted.	□	□

If every row is "Ready" and you can defend the evidence out loud, you are prepared. If two or more are "Needs work," return to those labs before the practice exam; the capstone just told you exactly where your gaps are.

Check Yourself

Cross-domain items: each requires reasoning across two or more domains at once. Commit to an answer before expanding.

An associate configures a contract-review Project. During validation, it produces a fluent risk summary that rates a clause "Low", but the clause isn't in any uploaded document; the model inferred it from general training. The instructions never stated source precedence. What is the best fix?

A. Switch to a more capable model, since the current one is hallucinating.
B. Add a source-precedence rule to the custom instructions stating that only uploaded documents may be used for risk ratings, and that the Project must decline when a clause isn't found, then rerun the validation input.
C. Accept the output; the summary reads well and the rating is plausible.
D. Delete the knowledge sources and rely on the model's general contract knowledge instead.

Correct: B. This spans configuration (Domain 5), validation (Domain 2), and troubleshooting (Domain 7). The root cause is a missing precedence rule: the Project treated general training as ground truth for a factual claim about a specific document. The one-variable fix is to state that curated sources are the sole authority for ratings and to require a decline when a clause isn't found, then confirm the fix with a rerun.

A misdiagnoses a configuration gap as a capability gap; a stronger model can hallucinate confidently too. C is the exact failure the validation domain exists to catch; fluent and plausible is not verified. D removes the very ground truth the Project needs, guaranteeing more invention, not less.

An associate wants a marketing Project to draft social posts from campaign briefs. The briefs routinely include unreleased pricing and a few named beta customers. The associate plans to upload past briefs as knowledge so the voice stays consistent. What should happen before this Project is used?

A. Upload the briefs as-is; consistency of voice matters more than the details.
B. Classify the data, anonymize or remove the unreleased pricing and named customers before uploading, and write a guardrail forbidding fabricated claims, then curate only the sources that actually define the voice.
C. Skip the knowledge base entirely and just describe the brand voice in one sentence.
D. Upload everything and add a note in the handoff doc telling users not to share the outputs externally.

Correct: B. This spans governance (Domain 6) and configuration (Domain 5). Unreleased pricing and named beta customers are confidential data that shouldn't enter the Project at all; classification and anonymization come before upload, because you can't retract a document once it's in. Only then do you curate the sources that genuinely define the voice, plus a no-fabrication guardrail for the claims-substantiation rule.

A ignores the data classification and puts confidential information into a Project used for external drafts. C throws away useful, safe context; the voice sources minus the sensitive fields would have been fine. D treats a downstream disclaimer as a substitute for not uploading sensitive data in the first place; the exposure already happened at upload.

A status-reporting Project has worked well for a month. A colleague now asks that it run automatically every Friday, pull updates directly from the team's project-tracking system, and email the executive summary to leadership without anyone reviewing it first. How should the associate respond?

A. Build it: scheduling and integration are just configuration settings in the Project.
B. Recognize that scheduled execution, system integration, and unreviewed automated sending are Architect/Developer work; keep the Project as a human-run tool, preserve the review requirement, and hand off cleanly with the handoff doc for anyone building the automated version.
C. Remove the human-review guardrail so the summary can be sent automatically, and leave everything else as-is.
D. Agree to all of it and add a line to the handoff doc noting the outputs are now automated.

Correct: B. This spans workflow design and escalation (Domain 4) and governance (Domain 6). Running on a schedule, integrating with an internal system, and acting without a human in the loop are all past the Associate line; that is Architect/Developer territory. The correct move is to recognize the boundary, keep the Associate-scope Project intact with its review requirement, and hand off cleanly so the right role can build the rest.

A wrongly treats cross-system automation as in-scope configuration. C and D both dismantle the never-without-review guardrail that governance put there specifically to keep an unverified summary from reaching leadership; removing it isn't a workaround, it's the governance failure the guardrail existed to prevent.

Key Takeaways

The capstone is one deliverable: a working, governed, validated Claude Project plus a handoff document a colleague could use tomorrow without asking you a question.
Build in the seven-stage order (frame, prompt, choose, configure, govern, validate, tune) because each stage's output is the next one's input, and governance should send you back to revise.
Validation is the heaviest domain. Fluent and plausible is not verified. Fact-check against curated sources and prove the Project declines what it can't answer.
The handoff doc (especially "what it must not be used for," the data rules, and the review requirement) is what turns a Project from a personal trick into a durable asset.
Know where the Associate line sits: scheduling, integration, unreviewed automation, and governed large-scale deployment are Architect/Developer work. Recognizing that boundary and handing off cleanly is itself a passing answer.

You've now done the thing the exam measures. When you can build this capstone from memory and defend every stage, you're ready. Take the practice exam to pressure-test your judgment under exam conditions, and keep the quick reference sheet beside you as you review. Good luck. You've earned the attempt.