Revision 7T · Full Tutorial Edition · Updated 1 September 2026
PWR-214 · SUPERVISED full tutorial
Share a bounded task with automation while keeping mode, disagreement, override and degraded control visible
The corridor simulator displays MANUAL, AUTO or SHARED while the person commands direction and automation may slow or steer around foam obstacles. Compare all three modes, record intent conflicts and override delay, then practise assistance loss. Safe handling here does not establish shared control of a real mobility or manipulation device.
What you will produceWith a qualified team, the learner completes a simulated navigation or manipulation task in manual, automatic and shared modes, logs intent conflicts and demonstrates override.
Method8 numbered Power-specific steps
Practice authorityFull method with qualified supervision where stated
Full step-by-step individual tutorial · TLU-PWR-214
With a qualified team, the learner completes a simulated navigation or manipulation task in manual, automatic and shared modes, logs intent conflicts and demonstrates override.
Participant choice — Allocate decisions explicitly: The team writes that the person chooses destination and may stop; automation may slow and propose obstacle avoidance within the corridor.
Learner failure role — Practise degraded control: The team removes automation assistance; the learner uses the approved manual or alternative fallback or stops in safe state.
Shared autonomy outcome review may inspect “Task success, intent errors, override latency, workload, collisions and failure recovery versus manual, autonomous and shared control” under the configured comparator.
Qualified help is required for
Team-owned gate — Make mode visible: Check the persistent mode label, transition sound or vibration and current override control.
Provider-controlled rehearsal — Record manual baseline: Complete the corridor in manual mode and log time, path error, interventions, workload and collisions.
Scheduling owner for Shared autonomy: the responsible team. Repeat rule: The clinical-engineering team sets mode order, repetitions and progression. Use one matched route per mode with rest; repeat only after intent errors, overrides, workload and agency are reviewed.
Never do this from the page alone
Unsafe Shared autonomy choice: Let the system infer all goals silently.
Second failure that ends progression: Treat automation correction as always right.
Solo use is barred for Shared autonomy. Trigger: Stop for collision, pain, dizziness, distress, loss of balance, visual/sensory overload or unsafe fatigue.
2 · Get ready
Gather what you need and check the starting conditions
What you need
Declared Shared autonomy fixture: A wheelchair-style simulator travels a marked virtual corridor. The person commands direction; automation may slow or steer around foam obstacles. A bright mode label shows MANUAL, AUTO or SHARED.
Setup aid for Make mode visible: Verify decision allocation, mode indicator, limits, override, logs and fallback.
Shared autonomy log: Task success, intent errors, override latency, workload, collisions and failure recovery versus manual, autonomous and shared control; retain Shared autonomy errors, assistance, stop and fallback.
Shared-autonomy evidence grid: use “Shared control of a medical robot with haptic guidance” and the BCI mobile-robot shared-control study to record person command, automation contribution, mode display, disagreement, override and outcome. Use the NIST Privacy Framework to define who may inspect command traces. The supplied corridor remains a simulator, and the qualified team controls mode changes and degraded-assistance tests.
Before you start
Obtain qualified clinical-engineering supervision and participant consent for the exact simulator or approved device.
Verify decision allocation, mode indicator, limits, override, logs and fallback.
Start check for Shared autonomy: Every decision has a human or machine owner.
Top-of-sheet stop for Shared autonomy: Stop for mode uncertainty, unexpected intervention, repeated intent error, failed override, lost link or limit breach.
3 · The method
Follow these steps in order
Allocate decisions explicitly
The team writes that the person chooses destination and may stop; automation may slow and propose obstacle avoidance within the corridor.
Why: Every decision has a human or machine owner.
Check: Every decision has a human or machine owner.
Make mode visible
Check the persistent mode label, transition sound or vibration and current override control.
Why: The learner can identify the mode without guessing from motion.
Check: The learner can identify the mode without guessing from motion.
Why: The simulator cannot leave the declared envelope.
Check: The simulator cannot leave the declared envelope.
Record manual baseline
Complete the corridor in manual mode and log time, path error, interventions, workload and collisions.
Why: Shared performance has a matched comparator.
Check: Shared performance has a matched comparator.
Run shared mode
The learner states destination, automation proposes path changes and the learner confirms or overrides according to the protocol.
Why: Each machine intervention and human response is logged.
Check: Each machine intervention and human response is logged.
Name disagreements
When automation steers right but the learner intends left, say “conflict,” stop or override and record whose evidence controlled the result.
Why: Intent error is not hidden inside successful arrival.
Check: Intent error is not hidden inside successful arrival.
Practise degraded control
The team removes automation assistance; the learner uses the approved manual or alternative fallback or stops in safe state.
Why: Loss of automation does not cause continued uncontrolled movement.
Check: Loss of automation does not cause continued uncontrolled movement.
Compare all modes
Review task success, intent errors, override latency, workload, collisions and agency in manual, auto and shared conditions; participant chooses next step.
Why: Shared mode is not declared best from completion alone.
Check: Shared mode is not declared best from completion alone.
4 · Worked example
See the whole method used once
Scenario
A wheelchair-style simulator travels a marked virtual corridor. The person commands direction; automation may slow or steer around foam obstacles. A bright mode label shows MANUAL, AUTO or SHARED.
Walkthrough
The team writes: learner chooses the blue destination; automation may slow or propose a route; learner owns stop.
The learner identifies SHARED mode and completes the corridor manually first with one wall contact.
In shared mode, automation slows before the foam obstacle and the learner accepts the route change.
At the next marker automation steers right while the learner chose left; the learner says “conflict” and overrides within two seconds.
The team removes assistance; the learner moves to the marked safe bay using approved manual control.
The review compares path, contact, override time, workload and reported agency across modes.
Result
The learner completes the simulator route and handles one intent conflict and one assistance loss. This does not establish safe shared control for a real mobility or manipulation device.
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
Decision rights
State what person and automation each control.
Let the system infer all goals silently.
Hidden allocation makes errors and responsibility unclear.
Mode awareness
Use a persistent label and transition cue.
Infer mode from how the device feels.
Mode confusion delays override; this distorts the shared-control corridor.
Disagreement in shared-control corridor
Stop, label conflict and log it.
Treat automation correction as always right.
Intent inference can be wrong even when the route completes.
Degraded mode
Rehearse manual/alternative fallback or safe stop.
Assume automation will remain available during the shared-control corridor.
Assistance loss can create abrupt workload and control gaps.
6 · Common mistakes
Spot the error and apply the correction
Common mistakes and corrections
Mistake
Fix
Let the system infer all goals silently.
Put destination, motion and stop ownership on one card.
Infer mode from how the device feels.
Confirm mode before every start and transition.
Treat automation correction as always right.
Preserve user intent and inspect the trigger.
Assume automation will remain available.
Test a planned transition under supervision.
7 · Practice
Turn the steps into a usable skill
First session
Shared-control corridor visit: A wheelchair-style simulator travels a marked virtual corridor. The person commands direction; automation may slow or steer around foam obstacles. A bright mode label shows MANUAL, AUTO or SHARED.
Visible mode and override: Make mode visible: Check the persistent mode label, transition sound or vibration and current override control.
Matched manual route: Record manual baseline: Complete the corridor in manual mode and log time, path error, interventions, workload and collisions.
Logged shared intervention: Run shared mode: The learner states destination, automation proposes path changes and the learner confirms or overrides according to the protocol.
Assistance-loss transition: Practise degraded control: The team removes automation assistance; the learner uses the approved manual or alternative fallback or stops in safe state.
Repeat plan
The clinical-engineering team sets mode order, repetitions and progression. Use one matched route per mode with rest; repeat only after intent errors, overrides, workload and agency are reviewed.
Progress when
Every decision has a human or machine owner.
The learner can identify the mode without guessing from motion.
The simulator cannot leave the declared envelope.
Mode is correctly identified, intent conflicts are logged, override meets the protocol time, degraded mode reaches safe state and shared control improves the agreed outcome without unacceptable agency loss.
Do not progress when
Do not continue while this error remains: Let the system infer all goals silently.
Pause until this correction works: Confirm mode before every start and transition.
This Shared autonomy stop ends the block: Stop for mode uncertainty, unexpected intervention, repeated intent error, failed override, lost link or limit breach.
8 · Check the result
Measure what changed
Task success, intent errors, override latency, workload, collisions and failure recovery versus manual, autonomous and shared control
How: Configured fixture: A wheelchair-style simulator travels a marked virtual corridor. The person commands direction; automation may slow or steer around foam obstacles. A bright mode label shows MANUAL, AUTO or SHARED. The provider logs “Make mode visible”, every “Run shared mode” result, the “Practise degraded control” response and Task success, intent errors, override latency, workload, collisions and failure recovery versus manual, autonomous and shared control. Mark MANUAL, AUTO or SHARED on every route row, then log the person’s command, automation correction, override, assistance loss, collision and workload; an improvement counts only within a clearly named mode.
Good result: Mode is correctly identified, intent conflicts are logged, override meets the protocol time, degraded mode reaches safe state and shared control improves the agreed outcome without unacceptable agency loss.
This does not prove: Boundary for Shared autonomy: “Task success, intent errors, override latency, workload, collisions and failure recovery versus manual, autonomous and shared control” describes only A wheelchair-style simulator travels a marked virtual corridor. The person commands direction; automation may slow or steer around foam obstacles. A bright mode label shows MANUAL, AUTO or SHARED. It cannot establish “The robot always knows what the user wants”.
Self-check
Without the example, demonstrate: Every decision has a human or machine owner.
Find the fault in this attempt: “Let the system infer all goals silently.” Apply “Put destination, motion and stop ownership on one card.”; what changes?
What evidence in the completed record shows that this is wrong: “Infer mode from how the device feels.”?
Shared autonomy stop decision: Stop for mode uncertainty, unexpected intervention, repeated intent error, failed override, lost link or limit breach.
9 · Stop, adapt or get help
Keep the safety boundary practical
Stop and get help
Stop for mode uncertainty, unexpected intervention, repeated intent error, failed override, lost link or limit breach.
Stop for collision, pain, dizziness, distress, loss of balance, visual/sensory overload or unsafe fatigue.
Do not use the lesson in public, clinical or hazardous settings or change autonomy level outside the responsible team.
Accessibility and adaptations
Provide mode through combined visual, audio and tactile cues and an accessible override.
Use slower simulation, larger corridor or step mode while keeping decision-rights and failure checks.
10 · Evidence and limits
Why these instructions are here
primary research
Registered support for Shared autonomy: “Shared control of a medical robot with haptic guidance”. It bears on Task success, intent errors, override latency, workload, collisions and failure recovery versus manual, autonomous and shared control inside the Shared autonomy fixture. It does not validate “The robot always knows what the user wants”.
Constraint for Shared autonomy, drawn from “Continuous shared control of a mobile robot with brain–computer interface and autonomous navigation for daily assistance”: Studies were small or used nondisabled participants; intent inference, slower travel and failure-state agency remain unresolved.
Privacy design for Shared autonomy: minimise approved data in “A wheelchair-style simulator travels a marked virtual corridor. The person commands direction; automation may slow or steer around foam obstacles. A bright mode label shows MANUAL, AUTO or SHARED.” Keep Shared autonomy provenance and access visible before interpreting Task success, intent errors, override latency, workload, collisions and failure recovery versus manual, autonomous and shared control.
Shared autonomy boundary: interpret “Task success, intent errors, override latency, workload, collisions and failure recovery versus manual, autonomous and shared control” only for A wheelchair-style simulator travels a marked virtual corridor. The person commands direction; automation may slow or steer around foam obstacles. A bright mode label shows MANUAL, AUTO or SHARED.
A successful result does not establish “The robot always knows what the user wants”.
Shared autonomy limiting finding: Studies were small or used nondisabled participants; intent inference, slower travel and failure-state agency remain unresolved.
No perfect-performance claim for Shared autonomy: the evidence register does not make “Task success, intent errors, override latency, workload, collisions and failure recovery versus manual, autonomous and shared control” universal, consequence-free or flawless in A wheelchair-style simulator travels a marked virtual corridor. The person commands direction; automation may slow or steer around foam obstacles. A bright mode label shows MANUAL, AUTO or SHARED.
Scope remains Shared autonomy: A wheelchair-style simulator travels a marked virtual corridor. The person commands direction; automation may slow or steer around foam obstacles. A bright mode label shows MANUAL, AUTO or SHARED. Recheck the comparator, support and “Task success, intent errors, override latency, workload, collisions and failure recovery versus manual, autonomous and shared control” after any configuration change.
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
Allocate decisions explicitly
The team writes that the person chooses destination and may stop; automation may slow and propose obstacle avoidance within the corridor.
Why this step exists
Every decision has a human or machine owner.
Success check
Every decision has a human or machine owner.
I’m stuck on this step
Reset: Re-read this authored instruction — “The team writes that the person chooses destination and may stop; automation may slow and propose obstacle avoidance within the corridor.” — and its success check, then attempt only this step.
Possible snag: Let the system infer all goals silently.
Correction: Put destination, motion and stop ownership on one card.
Possible snag: Assume automation will remain available.
Correction: Test a planned transition under supervision.
Stop / get help: Stop for mode uncertainty, unexpected intervention, repeated intent error, failed override, lost link or limit breach.
02
Make mode visible
Check the persistent mode label, transition sound or vibration and current override control.
Why this step exists
The learner can identify the mode without guessing from motion.
Success check
The learner can identify the mode without guessing from motion.
I’m stuck on this step
Reset: Re-read this authored instruction — “Check the persistent mode label, transition sound or vibration and current override control.” — and its success check, then attempt only this step.
Possible snag: Infer mode from how the device feels.
Correction: Confirm mode before every start and transition.
Stop / get help: Stop for mode uncertainty, unexpected intervention, repeated intent error, failed override, lost link or limit breach.
Reset: Re-read this authored instruction — “Engineers configure speed, corridor, obstacle clearance, stop, manual/degraded mode and safe state.” — and its success check, then attempt only this step.
Possible snag: The result from “Engineers configure speed, corridor, obstacle clearance, stop, manual/degraded mode and safe state.” does not yet meet this declared check: The simulator cannot leave the declared envelope.
Correction: Return to the start of “Set bounds and fallback”, reduce complexity or pace, and repeat only the part needed to satisfy: “The simulator cannot leave the declared envelope.”
Stop / get help: Stop for mode uncertainty, unexpected intervention, repeated intent error, failed override, lost link or limit breach.
04
Record manual baseline
Complete the corridor in manual mode and log time, path error, interventions, workload and collisions.
Why this step exists
Shared performance has a matched comparator.
Success check
Shared performance has a matched comparator.
I’m stuck on this step
Reset: Re-read this authored instruction — “Complete the corridor in manual mode and log time, path error, interventions, workload and collisions.” — and its success check, then attempt only this step.
Possible snag: The result from “Complete the corridor in manual mode and log time, path error, interventions, workload and collisions.” does not yet meet this declared check: Shared performance has a matched comparator.
Correction: Return to the start of “Record manual baseline”, reduce complexity or pace, and repeat only the part needed to satisfy: “Shared performance has a matched comparator.”
Stop / get help: Stop for mode uncertainty, unexpected intervention, repeated intent error, failed override, lost link or limit breach.
05
Run shared mode
The learner states destination, automation proposes path changes and the learner confirms or overrides according to the protocol.
Why this step exists
Each machine intervention and human response is logged.
Success check
Each machine intervention and human response is logged.
I’m stuck on this step
Reset: Re-read this authored instruction — “The learner states destination, automation proposes path changes and the learner confirms or overrides according to the protocol.” — and its success check, then attempt only this step.
Possible snag: The result from “The learner states destination, automation proposes path changes and the learner confirms or overrides according to the protocol.” does not yet meet this declared check: Each machine intervention and human response is logged.
Correction: Return to the start of “Run shared mode”, reduce complexity or pace, and repeat only the part needed to satisfy: “Each machine intervention and human response is logged.”
Stop / get help: Stop for mode uncertainty, unexpected intervention, repeated intent error, failed override, lost link or limit breach.
06
Name disagreements
When automation steers right but the learner intends left, say “conflict,” stop or override and record whose evidence controlled the result.
Why this step exists
Intent error is not hidden inside successful arrival.
Success check
Intent error is not hidden inside successful arrival.
I’m stuck on this step
Reset: Re-read this authored instruction — “When automation steers right but the learner intends left, say “conflict,” stop or override and record whose evidence controlled the result.” — and its success check, then attempt only this step.
Possible snag: Treat automation correction as always right.
Correction: Preserve user intent and inspect the trigger.
Stop / get help: Stop for mode uncertainty, unexpected intervention, repeated intent error, failed override, lost link or limit breach.
07
Practise degraded control
The team removes automation assistance; the learner uses the approved manual or alternative fallback or stops in safe state.
Why this step exists
Loss of automation does not cause continued uncontrolled movement.
Success check
Loss of automation does not cause continued uncontrolled movement.
I’m stuck on this step
Reset: Re-read this authored instruction — “The team removes automation assistance; the learner uses the approved manual or alternative fallback or stops in safe state.” — and its success check, then attempt only this step.
Possible snag: The result from “The team removes automation assistance; the learner uses the approved manual or alternative fallback or stops in safe state.” does not yet meet this declared check: Loss of automation does not cause continued uncontrolled movement.
Correction: Return to the start of “Practise degraded control”, reduce complexity or pace, and repeat only the part needed to satisfy: “Loss of automation does not cause continued uncontrolled movement.”
Stop / get help: Stop for mode uncertainty, unexpected intervention, repeated intent error, failed override, lost link or limit breach.
08
Compare all modes
Review task success, intent errors, override latency, workload, collisions and agency in manual, auto and shared conditions; participant chooses next step.
Why this step exists
Shared mode is not declared best from completion alone.
Success check
Shared mode is not declared best from completion alone.
I’m stuck on this step
Reset: Re-read this authored instruction — “Review task success, intent errors, override latency, workload, collisions and agency in manual, auto and shared conditions; participant chooses next step.” — and its success check, then attempt only this step.
Possible snag: The result from “Review task success, intent errors, override latency, workload, collisions and agency in manual, auto and shared conditions; participant chooses next step.” does not yet meet this declared check: Shared mode is not declared best from completion alone.
Correction: Return to the start of “Compare all modes”, reduce complexity or pace, and repeat only the part needed to satisfy: “Shared mode is not declared best from completion alone.”
Stop / get help: Stop for mode uncertainty, unexpected intervention, repeated intent error, failed override, lost link or limit breach.
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.
Decision rights — Hidden allocation makes errors and responsibility unclear.
Correct / safer
State what person and automation each control.
Wrong / riskier
Let the system infer all goals silently.
Mode awareness — Mode confusion delays override; this distorts the shared-control corridor.
Correct / safer
Use a persistent label and transition cue.
Wrong / riskier
Infer mode from how the device feels.
Disagreement in shared-control corridor — Intent inference can be wrong even when the route completes.
Correct / safer
Stop, label conflict and log it.
Wrong / riskier
Treat automation correction as always right.
Degraded mode — Assistance loss can create abrupt workload and control gaps.
Correct / safer
Rehearse manual/alternative fallback or safe stop.
Wrong / riskier
Assume automation will remain available during the shared-control corridor.
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.