Jonathon's AI Wiki

Module 7 — Governance v2 + Keep Learning

28 min read

Source: wiki synthesis: Troubleshooting Claude + CCA-F Reference + WEO AI Governance + Intro Module 8 — Keep Learning

Time: Read 15 min | Watch 15 min | Practice 15 min — total ~45 min

Watch First

One short video before you read. The intro course’s Module 7 covered the rules; this module assumes you’ve internalized them and are now living in the gray zones the rules don’t fully cover.

  • Anthropic on Responsible Deployment — search for the most recent Anthropic-published or Anthropic-Academy walkthrough on responsible AI deployment (~10–15 min). Look for content that covers data classification, scope limitation, and audit trails — those are the three concepts you’ll keep returning to. Prefer recent-and-official over older-and-thorough; surfaces shift fast.

Why It Matters at WEO

The intro course taught the rules: data classification levels, the approved-tools list, when to disclose AI use, when to bring something to your AI lead. That’s the floor. This module is the next layer up — situations where the rules technically allow several paths and you have to pick the right one.

Intermediate Claude users hit governance edge cases the intro course doesn’t cover: a Connector that could touch sensitive data even though the prompt isn’t asking for it, a community Skill that does what you need but ships with phrasing the publisher won’t fix, an automation that runs unattended and auto-publishes before any human reads what Claude wrote. Knowing the playbook for these dilemmas is the difference between shipping responsibly and creating a remediation incident that costs you a week of client trust.

Three things to internalize: governance is an ongoing practice, not a one-time install check; the conservative default is the right starting position when you’re unsure; and the WEO AI Council exists for the moments when the right answer isn’t obvious — using it is a sign of judgment, not weakness.

Section 1 — Three Real-World Dilemmas

Each dilemma is a fully worked scenario. The shape: situation, the decision factors, the recommended path, what NOT to do, and how to escalate. Walk all three even if only one matches your current work — the patterns generalize.

Dilemma 1 — The PHI-adjacent Connector

Situation. Smile Springs’ clinical-team lead messages you. She wants Claude wired into the practice-management system to auto-draft outreach to patients overdue for cleanings. The system contains protected health information — names, dates of birth, last visit dates, treatment notes, billing balances. A Connector for this vendor exists in the marketplace. The clinical lead has heard “you can connect Claude to anything now” and wants the working drafts on her desk by next week.

This is not a “no.” It’s a how do we say yes responsibly problem. Auto-drafted recall outreach is high-leverage work; manually it eats hours every week. The question is what shape the integration takes — and what data Claude is allowed to see on the way to producing the draft.

Decision factors. Five things to think through, in order:

  • Data sensitivity classification. Treatment notes are higher-sensitivity than name + last visit. Billing balances are higher-sensitivity than appointment history. Not everything in the system is the same level of risk.
  • Scope. Read-only beats read-write. Read-only with a narrow projection (just the fields needed) beats read-only with full table access. Pick the narrowest scope that lets the work happen.
  • Where the responses live. A draft that lands directly in the patient’s inbox is high-risk. A draft that lands in a local outbox the practice manager reviews before send is much lower risk. The placement of the human checkpoint is part of the design.
  • Audit trail. Can you reconstruct, three months from now, exactly what data Claude saw and what it produced? If not, you don’t have a real audit trail — you have a habit you happen to be following.
  • Who can see the prompts. A shared Project where any team member can read the system prompt is one trust model. A locked Project that only the clinical lead and the AI lead can read is another. Decide which one you need.

Recommended path. The conservative shape — also the right shape for a first deployment:

  • Scoped read-only Connector with two fields only: patient first name and last visit date. Nothing else. Treatment notes, balances, DOB — none of it gets pulled into context.
  • Claude generates the draft from those two fields plus a templated body the clinical lead has reviewed in advance. The draft writes to a local outbox file.
  • The practice manager reviews every draft in the outbox before any of them go out. Human-in-the-loop is non-negotiable for the first 30 days.
  • Audit log retained 90 days. Every Claude session against the data is logged with timestamp, field-level scope, and the resulting draft.
  • Before going live, walk the workflow through your AI lead. PHI involvement is flagged explicitly. The WEO AI Council is the body for formal sign-off; treat the integration as approved when the Council has reviewed it, not when it technically works.

