# Question Theory

URL: https://mechanisticmindset.com/wiki/question-theory
Tags: core-framework, computational-lens

# Question Theory

#core-framework #computational-lens

## What It Is

"How can I be better?" and "What's the next action on highest-priority task?" ask your attention to do different jobs. The first leaves the domain, the possible answers and the point of completion unspecified. The second identifies a set of tasks, a way to choose among them and a specific result to return.

Questions are **compulsory computational operations**. A question starts the brain searching, binds attention to the structure of the query and keeps the search running until it produces an answer. Statements can prompt agreement or resistance, and intentions can produce simulations of a future without any action. A question instead creates a search that cannot be ignored.

Questions function identically to graph-database queries: they specify starting nodes, relationships to follow, constraints and stopping conditions. Each question maps directly to a Cypher query with a measurable computational cost. A bounded example looks like this:

```cypher
// Natural: "What's the next action on highest-priority task?"
MATCH (me)-[:HAS_TASK]->(task)
WHERE task.status = "active"
RETURN task.next_action
ORDER BY task.priority DESC
LIMIT 1
```

This query costs O(n log n) and returns one concrete action. The unbounded question asks for something quite different:

```cypher
// Natural: "How can I be better?"
MATCH (anything)
WHERE anything.might_help_me = true
RETURN anything
```

Its cost is O(∞): it never completes or returns a random result. The difference comes from how much search the question requests and whether it specifies what would count as an answer.

This makes question design an engineering problem. A poor question can impose exponential computational costs and still return a vague abstraction. A bounded question can return an action immediately.

## Questions as Reality Programming

A question changes what happens after you ask it. It directs attention toward certain information, affects which patterns you recognize, and constrains the answers you generate. Those answers then affect action and its results. In that sense, questions are programs that create future reality.

"What's wrong with me?" starts a search for deficiencies. Failures become relevant evidence, and an explanation in terms of a character flaw fits the request. Repeating the question keeps producing a view of yourself as flawed because the search itself selects and interprets information that way.

"What mechanism prevents work launch?" starts a search for causes. An answer has to identify how the work failed to begin. That creates the possibility of changing the sequence or conditions that produced the failure.

The self-fulfilling effect follows through those steps. A question shapes the search; the search shapes what you notice and conclude; those conclusions shape what you do. Repeatedly asking "What's the next action?" produces an execution-oriented future. Repeatedly asking "Why can't I do this?" produces a limitation-oriented one. The same person can arrive at different outcomes because the questions keep directing different searches.

## The Forcing Function Property

The distinction among statements, intentions, commands and questions is how much computation each compels and what it costs:

| Language Form | Brain Response | Willpower Cost | Example |
|--------------|----------------|----------------|---------|
| Statement | Resistance/agreement evaluation | 2-3 units | "I should eat healthier" |
| Intention | Future simulation (no action) | 0 units | "I will eat healthy" |
| Command | Can be resisted | 2-3 units to comply | "Start working" |
| **Question** | **Automatic search (cannot be ignored)** | **0 units** | "What prevents me from eating the predetermined meal?" |

The word "mechanism" in "What's the mechanism that prevents [work launch](/wiki/state-machines)?" constrains the type of answer. "You're lazy" does not name a mechanism, so it is automatically rejected. The query has to return a causal chain.

```cypher
// Moralistic question (accepts character traits)
MATCH (me)-[:HAS_CHARACTER_FLAW]->(flaw)
RETURN flaw
// No such property exists in reality

// Mechanistic question (requires causal chain)
MATCH (work_launch {status: "failed"})<-[:PREVENTS]-(cause)
RETURN cause.mechanism
// Returns actual debuggable mechanism
```

A habitual mechanism question therefore prevents the character judgment before it is produced. This is the type-system account of zero-cost error prevention: the permitted answer type does the work that would otherwise require [willpower](/wiki/willpower) to resist a moralistic interpretation.

## Four Properties of Effective Questions

### Property 1: Search Space Specificity

A search needs a boundary if it is to finish. A domain limits where to look; a time window limits what could count as useful; a priority rule identifies which result to return.

