Most problems are not hard to solve. They are hard to see.
The difficulty is rarely the solution itself. It is the frame -- the set of assumptions, inherited constraints, and habitual angles that determine what you even consider. Change the frame, and the "impossible" problem often becomes tractable. Keep the frame, and no amount of effort within it will work.
The Cube exists to systematically break you out of whatever frame the problem arrived in.
There are hundreds of mental models. We chose six, and only six, for specific reasons.
Each framework attacks the problem from a genuinely different direction. They are not variations of the same move. Inversion is not a milder version of Pre-Mortem. Steelmanning is not a subset of First Principles. Each one sees something the others cannot.
All six share a common trait: they refuse to accept the problem as presented. Inversion flips it. First Principles strips it. Steelmanning challenges it. Second-Order Thinking extends it. Pre-Mortem kills it. Boundary Conditions stretches it. None of them start by asking "how do I solve this?" They all start by questioning whether "this" is even the right thing to be looking at.
These are not domain-specific tools. They work on technical problems, business decisions, personal dilemmas, creative challenges, and strategic planning. A framework that only works in software engineering or only in marketing would limit The Cube's utility. These six work everywhere.
The six frameworks are arranged on the cube so that opposite faces create dialectical tension:
- Inversion vs First Principles -- What makes it worse vs what is actually true. Destruction vs construction.
- Pre-Mortem vs Boundary Conditions -- How it dies vs where it breaks. Time vs structure.
- Steelmanning vs Second-Order Thinking -- Why not to solve it vs what happens when you do. Resistance vs consequences.
These tensions are not bugs. They are the most valuable part. When two frameworks contradict each other on the same problem, the contradiction itself is the insight.
Each framework alone is useful. But The Cube's real value is in the combinations -- the edges where two frameworks meet, the corners where three converge, the axes where opposites collide. A single framework gives you a viewpoint. The cube gives you a map.
The problem statement -- the Core -- is locked before any analysis begins. It does not change during rotation. The frameworks move around it, like the faces of a Rubik's cube rotating around its fixed center. This discipline prevents the common failure mode of "solving a different, easier problem" midway through analysis.
Every sentence in a Cube report must be about this problem. If a sentence could apply to any problem, it should not exist. Generic advice is worse than no advice because it creates the illusion of insight without the substance. "Manage risk carefully" is not an insight. "The vendor contract expires 30 days before the migration completes, and there is no renewal clause" is an insight.
When two or three frameworks are combined at an edge or corner, the insight must come from their intersection -- something neither framework would reveal alone. Simply restating what each framework already said, but in the same paragraph, is not cross-analysis. The question is always: "What does this combination see that the individual frameworks cannot?"
The cube's structure is not decorative. Adjacent faces create synergy. Opposite faces create tension. Corners triangulate. Every position in the rotation protocol exists because of a specific geometric relationship, and the analysis at that position should reflect that relationship.
The Cube does not produce insight that lives only in the analyst's head. It produces a structured, navigable report that any stakeholder can read, reference, and act on. Position numbers, named rotations, key insight summaries, cross-references -- these are not formatting choices. They are what make the analysis useful beyond the moment it was generated.
The full rotation is 30 positions. That is a lot. We do not apologize for it. A complex problem deserves a complete analysis. We provide lighter modes (/cube-quick, /cube-face) for problems that do not need the full treatment, but the full Cube does not cut corners. Every geometric position is analyzed because every position can reveal something unique.
It is not a decision-maker. The Cube reveals the problem space with maximum clarity. It ranks solutions and identifies risks. But the decision belongs to the human. The Cube's job is to make sure the human decides with eyes fully open.
It is not a checklist. Running through 30 positions mechanically, without genuine inquiry at each position, produces a 30-point waste of time. The value is in the quality of thinking at each position, not the quantity of positions.
It is not therapy. The Cube can analyze personal decisions, but it is a cognitive tool, not an emotional support system. It will steelman against your preferred outcome. It will pre-mortem your dream project. It will invert your best idea. This is not hostility. It is rigor.
It is not final. The Cube is version 1. The framework selection, rotation protocol, and output format are all open to improvement. New stacks can be added for new domains (see below).
When The Cube needed to cover sales, marketing, and engineering, the tempting path was to add more faces to a single cube. A 12-faced dodecahedron. A 20-faced icosahedron. More frameworks crammed onto one shape.
We went the other direction: multiple cubes, each with six faces.
The reason is geometric and cognitive. Six faces is the right number for a single analysis session. It produces 30 positions -- enough for comprehensive coverage, few enough for a human to hold in their head. More faces would create exponentially more combinations (a 12-faced shape would produce hundreds of positions) without proportionally more insight.
Instead, each domain gets its own cube with its own six frameworks, its own tensions, its own named rotations. The rotation protocol stays the same. The geometry stays the same. Only the lenses change.
This is the same principle behind the frameworks themselves: do not add complexity unless it adds proportional insight. A second cube with six focused frameworks produces more value than a single cube with twelve diluted frameworks.
Every stack follows the same structural requirements as the core cube:
- Six frameworks, no more. Each must be genuinely orthogonal.
- Three productive opposite-pair tensions. The axes must create real dialectical tension, not artificial pairing.
- Universal applicability within the domain. A sales framework that only works for SaaS does not belong on the Sales cube. It must work for any sales context.
- Named rotations that carry meaning. Every edge, axis, and corner gets a name that captures the character of that specific combination.
The test for a new stack is the same as the test for a new framework: does it produce insight that existing stacks cannot? If a problem can be adequately analyzed by the Core cube, a new domain-specific stack is not needed. Stacks exist for domains where the general frameworks miss domain-specific angles that practitioners would immediately recognize as essential.
All six frameworks share one thing: they refuse to accept the problem's native framing.
This is the single most important idea behind The Cube. When someone brings you a problem, the way they describe it already contains assumptions about what matters, what is fixed, what is flexible, and what the solution space looks like. Those assumptions are usually invisible to the person who has the problem. They are "just how things are."
But they are not how things are. They are how things look from one angle.
The Cube gives you every other angle.