Riseplan from Roast & Rise

Claude Fable 5 Work Readiness Sprint

Selection, deployment, and review of Anthropic Fable 5 for high-value enterprise knowledge work, engineering, research synthesis, and automation while integrating model, policy, and security controls.

Learners will diagnose what changed, choose and justify model-driven workflows, articulate and adjust controls for risk and data management, and deliver a 30-day adoption test with practical artifacts.

Course thesis

Teams can make frontier models work for them safely, precisely, and with clear value by diagnosing the change, mapping the right use, adapting controls, and running a measured 30-day adoption path.

What you leave with

Learner

Founders, managers, team leads, security leads, AI/product owners responsible for making decisions around adopting Anthropic's Claude Fable 5 and Claude Mythos 5 in their workflows.

Workflow

Behavior

Outcomes

What the learner should be able to do after finishing this public Riseplan.

Explain the differences between Fable 5, Mythos 5, and earlier Claude models, including public/restricted access and expectations.

Identify and prioritize workflows that align with Fable 5's state-of-the-art capabilities.

Adapt risk and data policies for frontier models, accounting for safeguards, fallbacks, and retention changes.

Run practical tests with clear prompts, review paths, and cost-quality tracking.

Produce, review, and use the four core artifacts: model-use decision map, workflow risk register, prompt/test harness, and cost-and-quality scorecard.

Lead a 30-day measured adoption sprint with checkpoints and reporting.

Chapters

The Leap: What Changed with Fable 5 and Mythos 5

Understand Anthropic's new state-of-the-art models, Fable 5 and Mythos 5: their public/restricted access, strengths, boundaries, pricing, and implications for work.

Why this matters in the workflow

Before you decide if, how, and where to use Claude Fable 5 at work, you need clarity. Anthropic's Fable 5 and Mythos 5 represent a leap in what's public, what's guarded, and what's at stake. Teams that understand these contours avoid expensive mistakes, wasted sprints, and security headaches.

Situational awareness comes first: What's on the table, what's under lock, and where are the lines.

The working model

Worked example

**Claude Fable 5 / Mythos 5 Fact Sheet (example)** --- **Model Name:** Claude Fable 5 (public), Claude Mythos 5 (restricted) **Model Class:** Mythos-class (above Claude Opus) **Access:** - Fable 5: Public via API and consumption-based Enterprise immediately. Included in subscriptions through June 22; usage credits from June 23. - Mythos 5: Access limited to Glasswing partners and certain infrastructure/cyberdefense/biology research partners. **Safeguards:** - Fable 5: Enhanced guardrails on cyber, bio, chemistry, and distillation. These tasks route to Claude Opus 4.8. - Mythos 5: Same engine, fewer safeguards for trusted partners. **Strengths:** - State-of-the-art on nearly all tested benchmarks. - Best at complex, long-horizon work: software engineering, knowledge work, vision, scientific research, reasoning. **Fallback/Limitations:** - About 95% of requests stay with Fable 5; sensitive requests rerouted. - Universal jailbreak prevention not possible (1,000+ hours red-teaming; no universal fails found yet). **Data/Retention:** - All Mythos-class (including Fable 5) traffic retained 30 days for safety monitoring. - Data not used for model training. **Pricing:** - $10 per million input tokens - $50 per million output tokens **Internal Checkpoints Needed:** - Are current workflows among the supported, non-restricted use cases? - Do we require Mythos 5 features, or does Fable 5 suffice? - Who owns policy updates for data retention and fallback review? ---

Artifact template

Claude Fable 5 / Mythos 5 Fact Sheet Template

**Model Names:**

**Model Class:**

**Access:**

- Fable 5:

- Mythos 5:

**Safeguards:**

**Model Strengths/Best-Use Areas:**

**Fallbacks/Limitations:**

**Data/Retention Policy:**

**Pricing:**

**Immediate Questions/Clarifications for Our Team:**

Quality checklist

Only evidence-based entries; no speculation.

Side-by-side separation (Fable 5 vs Mythos 5) is clear and explicit.

Safeguards and fallback behaviors are described accurately.

At least one checkpoint or clarification item noted for internal follow-up.

Pricing, access, and retention policy are visible and correct.

Common mistakes

Copying vendor marketing lines instead of launch facts.

Leaving out fallback or retention policies.

Treating Mythos 5 as routinely accessible to non-partners.

Filling the sheet with wish lists or speculative use cases.

Not noting internal questions or missing clarity.

Checkpoint

Can you explain to a peer or executive the difference between Fable 5 and Mythos 5, including model class, public/restricted access, key strengths, and why safeguards matter?