| Question Type | Example | Cypher Equivalent | Cost | Completes? |
|--------------|---------|-------------------|------|-----------|
| Unbounded | "How can I be better?" | `MATCH (anything) RETURN anything` | O(∞) | Never |
| Domain-bounded | "How can work launch improve?" | `MATCH (work_launch)-[:HAS_IMPROVEMENT]->(i) RETURN i` | O(n) | Yes |
| Time-bounded | "What's next 25-min action?" | `MATCH (task)-[:NEXT_ACTION]->(a {duration: 25}) RETURN a LIMIT 1` | O(1) | Yes |
| Fully-bounded | "What's next action on highest-priority task?" | `MATCH (task {priority: "highest"})-[:NEXT_ACTION]->(a) RETURN a` | O(1) | Yes |

"What should I do?" leaves every option available, and each option can open further branches:

```mermaid
graph TD
    Q[What should I do?]
    Q --> A[Option A]
    Q --> B[Option B]
    Q --> C[Option C]
    Q --> D[...]
    Q --> E[Option N]
    A --> A1[Sub-option A1]
    A --> A2[...]
    B --> B1[...]
    C --> C1[...]
    style Q fill:#ff9999
    style E fill:#ff9999
```

The corresponding query does not provide a way to choose among the possible next states:

```cypher
// "What should I do?"
MATCH (current_state_of_entire_world)
MATCH (current_state)-[:CAN_TRANSITION_TO]->(next_state)
RETURN next_state
// Returns: infinite branches, no way to choose, never completes
```

A question about the next action on the highest-priority task supplies that selection rule:

```mermaid
graph TD
    Q[What's next action on<br/>highest-priority task?]
    Q --> P[Get priority task]
    P --> A[Get next action]
    A --> R[Return: specific action]
    style R fill:#99ff99
```

A question about a particular state transition can be bounded in the same way. Naming the lounge state and the work state narrows the search to the trigger connecting them:

```cypher
// "Given lounge state, what's the transition to work state?"
MATCH (lounge_state)-[:TRANSITIONS_TO {trigger: X}]->(work_state)
RETURN trigger
// Returns: specific mechanism, completes immediately
```

### Property 2: Framing Constraint

The wording of a question specifies which kinds of answers are acceptable. A question about character accepts a character trait. A question about what caused or prevented an action requires an account of the process.

| Moralistic Framing | Mechanistic Framing |
|-------------------|---------------------|
| "Why am I lazy?" | "What mechanism prevents work launch?" |
| "Why do I lack discipline?" | "What's the activation energy for this behavior?" |
| "Why can't I focus?" | "What competes for attention right now?" |
| "Why am I weak-willed?" | "How many willpower units were spent before this decision point?" |

The first query below ends at a supposed flaw. The second follows a relationship from the behavior through the mechanism to the root cause, producing something that can be investigated and changed.

```cypher
// Moralistic framing
MATCH (me)-[:HAS_CHARACTER_FLAW]->(flaw)
RETURN flaw
// Type: Character trait (unactionable)

// Mechanistic framing
MATCH (behavior)-[:PREVENTED_BY]->(mechanism)-[:CAUSES]->(root_cause)
RETURN mechanism, root_cause
// Type: Causal chain (debuggable)
```

### Property 3: Observability

An answer is observable when there is a way to check it. A global judgment about progress or discipline can change with your mood while the underlying behavior stays the same. A log supplies a record against which the answer can be verified.

| Unobservable | Observable |
|-------------|-----------|
| "Am I making progress?" | "What's the 30-day delta in tracked metrics?" |
| "Do I work hard?" | "How many hours logged vs planned this week?" |
| "Am I disciplined?" | "How many times did predetermined sequence execute?" |
| "Is this relationship healthy?" | "What does HRV trend show over 14 days?" |

The whiteboard query returns weight, calories and gym attendance. Those are actual recorded values; the query for a personal property called discipline has no corresponding value to retrieve.

```cypher
// Unobservable
MATCH (me)-[:HAS_PROPERTY]->(discipline)
RETURN discipline.level
// Returns: ERROR - no such property exists

// Observable
MATCH (whiteboard)-[:DISPLAYS]->(data {date: today()})
RETURN data.weight, data.calories, data.gym_attendance
// Returns: Actual numbers from whiteboard
```

### Property 4: Action Relevance

An effective question returns something executable within 5 minutes. A broad aspiration may need several further decisions before you can act on it.

| Abstract (Not Actionable) | Concrete (Actionable) |
|--------------------------|----------------------|
| "How do I eat healthier?" | "What forcing function eliminates breakfast decision point?" |
| "How do I be more productive?" | "What's the next 25-minute work chunk?" |
| "What's my purpose?" | "What's the next action on highest-priority task?" |
| "How do I succeed?" | "What metric needs to improve this week?" |

