argument-architect

name

argument-architect

description

Build a rigorous argument from a claim using Zakery Kline's inference methodology. Use when someone says 'help me argue for X', 'is my argument valid', 'how do I prove this', 'build a case for', 'what are the hidden assumptions', 'check my reasoning', 'make this argument bulletproof', 'how would I defend this claim', or 'argument map.' Walks through inference chains, hidden assumptions, and counterexamples.

Argument Architect

Build a rigorous, step-by-step argument from a claim using the methodology from Chapter 2 of Zakery Kline's How to Think. This is not a rhetoric tool — it's a logic tool. The goal is not to make something sound convincing but to make the inferential structure visible, testable, and honest.

When to Use

The user has a claim they want to argue for — or a position they hold and want to stress-test. They might say:

• "I believe X — help me build a rigorous case"
• "How would I argue that...?"
• "Is this argument valid?"
• "What are the weak points in my reasoning?"
• "Make this argument bulletproof"

The Core Principle

"Sound reasoning proceeds incrementally, not in leaps. Each new conclusion should follow directly from what has already been established."

Most arguments fail not because the conclusion is wrong but because the inferential steps are invisible. People jump from premise to conclusion with three unstated steps in between — and it's in those gaps that the errors hide. The Argument Architect makes every step explicit.

How to Run This

Step 1: Name the Claim

Ask: "What is the claim or conclusion you want to argue for? State it as precisely as you can — one sentence."

Push for precision. "I think remote work is better" is too vague. "Remote work increases individual productivity for knowledge workers in roles that don't require real-time collaboration" is arguable. The narrower the claim, the stronger the argument can be.

If the user gives a vague claim, help them sharpen it before proceeding. A fuzzy target produces a fuzzy argument.

Step 2: Identify the Starting Certainties

Ask: "What are the indisputable truths that anchor this argument? What do you and your audience both already accept as given?"

Starting certainties are the foundation. They must be things your interlocutor would grant without argument — shared facts, agreed-upon definitions, common observations. If your starting point is already contested, you don't have an argument; you have two arguments stacked on top of each other, and the bottom one hasn't been made yet.

Help the user distinguish between:

• Genuinely indisputable (empirical facts, logical necessities, shared definitions)
• Feels obvious to them but is actually contested (this is where most arguments go wrong at the root)

List 2-5 starting certainties. Label each one with its basis:

• [Empirical] — observable, measurable, verifiable
• [Definitional] — true by the meaning of the terms
• [Logical] — true by the laws of thought (non-contradiction, excluded middle)
• [Stipulated] — agreed upon for the sake of this argument

Step 3: Map the Inference Chain

This is the core of the method. For each step from starting certainty to conclusion, ask: "What type of inference connects this step to the next?"

The four inference types:

Deductive (general to specific — if the premises are true, the conclusion MUST follow)

• Structure: All A are B. X is A. Therefore X is B.
• Strength: Certainty — but only as strong as the premises.
• Watch for: Hidden premises that make the deduction invalid. "All entrepreneurs take risks. She takes risks. Therefore she's an entrepreneur" — invalid (affirming the consequent).

Inductive (observations to pattern — probable but not certain)

• Structure: We've observed X in cases 1, 2, 3... N. Therefore X is probably general.
• Strength: Proportional to sample size, diversity, and absence of counterexamples.
• Watch for: Small samples, biased samples, black swan vulnerability. "Every startup I've seen succeed had a technical cofounder" — how many startups have you seen?

Abductive (best explanation for observed phenomena)

• Structure: We observe Y. X would explain Y better than alternatives. Therefore X is probably true.
• Strength: Depends on (a) how well X explains Y, (b) how many alternative explanations exist, (c) whether X predicts other things we can check.
• Watch for: Ignoring simpler explanations. Confirmation bias in selecting which explanation "feels right."

Transcendental (precondition reasoning)

• Structure: X exists. Y is a necessary precondition for X. Therefore Y must exist/be true.
• Strength: Very strong when the necessity claim holds. The key question is whether Y is truly NECESSARY for X, or merely sufficient.
• Watch for: Confusing "sufficient condition" with "necessary condition." "Communication requires language" — does it? Animals communicate without language.

For each inferential step, write it out explicitly:

Step 1: [Starting Certainty] ——[Inference Type]——> [Intermediate Conclusion 1]
Step 2: [Intermediate Conclusion 1] + [Starting Certainty 2] ——[Inference Type]——> [Intermediate Conclusion 2]
...
Step N: [Intermediate Conclusion N-1] ——[Inference Type]——> [Final Claim]

"When correctly applied, they allow us to recognize claims that cannot possibly be true because they violate these fundamental principles."

If any step requires a leap — where the inference type isn't clear or the connection isn't direct — stop and flag it. That gap is where the argument is weakest.

Step 4: Flag Hidden Assumptions

Every argument rests on unstated assumptions. Use Kline's five-type taxonomy to hunt for them:

Category Assumptions — Treating something as belonging to a category it may not belong to.

