Imagine putting your hardest business decision in front of a room of the greatest business thinkers and every serious strategy framework at once, and having them pressure-test it until it comes back sharper. That's the judgment engine. You hand it a real decision, a pricing model or a market to enter or a positioning call, and it convenes the right thinkers and frameworks for that specific problem, has them argue it out, and hands you back a sharper decision.
What makes it worth anything is the depth underneath. It isn't a prompt that tells a language model to "think like a strategist." It reasons over a real, frozen corpus of business thinking: forty-three frameworks, nine thinker lenses each anchored to a real person's actual work, six adversarial critics, six decision doctrines. Grounded to source material, not summoned from a model's memory of business books. The thinkers in the room are real, and the engine can prove where each one's judgment comes from.
That grounding is the difference between this and every "AI strategy advisor" that hands you a menu. Those tools describe a decision and return ten frameworks that might be relevant with a paragraph on each. You still do the actual work of picking the ones that fit, applying them, resolving where they disagree, and deciding.
The judgment engine does that work and lands the call, with falsifiable tests you can check later to see if you were right. It shows its reasoning at every step. It never answers "here are ten frameworks that might apply."
It runs in two modes.
- ROUTE answers "which framework fits this decision?" Name the layer the decision lives in, recommend one or two frameworks by name, warn you where they conflict. Lean and fast.
- ENGINE takes a real decision and lands a call. It classifies the problem, selects a small stack of frameworks and thinking lenses, applies them, reconciles the disagreement into one judgment, and renders a decision artifact that ends in an action and a set of tests.
Mostly you'll use ENGINE; ROUTE is the quick-lookup mode. Either way, everything depends on what's in the corpus.
Why it's deep
A catalog of 43 business frameworks across four operating layers: strategy, alignment, execution, measurement. Each framework carries its when-it-fails condition and a conflict map, so the engine knows not to stack two full operating systems on top of each other and call it strategy. The catalog also keeps a fad graveyard: frameworks whose branded copy-paste version died but whose underlying principle survived. Spotify's model is in there. The labels don't transfer; the idea underneath still works, so the engine reaches for the principle, not the poster.
Nine thinker lenses, each one anchored to a real thinker's actual work, not a vibe of their name. The roster covers the rationalist, the behavioral economist, the negotiator, the strategist, the wartime CEO, the Austrian economist, the growth mechanic, the influence practitioner, and the operator. When the negotiator lens speaks, it's applying Chris Voss's tactical empathy and calibrated questions from his real source material. When the behavioral economist speaks, it's Ariely's anchoring, decoy effect, and loss aversion. Every principle a lens uses traces back to a resolved citation.
Six adversarial lenses whose job is to break the recommendation. The CFO, the competitor, the customer-skeptic, the historian, the operator, and the systems-thinker. Each has an explicit objective so it can't ship as a generic stereotype. The CFO doesn't just "worry about money." It maximizes long-term risk-adjusted value and will kill a cheap initiative with no path to a return. The customer-skeptic refuses to let internal enthusiasm stand in for demonstrated willingness to pay. The historian asks who has tried this before and what the base rate was. They run to refute, not to agree.
Six doctrines, the load-bearing decision principles that sit above any single framework: reversible-versus-irreversible, mechanisms-over-goals, optimize-the-constraint, leading-versus-lagging indicators, strategy-is-choice-and-tradeoff, and what-must-be-true. These are the moves that turn a choice into something testable. What-must-be-true converts a recommendation into ranked assumptions so you can attack the weakest one before you commit.
Six stack recipes, default starting stacks for recurring decision types: pricing and packaging, market entry, positioning, GTM transformation, ICP and segment selection, and operating-model redesign. A recipe is a starting point the engine adds to, subtracts from, and reorders based on the specific problem. It's a running start, not a template.
The differentiator sits underneath all of it. The engine is framework-fluent but framework-skeptical. It picks the lightest framework that makes the decision clear and cuts any that add ceremony without changing the outcome. A beautiful answer that changes no decision fails.
And it refuses to fake a lens. Ask it "what would [some famous thinker] say" and if that thinker isn't grounded in real source material, it declines and offers you the nearest grounded lens instead. It will not let a language model impersonate a famous name and pass the improvisation off as that person's judgment. Every lens it puts in a stack traces to actual work.
That refusal is the point. A panel of borrowed names is exactly the thing that makes AI strategy advice worthless, and the engine is built to not do it.
How it was built
The catalog wasn't scraped and it wasn't generated from the model's memory of business books. Each framework's claims were grounded, tied to real source material in batches, with the citations resolved rather than asserted. A framework earns a core slot by clearing an evidence floor, not by scoring well on vibes.
Then it was audited adversarially by a second AI model. Gemini ran as an external reviewer against the catalog and the lens layer and returned a documented verdict of REVISE, with a specific must-fix list. In a later cross-model pass, two different model families reviewed independently, without seeing each other's answers, and converged on the same defect. A routing label had smuggled in a thinker's conclusion as if it were established fact.
That is the exact failure mode the whole thing was built to prevent, and our own automated check had waved it through, because it was reading the wording and not the logic. An outside reviewer caught it by checking for the property itself. It got fixed, and the re-review confirmed the fix.
It's an operator's tool. Grounded, externally audited, tested on real decisions, and refined against what broke. No more than that.
What it can do
The engine lands decisions in the classes it has recipes and grounding for:
- Pricing and packaging
- Market and segment entry
- Positioning
- Operating-model redesign
- GTM transformation
- Capital allocation
- Negotiations
The output is a decision artifact with twelve sections. It classifies the problem, shows which frameworks and lenses it selected and, the part that matters, which it rejected and why. It applies them, runs the adversarial panel, reconciles the disagreement into one judgment, and ends in an action plus a set of what-must-be-true tests.
Those tests name the leading indicators that would tell you early whether the call was right. The recommendation is checkable later instead of just plausible now.
One worked example
Here is the shape of a real run, anonymized to the archetype.
A vertical-SaaS CEO is deciding whether to move to usage-based pricing to capture the value of new AI features. Value is migrating from per-seat to per-use, and the seat model isn't sized to hold the new work the product does.
The engine classified it as a pricing-and-packaging decision and pulled a small stack: value-chain and jobs-to-be-done to locate where the buyer actually pays, the behavioral-economist and negotiator lenses for how the price is perceived, the CFO and customer-skeptic to attack it, and the what-must-be-true doctrine to turn the call into tests. Then the panel pressure-tested the whole thing, running to refute it.
The move that mattered wasn't a yes or a no on the meter. The CEO was planning to launch usage pricing across both of the segments the product was pulling toward, to avoid leaving either one behind. The strategist lens raised a different call the CEO wasn't planning to make: commit to one segment first and defer the other outright.
The reasoning was the straddling cost. Serving two adjacent segments at once leaves you weaker at both, and the "keep both" instinct would also make the pricing bet untestable, because blended data hides which segment is actually accepting the meter.
Then the panel tried to break that alternative, and it held. The customer-skeptic pushed that deferring a segment leaves revenue on the table; the answer was that a straddle leaves more on the table later, in a bet you can't read. The engine didn't hand down a verdict. It surfaced the sharper option and defended it hard enough to change the plan.
Two supporting points came out of the same run. The operator lens pushed on capital efficiency: the instruments that make a variable bill predictable for the customer move the cost variance onto your own P&L, so model that cost shock before committing to the multiple. The behavioral-economist lens pushed on perception: a variable bill is felt as a loss, so lead the invoice with value delivered rather than consumption, and the same meter reads as return instead of tax.
The call came with tests you can check, not just an argument. Two that would tell you early whether the alternative was right:
- In a time-boxed pilot, the committed segment accepts the meter without a discount ask above a set threshold; below it, the pricing thesis for that segment is wrong and the plan is dead.
- The deferred segment's pipeline does not degrade faster than a stated rate over the same window; if it does, the exclusion cost more than the model assumed and the sequencing needs a rethink.
It runs in loops
Like everything STEEPWORKS builds, the engine runs in a loop. Every run it appends a record: the decision you brought, the stack it chose, the call it landed. You add how it actually turned out and where you'd have run it differently.
That record is the point. It's how the engine's eval set grows from real use instead of a fixed test suite, so the routing and the stacks get tuned against decisions that actually happened, not hypotheticals. Every decision you run through it makes the next one better-grounded, because the record accretes and gets evaluated instead of evaporating.
Get it
This is the STEEPWORKS judgment engine, the same reasoning discipline, packaged so you can hand it your own decisions and let the loop learn how you decide.
If you have a real decision in front of you and want it wired into how your team decides, work with STEEPWORKS.