The breakfast example shows the necessary descent. "Eat healthier" names a goal. Identifying breakfast narrows the domain. Identifying the decision point finds the mechanism. A rule allowing only home meals for breakfast supplies an implementation that eliminates that decision point.

```cypher
// Level 1: Too abstract
MATCH (abstract_goal {name: "eat healthier"})
RETURN abstract_goal
// No path to implementation

// Level 2: More specific
MATCH (meals)-[:IS_PROBLEMATIC]->(breakfast)
RETURN breakfast
// Still requires decomposition

// Level 3: Mechanistic
MATCH (breakfast)-[:PREVENTED_BY]->(decision_point)
RETURN decision_point
// Getting closer

// Level 4: Actionable forcing function
MATCH (decision_point)-[:ELIMINATED_BY]->(forcing_function)
WHERE forcing_function.type = "prevention_architecture"
RETURN forcing_function.implementation
// Returns: "No outside breakfast policy - only home meals allowed"
```

## Computational Cost Framework

A question can be expensive to answer without being useful. The relevant comparison is between the cost of its search and the value of the result:

```
         High Utility
              |
    Q3        |        Q1
  (Medium)    |     (Ideal)
              |
──────────────┼──────────────── High Cost
              |
    Q4        |        Q2
  (Worst)     |    (Useless)
              |
         Low Utility
```

### Cost Categories

Different requests require different amounts of work. Retrieving one known value, listing related tasks, sorting priorities, comparing interacting factors and enumerating possible strategies produce the following cost categories:

| Complexity | Example Question | Cypher Pattern | When to Use |
|-----------|-----------------|----------------|-------------|
| **O(1)** Constant | "What's on the whiteboard?" | `MATCH (node {id: "specific"}) RETURN node.property` | Checking current state |
| **O(n)** Linear | "What are today's tasks?" | `MATCH (today)-[:HAS_TASK]->(tasks) RETURN tasks` | Enumerating direct relationships |
| **O(n log n)** Logarithmic | "What's highest-priority task?" | `MATCH (tasks) RETURN tasks ORDER BY priority DESC LIMIT 1` | Finding optimal values |
| **O(n²)** Quadratic | "What factors interact?" | `MATCH (a), (b) WHERE a.relates_to = b RETURN a, b, relationship(a,b)` | System analysis |
| **O(2ⁿ)** Exponential | "What are all possible strategies?" | `MATCH paths = (start)-[*]->(end) RETURN paths` | Almost never - reformulate |

### Cost Reduction Patterns

Constraints reduce cost by excluding work before it is performed. Specifying one improvement avoids a comparison among every possible improvement; specifying three factors provides a limit to what the answer must contain.

| Before (Expensive) | After (Optimized) | Reduction |
|-------------------|-------------------|-----------|
| "What are my options?" | "What's the next action on highest-priority task?" | O(2ⁿ) → O(log n) |
| "How can I improve?" | "What's one improvement to work launch sequence?" | O(n²) → O(n) |
| "What should I do?" | "Given lounge state, what's the transition to work state?" | Unbounded → Bounded |
| "Tell me about X" | "What are the three key factors in X?" | O(n) → O(1) |

## The Nine Question Pathologies

### Pathology 1: Unbounded Search Space

A blank mind, paralysis or a sense of being overwhelmed can follow a question with no search boundary. "What should I do?", "How can I be better?" and "What are all my options?" each leave the possible result open.

```cypher
// Attempts to return EVERYTHING
MATCH (anything)
RETURN anything
// Never completes
```

The repair progressively adds a domain, a timeframe and a priority rule. In this example, the search becomes about work launch in the next 25 minutes and ends after returning the highest-priority result.

```cypher
// Add constraints progressively
// Step 1: Domain
MATCH (work_tasks)
WHERE work_tasks.domain = "work_launch"

// Step 2: Timeframe
AND work_tasks.timeframe = "next_25_minutes"

// Step 3: Priority
RETURN work_tasks
ORDER BY work_tasks.priority DESC
LIMIT 1
// Now completes in O(log n)
```

### Pathology 2: Moralistic Framing

A moralistic question searches for a defect in the person. A mechanistic question searches for the cause of a particular behavior. The change matters because the answer must then identify something that can be altered.