After 30 days of clean operation, you can talk about loosening — maybe adding a last-treatment summary, maybe removing the per-message review for clearly templated outreach. The loosening is a separate conversation with a separate review.

What NOT to do.

  • Don’t grant full read-write access. The Connector should never write back. Every step that writes (creating a draft, queuing a send) goes through a human or a controlled file.
  • Don’t auto-send drafts. “It’s only outreach” is the rationale that cuts the human checkpoint. The whole reason you’re piloting with two fields and a review window is that auto-send is what you’re protecting against.
  • Don’t pull treatment notes into context “just in case Claude writes a more personal draft.” The voice gain isn’t worth the risk surface. If templated feels too generic, the answer is a better template, not more PHI in context.
  • Don’t skip the audit log because it’s a draft. Drafts written by an LLM with PHI in context are exactly the artifact you’ll need to reconstruct if something goes wrong.

Escalation. File the request through your AI lead. Flag PHI involvement explicitly in the first sentence — don’t bury it. The Council reviews. If they approve the scoped read-only design, you build it; if they want a different shape, you build that. Don’t run a “small pilot” without formal sign-off.

The judgment to internalize: the question is never “can Claude do this?” The Connector exists; Claude can do it. The question is “what shape is the right shape for the data involved, and who has signed off on it?”

Dilemma 2 — The Skill With Banned Phrasings

Situation. You’re working on Smile Springs case-study content. A community Skill on the marketplace — call it “case-study-formatter” — does exactly the structural work you need: restructures a case study into problem/approach/result, generates pull quotes, formats for blog publication. The structure is great. The voice is wrong.

The prompt template uses banned phrasings throughout — “leverage our proven approach,” “world-class results,” “revolutionize the patient experience.” Some of those leak into the output even when your underlying content doesn’t contain them; the Skill is rewriting in its own voice. You can’t review your way out of this — the leaks are subtle enough that some of them ship.

Decision factors. Four options, not equally good:

  • Vet → install as-is. Run the Skill, edit out banned phrases on every output. Leak-prone discipline — you’ll catch most, but not all. The week you’re rushing is the week one slips through.
  • Fork. Copy the source into your skills repository. Edit the banned phrases out. Ship the fork as your team’s version. Tag clearly as a fork (e.g., fork-of-case-study-formatter-smile-springs).
  • Request fix. Open an issue or PR on the publisher’s repo. Low-priority — community Skill maintainers often have their own opinions about voice and may decline.
  • Skip. Use a different Skill or build your own. Right answer when the banned phrases are baked into the approach, not just the strings.

The vet → install path is wrong here. You already know the failure mode; pretending you’ll catch every leak in review is the chain-of-trust gap that produces incidents. Cross it off.

Recommended path. Fork. Fastest, cleanest, doesn’t depend on another team’s roadmap.

The build:

  • Read the Skill source carefully. Identify every location where banned phrasings appear — usually in <role>, <style_guide>, or <examples> blocks. Look for the subtler stuff too: rhetorical openers, hedge phrases, anything that’s not WEO voice.
  • Copy into your team’s skills repository (or personal skills folder). Rename with a fork-of- prefix and your team’s identifier. Example: ~/skills/fork-of-case-study-formatter-smile-springs.md.
  • Edit the banned phrases out. Replace with WEO voice equivalents or delete the surrounding sentence. Run the fork against a real Smile Springs case study and check the output for residual leaks.
  • Document the fork: a short note at the top of the file naming the original Skill, its publisher, the version you forked, what you changed, and why. Three lines is enough.
  • Credit the source. Even when not redistributing publicly, the credit line keeps the lineage clean. If your team ever contributes changes back upstream, you’ll thank yourself.