• "This is a free speech issue" — is it? Or is it a workplace conduct issue? The category you assign determines which principles apply.
• Ask: "What category am I placing this in? Could it belong to a different category that would change the analysis?"

Causality Assumptions — Assuming a causal relationship that hasn't been established.

• "Social media causes depression in teens" — correlation is established, but causation is contested. Does social media cause depression, or do depressed teens use more social media, or does a third factor drive both?
• Ask: "Am I assuming X causes Y? Could Y cause X? Could Z cause both?"

Value Assumptions — Smuggling in an unstated value judgment as if it were a fact.

• "Education should prepare students for the workforce" — this sounds factual but contains the value assumption that workforce preparation is education's purpose. Someone who believes education is for cultivating wisdom would reject the entire argument built on this foundation.
• Ask: "What value am I treating as self-evident? Would my opponent share this value?"

Possibility Assumptions — Assuming something is possible (or impossible) without establishing it.

• "We could solve homelessness if we just built enough housing" — this assumes the problem is purely one of housing supply, which may not be possible to solve through construction alone.
• Ask: "Am I assuming this is achievable? What would have to be true for it to actually work?"

Linguistic Assumptions — Using a word in a way that smuggles in a conclusion.

• "Taxation is theft" — this works only if "theft" means "taking property without consent," AND if you define taxation as non-consensual. The argument is embedded in the word choice.
• Ask: "Am I using any loaded terms? If I replaced them with neutral synonyms, would the argument still hold?"

For the user's argument, identify at least 2-3 hidden assumptions across these categories. For each one, note whether it strengthens or weakens the argument — and whether the intended audience would accept or reject it.

Step 5: Test with Counterexamples

Ask: "Can I construct a case where all the premises are true but the conclusion is false?"

If yes, the argument has a logical gap. This is the most powerful test because it doesn't attack the premises — it attacks the STRUCTURE.

For inductive arguments, look for the strongest counterexample: the case that most directly challenges the pattern. One strong counterexample does more damage than ten weak ones.

For deductive arguments, test whether the logical form is valid by substituting obviously true premises. If the form can produce a false conclusion from true premises, the form is invalid regardless of content.

Step 6: Convergence Check

"Particularly strong reasoning often integrates multiple streams of evidence that converge on the same conclusion."

Ask: "Does this argument rely on a single chain of reasoning, or do multiple independent lines of evidence point to the same conclusion?"

Single-chain arguments are fragile — break one link and the whole thing falls. Multi-stream arguments are robust — even if one line of evidence weakens, the others still support the conclusion.

If the argument is single-chain, ask: "Is there a completely independent reason to believe this conclusion? A different starting point that arrives at the same place?"

Step 7: Direction Check

The most important meta-question:

Ask: "Are you reasoning forward from evidence to conclusion? Or backward from a conclusion you already hold to evidence that supports it?"

Forward reasoning: "Here's what I observe. What conclusion follows?" Backward reasoning: "Here's what I believe. What evidence supports it?"

Backward reasoning isn't automatically wrong — but it's vulnerable to confirmation bias. If the user admits they started with the conclusion, flag this and ask: "What evidence would make you abandon this conclusion? If you can't name any, this isn't an argument — it's a rationalization."

---

Output

After running all seven steps, produce the Argument Map:

ARGUMENT MAP
============

CLAIM: [The user's precise claim]

STARTING CERTAINTIES:
1. [Certainty 1] [Empirical/Definitional/Logical/Stipulated]
2. [Certainty 2] [Type]
3. [Certainty 3] [Type]

INFERENCE CHAIN:
Step 1: [Certainty 1] ——[Deductive/Inductive/Abductive/Transcendental]——> [Conclusion 1]
        Justification: [Why this inference holds]
Step 2: [Conclusion 1] + [Certainty 2] ——[Type]——> [Conclusion 2]
        Justification: [Why this inference holds]
...
Step N: ——[Type]——> [FINAL CLAIM]

HIDDEN ASSUMPTIONS FLAGGED:
- [Category/Causality/Value/Possibility/Linguistic]: [Description]
  Risk level: [Low/Medium/High — based on whether audience would accept]
- [Type]: [Description]
  Risk level: [Level]

COUNTEREXAMPLE CHECK:
- Strongest counterexample: [Description]
- Does it break the argument? [Yes/No/Partially — and why]

CONVERGENCE:
- Number of independent evidence streams: [N]
- [If single-chain]: Fragility warning — one broken link defeats the argument
- [If multi-stream]: Which streams are strongest/weakest

DIRECTION:
- [Forward/Backward/Mixed]
- [If backward]: What evidence would falsify this claim?

OVERALL STRENGTH: [Strong / Moderate / Weak]
- Strongest link: [Which step and why]
- Weakest link: [Which step and why]
- Recommended fix: [What would make the weakest link stronger]

Then close with an honest assessment. Don't flatter the argument. The purpose of this tool is to find the holes BEFORE an opponent does. A weak argument identified early can be strengthened; a weak argument defended publicly just damages credibility.

If the argument is genuinely strong, say so and explain what makes it strong. If it's weak, say so and explain exactly what would need to change to make it defensible.