Riseplan from Roast & Rise
AI Continuity with OpenAI, Open Models, and Local Fallbacks
A practical continuity plan for using hosted AI, open-weight models, and local fallback without locking your work to one provider.
Fable 5 made the quiet risk visible: AI access can change overnight. This RisePlan helps you choose OpenAI-style hosted APIs, open-weight models, local fallback, or a hybrid path without locking your work to one provider.
Course thesis
Fable 5 turned a hidden dependency into a visible business risk. Strong teams will still use hosted frontier AI where it wins. They will also design the data paths, evals, prompts, and fallbacks that let work continue when access changes.
What you leave with
Use hosted AI with clear eyes, know when open or local fallback matters, and build a 30-day continuity test for real work.
For
Founders, operators, IT/security leads, and AI owners who use hosted AI tools and need a practical plan for provider change, model shutdowns, policy shifts, and fallback options.
Workflow
Choosing and running AI workflows with hosted providers, open-weight options, and local fallbacks while preserving data, evals, governance, and continuity.
Change
You can map AI provider dependency, choose when hosted APIs, open-weight models, or local fallback fit, design portable workflows, and prove a fallback path in 30 days.
What you can do
Use these as checks while you move through the plan.
Explain the Fable 5 shutdown as a provider-dependency warning for real AI workflows.
Compare hosted API, private hosted, open-weight vendor deployment, local runtime, and hybrid routing.
Map where a workflow depends on provider access, data rules, prompts, schemas, integrations, and review.
Build a portability kit with prompt, schema, eval set, data export path, logs, and adapter notes.
Run a primary-versus-fallback drill and turn the result into a continuity decision memo.
Chapters
01
The Shutdown Lesson: AI Access Is a Dependency
Map where hosted AI already powers the work, who controls access, what data crosses the line, and what must keep running if the provider path changes.
Why this matters in the workflow
Anthropic said on June 12, 2026 that a US government directive required it to disable Fable 5 and Mythos 5 for all customers while it complied with foreign-national access restrictions. Source. Axios framed the episode as a live test of who controls frontier model deployment. Source.
The lesson is operational. If a workflow depends on one provider, one model, one region, one account, or one safety policy staying available, that workflow carries dependency risk. OpenAI, Anthropic, Google, Mistral, local models, and internal tools can all be part of the answer. First you need to know where each dependency sits.
The working model
Create an AI dependency map. For each important workflow, record the model/provider, access path, data sent, retention or compliance rule, model-specific prompts, integration points, fallback option, and owner. The map turns a vague platform risk into something a manager can inspect.
Quality checklist
The map names a real workflow, not a generic use case.
Provider, access path, data flow, and owner are explicit.
Model-specific prompts, schemas, or integration assumptions are captured.
Fallback is named honestly, including `none` where that is true.
A workflow owner has reviewed the one-week disruption question.
Common mistakes
Talking about AI risk in general without naming the actual workflow.
Listing the provider while ignoring the integration path and data flow.
Assuming an enterprise contract is the same thing as continuity.
Treating a human workaround as a fallback without checking time, quality, and capacity.
Leaving ownership blank.
Checkpoint
Can you show one workflow where the provider, access path, data flow, fallback, and owner are visible on one page?
Exercise
Map the AI Dependencies in One Live Workflow
Steps
- Pick one real workflow that already uses AI or is likely to within the next month. Examples: proposal drafting, support triage, code review, research synthesis, internal knowledge search.
- Record the current or planned primary provider. This could be OpenAI, Anthropic, Google, a vertical SaaS tool, an open-weight model served by a vendor, or a local model.
- Write down the access path: API, SaaS UI, partner integration, private cloud, local runtime, or employee account.
- List what data enters the system, what output comes back, what logs are kept, and who owns review.
- Name the fallback today. If there is none, write `none` in the cell. Do not soften it.
- Share the map with the workflow owner and ask: what would break if this provider disappeared for one week?
Use this at work tomorrow
Bring the dependency map to the next AI discussion and ask what breaks first if the primary model path goes dark.
02
Choose the Lane: Hosted API, Open-Weight, Local, or Hybrid
Choose the right AI lane for the work: OpenAI-style hosted API, enterprise hosted deployment, open-weight vendor deployment, local model, or hybrid routing.
Why this matters in the workflow
The Fable 5 shutdown does not mean every team should abandon hosted AI. That would be the lazy lesson. Hosted providers such as OpenAI can still be the fastest path to strong capability, managed infrastructure, safety tooling, and product velocity. Open-weight or local models matter when the workflow needs control, data residency, offline resilience, cost leverage, or a fallback path.
The working model
Use a provider-lane matrix. Compare five lanes for the workflow: hosted frontier API, enterprise/private hosted deployment, open-weight model managed by a vendor, self-hosted open-weight/local model, and hybrid routing. Score each lane on capability, data boundary, latency, cost control, portability, governance load, and continuity.
Quality checklist
At least four provider lanes are compared.
Scores reflect the workflow, not general model hype.
Hosted AI is considered where capability and speed matter.
Open-weight or local options are considered where control and continuity matter.
Primary and fallback recommendations are both written.
The riskiest assumption is named for testing.
Common mistakes
Turning the Fable 5 incident into a blanket anti-hosted policy.
Choosing local before checking whether the workflow needs frontier reasoning.
Choosing hosted before checking data, retention, region, or exit needs.
Treating open-weight as operationally simple.
Forgetting that a fallback can be narrower than the primary path.
Checkpoint
Can you defend the primary AI lane and the fallback lane for one workflow without making hosted or local a religion?
Exercise
Build Your Provider-Lane Matrix
Steps
- Use the workflow from your dependency map.
- Compare at least four lanes: hosted API, enterprise/private hosted deployment, open-weight vendor deployment, and local/self-hosted model. Add hybrid if it is realistic.
- Score each lane as Good, Fair, or Poor for capability, data boundary, speed to build, cost control, portability, governance load, and continuity.
- Write a one-sentence primary recommendation.
- Write a one-sentence fallback recommendation.
- Mark the biggest assumption that needs proof before anyone builds.
Use this at work tomorrow
Take one AI workflow and write the primary lane, fallback lane, and assumption to test before the next vendor or architecture call.
03
Design for Portability Before You Need It
Turn a model-dependent workflow into a portable one by separating prompts, data, evals, schemas, logging, and provider adapters.
Why this matters in the workflow
Most lock-in happens quietly. A prompt is tuned to one model. A JSON response shape depends on one provider. Retrieval data lives inside one SaaS product. Evals are missing, so nobody can compare replacement quality. Then access changes and the team discovers the workflow was glued to the vendor.
The working model
Treat the model as one replaceable part of the workflow. Keep the prompt library, business rules, retrieval data, output schema, eval set, and review logs outside the provider. Use a thin provider adapter so hosted APIs and open or local runtimes can be compared against the same task.
Quality checklist
Prompt is versioned and stored outside a single provider UI.
Input and output contracts are written clearly.
Eval set includes at least 10 realistic examples.
Retrieval or company knowledge can be exported or recreated.
Primary and fallback adapter notes are both present.
Comparison logs are enough to judge quality, cost, latency, and review effort.
Common mistakes
Keeping prompts only inside a provider playground.
Letting each model return a different shape with no shared contract.
Skipping eval examples, then judging fallback quality by vibe.
Putting company knowledge inside a tool that cannot export it cleanly.
Missing logs that explain why one provider was better or worse.
Checkpoint
Can another team member run the same task through a second provider or local model using your prompt, schema, evals, and data path?
Exercise
Build the Portability Kit
Steps
- Pick the same workflow from your provider-lane matrix.
- Save the core prompt outside the provider UI. Add version, owner, and purpose.
- Define the input and output contract. Example: required fields, JSON shape, citations required, confidence labels, human review rule.
- Build a small eval set with 10 realistic examples. Include easy, typical, and awkward cases.
- Record the data source. If retrieval is used, name where the knowledge lives and how it can be exported.
- Write adapter notes for the primary provider and one fallback provider or local model path.
- Decide which logs and review notes you need to compare models fairly.
Use this at work tomorrow
Take one prompt out of the provider UI, give it a schema and eval set, and make it runnable somewhere else.
04
Run the Fallback Drill
Test whether your fallback can handle the critical slice of work when the primary hosted AI path is unavailable or no longer acceptable.
Why this matters in the workflow
A fallback that never runs is a wish. When a provider changes access, retires a model, shifts policy, or suffers an outage, the team needs proof that another path can carry at least the critical slice of work.
The working model
Run a fallback drill over 30 days. Use the same task, same input contract, same output contract, and same eval set across the primary hosted path and the fallback path. Measure quality, latency, cost, review effort, data handling, and recovery time. The fallback can be narrower than the primary. It only needs to protect the work that cannot stop.
Quality checklist
The primary and fallback paths run the same examples.
Quality, latency, cost, review effort, and data handling are scored.
The fallback standard is realistic and written.
The activation trigger is clear.
A named owner knows how to activate the fallback.
Limitations are visible rather than hidden.
Common mistakes
Testing a toy prompt instead of the real critical task.
Letting the fallback use easier inputs than the primary path.
Demanding the fallback match the primary path on every dimension.
Forgetting human review capacity during fallback mode.
Failing to define the trigger that activates fallback.
Checkpoint
Can you show a completed fallback scorecard that proves what the alternate path can and cannot carry?
Exercise
Run a Primary-versus-Fallback Test
Steps
- Pick one critical task from the portability kit.
- Run 10 eval examples through the primary path. Example: hosted OpenAI API or current SaaS AI workflow.
- Run the same examples through the fallback path. Example: another hosted provider, open-weight vendor deployment, or local runtime.
- Score both paths on task quality, latency, cost, review minutes, data handling, and failure modes.
- Write the minimum fallback standard. Example: `fallback must produce usable first drafts for 70% of standard cases within 2x review time`.
- Decide the recovery trigger. Example: provider outage over 4 hours, policy change blocks the workflow, data rule changes, price spike, model retirement.
- Assign who activates fallback and where the runbook lives.
Use this at work tomorrow
Run five real examples through the primary path and one fallback path, then write what the fallback is allowed to handle.
05
Make the Model Portfolio Decision
Turn the evidence into a clear AI portfolio call: keep the hosted path, add a fallback, switch lanes, self-host a narrow workflow, or stop.
Why this matters in the workflow
The endpoint is a portfolio decision, not a model preference. Some work should stay on a hosted frontier API. Some work should move to enterprise/private hosted deployments. Some should get an open-weight or local fallback. Some should stay manual until the data and review rules are ready.
The working model
Use a continuity decision memo. It turns dependency map, provider-lane matrix, portability kit, and fallback drill into one call: keep, hedge, switch, self-host, or stop. The decision must name the owner, trigger, budget, data rule, and next review date.
Quality checklist
Decision is one of the named portfolio moves.
Evidence comes from the actual outputs.
Operating rule is clear enough to follow under pressure.
Owner, trigger, budget/capacity, data rule, and review date are present.
The memo separates normal mode from disruption mode.
Stakeholders know where the memo lives.
Common mistakes
Ending with a preference instead of an operating rule.
Making one portfolio decision for every workflow.
Ignoring who pays for and maintains the fallback.
Leaving the trigger vague.
Forgetting to revisit the decision as model access, pricing, and policy change.
Checkpoint
Can a manager read your memo and know exactly which AI path to use, when to switch, who owns it, and when to review it?
Exercise
Draft the Continuity Decision Memo
Steps
- Pull in the four outputs you created: dependency map, provider-lane matrix, portability kit, and fallback scorecard.
- Choose one decision: keep hosted primary, add fallback, split by data sensitivity, switch provider, self-host a narrow workflow, or stop the AI path.
- State the evidence in five lines or fewer.
- Name the operational rule. Example: `OpenAI remains primary for non-sensitive proposal outlines; local fallback handles outline-only mode during disruption`.
- Add owner, activation trigger, budget limit, data rule, and review date.
- Share the memo with the workflow owner, security/data owner, and manager who owns the business outcome.
Use this at work tomorrow
Write one continuity memo for your highest-risk AI workflow and make the trigger visible to the people who would activate it.
30-day path
Week 1: Map one AI dependency and compare provider lanes for that workflow.
Week 2: Build the portability kit: prompt, schema, eval examples, data export path, logs, and adapter notes.
Week 3: Run the fallback drill across primary and alternate paths, then score quality, latency, cost, review effort, and data handling.
Week 4: Write the continuity decision memo and review the trigger, owner, data rule, budget/capacity limit, and next review date.
Success signals
AI dependency map completed for one live workflow and reviewed with the owner.
Provider-lane matrix names a primary path and fallback path without treating hosted or local as ideology.
Portability kit includes prompt, schema, eval examples, data export path, and adapter notes.
Fallback drill compares the same examples across primary and fallback paths.
Continuity memo names the operating rule, activation trigger, owner, data rule, and review date.
Reflection prompts
Which AI-assisted workflow would hurt first if access changed?
Where are we using hosted AI because it is the best tool, and where are we using it because it was easiest?
What proof would make a fallback credible enough to trust under pressure?
Manager checklist
Choose one workflow where AI dependency matters.
Name the primary provider path and fallback path.
Review the portability kit before more automation is built.
Approve the continuity memo and fallback trigger.
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