Revision 7T · Full Tutorial Edition · Updated 1 September 2026
PWR-235 · SELF GUIDED full tutorial
Map one critical function, expose shared backup failures and rehearse a safe fictional failover
This lesson teaches redundancy and resilience through a fictional service map. You will define the minimum function, trace dependencies, test whether a backup has capacity and independence, write a failover trigger, run a benign tabletop, test failure of both routes, recover and assign maintenance. A plan or spare object is not counted as resilience until the function test passes.
What you will produceThe learner produces a dependency and failover map for one fictional service and demonstrates a tabletop switch to an independent route within the declared recovery time.
Full step-by-step individual tutorial · TLU-PWR-235
The learner produces a dependency and failover map for one fictional service and demonstrates a tabletop switch to an independent route within the declared recovery time.
Map people, premises, technology, supplier, information and authority dependencies.
Declare no acceptable fallback and stop the fictional service.
Qualified help is required for
Business continuity, cybersecurity, emergency, clinical, infrastructure or public-service planning.
Any live failover, outage, load test or hidden fault injection.
Approval of recovery time, data loss, staffing, supplier or equity trade-offs.
Never do this from the page alone
Disable a real system, account, network or service for practice.
Count duplicated items in one failure domain as independent backups.
Promise resilience from a document that has not been safely tested by the responsible organisation.
2 · Get ready
Gather what you need and check the starting conditions
What you need
Fictional community information service with a primary laptop, spare laptop, one shared cloud account, paper telephone list, separate mailbox and four staff roles.
Function/dependency table, common-cause map, failover trigger card and tabletop clock.
Three supplied failure cards plus an observer rubric. F1 says the shared cloud account is locked while both laptops still work; the expected switch is to paper intake plus the separate mailbox. F2 says the trained coordinator is absent; the expected response is to name the authorised alternate role before proceeding. F3 says both paper forms and the separate mailbox are unavailable; minimum service cannot be met, so the tabletop stops and escalates to the service owner rather than inventing another route.
Before you start
Label every item fictional and keep the exercise disconnected from live systems.
Name the smallest acceptable service and fictional maximum interruption before mapping backups.
Agree that any resemblance to a live incident ends the exercise and requires authorised review.
3 · The method
Follow these steps in order
Define minimum function
State the fictional caller, verified callback output, acceptable quality and two-day maximum interruption.
Why: Resilience cannot be judged without a service target.
Check: The function is observable and deliberately smaller than “keep everything running.”
Map primary dependencies
List people, building, power, device, account, network, supplier, information and decision authority.
Why: Invisible dependencies cause a backup to fail with the same upstream service.
Check: Every dependency has an owner or unknown marker.
Describe backup capacity
Record what each alternative can deliver, for how long, to whom and with what loss of quality.
Why: A backup can exist but be too small or inaccessible.
Check: Capacity is compared directly with the minimum function.
Test independence
Mark shared power, building, credential, supplier, data source and key person.
Why: Redundancy inside one failure domain is fragile.
Check: The map shows which failures take down both routes.
Write the failover trigger
Specify the event, decision role, ordered switch steps, communication and time limit.
Why: Improvised switching can cause duplicate or conflicting work.
Check: A participant can follow the trigger without additional explanation.
Run the benign failover
Draw a fictional primary-failure card, start the clock and switch records/roles to the approved alternative without touching live systems.
Why: A tabletop checks sequence and ownership safely.
Check: The minimum service resumes within the fictional target or the gap is recorded.
Test both-routes failure
Draw the relevant common-cause or backup-failure card and choose degraded service, safe stop or external handoff.
Why: Resilience includes naming when fallback capacity no longer meets minimum service.
Check: No participant invents an unauthorised third route.
Recover and reconcile
Return to the primary in the story, compare records, resolve duplicates and tell users which version is current.
Why: Failback can create a second incident.
Check: The current record and service owner are unambiguous.
Assign maintenance
Set owners and dates for contacts, access, paper copies and the next test; verify one correction.
Why: Backups decay when contacts, credentials and role knowledge are never exercised.
Check: The repaired dependency passes a matched retest.
4 · Worked example
See the whole method used once
Scenario
A fictional service answers ordinary community questions within two working days using one cloud account; a paper telephone list and a separate shared mailbox are candidate fallbacks.
Walkthrough
The learner defines minimum service as recording the caller’s question and giving a verified callback within two days.
The dependency map shows both primary laptop and spare laptop use the same cloud account, so the spare is not independent for account failure.
They choose the paper intake form plus separate mailbox as the tabletop route and switch in six minutes after an account-failure card.
A second card removes the trained coordinator; the team discovers the alternate role is undocumented, assigns a role card and verifies it in a matched rerun.
Result
The tabletop exposes one false redundancy and repairs a key-person dependency. It does not validate the live organisation’s continuity.
5 · Right and wrong
Compare correct or safer execution with the common wrong version
Right and wrong comparison
Moment
Right / safer
Wrong / riskier
Why it matters
Defining criticality
Choose the smallest service users actually need.
Mark every activity critical and leave no defensible recovery order.
If everything is critical, trade-offs and recovery order remain hidden.
Counting backups
Check fallback capacity and whether primary and backup share common failures.
Count a spare laptop on the same account as independent.
The shared credential can disable both.
Failing over
Use a trigger, owner and ordered communication.
Let several people improvise switches at once.
Uncoordinated action creates duplicate or lost work.
Ending capacity
Use degraded service, safe stop or authorised handoff.
Keep promising full service after both routes fail.
Honest limits prevent hidden unsafe work.
6 · Common mistakes
Spot the error and apply the correction
Common mistakes and corrections
Mistake
Fix
Backup object with no capacity test
Compare volume, duration, access and quality against the minimum function.
Two resilience routes share the same account credentials.
Map credentials, identity provider and data source as dependencies.
Resilience depends on one undocumented role holder.
Document an alternate role and test cold handoff.
The primary route returns without reconciling fallback records.
Add record reconciliation, user notification and current-version checks.
A resilience test gap has no closure owner.
Assign owner, resources, due date and a matched verification card.
7 · Practice
Turn the steps into a usable skill
First session
Define minimum service and interruption target.
Map primary and backup dependencies and common causes.
Write the failover trigger and role handoff.
Run one primary-failure and one both-routes-failure tabletop.
Reconcile the fictional records, assign one correction and retest it.
Repeat plan
Review dependencies quarterly and after supplier, staff, building, technology or authority changes. The responsible organisation sets real exercise cadence; self-guided work remains fictional.
Progress when
The learner distinguishes duplicate from independent capacity.
The tabletop meets the declared switch target without role or version ambiguity.
Both-routes failure ends in a planned degraded service, safe stop or authorised handoff.
Do not progress when
The exercise touches a live system, real users, confidential data or regulated service.
Recovery time, acceptable loss or authority cannot be set by the participants.
A hidden fault injection or live outage is proposed.
8 · Check the result
Measure what changed
Tabletop continuity of one fictional critical function
How: Record minimum service, recovery target, capacity, shared dependencies, switch time, role handoff, both-routes response, failback and correction closure.
Good result: A good result resumes the minimum fictional service within target using a genuinely independent route and completes reconciliation.
This does not prove: It does not prove real capacity, equitable continuity, cybersecurity, compliance or recovery under a live disruption.
Self-check
What is the smallest service and maximum interruption?
Which single failure disables both primary and backup?
Who declares failover and who owns the service afterward?
How are records reconciled during recovery?
9 · Stop, adapt or get help
Keep the safety boundary practical
Stop and get help
Stop if any step could affect a live service, account, employee, user or confidential record.
Stop when participants lack authority to define service loss, failover or acceptable burden.
Route real continuity, cybersecurity, clinical, emergency or infrastructure work to the accountable organisation and specialists.
Accessibility and adaptations
Include accessible communications, alternate formats and support roles as dependencies and capacity requirements.
Use readable role cards, diagrams, AAC and asynchronous tabletop input.
Test the intended user’s access to the fallback; do not treat a technically working route as resilient if it excludes them.
10 · Evidence and limits
Why these instructions are here
official guidance
NIST contingency-planning guidance describes business impact, alternate processing, testing, recovery and maintenance; a written plan alone is not demonstrated capacity.
All practice uses a fictional service and tabletop cards.
Redundancy is measured against one function, failure and capacity.
A passed tabletop cannot validate live recovery time or outcome.
A plan or backup object cannot guarantee resilience.
Official standards specify practices rather than demonstrate outcomes; a written plan cannot establish capacity, recovery time or equitable continuity.
Open the complete canonical research register
Official normative system supportLimiting / contrary
Progress is saved only in this browser on this device.
Step-by-step learner mode
Each activity includes its success check, a nearby accessible alternative and an “I’m stuck” correction path. Alternatives preserve the target where possible; when they change the task, Titan labels them as related rather than equivalent.
01
Define minimum function
State the fictional caller, verified callback output, acceptable quality and two-day maximum interruption.
Why this step exists
Resilience cannot be judged without a service target.
Success check
The function is observable and deliberately smaller than “keep everything running.”
I’m stuck on this step
Reset: Re-read this authored instruction — “State the fictional caller, verified callback output, acceptable quality and two-day maximum interruption.” — and its success check, then attempt only this step.
Possible snag: The result from “State the fictional caller, verified callback output, acceptable quality and two-day maximum interruption.” does not yet meet this declared check: The function is observable and deliberately smaller than “keep everything running.”
Correction: Return to the start of “Define minimum function”, reduce complexity or pace, and repeat only the part needed to satisfy: “The function is observable and deliberately smaller than “keep everything running.””
Stop / get help: Stop if any step could affect a live service, account, employee, user or confidential record.
02
Map primary dependencies
List people, building, power, device, account, network, supplier, information and decision authority.
Why this step exists
Invisible dependencies cause a backup to fail with the same upstream service.
Success check
Every dependency has an owner or unknown marker.
I’m stuck on this step
Reset: Re-read this authored instruction — “List people, building, power, device, account, network, supplier, information and decision authority.” — and its success check, then attempt only this step.
Possible snag: Two resilience routes share the same account credentials.
Correction: Map credentials, identity provider and data source as dependencies.
Stop / get help: Stop if any step could affect a live service, account, employee, user or confidential record.
03
Describe backup capacity
Record what each alternative can deliver, for how long, to whom and with what loss of quality.
Why this step exists
A backup can exist but be too small or inaccessible.
Success check
Capacity is compared directly with the minimum function.
I’m stuck on this step
Reset: Re-read this authored instruction — “Record what each alternative can deliver, for how long, to whom and with what loss of quality.” — and its success check, then attempt only this step.
Possible snag: Backup object with no capacity test
Correction: Compare volume, duration, access and quality against the minimum function.
Stop / get help: Stop if any step could affect a live service, account, employee, user or confidential record.
04
Test independence
Mark shared power, building, credential, supplier, data source and key person.
Why this step exists
Redundancy inside one failure domain is fragile.
Success check
The map shows which failures take down both routes.
I’m stuck on this step
Reset: Re-read this authored instruction — “Mark shared power, building, credential, supplier, data source and key person.” — and its success check, then attempt only this step.
Possible snag: The result from “Mark shared power, building, credential, supplier, data source and key person.” does not yet meet this declared check: The map shows which failures take down both routes.
Correction: Return to the start of “Test independence”, reduce complexity or pace, and repeat only the part needed to satisfy: “The map shows which failures take down both routes.”
Stop / get help: Stop if any step could affect a live service, account, employee, user or confidential record.
05
Write the failover trigger
Specify the event, decision role, ordered switch steps, communication and time limit.
Why this step exists
Improvised switching can cause duplicate or conflicting work.
Success check
A participant can follow the trigger without additional explanation.
I’m stuck on this step
Reset: Re-read this authored instruction — “Specify the event, decision role, ordered switch steps, communication and time limit.” — and its success check, then attempt only this step.
Possible snag: The result from “Specify the event, decision role, ordered switch steps, communication and time limit.” does not yet meet this declared check: A participant can follow the trigger without additional explanation.
Correction: Return to the start of “Write the failover trigger”, reduce complexity or pace, and repeat only the part needed to satisfy: “A participant can follow the trigger without additional explanation.”
Stop / get help: Stop if any step could affect a live service, account, employee, user or confidential record.
06
Run the benign failover
Draw a fictional primary-failure card, start the clock and switch records/roles to the approved alternative without touching live systems.
Why this step exists
A tabletop checks sequence and ownership safely.
Success check
The minimum service resumes within the fictional target or the gap is recorded.
I’m stuck on this step
Reset: Re-read this authored instruction — “Draw a fictional primary-failure card, start the clock and switch records/roles to the approved alternative without touching live systems.” — and its success check, then attempt only this step.
Possible snag: The result from “Draw a fictional primary-failure card, start the clock and switch records/roles to the approved alternative without touching live systems.” does not yet meet this declared check: The minimum service resumes within the fictional target or the gap is recorded.
Correction: Return to the start of “Run the benign failover”, reduce complexity or pace, and repeat only the part needed to satisfy: “The minimum service resumes within the fictional target or the gap is recorded.”
Stop / get help: Stop if any step could affect a live service, account, employee, user or confidential record.
07
Test both-routes failure
Draw the relevant common-cause or backup-failure card and choose degraded service, safe stop or external handoff.
Why this step exists
Resilience includes naming when fallback capacity no longer meets minimum service.
Success check
No participant invents an unauthorised third route.
I’m stuck on this step
Reset: Re-read this authored instruction — “Draw the relevant common-cause or backup-failure card and choose degraded service, safe stop or external handoff.” — and its success check, then attempt only this step.
Possible snag: Resilience depends on one undocumented role holder.
Correction: Document an alternate role and test cold handoff.
Possible snag: A resilience test gap has no closure owner.
Correction: Assign owner, resources, due date and a matched verification card.
Stop / get help: Stop if any step could affect a live service, account, employee, user or confidential record.
08
Recover and reconcile
Return to the primary in the story, compare records, resolve duplicates and tell users which version is current.
Why this step exists
Failback can create a second incident.
Success check
The current record and service owner are unambiguous.
I’m stuck on this step
Reset: Re-read this authored instruction — “Return to the primary in the story, compare records, resolve duplicates and tell users which version is current.” — and its success check, then attempt only this step.
Possible snag: The primary route returns without reconciling fallback records.
Correction: Add record reconciliation, user notification and current-version checks.
Stop / get help: Stop if any step could affect a live service, account, employee, user or confidential record.
09
Assign maintenance
Set owners and dates for contacts, access, paper copies and the next test; verify one correction.
Why this step exists
Backups decay when contacts, credentials and role knowledge are never exercised.
Success check
The repaired dependency passes a matched retest.
I’m stuck on this step
Reset: Re-read this authored instruction — “Set owners and dates for contacts, access, paper copies and the next test; verify one correction.” — and its success check, then attempt only this step.
Possible snag: The result from “Set owners and dates for contacts, access, paper copies and the next test; verify one correction.” does not yet meet this declared check: The repaired dependency passes a matched retest.
Correction: Return to the start of “Assign maintenance”, reduce complexity or pace, and repeat only the part needed to satisfy: “The repaired dependency passes a matched retest.”
Stop / get help: Stop if any step could affect a live service, account, employee, user or confidential record.
Correct versus incorrect execution
These accessible process diagrams are built from the tutorial’s own right/wrong teaching. They are not anatomical illustrations and do not add technique beyond the canonical tutorial.
Defining criticality — If everything is critical, trade-offs and recovery order remain hidden.
Correct / safer
Choose the smallest service users actually need.
Wrong / riskier
Mark every activity critical and leave no defensible recovery order.
Counting backups — The shared credential can disable both.
Correct / safer
Check fallback capacity and whether primary and backup share common failures.
Wrong / riskier
Count a spare laptop on the same account as independent.
Failing over — Uncoordinated action creates duplicate or lost work.
Use degraded service, safe stop or authorised handoff.
Wrong / riskier
Keep promising full service after both routes fail.
Method-structure checklist
10 of 10 structural checks present
✓ Ordered, Power-specific instructions — present
✓ Every activity has a success check — present
✓ Materials or supplied records are declared — present
✓ Measurement or assessment rule is present — present
✓ Tutorial-specific troubleshooting is present — present
✓ Stopping or escalation boundary is present — present
✓ Every activity has an adjacent alternative — present
✓ Correct-versus-incorrect comparison is present — present
✓ Evidence context is bound to the Power record — present
✓ Planning metadata is present — present
The method-readiness band and presence checklist assess tutorial presentation and are separate from evidence quality for the underlying Power. They are automated editorial aids, not human approval.
Manual editorial sign-off: Pending. This tutorial must not display a human-approved state until an identified editor signs the exact content hash.