Axiom, Model, Thesis, Hypothesis: A Thinking Toolkit

Why Words Matter

When you're building something on the cutting edge — AI agents, automation systems, things that don't have established playbooks — your thinking is the product. And the precision of your thinking depends on the precision of your words.

I caught myself using "axiom," "model," "thesis," and "hypothesis" interchangeably during a session with my AI agent today. My agent pushed back: these words aren't synonyms. They're different tools for different jobs. And once you know the difference, you start thinking more clearly — because you know what kind of evidence each idea needs.

Here's the toolkit.

The Four Levels

Axiom (公理) — Self-Evident, No Proof Needed

An axiom is something you accept as true without proof. It's the foundation you build on. If you have to argue for it, it's not an axiom.

Examples from my thinking today:

• "Knowledge workers have more to do than time" — I don't need data for this. It's observable reality.
• "Context windows are limited" — this is a technical constraint, not a debatable position.
• "People value convenience over speed" — from years of watching employees and customers. I've never seen evidence against it.

Key test: If someone says "prove it," and your honest answer is "just look around" — it's probably an axiom.

When to use it: When you need a stable starting point. Axioms don't change. You build on them, not toward them.

Model (模型) — A Simplified Map of Reality

A model is a useful simplification. It's deliberately incomplete — that's what makes it usable. A model tells you what to focus on by leaving other things out.

My example:

Agent = IDE + Context Pack + CLI Library

This is clearly a model, not an axiom. It's a simplification that helps me decompose the problem: what does an agent need? An environment, knowledge, and tools. It's useful because it immediately tells me what to build and what to deprioritize.

But it's not the whole truth. It doesn't capture orchestration (how context and CLIs get selected). It doesn't capture feedback loops (how the agent improves over time). And that's fine — a model that captures everything is called "reality," and it's too complex to act on.

Key test: "Does this simplification help me make decisions?" If yes, it's a useful model. If it leads to wrong decisions, the model needs updating.

When to use it: When you need a framework for action. Models guide strategy and roadmaps.

Thesis (论点) — A Position You're Arguing For

A thesis is a claim that could be wrong. You believe it, you'll act on it, but you acknowledge it needs defending. A thesis invites debate.

My examples from today:

• "GUI should be deprioritized in favor of CLI-first development" — this is a strategic position I'm taking. Someone could argue against it (and be right in certain contexts).
• "Building CLI is 3-4x faster than building GUI" — I believe this from experience, but someone with different tooling might disagree.
• "Power users (Kelvin, Jong Lin) will maintain and improve the context and CLIs" — this is a bet I'm making about specific people. I could be wrong.

Key test: "Can a smart person disagree with this?" If yes, it's a thesis, not an axiom. You need to be able to argue for it and consider arguments against it.

When to use it: When making strategic decisions. A thesis is your "bet" — the direction you're committing resources to. Name it as a thesis so you remember to validate it.

Hypothesis (假说) — A Testable Prediction

A hypothesis is the most specific level. It's a prediction that can be confirmed or denied by evidence. You design a test, run it, and update your beliefs.

My examples:

• "CS team efficiency will increase by 15% with 1-hour setup of SN Checker CLI + context" — I can measure this. Give them the tool, track task completion times for 2 weeks. Did it go up 15%?
• "Kit Yang will use the agent for customer form completion within 1 week of setup" — observable. Either she does or she doesn't.
• "CLI maintenance overhead will be less than 2 hours per month per CLI" — measurable over 3 months.

Key test: "Can I design a test that would prove this wrong?" If yes, it's a hypothesis. If you can't test it, it might be a thesis or a belief, but it's not a hypothesis.

When to use it: When you want to de-risk. Hypotheses turn "I think" into "let's check." They're the bridge between theory and evidence.

Why This Matters

Here's the practical punchline. When you know what level your idea lives at, you know what to do with it:

Without this vocabulary, everything feels equally uncertain. "Is my agent model correct?" feels paralyzing. But once you decompose it:

• The model (Agent = IDE + Context + CLI) → is it useful for decisions? Yes. Keep using it.
• The thesis (GUI should be deprioritized) → can I argue for it? Yes. Commit, but stay aware.
• The hypothesis (15% efficiency gain) → can I test it? Yes. Run a pilot, measure.

Suddenly you know exactly what to do with each idea.

The Derivation Pattern: 推演 (Deductive Extrapolation)

There's a thinking pattern I use naturally that I want to name explicitly: 推演 — derivation from discoveries.

In English, the closest terms are derivation or second-order thinking (二阶思维). But 推演 captures the chain quality better — each step derives from the previous one, building momentum.

The pattern goes like this:

1. Start with a new discovery (a model, a tool, a breakthrough)
2. Ask: what does this imply? (first-order derivation)
3. Then ask: what does THAT imply? (second-order)
4. Keep going until the implications get speculative (third, fourth order)
5. Also ask the inverse: what does this make irrelevant? (via negativa / 反面推演)

Here's how I used it today:

Discovery:    Agent = IDE + Context + CLI
    │
    ▼
1st order:    GUI isn't in the formula
    │
    ▼
2nd order:    GUI can be deferred or skipped
    │
    ▼
3rd order:    Our entire MIBOS roadmap timeline changes
    │
    ▼
4th order:    Build-vs-buy calculus changes for internal tools
    │
    ▼
Inverse:      What ELSE isn't in the formula that we're spending time on?

Four levels deep in one sitting. Most people stop at level 2. The value compounds at each level — but so does the speculation risk. Levels 1-2 are usually solid. Level 3-4 should be treated as hypotheses, not conclusions.

The inverse question ("what's NOT in the formula?") is especially powerful. It's called via negativa — defining something by what it excludes. Sometimes knowing what doesn't matter is more valuable than knowing what does.

Practical Application

Next time you have an insight — a new tool, a mental model, a breakthrough realization — try this:

1. Name its level. Is it an axiom, model, thesis, or hypothesis?
2. Derive the implications. Go at least 2 levels deep. Ask both "what does this imply?" AND "what does this make irrelevant?"
3. Check your confidence at each level. Level 1 is usually high confidence. Level 4 is speculation. Label accordingly.
4. Design tests for hypotheses. If something is a hypothesis, don't argue about it — test it.

The vocabulary is small. Axiom, model, thesis, hypothesis. Four words. But the clarity they bring to messy, cutting-edge thinking is disproportionate.

Adrian Gan is the CEO of Mipos Sdn Bhd and builder of the Agentic Hub. He's currently deriving his way from context engineering to business automation, one level at a time.