Solve Axis

The walkthrough, looping — turn sound on for the narration.

One-Line Summary

Solve Axis is a concept for an AI-native enterprise supply-chain modelling product — organised around how analysts actually reason about a solve, with a designed accountability layer that makes AI safe to trust on a high-stakes decision.

Why This Project Exists

Most enterprise modelling tools are more capable than they are usable. They can run an enormous range of solves — optimisation, stress tests, scenarios, sensitivity, robustness — but each one arrives as its own bespoke form, bolted on when the market asked for it. The power is real. The coherence isn't.

The result is a screen that grows by accretion. Analysts don't think in "run types"; they think in questions their boss just asked. But the product makes them translate that question into a specialist's vocabulary before it will do anything. The tool's mental model and the user's mental model never meet.

So I set the obvious remediation aside and asked a harder question:

If you started clean today — with AI integrated as connective tissue, not a feature bolt-on — what would the organising model be, and how far could design strategy take it before it hit the platform boundary?

The Problem

The gap isn't capability. It's coherence — and, increasingly, trust.

Two things are true at once. Adding AI that configures a solve from a plain-language question is now table stakes; everyone will claim it. And betting a seven-figure network decision on a solve an AI quietly configured for you is a non-starter unless you can see, and override, what it assumed.

The analyst needs:

To start from the decision, not the solver — "how fragile is this network if two sites go down?", not a menu of named runs.
To recognise the proposed solve as something they've done before, not a coordinate in an abstract space.
To know which numbers are a guarantee and which are the AI's opinion.
To catch a wrong setup before committing the compute or the decision.
To hand a reviewer, six months later, proof of what was decided and why.

The Framework

Key Design Decisions

What I Built

Goal-Led Entry — the plain-language front door, with the proposal and a recognizable anchor.
The Accountability Moment — the pre-commit review: two confidences, the load-bearing assumption, and override-as-question.
The Decision Record — a sealed, tamper-evident, signed artifact, exportable for audit.
The Boundary — a map of what the engine can and can't run, with the honest response to each.
The wider platform — two context screens situating the focused flow inside a much larger product.

I also pressure-tested the design the way I'd run real research when real users are scarce: four AI personas — an analyst, a solver engineer, a senior design leader and a skeptical buyer — run as concurrent agents, reviewing the work twice. A pre-read round shaped the brief; a reaction round judged the screens. Their verdicts moved from "not yet" to "use it daily," "interview," and "pilot."

Process & Architecture Snapshot

Design: organising model and AI thesis first, then expression — designed in a vector tool before any code.
Validation: four-persona panel, two concurrent-agent rounds, findings folded back into the brief.
Design system: IBM Carbon · Source Serif 4 (display) · DM Sans (interface) · IBM Plex Mono (data).
Build: Next.js (App Router) · React · TypeScript · GSAP scroll motion · a three.js "solve space."

What This Demonstrates

A modelling surface organised around user reasoning, not feature inventory.
AI as the expression of a model — not a chatbot bolted to its side.
A trust model that separates what's proven from what's guessed.
Accountability designed as an artifact, not asserted as a value.
The discipline to show where design strategy ends and platform investment begins.
A way to run rigorous design critique — adversarial, multi-perspective — at the speed of a solo project.

What It Does Not Claim

It is not a shipped product. Any figures shown are projected targets you'd instrument, not results from a live system.

It does not resolve the compute architecture, or design production IA for every run type. The model is the deliverable; the open questions are part of the product.

And it names no employer. This is my original framework applied to a fictional product — abstracted from proprietary work and anonymised so the thinking travels without the source.

Why It Matters

High-stakes optimisation decisions are exactly where "human-in-the-loop" tends to become rubber-stamp — a confident interface, an unexamined number, a decision no one can later defend. As AI moves deeper into these tools, the differentiator won't be that the AI can configure a solve. It'll be whether the design makes that solve safe to trust.

That's a design problem before it's a model problem. Solve Axis is one answer to it.