ITR8: Thinking in Problems and Solutions

When I am deep in problem-solving, I don’t think in neat project hierarchies. I think in problems and solutions. One leads to another. Solutions improve through iteration. Problems decompose into smaller pieces. And sometimes, solving one problem creates new ones.

I built ITR8 to map that thinking directly.

The Core Insight: Structural Symmetry

Problems and solutions are structurally equivalent—they’re just mirror images of each other.

A problem breaks down into sub-problems. You decompose complexity.

A solution iterates into refined versions. You evolve approaches.

Both operations capture the same idea: taking something and subdividing it into more manageable parts. The difference is semantic. Problems fragment; solutions improve. But the underlying structure is identical.

This symmetry isn’t accidental. It’s fundamental to how problem-solving works. And it’s what ITR8 is built on.

Why Layout Matters

Most tools treating problems and solutions treat them as interchangeable nodes. ITR8 doesn’t. Instead, the direction of each node is determined by what it is.

Problems flow downward. When you break down a problem, sub-problems branch beneath it. This mirrors how we mentally decompose: you start with a big issue and drill down into its components.

Solutions flow upward. When a solution iterates, refined versions climb above it. This mirrors how we mentally evolve: you start with an approach and refine it into better versions.

Everything flows rightward. Causal chains, connections, the whole network moves left to right. This creates a natural reading direction and prevents the chaos of nodes ping-ponging in all directions.

The result is a layout that emerges from the content itself, without manual positioning. Your graph organizes spatially because the relationships have inherent direction.

Connection Types That Make Sense

Once you understand the symmetry, the connection types become obvious:

• --solves-->: A solution addresses a problem. Solution goes up, problem goes down.
• --causes-->: One problem leads to another. Both stay at the same level horizontally.
• --iterates-->: A solution refines into a better version. Both stay at the same level vertically.
• --breaks-down-->: A problem decomposes into sub-problems. Child problems branch downward.

No arbitrary rules. No “pick a layout style.” The connections tell the story, and the story determines the shape.

Starting Messy

One principle drove the design: if you’re using a tool to solve a problem, you probably aren’t already organized.

ITR8 doesn’t demand a single root node. Don’t have to start with one pristine problem at the top. Dump ten problems, add solutions as they occur to you, add iterations when you refine them. The layout will still make sense because the direction rules are structural, not positional.

This matters more than it sounds. Most tools in this space want you to be organized before you use them. ITR8 wants you to be disorganized—that’s the whole point.

Text Input, Visual Output

You can use the GUI to click and create nodes, or you can write it out in a text syntax inspired by Mermaid:

P: Slow website performance
P: High server costs
S: Implement caching
S: Use CDN

Slow website performance --solves--> Implement caching
High server costs --solves--> Use CDN
Slow website performance --causes--> High server costs

Paste that in, and you get a visual network. Or import/export as a file. Or encode it into the URL and share it as a link. GitHub Pages doesn’t mind.

The flexibility matters. Sometimes you want to sketch in the GUI. Sometimes you want to paste a whole network. The tool adapts.

Why This Matters

Problem-solving isn’t linear. It’s interconnected, iterative, and messy. You start with one issue, discover it causes another, refine your approach, realize you need a sub-solution, iterate again.

Most tools flatten that into hierarchies or force you into linear workflows. ITR8 maps the actual shape of the thinking.

The symmetry between problems and solutions isn’t just elegant—it’s honest. It reflects how these things actually relate. And when your tool’s structure matches your thought process, you stop fighting the interface and start using it to think.

That’s when it becomes useful.