| Moralistic (Bad) | Mechanistic (Good) |
|-----------------|-------------------|
| "Why am I so lazy?" | "What mechanism prevents work launch?" |
| "Why do I lack discipline?" | "What's the activation energy for this behavior?" |
| "What's wrong with my willpower?" | "How many willpower units were spent before this decision point?" |
| "Why can't I just start?" | "What's the activation energy for starting?" |

The flaw query below returns guilt without identifying a property that exists in reality. The failed-launch query returns the mechanism that prevented the action.

```cypher
// Moralistic framing
MATCH (me)-[:HAS_CHARACTER_FLAW]->(flaw)
RETURN flaw
// No such property exists in reality, only generates guilt

// Mechanistic framing
MATCH (work_launch {status: "failed"})<-[:PREVENTS]-(cause)
RETURN cause.mechanism
// Returns debuggable causal chain
```

### Pathology 3: Unobservable Target

An observable question specifies both a quantity and a way to obtain it. The measurement device matters: asking for a trend is useful only when the relevant record exists.

| Unobservable | Observable | Measurement Device |
|-------------|-----------|-------------------|
| "Am I making progress?" | "What's the 30-day delta in tracked metrics?" | Tracking log |
| "Do I work hard?" | "How many hours logged vs planned this week?" | Time tracker |
| "Am I disciplined?" | "How many times did predetermined sequence execute?" | Execution log |
| "Is this healthy?" | "What does HRV trend show over 14 days?" | Whoop device |

### Pathology 4: Abstract Non-Actionable

An abstract answer can be correct yet leave you needing another plan. The sequence below continues from a broad eating goal through the problematic meal and causal mechanism until it reaches an executable breakfast rule.

```
Level 1: "How do I eat healthier?"         ← Too abstract
         ↓
Level 2: "What specific meal is problematic?"  ← More specific
         ↓
Level 3: "What mechanism causes off-plan eating?"  ← Mechanistic
         ↓
Level 4: "What forcing function eliminates decision point?"  ← Actionable
         ↓
Level 5: "Implement no-outside-breakfast policy"  ← Executable
```

### Pathology 5: No Stopping Condition

Even a question about one subject can request an unlimited answer. "Tell me about willpower" names the subject but says nothing about when enough has been returned. A count, a highest-impact choice or one useful property supplies a stopping condition.

| No Boundary | With Boundary |
|------------|---------------|
| "Tell me about willpower" | "What are three ways willpower depletes?" |
| "What are the factors?" | "What's the highest-leverage factor?" |
| "Explain this concept" | "What's the key property that makes it useful?" |

Without the boundary, the result can exceed working memory. With a limit of three, the query returns a focused answer whose completion is explicit.

```cypher
// No stopping condition
MATCH (nodes)-[:RELATED_TO]->(topic)
RETURN nodes
// Returns everything, overflows working memory

// With explicit boundary
MATCH (nodes)-[:RELATED_TO]->(topic)
RETURN nodes
ORDER BY impact DESC
LIMIT 3
// Returns focused, complete answer
```

### Pathology 6: Missing Start Node

A desired destination does not identify the current state. If the question leaves that state unspecified, the search has several possible interpretations. Naming the lounge state as the current state makes the requested transition deterministic.

```cypher
// Missing start node
MATCH (???)-[:LEADS_TO]->(goal)
RETURN ???
// No starting point specified, multiple possible interpretations

// With start node
MATCH (lounge_state)-[:TRANSITIONS_TO {via: X}]->(work_state)
WHERE lounge_state.current = true
RETURN X
// Clear start node enables deterministic traversal
```

### Pathology 7: Cartesian Product

Comparing every item with every other item generates work that a specific relationship can avoid. The constrained query follows only direct causes and retains those above an impact threshold of 0.2.

```cypher
// Cartesian product - compares everything to everything
MATCH (a), (b)
RETURN a, b, relationship(a,b)
// O(n²) exponential cost

// Constrained join
MATCH (a)-[:DIRECTLY_CAUSES]->(b)
WHERE impact > 0.2
RETURN a, b
// O(n) linear cost with specific relationship
```

### Pathology 8: Future Simulation

A question about a future plan can produce a simulated sequence while leaving the current obstacle untouched. The corresponding present-tense question asks what is blocking execution now or what is actually scheduled.

