Question inherited baggage. Rebuild only from bedrock you can defend.
When to use
- "Why do we do it this way?", "is this really required?", "what would this cost if we started from scratch?"
- A strategy or design copied from an incumbent ("like Uber for X") that nobody has checked.
- Cost, architecture or process choices that exist only because they always have.
Skip: quick convention-following checklists with no wish to revisit assumptions, or purely social coordination with nothing to model.
Before you start
- State in one block: Reconstruction target (belief, cost, design or strategy to ground) and Pass (Surface, Question, Bedrock, Rebuild, Implications).
- Gather first. Read the code, contracts, specs or data that show what is actually required (a regulation, an SLA, a measured limit) before tagging anything fundamental. Ask up to 3 questions only for immutable constraints that tools cannot answer.
- Light path. Small ask: 3 assumptions, 3 bedrock items, a 3-step rebuild, 2 implications.
Steps
1. Surface
State the conventional answer or the analogy people rely on. List loaded words and hidden comparisons.
2. Question
For each major assumption: Assumption: ... - Why believed? (authority, analogy, experience) - What if false?
3. Bedrock
List truths that survive scrutiny: physics, logic, arithmetic, legal musts, documented needs of real users. Tag each [FUNDAMENTAL] or [ASSUMPTION].
Aim for three or more honest bedrock items. If fewer exist, say why in one line.
4. Rebuild
Derive conclusions in numbered steps using only [FUNDAMENTAL] items. "Industry standard" is not a premise unless translated into a fundamental (for example "buyers require SLA X because regulation Y"). A new premise goes into Bedrock first, with a tag.
5. Implications
- So what: what changes versus the conventional path.
- Cost of being wrong if a tagged assumption fails.
- A short vs convention contrast when it helps the decision.
If bedrock is too thin to rebuild, write insufficient grounding and list the evidence that would fix it.
Pitfalls
- Calling a preference or a habit "fundamental".
- Rebuilding from first principles and arriving exactly at the old answer. That is fine if each step is defended; say so.
- Faux profundity. Keep every step short and checkable.
- Ignoring switching cost. A better design from scratch may not beat the current one after migration.
Worked example: references/example.md.
Checklist
- Target and Pass stated
- Surface names the convention or analogy
- Question ties each assumption to why it is held
- Bedrock tagged
[FUNDAMENTAL]or[ASSUMPTION] - Rebuild uses only fundamentals
- Implications name what changes and the cost of being wrong