Gating progress on success traps the user who cannot succeed
A guided flow unlocked each step only when the previous one reported completion, and the interactive steps reported completion only on a correct answer — so a user who could not solve one step could not reach any step after it, with no way forward that did not require someone else's help.
Resurfaces when
- building a wizard or guided flow
- unlocking the next step on completion
- designing a tutorial or onboarding sequence
- a user reports being stuck with no way forward
- gating content behind a correct answer
- replacing a self-serve skip control with a permission-gated approval flow
- a student-facing escape hatch overlaps a teacher-only permission gate
- reworking who is allowed to bypass a progress gate
The lesson’s retrieval contract, weighted three times heavier than its body. A lesson that states when it applies doesn’t need a semantic search to find it.
The lesson
Progression gates are usually written from the perspective of the user who eventually succeeds, for whom the gate is invisible. The user who cannot succeed experiences it as a dead end, and the more carefully the gate is built the more complete the trap. Every gated sequence needs an exit that does not depend on solving the thing, and it must not depend on a human being available to unblock them — support is not a mechanism, it is a hope with a rota. Offer the exit quietly, so it does not become the default path for people who could have finished.
The failure that taught it
In a guided lesson flow, each step unlocked the next when it signalled completion. Interactive steps signalled only on a fully correct answer, while passive steps had an explicit continue control. A learner who got stuck on one interactive step therefore lost the entire remainder of the session, and nothing in the interface acknowledged the state — it simply never advanced. The fix needed two layers precisely because the first could not assume an instructor was present to intervene.
How to apply it
For any sequence that unlocks on completion, write down what happens to someone who cannot complete step N, and build that path before shipping the gate. Make the escape available on every gated step rather than only the ones you expect to be hard, and record that it was used rather than blocking on it. Treat 'they can ask for help' as an unavailable answer when designing the mechanism — help may be asleep.
Where this claim comes from
- Lessonhigh confidence
Gating progress on success traps the user who cannot succeed
- Distillationmechanism stated
Written from the mechanism, not the incident — which is what lets it transfer to code sharing nothing with the original.
- Scar2 occurrences
2 separate failures, recorded independently at the time. A clustering pass found they shared one cause.
- Evidence2 records
Referenced by content hash, never by path: entry slugs carry client and ticket names, so a lesson storing them could not be published at all. Resolving a hash needs a map that never leaves the machine. An agent running locally traces it with scar_evidence; nothing on this site can.
What happened when it was used
- 15
- retrieved
- 3
- acted on
- 1
- held up
- 0
- did not hold up
Applied 3 times. Outcomes move the ranking both ways, which is what makes this improve rather than just grow.