| Future Simulation (Bad) | Current Reality (Good) |
|------------------------|----------------------|
| "What will I do tomorrow?" | "What prevents execution right now?" |
| "How will I handle this?" | "What's the immediate next action?" |
| "What's my plan?" | "What's actually on today's schedule?" |
| "When will I start?" | "What makes start not happen right now?" |

### Pathology 9: Rhetorical Non-Questions

A sentence can have the form of a question while carrying an instruction or judgment whose answer is already assumed. A genuine diagnostic question leaves room to discover the mechanism.

| Rhetorical | Genuine |
|-----------|---------|
| "Don't you think you should work?" | "What prevents work launch right now?" |
| "Isn't it obvious that X?" | "What's the mechanism here?" |
| "Why don't you just start?" | "What's the activation energy for starting?" |

## Search Algorithms Questions Trigger

### Algorithm Comparison Table

Questions select different search procedures. Looking for a cause, listing a set, choosing the best local option, matching a pattern, tracing prerequisites and simulating consequences each require a different traversal.

| Algorithm | Triggered By | Cost | Use Case | Cypher Pattern |
|-----------|-------------|------|----------|----------------|
| **Depth-First Causal** | "What caused X?" | O(d) to O(b^d) | Debugging failures | `MATCH (effect)<-[:CAUSES*]-(root)` |
| **Breadth-First Enum** | "What are all X?" | O(n) | Complete inventories | `MATCH (start)-[:REL]->(neighbors)` |
| **Greedy Local** | "What's highest priority?" | O(n) | Decision-making | `MATCH (options) RETURN max(value)` |
| **Pattern Matching** | "Is this pattern X?" | O(m×n) | Classification | `MATCH (current) WHERE matches(pattern)` |
| **Backward Chaining** | "How do I get to X?" | O(d) | Planning | `MATCH (goal)<-[:REQUIRES*]-(current)` |
| **Forward Simulation** | "What happens if X?" | O(s^d) | Risk assessment | `MATCH (decision)-[:LEADS_TO*]->(outcome)` |

### Backward Chaining Example

"How do I get work launched?" starts at the desired state and asks for its prerequisites. Work requires the sequence; the sequence requires the morning mantra and braindump; these require waking at 5am; that requires sleeping by 10pm. Once found backward, the path can be carried out forward.

```cypher
// Question: "How do I get work launched?"

// Step 1: Start at goal
MATCH (goal {state: "work_launched"})

// Step 2: Find what requires this
MATCH (goal)<-[:REQUIRES]-(prerequisite1)
RETURN prerequisite1
// Returns: "work sequence executed"

// Step 3: Find what requires that
MATCH (prerequisite1)<-[:REQUIRES]-(prerequisite2)
RETURN prerequisite2
// Returns: "morning mantra + braindump completed"

// Step 4: Continue backward
MATCH (prerequisite2)<-[:REQUIRES]-(prerequisite3)
RETURN prerequisite3
// Returns: "wake at 5am"

// Step 5: Final step
MATCH (prerequisite3)<-[:REQUIRES]-(prerequisite4)
RETURN prerequisite4
// Returns: "sleep by 10pm"

// Complete path: sleep 10pm → wake 5am → mantra → braindump → work launches
```

## The Forward/Backward Asymmetry

### Why Forward Search Fails

"What should I do next?" begins with the whole current world. Every fact, relationship and possible transition can enter the search, and the question gives no criterion for choosing among the resulting branches.

```cypher
// "Work forwards": What should I do next?
MATCH (current_state_of_entire_world)
├── All nodes (every fact, concept, possibility)
├── All edges (every relationship)
├── All properties (every attribute)
└── Infinite possible transitions

// Attempt:
MATCH (current_state)-[:CAN_TRANSITION_TO]->(next_state)
RETURN next_state
// Returns: infinite branches, no way to choose, never completes

// Cost: O(∞)
```

### Why Backward Search Works

Starting with the specific goal "work launched" removes that open-ended choice. The search follows requirements backward until it reaches the current state, then returns a path between the two.

```cypher
// "Work backwards": What requires work launched?
MATCH (goal_state {id: "work_launched"})

// Step backward:
MATCH (goal_state)<-[:REQUIRES]-(step1)
RETURN step1
// Returns: "work sequence executed"

// Continue:
MATCH path = (current_state)-[:LEADS_TO*]->(goal_state)
WHERE goal_state.id = "work_launched"
RETURN path
ORDER BY length(path) ASC
LIMIT 1

// Cost: O(d) where d = depth to goal
```