Exercise

Build Your Fable 5 / Mythos 5 Fact Sheet

### Steps 1. Open a blank doc (use the template below). 2. Fill in each section with evidence from the supplied launch facts only-not hype, not speculation. 3. For each field, note ONE thing that must be clarified internally (e.g., "Do we need Glasswing for our use case?"). 4. Review with a peer or team lead for any missed boundary or operational edge. **You will use this fact sheet in sprint kickoffs, briefings, and to anchor downstream decisions.**

Artifact

Draft your Claude Fable 5 / Mythos 5 fact sheet using (only) the provided evidence. Mark anything you believe needs direct clarification for your workflow.

Use this at work tomorrow

Book a sprint kickoff, present your fact sheet, and use it to set boundary conditions before further workflow mapping.

Choosing High-Value Use Cases (Without Wishful Thinking)

Build a Fable 5 model-use decision map grounded in launch-stage strengths, explicit exclusions, and live workflow needs.

Why this matters in the workflow

Frontier models break old boundaries. They also break old habits. The temptation: try the new tool on every problem. The real work: know where Fable 5 is likely to deliver compounding value, where the guardrails defer, and when to keep a human in the loop. This is how teams avoid noisy pilots, false positives, and wasted cycles while surfacing cases where Fable 5 changes what's possible.

The working model

- Fable 5 is public, Mythos-class, and tuned for long, complex, high-reasoning tasks. Think: software engineering, technical synthesis, knowledge work, research, visual understanding. - Safety filters mean sensitive cyber, bio, chemistry, or distillation detour to Claude Opus 4.8, effectively blocking those lanes for most teams. - Public Fable 5 is not the whole Mythos 5: the trusted-access variant runs with fewer safeguards, but access is restricted (security, infra, sometimes bio/chemistry, Glasswing partners). - The right approach: select high-value, high-complexity, human-reviewed tasks. Exclude areas likely to trigger false positives or fallback, or where model limits would introduce risk or temptation to overtrust.

Worked example

| Workflow | Model Role | Status | Rationale | |-----------------------------------|--------------------|------------------|---------------------------------------------| | Technical documentation | Draft first version | Approved | Fable 5 excels at long-form synthesis, can speed up docs, requires human review. | | Code vulnerability scanning | Run static analysis | Blocked | Trafficked requests may fallback to Opus; company policy excludes cyber risk. | | Customer onboarding visuals | Generate guides | Approved | Visual tasks cited as a Fable 5 strength; subject to manual accuracy check. | | Automated compliance checklist | Final review step | Paused for review | May need more policy clarity on data retention and fallback handling. | | Broad competitor analysis | Synthesize sources | Approved | Knowledge work and synthesis are strengths; output is non-sensitive. | | Internal password auditing | Automated check | Blocked | Sensitive security task; Fable 5 will not support, and use violates controls. | | Workflow exclusions: Do not attempt to automate cyber exploit generation or sensitive bio-chemistry synthesis with Fable 5.

Artifact template

|-----------------------------|---------------------|----------------------|----------------------------------------------|

| | | | |

List at least two explicit workflow exclusions (e.g., 'Do not use Fable 5 for X or Y.')

Quality checklist

All major team workflows are considered and listed.

Each use case has a short, evidence-grounded rationale.

Statuses are not generic; each is Approved, Blocked, or Paused, with a reason.

At least two explicit exclusions are listed.

Reviewed with at least one peer or manager for hidden risks or wishful thinking.

No use case contradicts published Fable 5 fallback and safety boundaries.

Common mistakes

Listing every use case as Approved without scrutiny or exclusions.

Failing to specify why a workflow is Blocked or Paused.

Allowing wishful thinking to override safety or fallback evidence.

Ignoring Anthropic's stated model boundaries (e.g., trying sensitive cyber or bio use).

Leaving the map unreviewed-missing deeper workflow risks.

Checkpoint

Can you show your decision map (with exclusions and rationale) to a leader and clearly defend each choice?

Exercise

Draft Your Fable 5 Decision Map (Real Work, Real Boundaries)

**You will create a one-page model-use decision map for your team's workflows.** **Steps:** 1. List up to seven key workflows you or your team own. 2. For each, briefly describe what the model would do if included. 3. Assess each against Fable 5's public strengths, safety fallbacks, and any domain or data considerations. 4. Decide for each: **Approved**, **Blocked**, or **Paused for review**. Add rationale (1-2 lines). 5. Identify at least two explicit exclusions. 6. Review with a peer or manager. Ask: Are any wishful or risky? What's missing? Use the template below for clean structure.