What NOT to do.

  • Don’t install as-is and rely on output review to catch every leak. Discipline-based fixes for systemic problems are how voice drift becomes published voice drift.
  • Don’t ignore the banned phrasings because the rest of the Skill is good. “Mostly works” is the trap — failures concentrate where trust is highest, and trusted Skills get less review than they should.
  • Don’t commit your fork to a public repository without crediting the source. Doing this cleanly means honoring upstream credit lines.
  • Don’t fork and never re-check. Skills evolve; the upstream may fix the issue or add features worth pulling. Schedule a quarterly check on every fork your team maintains.

Escalation. If the Skill touches functionality your team hasn’t approved (a new Connector, a new tool, anything that changes the data surface), the fork doesn’t change the approval requirement. File the same intake — through your AI lead, with the Council in the loop. A fork that edits prompt voice is a low-stakes change you can ship; a fork that adds an MCP server call is a different conversation.

The judgment to internalize: Skills are software. Forking, crediting, and documenting are the disciplines that keep software trustworthy. Treat your skills repository like a real repository, not a notes folder.

Dilemma 3 — The Auto-Publishing Routine

Situation. Three weeks ago, you set up a Routine to draft Smile Springs’ Monday-morning social posts. The Routine runs Sunday at 11pm, drafts the post, schedules it through the practice’s social-publishing tool (GoHighLevel or similar), and the post auto-publishes at 7am Monday. No human in the loop after the initial setup. It’s been running clean for three weeks — you check on your phone Monday morning, it’s always fine, by week three you stop checking carefully.

This Monday, a post auto-publishes containing a clinical claim with no medical disclaimer. The exact phrasing — “Regular cleanings prevent gum disease in 9 out of 10 patients” — needs sourcing or hedging. The voice-check Skill you use in chat would have caught it immediately. The Routine doesn’t run the voice-check. The post is live by 9am.

You catch it at 9:15. The clinical-team lead at Smile Springs catches it at 9:22 and messages you. The post needs to come down, the claim needs to be retracted or sourced, and someone (you) has to figure out how this happened, what else has shipped in three weeks that shouldn’t have, and what the fix is.

Decision factors. Four things to walk through:

  • Chain-of-trust review. Where did the failure mode enter? Probably the Routine prompt never specified the voice-check or the medical-claim guardrail. Maybe it did, and the LLM judged the claim was fine. Either way, the gap is that no deterministic check sat between Claude’s draft and the live publish. Architectural failure, not model failure.
  • Risk of recurrence. Same prompt, same lack of checkpoint — the next slip is a question of when, not if.
  • What to add as a control. Two shapes: a human review checkpoint (Routine drafts and queues; a human approves before publish), or a deterministic quality gate Claude fails closed on (Routine runs the voice-check and medical-claim check, refuses to schedule a post that fails either). For high-stakes content, both. For routine content, the deterministic gate is enough — but only if you’ve tested it fails closed, not open.
  • How fast to retroactively review prior posts. Every post since the Routine went live needs the checks run against it now. Not because every post is wrong, but because you don’t know yet.

Recommended path. Stop, retro, redesign, re-run.

  • Stop the auto-publish leg immediately. Pause the Routine, or change the final step from “publish” to “queue for human review.” Five minutes. Do it before anything else.
  • Run the voice-check and medical-claim checks against every post since the Routine went live. Twelve posts over three weeks. Build a list: which are clean, which have minor issues, which have the same level of problem as today’s. Paste each into a fresh chat, run the voice-check Skill, log the result.
  • Remediate the posts that fail. Today’s post comes down or gets edited. Others from the retroactive review get the same treatment, ranked by severity.
  • Document the chain-of-trust gap. Three paragraphs: what happened, what the gap was, what the new design will be. This goes to your AI lead and to the Council if relevant; it’s also the artifact future-you reads when someone asks “what’s our policy on auto-publish Routines?”
  • Redesign the Routine before turning it back on. The new shape: draft → run voice-check → run medical-claim check → if either fails, do not publish; post to a Slack channel with the failed draft and reason for human review. Only if both checks pass does the post get scheduled. Test the failure paths explicitly — feed the new Routine a deliberately bad post and confirm it fails closed.
  • Communicate to your AI lead within 24 hours. Don’t wait. The conversation is easier when you bring it than when they discover it through the client.

