Problem framing

Treat rising complexity and repeated non-convergence as diagnostic signals that the problem may be framed incorrectly. They are evidence to investigate, not proof that the requirement is false.

Pause refinement of the disputed design long enough to examine the problem it serves. Use the conversation and available artifacts before asking the user to repeat information.

Diagnose and reframe

1. Identify the signal concretely: which branches, exceptions, or layers keep appearing, or which point keeps being re-argued without new evidence?
2. Restate the intended outcome independently of the proposed implementation. Identify who needs it and what observable result would count as success.
3. Separate established requirements from assumptions and implementation choices. Check the evidence behind the requirement driving the complexity. Mark unsupported claims as unverified, not false. Preserve confirmed constraints, including compatibility, safety, and business obligations.
4. Name the suspected false problem explicitly. State which assumption may be manufacturing the difficulty and why. Consider whether the actual cause is missing information, conflicting requirements, or unavoidable domain complexity instead.
5. Offer a simpler framing tied to the same intended outcome. Explain exactly which complexity would disappear and which tradeoffs or constraints remain. A proposal that quietly drops a real requirement is not a successful reframing.
6. Identify the smallest check that can distinguish the original framing from the alternative. Use available evidence or a reversible experiment where practical; ask a focused question only when necessary information is missing.

Communicate the decision

Tell the user plainly, in their language: