The primitive
Decision tooling splits roughly into four species. Monitoring tells you what is. Business intelligence tells you what was. Generative AI tells you what someone might say. Governance, risk, and compliance tells you whether a rule has been followed. None of those answer the question the strategist, the CRO, the regulator, the party chair, and the CSO actually need answered: is the outcome I committed to still reachable, given where we are, under the constraints that govern us, with what confidence?
That question has a formal structure. It is the feasibility problem in constrained optimisation and reachability analysis. It has been solved rigorously for decades in fields like control theory, operations research, and computational geometry, where it underlies everything from aircraft autopilot envelopes to power-grid stability analysis. What it has not had, until now, is a production platform aimed at the institutions who actually need it day to day.
What “feasibility under constraints” means, concretely
Pick any decision you lose sleep over. Decompose it:
- A target you have committed to (a revenue number, a margin, a win percentage, a regulation's impact envelope, a supplier fulfilment commitment).
- A state the world is currently in — observed via signals.
- Actions you can take — bounded by what's realistic.
- Disturbances you can't control — bounded by what's plausible.
- Dynamics — a model of how state evolves under actions and disturbances.
- Constraints — hard rules that cannot be violated.
The feasibility question is: given (2), is there a sequence of actions (3) under plausible disturbances (4) that keeps the dynamics (5) within constraints (6) and reaches the target (1)? The answer is not yes/no — it is a probability, and if you do not track how calibrated that probability is against realised outcomes, you do not know whether the answer is worth anything.
Why generic LLMs cannot do this
Language models do not formally reason about reachability in a constrained state space. They sample from distributions over tokens they saw during training; they do not run a solver against your problem specification. Asked a feasibility question, they will confidently produce a number. That number is not grounded in your state, your dynamics, or the distribution of plausible disturbances. It is grounded in what a similar number looked like in their training corpus. For anything you are willing to put in front of a board or file with a regulator, that is not enough.
We use LLMs deliberately and narrowly at ARIAA — parsing natural- language queries, drafting explanations of solver verdicts. The reasoning itself is always done by the solver.
Why legacy tools cannot do this
Legacy risk, scenario-planning, and GRC platforms enumerate. They list controls, positions, and policies. They run finite what-ifs against pre-baked assumptions. They do not compose engines, they do not integrate live signals into the reasoning step, they do not track their own calibration against outcomes, and they do not model cross-domain contagion. They are the right tool for enumeration problems. They are the wrong tool for feasibility problems.
The service
ARIAA productises computational feasibility as a service:
- A reasoning core — a composable stack of proprietary solvers (reachability, viability, robust, causal, contagion, spatial, time-series, quantum-explorer, digital-twin, and narrative).
- Ten pre-built domains — political, public policy, finance, media, supply chain, enterprise strategy, climate, public health, cybersecurity, energy.
- Custom domain composition — declarative ASDL spec; typical custom domain is a few weeks.
- Calibration as a standing discipline — every verdict is Brier-graded against realised outcomes; calibration reports are part of the product.
- Enterprise deployment — SaaS, dedicated cloud, on-prem, air-gapped.
The calibration discipline
The moat of a reasoning system is not its code; it is its calibration track record. We log every forecast at the moment it is made, along with the state and assumptions that produced it. When the outcome arrives, the Brier score is written to the calibration table. Over time that table is an asset no competitor can reproduce without running their system against the same decisions for the same period. That is why we do not open-source. Open-sourcing the engines hands the code but not the record, which is precisely the wrong direction of information flow.
Where to go from here
If you want to apply this framing to your own vertical, pick the closest fit below. Each solution page describes the decision class, the domain pack, the signal feed, and the deployment envelope.