Artifact

Draft and fill your decision map for real workflows. Share for peer review.

Use this at work tomorrow

Map your real workflows, approve or block each use, and make the exclusions explicit-review before any pilot.

Updating Risk, Data, and Policy Controls

Adapt your workflows to Fable 5's new realities: build a working risk register and update controls for data, access, fallback, and security. Make your team ready for safe, evidence-backed, and reviewable model deployment.

Why this matters in the workflow

Claude Fable 5 does not just raise the ceiling on AI-powered work. It redraws the map for risk, data, and governance. It brings new strengths and new exposures. Safeguards are real but imperfect. Data retention is mandated. Access paths and fallback rules change, especially for Mythos 5. If your controls lag behind the model's profile, your adoption is a liability, not a leap. Updating the risk register is your proof of awareness and intent. Updating policies is your translation into action.

The working model

Every credible Fable 5 deployment covers four control points: - **Access and review:** Who gets to use the model, for what types of work, and under what human review? - **Fallbacks and blocked tasks:** When/where does the system block, revert, or route requests (like unsafe cyber requests) to other models (e.g., Claude Opus 4.8)? - **Data handling and retention:** How do you comply with Anthropic's 30-day retention and Glasswing's safety monitoring, but keep unauthorized flows from creeping in? - **Logging and audit:** What records exist for prompts, decisions, fallbacks, and incidents? A live risk register tracks each workflow, named risks, mapped controls, and ownership. You make your risk visible and actionable.

Worked example

**Workflow:** Engineering team uses Fable 5 to generate technical documentation from product specs. **Risks:** 1. Sensitive IP or client info included in prompts. 2. Model returns outdated or hallucinated standards. 3. Workflow exceeds token budget. **Controls:** 1. Strip sensitive identifiers via pre-processing before prompt. Owner: Data steward. 2. Require a human reviewer to fact-check every output before publishing. Owner: Doc lead. 3. Set monthly cap alert per workflow and review monthly cost/utility. Owner: Eng manager. **Policy update:** Security policy now includes: "For Fable 5 use, technical prompts must be run through the masking filter and outputs are reviewed before release. All activity is logged for 30 days and reviewed by the product security team."

Artifact template

Workflow name:

Risks (list at least 3):

Controls for each risk (fallbacks, review, caps, logging, retention):

Owner for each control:

Policy section updated:

Date of latest review:

Quality checklist

Are all key risks (including data, misuse, fallback, review) named for each workflow?

Does each risk have a mapped, concrete control, not just general intent?

Are fallback/routing and human review mandates explicit where needed?

Is data retention/handling adapted to Anthropic's requirements?

Is ownership assigned and up to date?

Is there visible redlining or an update in your live policy or process doc?

Common mistakes

Leaving fallback/blocked prompt paths undefined.

Failing to note or act on mandatory 30-day data retention.

Making controls too abstract-e.g., 'review required' with no assignment or timing.

Omitting cost/budget control as a risk.

Claiming perfect jailbreak resistance.

Creating a register but not assigning owners.

Checkpoint

Can you show, with your risk register, how two specific controls/policy changes address live Fable 5 adoption hazards?

Exercise

Build and Redline Your Fable 5 Workflow Risk Register

1. **Identify one real workflow** (e.g., AI draft code review, customer email response, regulatory research summary) where Fable 5 could be used today. 2. **List at least three plausible risks** for this workflow under Fable 5 (e.g., sensitive data exposure, false positive block, review step skipped). 3. **Map each risk to a specific control.** Fill in fallback routing, human review mandates, caps, retention notes, and logging/audit triggers. 4. **Redline one section of your current policy** (data policy, security protocol, or workflow guide) to bake in your new control for Fable 5's realities. Make the change visible. 5. **Assign an owner for each risk-control pair.** 6. **Save and circulate the register to your core team.** You should spend no more than 15 minutes to capture the reality as it stands now, not a perfect future.

Artifact

Draft and revise a live Workflow Risk Register for one Fable 5 deployment, then update at least one part of your policy documentation to reflect new retention or fallback control needs.

Use this at work tomorrow

Redline your data policy for Fable 5's 30-day retention and fallback control. Circulate your filled-in risk register for one workflow before the next adoption discussion.

Test Harness: Prototyping and Proving Value in 30 Days

Build and run a practical test harness for Claude Fable 5. Log prompt/workflow outcomes in a cost-and-quality scorecard. Surface evidence before rolling out.

