ancons-assume-no-constraint

name	ancons - Assume No Constraint
description	Force the assumption that a perceived constraint doesn't exist. What would you do with total freedom? What does the unconstrained solution reveal about the constrained one?
output	{"format":"prose"}

Assume No Constraint

Input: $ARGUMENTS

---

Core Move

Take a constraint everyone accepts and assume it doesn't exist. Unlimited budget. No deadline. No policy. No physical limitation. Then design the ideal solution and work backward to reality.

This is how breakthrough thinking happens: by temporarily removing the box before thinking inside it.

---

Procedure

Step 1: State the Constraint Being Removed

What constraint are we pretending doesn't exist?

Step 2: Force the Assumption

"This constraint does not exist. We have total freedom in this dimension."

Step 3: Trace Implications

Without the constraint:

1. What's the ideal solution? — With no limitation here, what would you actually do?
2. How different is it from the current approach? — Radically different or minor tweak?
3. What does the gap reveal? — The difference between ideal and current shows the TRUE cost of the constraint.
4. Can we approximate the ideal? — What's the closest achievable version of the unconstrained optimum?
5. Is the constraint worth its cost? — Now that we see what it costs us, is it worth maintaining?
6. What's the 80% version? — What gets us 80% of the unconstrained value at 20% of the cost?

Step 4: Test the Assumption

• Is the constraint actually as hard as believed?
• Could technology, policy change, or creative structuring remove it?
• Has anyone operated without this constraint? What happened?
• Is the constraint self-imposed?

Step 5: Synthesize

CONSTRAINT REMOVED: [stated]
WITHOUT IT:
  Ideal solution: [unconstrained optimum]
  Gap from current: [how different]
  True cost of constraint: [what we're giving up]
  80% version: [practical approximation]
CONSTRAINT ACTUALLY NECESSARY?: [yes/no/reducible]
RECOMMENDED MOVE: [live with it / challenge it / approximate around it]

---

When to Use

• Feeling boxed in by constraints
• Want to see what's really possible
• Testing whether a "constraint" is actually just a habit

Integration

• Pair with /acons for the opposite stance
• Follow with /cba to evaluate the constraint's cost-benefit
• Use before /de to design from the ideal backward