What NOT to do.

  • Don’t keep the Routine running with a vague “I’ll watch it more carefully” plan. Discipline can’t substitute for design. The next slip happens on the day you’re sick or in a meeting.
  • Don’t delete the Routine to avoid the conversation. The Routine isn’t the problem — the architecture around it is. Fixing the architecture is the work; deleting it erases the lesson.
  • Don’t assume the issue was a one-off. The retroactive review is non-negotiable.
  • Don’t roll out the redesigned Routine to other clients without testing the failure paths. “It works on Smile Springs” is not the same as “the failure mode actually fails closed.”

Escalation. Within 24 hours, write the chain-of-trust review and walk your AI lead through it. If the Council has a standing review for auto-publishing automations, this is the case study you bring; if not, your situation creates the policy. Don’t carry this alone — the value of the Council is that the next person facing this dilemma has a precedent.

The judgment to internalize: any automation that publishes externally needs a human review checkpoint OR a deterministic quality gate Claude itself can fail-closed on. Trust without verification doesn’t compose. Three clean weeks isn’t evidence the design is safe; it’s evidence you got lucky three times.

Section 2 — Edge Cases (the governance angle)

These are intermediate failure modes — the situations where Claude’s behavior is technically working as designed but produces a result you have to handle differently than the intro course covered. The diagnostic moves for each are in the troubleshooting reference; this section adds the governance angle — what to log, who to escalate to, when to stop.

When Claude refuses

The intro course taught: a refusal is sometimes the right answer. Don’t argue with it.

The intermediate reframe: distinguish a real refusal (Claude is correctly declining something that touches a safety guideline) from a false-positive refusal (the classifier tripped on phrasing in a clearly commercial context). The recovery moves are different.

For a real refusal, stop. Don’t argue your way past it — that’s how you turn a disciplined system into a rationalized one. Note what you were trying to do, why Claude declined, and bring it to your AI lead before pursuing a workaround. Sometimes the right answer is “we don’t do that work.”

For a false-positive refusal, reframe with explicit context: who you are, what audience the work is for, what you are not asking for. The refusal usually clears. If you reframe twice and it persists, treat it as a real refusal — the classifier is telling you the request lives in a region you should pause on, even if the surface phrasing seems benign.

The governance move in either case: if a refusal recurs across sessions on the same kind of work, log it. Pattern-level refusals are signal — your AI lead should know that an entire class of work is hitting safety filters, even if you’ve found local workarounds.

When the conversation runs out of context

Symptom: Claude starts losing earlier instructions, contradicting itself, forgetting the brand voice you established four hours ago.

The intermediate failure mode: pushing through the degraded session because you’ve invested time in it. Sunk cost is the enemy. A drifting session is producing worse output than a fresh session would, and every additional turn makes the drift harder to correct. The fix:

  • Stop. Recognize what’s happening — voice drift, instruction forgetting, contradictions across drafts.
  • Dump the current state to a file. Save the cleanest drafts and the working brief.
  • Restart in a clean session with the brief pinned in the first message. Re-paste the voice anchors. Re-paste the constraints. Treat the new session as canonical.

The governance move: never ship work from the second half of a degraded session without re-reviewing it against the brief, not against the prior draft. If Claude has been agreeing with itself for 30 turns and the voice has drifted, the latest draft is calibrated to the drift. Compare to the original brief, not the previous draft.

For published work, set a 90-minute session timer per deliverable. When the timer fires, if you’re not done, restart. The cost of starting fresh is much lower than the cost of shipping drift you didn’t notice.

When tool-use errors fail silently

Symptom: Claude says “I sent the email” or “I updated the spreadsheet.” The email isn’t in your Sent folder. The spreadsheet still says what it said an hour ago. The MCP server returned a malformed response, the Connector timed out, Computer Use clicked the wrong element — and Claude’s confidence about the result is disconnected from whether it actually happened.

This is the most consequential edge case in the intermediate set, because Claude’s natural-language confidence is hard to second-guess. “I just emailed the client the brief” sounds done. The brief is sitting in drafts, never sent, because the Gmail MCP returned an error Claude smoothed over.