Why this matters in the workflow

You cannot lead with hype, or with benchmarks from an R&D team you've never met. Teams need to prove that Fable 5 creates value on your real work, within your environment, at today's cost. A practical test harness lets you move from pitch to proof.

This isn't about exhaustive testing. It's about showing if a frontier model delivers on three fronts: *quality*, *cost*, and *review effort* across your priority use cases. The gaps are often subtle: high output quality paired with drift; low cost, but more review required; surprising failure modes that don't appear in Anthropic's public benchmarks. A scorecard makes these patterns visible at a glance, for the work that matters most to your team.

The working model

Worked example

**Scenario:** Security lead wants to semi-automate log anomaly analysis. - **Prompt/Input:** "Analyze the attached application log for anomalies relating to user authentication between June 1-5, 2026. List possible security incidents, their severity, and an evidence summary." - **Run:** Feeds log into Fable 5. - **Tokens:** 30,000 in / 8,000 out - **Time:** 2 min - **Output:** Model lists four suspect events, scores severity, one false positive flagged by reviewer. Fable 5 completes request, no fallback triggered. - **Review:** 8 min reviewing summary and raw logs. - **Cost:** $0.30 (input) + $0.40 (output) = $0.70 - **Result:** Useful first pass, saves reviewer 20 min vs. manual triage. Reviewer recommends prompt tightening, adds exclusion for common benign events.

Artifact template

|-----------|--------------------|-------------------------------|----------------------|-----------|------------|------------|------------|---------------------|--------------------|----------------|---------------------|-------------|

Quality checklist

Prompt and inputs reflect real (not synthetic) workflow.

Tokens/cost math is documented and matches launch pricing.

Each test is logged with full reviewer notes and an explicit quality score.

All blocked, fallback, or odd-edge outputs are noted.

There is a clear takeaway for next action (scale, tune, or pause/test further).

Common mistakes

Using idealized demo prompts instead of workflow reality.

Skipping reviewer notes or only logging positive outcomes.

Misunderstanding token pricing, leading to cost surprise later.

Ignoring cases where the model falls back or refuses for safety reasons.

Not filling in the scorecard at the time of trial, making later analysis unreliable.

Checkpoint

Have you run at least one live Fable 5 trial, filled the scorecard, and briefed a reviewer? If so, you're ready for structured reporting and a manager's review.

Exercise

Build Your Fable 5 Test Harness and Scorecard

**15-minute Exercise:** 1. Select one high-value workflow your team wants to pilot with Claude Fable 5 (e.g., code review, research summary, business communication, visual document analysis). 2. Write a real prompt or input sample for this workflow (redact sensitive details). 3. Run it through Fable 5 (API, UI, or partner tool as available). 4. Capture: - Prompt - Output - Tokens in/out (estimate, if needed) - Time to complete - Did the model complete the task or fall back? - Human review required? - Reviewer notes/results - Final cost calculation (price per tokens at current rates) 5. Enter all entries into the scorecard template below. 6. Briefly summarize whether Fable 5 performed above, at, or below expectation for this workflow. Flag a possible next action (scale, tune, or pause). --- _Artifact: Fable 5 Test Result & Scorecard (see template)_

Artifact

Run one live workflow trial using Fable 5. Log the outcomes in your scorecard for team review.

Use this at work tomorrow

Launch a Fable 5 workflow pilot today-use your own prompt, log the outcome in a scorecard, and bring evidence to your next team meeting.

Checkpoints, Reporting, and the Manager's Checklist

Guide adoption with clear checkpoints, actionable review tools, and a decision-ready report for Claude Fable 5's first 30 days at work.

Why this matters in the workflow

Frontier models like Claude Fable 5 don't run on autopilot. Leaders must see, check, and decide at each adoption stage. The point? Move from experiment to proof, then real value.

A manager who waits for data before acting is often too late. Without visible checkpoints, sprints drift. Costs creep. Risks hide.

A clear adoption checklist focuses the team, clarifies your proof path, and signals when to stop or scale. Reporting gives leadership a real view: what's working, what needs fixing, where rules still lag the model.

Worked example

