Transfer, Not Dependence

Why this matters

The point of enablement is that people can operate without you. A support system that makes people better while you are present is a service, not enablement. The uncomfortable measure is what happens when you are not there — and the design question is whether the support is built to withdraw.

What you will be able to decide after this

• Whether the support you provide is building capability or creating dependence.
• What evidence shows a person is ready for less support.
• How to step back without dropping anyone.

Core lesson

Signs of successful transfer:

• They can apply the Core Judgment filters without prompting
• They can set constraints and verify outputs on new tasks
• They know when to stop using AI
• They can explain their decisions and their remaining uncertainty
• They improve their own method over time

Signs of dependence:

• They wait for you to approve prompts or review every output
• They cannot adapt when the tool changes
• They treat every new situation as novel

The distinction is where the judgment sits. In transfer, the judgment has moved to the person; your role is context and edge cases. In dependence, the judgment still lives with you, and the person is a relay — fluent with the tool you vetted, helpless with the next one.

Design the support to withdraw as capability grows. That means the support has stages, not an indefinite shape:

• Start: tight support — defined practice tasks, close review, quick feedback.
• Grows: looser — new tasks, review on a sample instead of everything, the person owns their verification.
• Transfers: the person works new, realistic tasks without you, and your involvement is limited to what they ask for.

The evidence between stages is behavioral, not emotional: a new task handled with constraints and verification set by the person, a stop called without being prompted, a method that changed because they noticed a gap. And the withdrawal has to be scheduled — support that never reduces is not a plan, it is a dependency.

Worked example

An enablement lead runs weekly review sessions with six new users. The first weeks: every output reviewed, every prompt discussed, fast feedback. Week three, the stage change: each user picks a real task and works it alone — constraints, verification, stop decision — and the review covers a sample, not everything. Week five, the transfer test: a new, realistic task with no prior discussion, worked start to finish. Two of the six pass clean — constraints set, verification performed, uncertainty stated. Three pass with gaps: one cannot state what still cannot be verified, one skips the stop decision. One fails: the task stalls until the lead appears. The plan adjusts: the three get one more staged cycle with specific practice on the gap; the one goes back a stage instead of advancing on schedule. The schedule is the design; the evidence, not the calendar, decides who moves.

Practice

For the group you are enabling, write the three stages of support and what happens at each. Then mark what evidence would show a person is ready to move to the next stage.

Apply — produce the artifact

For the group you are enabling, write a simple transfer plan: what support you will provide at the start, what evidence will show they are ready for less support, and how you will step back.

Verify

Identify one person or team that has already received support. Test whether they can handle a new, realistic task using the filters and methods without your direct involvement. Note the gaps and adjust the plan.

Sources

This module is original practice guidance based on the authoring standard and does not depend on a specific external factual claim. Editorial review is still required.