The governance move: never trust tool-use output without verification. Add explicit “verify the result” steps to any prompt that uses tools. “After you send the email, search the Sent folder for the most recent message and quote the first line back to me. If you can’t find it, tell me the send failed.” That turns a probabilistic claim into a checkable one.

For Routines and Dispatched tasks especially — anything where you’re not watching Claude work — bake the verification step into the prompt. One extra turn; the benefit is a session whose output you can trust.

If you catch a silent tool-use failure, log it. MCP servers and Connectors fail in patterns; if your team’s Slack MCP is silently dropping messages on Tuesday afternoons, that’s a thing your AI lead should know about.

When stacked Skills conflict

Symptom: two Skills that work fine in isolation produce worse output together. Voice muddled, structure inconsistent, output reads like two people taking turns. Common when a structural Skill (a case-study formatter) and a voice Skill (a brand voice-check) load into the same session with overlapping rules.

Diagnostic: load Skills one at a time. Run the same input through each alone. If output quality is fine in isolation but degrades when both are loaded, you have a stacking conflict. The fix is usually to run sequentially — structural Skill first, save the output, then voice Skill in a fresh session on the saved output.

The governance move: when you notice a stacking conflict, document it. “Don’t load case-study-formatter and voice-check-smile-springs in the same session — run sequentially.” Future-you (and the next teammate) saves the diagnostic time.

If a Skill you’ve forked produces stacking conflicts with another Skill you maintain, the right answer is often to merge them. That’s a Skill-authoring exercise, not a triage move — schedule it rather than doing it under deadline pressure.

Section 3 — Keep Learning

You’ve finished seven modules and built a portfolio of artifacts. The forward path matters more than what’s behind you. Three concrete tracks for what to do next, plus the always-on practice that turns intermediate skill into expertise.

CCA-F Certification (Claude Certified Architect — Foundations)

Anthropic’s first official technical certification, launched March 2026. Optional, not required. Useful for anyone who wants formal recognition of their Claude proficiency or who’s going deep on systems-design work.

What it covers: agentic architecture (the highest-weighted domain — subagents, workflow decomposition, monolithic vs split), Claude Code configuration, prompt engineering and structured output, tool design and MCP integration, context management. The exam tests architectural tradeoffs under real constraints, not raw prompt technique.

Format: $99 per attempt, 120 minutes, 60 multiple-choice questions, passing score 720/1000. Free for the first 5,000 employees of Claude Partner Network organizations. Time to prepare: 10–20 hours from this course’s baseline.

Read the CCA-F Foundations reference for the full structure and Anthropic Academy course mapping. If you decide to pursue it, the study guide walks the topics module by module.

Anthropic Academy menu

Free, self-paced, official source. Beyond the intro course’s “Claude 101” entry point, the courses worth your time as an intermediate user:

  • Building with Claude — API fundamentals. Useful even when not building integrations directly; the conceptual frame helps when collaborating with someone who is.
  • Agent Skills Deep Dive — substantially deeper than this course’s Module 2. Right course if Module 2 felt thin.
  • Claude Code Workshop — hands-on, structured. The natural follow-on to Module 6 Builder track.
  • Responsible AI Deployment — directly extends this module. Right course if Section 1’s dilemmas felt under-rehearsed.

Each is 1–2 hours. Pick based on which Module 1–6 felt thinnest for you. The full catalog link is in the intro course’s Module 8. Bookmark it.

Community creators (categories, not channels)

YouTube creator landscape moves faster than any wiki article can keep up with. Four categories worth following:

  • Real-world Claude Code workflows. Creators whose content mix is roughly 80% practical / 20% bleeding-edge — actual workflows on actual projects, not feature demos.
  • Agentic systems and multi-agent patterns. Module 4 territory. Creators who walk multi-agent compositions end-to-end including model tiering and failure modes.
  • Prompt engineering at depth. Module 1 territory. Creators who treat prompts as artifacts you iterate on; the good ones publish v1 → v2 → v3 progressions.
  • Responsible AI / governance / safety. Module 7 territory. Smaller niche, slower-moving — but the right reading list when you hit a dilemma and want to see how others framed similar problems.

Find one creator per category. Follow them for a quarter. Drop ones whose content has stopped landing; replace with someone fresher. Working roster, not permanent loyalty. The intro course’s Module 8 has named picks current at publication; use as starting point.