*Scenario:* Product manager at a midsize SaaS company pilots Fable 5 in customer support automation. 1. **Checklist** includes - Confirm fact sheet shared with ops and security (Owner: PM, Week 1) - Decision map reviewed and stored (Owner: AI Lead, Day 4) - Updated data policy approved (Owner: DPO, Week 2) - Test prompts documented with output review dates (Owner: QA Lead, Week 2-3) - Cost and quality scorecard updated (Owner: PM, Ongoing) - 30-day review scheduled (Owner: PM, Set by Week 1) 2. **Reporting Template** covers - Key metrics: cost per ticket, first-contact resolution, flagged decision points (e.g. fallback triggers, blocked data flows) - Edge cases: cost spike investigation, two flagged ethics reviews - Final decision: Proceed to gradual scale (if pending DPO approval); pause expansion if not. *Both documents are shared live, checkpoint owners are clear, and the 30-day review makes the go/stop call unambiguous.*

Artifact template

Manager Adoption/Review Checklist

[ ] Fact sheet presented to core stakeholders (Owner: _________, Review date: _________)

[ ] Decision map reviewed and documented (Owner: _________, Review date: _________)

[ ] Data/risk/policy update completed and logged (Owner: _________, Review date: _________)

[ ] Test prompts/runbook signed off (Owner: _________, Review date: _________)

[ ] Workflow risk register updated (Owner: _________, Review date: _________)

[ ] Cost-and-quality scorecard current (Owner: _________, Review date: _________)

[ ] 30-day adoption review scheduled (Owner: _________, Review date: _________)

[ ] All blockers/edge cases raised and assigned (Owner: _________, Review date: _________)

[ ] Go/Stop/Next decision made (Owner: _________, Review date: _________)

30-Day Reporting Template

Pilot scope and objectives:

- ____________________________________________________________

Key checkpoints & owners:

- ____________________________________________________________

Weekly status & gaps:

- ____________________________________________________________

Metrics: Cost, output quality, blocker log

- ____________________________________________________________

Risks, blocker details, and owner:

- ____________________________________________________________

Key lessons: (What's working, what's not)

- ____________________________________________________________

Go/Stop/Next call: (Decision, rationale, next actions)

- ____________________________________________________________

Quality checklist

Checkpoints and review dates are specific-no placeholders.

Each owner is named and knows their responsibility.

Checklist triggers a real decision or action, not just a record.

Key metrics (cost, output, blockers) are in the report.

Report includes clear go/stop/next recommendation-no ambiguity.

Blockers and risks are logged with owners and next steps.

Common mistakes

Leaving checkpoint owners blank or assuming 'the team' owns it.

Using vague language: 'review as needed,' 'check output quality,' etc.

Missing a visible go/stop/next trigger, drifting past 30 days without action.

Checklist and report not shared (or updated) outside the trial team.

Failing to log risks or blockers until after the sprint fails.

Checkpoint

Can you show a completed checklist with owners, review dates, and a reporting template with visible decision triggers-ready for real review?

Exercise

Build Your Manager Adoption Checklist and 30-Day Review Report

### Step 1: Draft your team's *Manager Adoption/Review Checklist* using the template below. Identify who owns each checkpoint and when it will be reviewed. ### Step 2: Create a *30-Day Reporting Template* for your pilot (copy/paste or duplicate the template below). List your starting parameters, what you track, and your go/stop/next decision trigger. ### Step 3: Share both with your team. Commit to a review meeting before the 30-day window ends. ### Step 4: (Optional) Schedule a 15-minute session for peer review-does any checkpoint lack an owner, or is any trigger unclear?

Artifact

Draft and own your team's adoption checklist and reporting template for your Claude Fable 5 pilot. Assign checkpoint owners and clear review dates.

Use this at work tomorrow

Share the checklist and reporting template at your team kickoff. Assign owners and schedule the review today.

30-day path

Week 1: Complete the fact sheet and decision map, review with stakeholders.

Week 2: Build and adapt risk register; update relevant policies and controls.

Week 3: Set up prompt/test harness, run live workflow tests, and start scoring outcomes.

Week 4: Complete the manager checklist, run review session, and produce 30-day sprint report.

Checkpoint: Use each artifact in a real decision or process update, then document what holds and what needs revision.

Success signals

Learner can accurately explain Fable 5 vs Mythos 5 to a peer or executive.

Decision map is specific, grounded, and includes clear exclusions.

Risk register reflects updated model realities and at least two documented control changes.

Prompt/test harness logs at least three use cases with cost and quality tracked.

Manager adoption checklist and review report show clear decision points with supporting evidence.

Reflection prompts

Where does this topic show up in real work?

What behavior should change first?

What evidence would prove this Riseplan worked?

Manager checklist

Choose one owner for the behavior change.

Use the exercise on live work.

Review the artifact before scaling the habit.

Decide what changes after 30 days.

Want this shaped around your company?

Risey can research your company foundation first, then build a version of this path around your real workflows, customers, and culture.

Start with your company