### Comparison Table

The asymmetry concerns the starting node, branching and stopping condition. An unbounded forward question leaves them open; a backward question supplies a particular destination and ends at the current state.

| Dimension | Forward Search | Backward Search |
|-----------|---------------|-----------------|
| **Start node** | Unbounded (entire world) | Bounded (specific goal) |
| **Question** | "What can I do?" | "What requires this?" |
| **Answer space** | Infinite options | Finite path |
| **Stopping condition** | None | Current state reached |
| **Branching** | Exponential | Limited (few prerequisites per node) |
| **Cost** | O(∞) | O(d) |
| **Result** | Paralysis or random | Clear path |

## Diagnostic Protocol

The five checks below inspect a question before its search consumes resources. They ask whether the search is bounded, whether it requires a useful kind of answer, whether that answer can be checked, whether it can be acted on within 5 minutes, and whether its value justifies its cost.

| Step | Check | Red Flags | Green Flags | Fix |
|------|-------|-----------|-------------|-----|
| **1. Search Space** | Is it bounded? | "all", "everything", "best possible" | Domain, timeframe, scope specified | Add constraints |
| **2. Framing** | What answer types allowed? | Moralistic, character-based, vague | Mechanistic, causal, numerical | Reframe to require mechanism |
| **3. Observability** | Can answer be verified? | Mood-dependent, no measurement | Measurable, checkable against log | Convert to observable metric |
| **4. Actionability** | Executable in 5 min? | Requires further planning, abstract | Specifies exact steps | Descend abstraction ladder |
| **5. Cost/Utility** | Worth the search cost? | High cost, low utility | Low cost, high utility | Add constraints or increase specificity |

## Query Optimization Patterns

### Pattern 1: Indexed Lookup vs Full Scan

A specific identifying property lets a query go directly to a record. Without it, the query has to inspect each candidate.

```cypher
// Bad: Full scan
MATCH (n)
WHERE n.property = value
RETURN n
// Cost: O(n) - must check every node

// Good: Indexed lookup
MATCH (n:Label {property: value})
RETURN n
// Cost: O(1) - direct access via index
```

"What was that thing I did?" leaves the record unidentified. "What task did I complete on December 15th?" supplies a date that can locate it.

### Pattern 2: Limit Early vs Limit Late

A limit applied after exploring the whole graph does not save the cost of that exploration. Restricting the relationships and applying a threshold during traversal prevents irrelevant candidates from being explored in the first place.

```cypher
// Bad: Limit late
MATCH (n)-[:REL*]->(m)
RETURN m
ORDER BY m.value DESC
LIMIT 1
// Cost: Explores entire graph, then filters

// Good: Limit early
MATCH (n)-[:REL]->(m)
WHERE m.value > threshold
RETURN m
ORDER BY m.value DESC
LIMIT 1
// Cost: Prunes during traversal
```

### Pattern 3: Specific vs Any Relationship

A general relationship query follows every type of connection. A causal query follows only the relationship needed for the answer.

```cypher
// Bad: Any relationship
MATCH (a)-->(b)
RETURN a, b
// Cost: Follows all edge types

// Good: Specific relationship
MATCH (a)-[:CAUSES]->(b)
RETURN a, b
// Cost: Follows only causal edges
```

"How does this relate to anything?" requests the first kind of search. "What directly causes this?" requests the second.

## Practical Examples

### Example 1: Work Launch Failure

A useful sequence begins with the events that actually occurred, identifies what ran instead of work, asks why that option won attention, and finds the earliest point where the sequence could be changed.

| Bad Sequence | Good Sequence |
|-------------|---------------|
| "Why didn't I work today?" (moralistic) | "What was the actual sequence of events?" (reality check) |
| "What's wrong with me?" (unbounded, moralistic) | "What script executed instead of work script?" (diagnostic) |
| "How do I be more disciplined?" (abstract) | "What made tool exploration more salient than work?" (mechanism) |
| "What should I do differently?" (simulation) | "What's the earliest intervention point?" (intervention) |

In this example, the diagnostic search finds tool exploration. Anytype was visible, opening it cost 2 units rather than the work launch's 6, and it offered novelty dopamine plus visible progress. A tab blocker during work hours intervenes before that alternative becomes available.