Contributing to the WEO wiki

The wiki you’re reading is a Karpathy-pattern LLM-maintained vault. Contributing is one of the highest-leverage ways to deepen your understanding.

How contributions work:

  • Drop a useful source (PDF, transcript, article) into the vault’s raw/ folder. Say “compile” to the wiki’s Claude Code instance. The source gets ingested into the right topic cluster and cross-linked.
  • Ask a question against the wiki. If the answer requires synthesis across articles, the system can file the answer back as a new article. Your question becomes someone else’s reference.
  • Propose a connection between two articles in different topic folders. Cross-topic syntheses are first-class articles — often where the most useful applied knowledge lives.
  • Audit a section for stale claims. The wiki has a “lint” operation that flags drift, contradictions, and unsourced claims.

Why contributing works as a learning move: writing for the wiki forces you to know the material well enough that someone else’s question can be answered from your article. The strongest kind of learning — you can’t fake the depth, because the test is whether the next person can use what you wrote.

The vault’s operating manual lives in the project’s CLAUDE.md. You don’t need to memorize it; the schema does the heavy lifting. You drop sources in and ask good questions.

Continuing the practice

The course is seven modules. Real expertise is what you build with the kept artifacts after the course ends.

Three habits that compound:

  • Quarterly artifact review. A recurring 30-minute calendar block with your AI lead. Walk the artifacts you’ve kept. Which are you actively using? Which have gone stale? Which need an update because Claude’s surfaces shifted? Short review, large compounding — the library stays alive instead of decaying into dead files.
  • Teach the next person. The highest-leverage compounding move. Teaching forces articulation; the teammate ramps faster; you learn what you actually know vs what you’ve been faking. Both directions improve.
  • One new thing a month. One new Skill installed and vetted, or one new Routine shipped, or one Cowork Dispatch task tried, or one slash command authored. Achievable in an afternoon. Twelve a year is meaningful range.

Mel’s framing: the prompt library is a garden, not a museum. The artifacts you keep are the ones you tend. The ones you don’t tend rot quietly until the day you reach for them and find they don’t work anymore.

Section 4 — Try It [Both]

One exercise. Both tracks. ~15 min practice budget.

Walk one of the three Section 1 dilemmas from start to finish for your situation. The point is to make the decision-making concrete — pick a real Connector, Skill, or Routine you use or are considering, and run it through the playbook.

The steps:

  • Pick the artifact. A real one. A Connector you have authorized, a community Skill you’re considering, or an automation you’ve set up. Don’t pick a hypothetical — specificity is the value.
  • Identify which dilemma category it most resembles. PHI-adjacent (touches sensitive data), banned-phrasings (voice or behavior gap), or auto-publishing (ships output without a human checkpoint). One usually fits cleanly; if more than one fits, pick the highest-stakes match.
  • Walk the decision factors. Re-read the relevant Section 1 entry. Apply the factors to your case. Data sensitivity? Scope? Where do responses land? Audit trail?
  • Apply the recommended path. What shape of integration is right? What human checkpoint? What audit log? What’s the conservative-default starting position?
  • Identify the what-not-to-do moves. The shortcuts you’d be tempted to take under deadline pressure. Name them explicitly — the ones you’re tempted by are the ones you’re at risk of taking.
  • Define the escalation path. Who signs off before this goes live? What does the conversation with your AI lead look like? What triggers escalation to the Council?
  • Document the decision in a short note. Working doc, not polished policy. What the artifact is, which dilemma it resembled, what shape you’re shipping, what you decided to skip, when you’ll re-review. Half a page is enough.
  • File the note with your AI lead. This is the kept artifact for the module — and the practice that makes the next dilemma easier.

Why this matters more than the reading: the Section 1 dilemmas are useful only when translated to your own work. Reading once teaches the shape; walking your own case teaches the muscle. The 15 minutes you spend here is the 15 minutes that sticks.

Common Pitfalls

