Phase Re-entry Protocol: when adapting stops being enough.
A live system accumulates adaptations, and eventually a harder question surfaces: is this still a tuning problem, or has something shifted enough that the design needs to go back? Describe your original intent, what changed, and what concerns you — get a re-entry verdict with the evidence that tips it. “Keep adapting” is a fully valid verdict.
Bannan (2009) — Cycling Back Is Not Failure
Premise Audit, Not Vibes
“Keep Adapting” Must Be Earned
The Core Tension This Tool Sits Inside
AI affordance
A model can hold the original design intent next to months of accumulated changes and signals, and ask the question a busy team keeps deferring: are we still solving the problem we analyzed?
Named risk
Decontextualization — signals arrive stripped of the context that produced them, so an AI-assisted team keeps patching symptoms efficiently while the audience, task, or organization has shifted enough to invalidate the original analysis underneath.
Guardrail
Re-entry triggers are made explicit and checked against the original Phase 1 premises, not against dashboard comfort. The verdict names which premise broke and what evidence says so — and 'keep adapting' must be earned by the evidence too, not assumed as the default.
Human judgment domain
The call itself. Going back costs real time and political capital; only you can weigh that. The protocol makes the decision inspectable — it does not make it.
What this tool does not replace: Re-running the actual Phase 1 or Phase 3 work when the verdict says so — this tool decides where to knock, not what's behind the door.
Honesty check
A verdict about where to re-enter the framework, built only from what you described. It cannot see your system, your data, or your org — and the call stays yours.
Optional — this tool works fully standalone. Pick or create a project only if you want this verdict saved to the shared Design Journey, and prior cycles from this project offered as pasteable context below.
Describe The Situation
What was the plan, what changed, and what's bothering you now
Free text throughout — this protocol only reasons from what you write here. It never invents a signal, metric, or org event you didn't describe.
The design's original problem statement, audience, and theoretical grounding — as first analyzed.
0 / 2500 (min 60)
Accumulated adaptations, signal trends, context shifts, org changes — everything that has moved since ship.
0 / 3000 (min 40)
What prompted this check-in, in your own words.
0 / 1000 (min 20)
Rules or changes made so far — paste an Adaptive System Design cycle here if you have one.