```cypher
// Question: "What script executed instead of work script?"

MATCH (me)-[:EXECUTED]->(script {time: "morning"})
WHERE script.type = "default"
AND script.name != "work_script"
RETURN script

// Returns: {
//   name: "tool_exploration_script",
//   trigger: "Anytype visible",
//   activation_cost: 2,
//   reward: "novelty dopamine + visible progress"
// }

// Mechanism identified: Lower activation cost (2 vs 6) + immediate reward
// Intervention: Tab blocker to prevent Anytype access during work hours
```

### Example 2: Feeling "Unmotivated"

"Which variable in expected value calculation changed?" decomposes the feeling into reward, probability, effort and distance in time. The example finds that the time distance increased to 90 days until Julius's arrival. Expected value fell from 2.1 to 0.3. Intermediate milestones at 30 days shorten the distance to a nearer outcome.

```cypher
// Question: "Which variable in expected value calculation changed?"

// Formula: EV = (reward × probability) / (effort × time_distance)

MATCH (task)-[:HAS_REWARD]->(r {value: current})
MATCH (task)-[:HAS_PROBABILITY]->(p {value: current})
MATCH (task)-[:HAS_EFFORT]->(e {value: current})
MATCH (task)-[:HAS_TIME_DISTANCE]->(t {value: current})

WITH r.value as reward,
     p.value as probability,
     e.value as effort,
     t.value as time_distance,
     t.previous_value as time_distance_prev

RETURN
  (reward * probability) / (effort * time_distance) as EV_current,
  (reward * probability) / (effort * time_distance_prev) as EV_previous,
  CASE
    WHEN time_distance > time_distance_prev THEN "time_distance increased"
  END as diagnosis

// Returns: {
//   EV_current: 0.3,
//   EV_previous: 2.1,
//   diagnosis: "time_distance increased (90 days to Julius arrival)"
// }

// Intervention: Create intermediate milestones at 30 days
```

## Integration with Other Concepts

These connections identify where the question obtains its constraints and data. Working memory limits how much an answer can contain; tracking supplies observable records; state machines and activation energy supply variables for investigating a failed transition.

| Concept | How Question Theory Connects |
|---------|----------------------------|
| [Moralizing vs Mechanistic](/wiki/moralizing-vs-mechanistic) | "What's the mechanism?" prevents moralistic thinking through type constraints |
| [Working Memory](/wiki/working-memory) | Bounded questions respect 4-7 item limit; unbounded questions overflow capacity |
| [State Machines](/wiki/state-machines) | Diagnostic questions debug state: "What script is running?" "What prevents transition?" |
| [Activation Energy](/wiki/activation-energy) | Backward chaining reduces startup costs by eliminating "where to start" ambiguity |
| [Prevention Architecture](/wiki/prevention-architecture) | "What forcing function prevents this?" generates architectural solutions |
| [Tracking](/wiki/tracking) | Observable questions require measurement devices to convert narrative to data |

## Related Concepts

- [Moralizing vs Mechanistic](/wiki/moralizing-vs-mechanistic) makes the change in explanation operational through the questions asked.
- [Working Memory](/wiki/working-memory) explains the 4–7 item capacity that bounded questions must respect.
- [State Machines](/wiki/state-machines) supplies questions about current state and blocked transitions.
- [Activation Energy](/wiki/activation-energy) explains why a concrete starting point reduces launch cost.
- [Prevention Architecture](/wiki/prevention-architecture) connects intervention questions to forcing functions.
- [Tracking](/wiki/tracking) makes answers checkable against measurements.
- [The Braindump](/wiki/the-braindump) depends on question structure for clarity.
- [Discretization](/wiki/discretization) distinguishes bounded questions from abstract continuous ones.
- [Expected Value](/wiki/expected-value) supplies variables for diagnosing a changed response to a task.
- [Pedagogical Magnification](/wiki/pedagogical-magnification) examines how resolution changes search complexity and cost.

## Key Principle

Question design determines the search that thinking performs. Naming a mechanism constrains the answer to causes; naming a goal enables backward chaining; specifying a measurement makes the result checkable; adding boundaries keeps the answer within working memory. An actionable answer then connects the search to something you can do.

Making these questions habitual installs the constraints before the search begins. The right thinking follows automatically because the default question has already specified what to look for and when to stop.