The five mistakes you’ll see most often around governance v2:

  • Treating governance as a one-time check at install. The Connector got approved, so it’s fine forever. Six months later the scope has drifted, audit retention expired, the team has changed, and nobody’s reviewed since launch. Governance is an ongoing practice; quarterly reviews are not optional for anything that touches sensitive data.
  • Assuming Claude won’t surface PHI because “I didn’t ask for it.” Verify scope, don’t trust intent. Claude can pull whatever the scope allows. If you don’t restrict scope, assume Claude will eventually surface every field the Connector can read.
  • Forking a Skill but not crediting the source. The fork is fine; the missing credit is sloppy. A skills repository full of un-credited forks loses lineage, and the next maintainer can’t tell what’s safe to update vs load-bearing. Credit lines cost nothing.
  • Skipping the audit log because “it’s just a draft.” Drafts written by an LLM with sensitive data in context are exactly the artifact you’ll need if something goes wrong. Drafts also become production faster than expected — last week’s outbox is next week’s send.
  • Confusing “Claude refused” with “Claude can’t.” Refusals are a feature. They’re how the system flags a request that lives in a region that should pause you, even when the surface phrasing seems benign. Treat refusals as signal, not as bugs to work around.

Key Takeaways

  • Governance v2 is what the rules don’t fully cover: edge cases, gray zones, dilemmas where multiple paths are technically allowed and you pick the right one.
  • The three canonical dilemmas — PHI-adjacent Connectors, Skills with banned phrasings, auto-publishing Routines — capture most situations intermediate users hit. Walk each to build the pattern recognition.
  • The conservative default is the right starting position when unsure. Scoped reads beat full access; human checkpoints beat unattended ships; explicit audit trails beat informal ones.
  • Edge cases (refusals, context exhaustion, silent tool-use failures, stacked Skill conflicts) need both a diagnostic move and a governance move. Log patterns, not just cases.
  • The CCA-F is optional but useful for architecture-adjacent roles. Anthropic Academy adds substantial depth — pick courses based on which modules felt thinnest.
  • Contributing to the WEO wiki is one of the highest-leverage learning moves. Writing for the wiki forces depth you can’t fake.
  • Quarterly artifact reviews keep your library alive. The library you don’t tend decays.
  • Trust without verification doesn’t compose. Any automation that publishes externally needs a human checkpoint or a deterministic quality gate that fails closed.
  • The WEO AI Council is the escalation path for dilemmas this playbook can’t fully resolve. Using it is judgment, not weakness.
  • Teach the next person. Highest-leverage compounding move available.

Where To Go Next

You’ve finished the course. Ten hours of intermediate work, six prior modules, a portfolio of kept artifacts. The closing path forks by track:

Operator track:

  • Keep building your prompt library. The artifacts you use are the ones worth keeping; the rest will decay naturally.
  • Install one new Skill per month. Vet it. Decide whether it stays. Treat the install as an experiment, not a permanent commitment.
  • Ship one Cowork Dispatch task per month. The asynchrony is the point — you’ll find new shapes of work that benefit from “send Claude off, come back to the result.”

Builder track:

  • Ship one slash command per month. Your personal CLI grows by accretion; twelve a year is meaningful range.
  • Run /ultrareview on every load-bearing PR. The multi-agent review pattern catches things a solo review misses.
  • Contribute one wiki article per quarter. Writing for the wiki is depth you can’t fake — your article becomes the reference your teammates work from.

Both tracks:

  • Take the CCA-F if you want formal recognition. Optional. Useful for systems-design-adjacent roles.
  • Run a quarterly artifact review with your AI lead. Thirty minutes, four times a year, keeps the library alive.
  • Teach the next person what you learned. The highest-leverage compounding move. The teammate you onboard ramps faster; you learn what you actually know.

The intro course closed with: “come back to Module 7 before every new kind of client work.” This course closes with the next layer up: come back to this Module 7 the first time you hit a dilemma that doesn’t have a textbook answer. The three scenarios above are the shape of the problem; the playbook is the response. The judgment is what you build between them.

Course complete. The artifacts you keep using are the ones that earned their keep. The ones that didn’t get used can be deleted without ceremony — they served their purpose during the practice run. What you carry forward is muscle, not paperwork.

Graph View

Backlinks