Analyze deep uncertainty minimax regret
Apply Savage minimax regret when scenario probabilities are not defensible, compare maximin and equal-weight choices, and use PRIM-style iterative peeling to discover compact context boxes where the robust choice remains vulnerable.
What it's for
Lets leaders choose under genuine deep uncertainty without disguising arbitrary scenario weights as probabilities, while showing the future conditions that would make the choice fail.
What you give it
Inputs split into evidence read from your connected systems, calibration your team owns, and numerical controls that affect precision but never the result's meaning.
| Field | Type | Role | Required |
|---|---|---|---|
| actions | array of objects (2 fields) ≥ 2 items | Evidence | Yes |
| context_feature_names | array of string ≥ 1 item | Evidence | Yes |
| material_regret | number > 0 | Your calibration | Yes |
| max_detail_rows | integer ≥ 1, ≤ 500 | Numerical control | Optional |
| maximum_peels | integer ≥ 1, ≤ 100 | Your calibration | Optional |
| minimum_box_scenarios | integer ≥ 10, ≤ 10000 | Your calibration | Optional |
| peel_fraction | number ≥ 0.02, ≤ 0.25 | Your calibration | Optional |
| scenarios | array of objects (2 fields) ≥ 50 items | Evidence | Yes |
Each actions
record
| Field | Type | Required |
|---|---|---|
| id | string (non-empty) | Yes |
| payoffs | object | Yes |
{
"actions": [
{
"id": "aggressive",
"payoffs": {
"deep-future-0": 0,
"deep-future-1": 1.0101010101010102,
"deep-future-10": 10.1010101010101,
"deep-future-11": 11.11111111111111,
"deep-future-12": 12.121212121212121,
"deep-future-13": 13.131313131313131,
"deep-future-14": 14.141414141414142,
"deep-future-15": 15.151515151515152,
"deep-future-16": 16.161616161616163,
"deep-future-17": 17.171717171717173,
"deep-future-18": 18.181818181818183,
"deep-future-19": 19.19191919191919,
"deep-future-2": 2.0202020202020203,
"deep-future-20": 20.2020202020202,
"deep-future-21": 21.21212121212121,
"deep-future-22": 22.22222222222222,
"deep-future-23": 23.232323232323232,
"deep-future-24": 24.242424242424242,
"deep-future-25": 25.252525252525253,
"deep-future-26": 26.262626262626263,
"deep-future-27": 27.272727272727273,
"deep-future-28": 28.282828282828284,
"deep-future-29": 29.292929292929294,
"deep-future-3": 3.0303030303030303,
"deep-future-30": 30.303030303030305,
"deep-future-31": 31.31313131313131,
"deep-future-32": 32.323232323232325,
"deep-future-33": 33.333333333333336,
"deep-future-34": 34.343434343434346,
"deep-future-35": 35.35353535353536,
"deep-future-36": 36.36363636363637,
"deep-future-37": 37.37373737373738,
"deep-future-38": 38.38383838383838,
"deep-future-39": 39.39393939393939,
"deep-future-4": 4.040404040404041,
"deep-future-40": 40.4040404040404,
"deep-future-41": 41.41414141414141,
"deep-future-42": 42.42424242424242,
"deep-future-43": 43.43434343434343,Truncated for display — the full payload is 923 lines.
What you get back
This is the actual output of running the example above — computed by the same function the platform calls, not an illustration.
{
"actions": [
{
"id": "aggressive",
"material_regret_share": 0.25,
"maximum_regret": 45,
"mean_payoff": 50,
"mean_regret": 10.25,
"p90_regret": 35,
"scenario_optimality_share": 0.55,
"selected_by_minimax_regret": true,
"worst_payoff": 0
},
{
"id": "conservative",
"material_regret_share": 0.35,
"maximum_regret": 55,
"mean_payoff": 45,
"mean_regret": 15.25,
"p90_regret": 45,
"scenario_optimality_share": 0.45,
"selected_by_minimax_regret": false,
"worst_payoff": 45
}
],
"benchmark_choices": {
"choices_agree": false,
"equal_weight_expected_payoff_action_id": "aggressive",
"maximin_action_id": "conservative"
},
"configuration": {
"material_regret": 20,
"maximum_peels": 10,
"minimum_box_scenarios": 10,
"peel_fraction": 0.1,
"scenario_probabilities_used": false
},
"decision": "minimax_regret_action_identified",
"interpretation": "Minimax regret is a probability-free deep-uncertainty criterion; the vulnerability box describes supplied futures where the selected action loses value, not a forecast that those futures will occur.",
"method": "savage_minimax_regret_prim_vulnerability_discovery_v1",
"sample": {
"actions": 2,
"context_features": 2,
"scenarios": 100Truncated for display — the full payload is 866 lines.
How it works
Decision analysis — Turn uncertainty, cost and risk appetite into a defensible choice, with the reasoning left inspectable.
- 1 For every supplied future, subtract each action's payoff from the best payoff achievable in that same future to form the regret matrix.
- 2 Select the action with the smallest worst-case regret and report maximin and equal-weight choices as transparent sensitivity benchmarks, not equivalent decision rules.
- 3 Mark futures where the selected action's regret exceeds the governed material-regret threshold.
- 4 Use PRIM-style iterative edge peeling over declared numeric context features to find a compact, adequately supported box enriched for those vulnerable futures.
Before you trust it
Every tool in the catalog ships with the conditions under which its answer is meaningful — and the conditions under which it should abstain instead of guessing.
Assumptions & guardrails
- Actions, outcomes, utilities, evidence boundaries, uncertainty representation, and accountable ownership match the actual decision.
- Candidate actions are feasible, payoffs share a governed utility scale, and the scenario envelope is broad enough to contain futures leaders genuinely consider decision-relevant.
- Scenario rows are stress-test cases, not an empirical frequency distribution unless a separate defensible probability model exists.
- The result structures a governed choice; it does not replace accountable judgment or authorize action outside the declared decision boundary.
- A vulnerability box describes supplied conditions under which the robust action performs poorly; its coverage is not the probability that those conditions will occur.
Minimum evidence
- actions: at least 2 rows/items
- scenarios: at least 50 rows/items
- context_feature_names: at least 1 rows/items
- material_regret: required and organization-defined
How to validate it
Validate on future periods or held-out aggregate units, compare with a simple baseline, and require stability across plausible metric definitions and decision thresholds.
Calibrating it to your org
Same for everyone
The mathematical kernel, validation rules, method version, and JSON output semantics are organization-independent; no tenant-trained coefficients or company benchmark is embedded in the function.
Specific to you
- complete action-by-scenario payoff matrix in common utility units
- scenario context matrix without invented probability weights
- material regret threshold
- payoff/utility definition and action feasibility
- scenario envelope, PRIM peel fraction, minimum box support, and peel limit
Calibration workflow
- 1 Define the management decision, target outcome, aggregate unit, privacy boundary, cadence, and prediction/intervention horizon for this organization.
- 2 Build a tenant-scoped historical cohort using only information available before each prediction or decision; preserve zero periods, censoring, assignment probabilities, and unresolved outcomes when the method requires them.
- 3 Estimate statistical parameters on training history, but obtain costs, utilities, risk tolerance, practical-effect thresholds, capacity, and policy constraints from accountable decision owners.
- 4 Validate on later time windows or held-out aggregate units at the deployment grain, against a simple baseline and the function-specific validation strategy.
- 5 Deploy only if the returned decision clears evidence, overlap, calibration, robustness, and guardrail checks; warning, unsupported, schema-gap, and fallback decisions are abstentions.
- 6 Monitor realized outcomes, data drift, coverage, and decision regret; recalibrate at a governed cadence or after a detected regime/definition change, never merely because a stakeholder dislikes the result.
Call it from your AI
You don't wire up 388 tools in your MCP client. The GitRevio MCP server exposes 18 tools, three of which let an agent search the catalog, read a tool's schema, and run it — so the assistant finds this one on its own.
gitrevio_capabilities_search
{ "q": "apply savage minimax regret when scenario" }
→ finds "analyze_deep_uncertainty_minimax_regret"
gitrevio_capability_describe
{ "capability_id": "analyze_deep_uncertainty_minimax_regret" }
→ returns the input schema and agent guidance shown on this page
gitrevio_capability_run
{ "capability_id": "analyze_deep_uncertainty_minimax_regret", "arguments": { ... } }
→ returns the result shown aboveWorks in Claude Desktop, Claude Code, Cursor, Cline, Continue.dev, Goose and Aider. See the MCP server.
Related tools
Audit aggregate metric reversal
Detect Simpson's-paradox-style sign reversals between an executive aggregate relationship and its weighted within-stratum fixed-effect relationship, with whole-stratum bootstrap uncertainty and practical-magnitude gates.
Optimize technical debt paydown portfolio
Choose a dependency- and exclusion-safe technical-debt portfolio under capacity and cash budgets by discounting compounding recurring drag, failure exposure, remediation effectiveness, risk reduction, and engineering opportunity cost.
Audit informative metric missingness
Audit whether aggregate metric availability is associated with a governed outcome using permutation inference, bootstrap intervals, practical effect gates, and false-discovery control.
Audit joint metric dependency drift
Detect changes in cross-metric dependence with empirical-copula ranks, random-feature permutation inference, sliced Wasserstein magnitude, and FDR-controlled pair diagnostics.
Audit multivariate metric drift
Detect material distribution shifts with reference-fixed quantile bins, PSI, Jensen-Shannon divergence, standardized Wasserstein distance, permutation tests, and FDR control.
Audit point in time model integrity
Gate an analytical or AI model on point-in-time correctness by auditing actual feature availability, snapshot creation, target-window ordering, outcome resolution, source-record reuse, and embargoed train/calibration/test boundaries, with row and feature diagnostics rather than a generic leakage warning.