Claude Cursor Skill

cuopt-multi-objective-exploration

Trace, complete, and interpret the Pareto frontier across competing objectives using repeated single-objective cuOpt solves (weighted-sum and ε-constraint).

LLM Mart · 0 points · 0 0 0

#workflow

Virus-scanned Reviewed automatically before listing.

Full trust report

Download nvidia-skills-skills_cuopt-multi-objective-exploration-d8519c5.zip · 17 KB

nvidia/skills 3445 416 forks Apache-2.0 Updated 2d ago

Part of nvidia/skills — 26 skills

Install

skills CLI npx skills add https://github.com/NVIDIA/skills/tree/main/skills/cuopt-multi-objective-exploration

Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install nvidia-skills@llmmart

Git git clone https://github.com/NVIDIA/skills.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole nvidia/skills collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

Multi-Objective Exploration

cuOpt optimizes one objective per solve. Many real problems have several objectives that pull against each other — cost vs. service level, return vs. risk, makespan vs. overtime, distance vs. vehicle count. A single solve answers "what's optimal for one particular weighting," but it hides the tradeoff the user actually needs to see.

This skill turns a sequence of single-objective cuOpt solves into a Pareto frontier — the set of solutions where you can't improve one objective without giving up another — and gives the discipline to read it. It adds no solver features; it orchestrates the LP / MILP / QP solves already covered by the formulation and API skills.

When this applies

Reach for this workflow when the problem has two or more objectives with no agreed-upon weighting, signalled by language like:

"balance X and Y", "trade off", "as cheap as possible without hurting service"
"minimize cost and maximize coverage", "I want options, not one answer"
any objective the user is willing to relax in exchange for another

If there is a single clear objective (everything else is a hard constraint), this skill does not apply — formulate and solve once.

Core idea — one solve is one point on a curve

A single optimum encodes one implicit weighting of the objectives. Change the weighting and the optimum moves. The frontier is the curve traced by all the non-dominated optima.

A solution A dominates B when A is at least as good on every objective and strictly better on one. Dominated solutions are never worth choosing. The Pareto frontier is exactly the non-dominated set; the user's job is to pick a point on it, and yours is to show them the whole curve plus where the tradeoff is sharpest.

Do not collapse a multi-objective problem to a single weighted number and report its optimum as "the answer" — that silently makes the tradeoff decision for the user. Trace the frontier and let them choose.

Objectives and constraints are interchangeable. A requirement currently treated as fixed — a coverage floor, a fairness cap, a budget — is often a latent objective: its level was assumed, not given. Promoting such a constraint to a parametric ε-constraint and sweeping it reveals a tradeoff you'd otherwise hide, so read a single-objective model's hard constraints as candidate objectives, not just limits — but only when the level was an assumption. A genuinely fixed, non-negotiable limit (a hard budget cap, a regulatory minimum) stays a constraint; don't manufacture a tradeoff that isn't there. Express any promoted quantity linearly so it can serve as an ε-constraint (see cuopt-numerical-optimization-formulation).

Step 1 — define the objectives

An informative frontier needs objectives that genuinely conflict: if they don't pull against each other, it collapses to a single point with nothing to trade off. And each objective has to be formulated correctly, since a wrong form, sense, or scale distorts the tradeoff and shifts where the knee falls. Formulate each one with cuopt-numerical-optimization-formulation before sweeping.

Step 2 — build a payoff table (anchor each objective)

Solve each objective on its own first. For k objectives this is k solves. Record, for each, the value of every objective at that optimum:

              f1        f2        f3
min f1   →   f1*       f2(at f1*) f3(at f1*)
min f2   →   ...       f2*        ...
min f3   →   ...       ...        f3*

The diagonal (f1*, f2*, …) is each objective's best achievable value; the off-diagonals give the range each objective spans across the others' optima. This table does double duty:

It sets the sweep bounds for the ε-constraint method (the feasible range of each constrained objective).
It supplies the scales for normalization — objectives in dollars, percent, and hours can't be weighted meaningfully until divided by their ranges.

If any single-objective solve is already infeasible, stop and fix the model before sweeping — the frontier doesn't exist yet.

Step 3 — choose a scalarization

Weighted sum

Combine the objectives into one and sweep the weights:

minimize  w1·f1(x) + w2·f2(x) + ... ,   for a grid of weight vectors w

Cheap and trivial with any solver. Two limitations to respect:

It only finds points on the convex hull of the frontier. Concave (non-convex) regions of the frontier are unreachable no matter how you choose weights, and for MILP the reachable points can be sparse with large gaps. A frontier that looks suspiciously linear or has only a few clustered points is the symptom.
Weights are not priorities until the objectives are normalized. Divide each f_k by its payoff-table range first; otherwise the largest-magnitude objective dominates regardless of intent.

ε-constraint (preferred for a complete frontier)

Keep one objective; move the rest to constraints and sweep their right-hand sides:

minimize  f1(x)
subject to  f2(x) ≤ ε2
            f3(x) ≤ ε3
            (original constraints)

Sweep each ε_k across the range from the payoff table. Each (ε2, ε3, …) combination is a single standard cuOpt solve. This recovers the full frontier, including the concave regions weighted-sum cannot reach, which is why it's the default when completeness matters. The cost is more solves (a grid over the constrained objectives) and bookkeeping of the ε values.

ε-constrain linear objectives directly. A quadratic objective (e.g. risk xᵀΣx) is simplest kept as the objective f1 while you ε-constrain the linear ones. A convex quadratic objective can instead be ε-constrained directly: add it as a quadratic constraint xᵀQx ≤ ε, which cuOpt supports. Non-convex or equality quadratic constraints are unsupported, and the MILP path stays linear-constraint only.

Spot it in existing code: a hand-coded loop over a target or budget value (a return target, a cost cap) is already the ε-constraint method — name it as such, filter dominated points, and read the swept constraint's dual (LP/QP only).

Read that dual as the local exchange rate. Where the frontier is smooth, the dual on a swept ε-constraint is its slope — how much the kept objective f1 moves per unit of the bound — at no cost beyond the solve already run; at a kink it gives only a one-sided rate. A zero dual usually means the bound is slack — the sweep has run past the frontier's edge (one-way: a slack bound always shows a zero dual, but under degeneracy a binding bound can too). This reading needs LP/QP and a linear ε-constraint (MILP optima and problems with quadratic constraints return no duals) — where duals are unavailable, difference adjacent frontier points instead.

Picking a method: weighted-sum for a quick convex sketch or when you know the frontier is convex (e.g. a pure-LP/QP tradeoff); ε-constraint when the problem is MILP, when the frontier may be non-convex, or when the user needs a faithful and complete curve.

Step 4 — sweep, collect, and filter

frontier = []
for each weight vector (or ε vector) in the grid:
    set the combined objective (or ε right-hand sides)
    solve with cuOpt              # reuse the prior solution as a warm start
    if status is Optimal/Feasible:
        record (objective values, solution)
discard dominated and duplicate points
sort the survivors to form the frontier

Practical notes:

Warm-start LP sweeps. For an LP frontier, carry the previous solve's PDLP warmstart data into the next to cut solve time. Per cuOpt this is LP-only: a MILP solve doesn't take a PDLP warmstart (you can optionally seed a MIP start instead). See cuopt-numerical-optimization-api for the calls.
Cap each MILP solve. Set a per-solve time limit on MILP sweeps (see cuopt-numerical-optimization-api) — a sweep is many solves, and branch-and-bound can over-spend certifying optimality past a tiny gap, while cuOpt sets no limit by default and won't warn. Report the points as optimal to the gap you set, not certified optimal.
Filter dominated points. A correct sweep can still emit dominated points (especially weighted-sum near the hull, or MILP). Drop them; they are not part of the frontier.
Resolution is a budget. Curve fidelity trades against solve count. Start coarse to see the shape, then refine the grid only where the curve bends.
Spend the budget where the slope changes (LP/QP). Because the ε-constraint dual is the frontier's local slope, compare it across solved points: where it barely changes, the curve is nearly straight — interpolate rather than add solves; where it jumps by more than the solve tolerance, the frontier bends between those points — refine there (smaller differences are solver noise, not curvature). This concentrates solves where the curve actually bends instead of spreading them over a uniform grid. On MILP, judge where to refine from the gaps between primal objective values instead.
Verify, don't assume. When you claim one method beats another, measure it — e.g. count the efficient points ε-constraint recovered that weighted-sum missed — rather than asserting it; and flag any solve returning feasible-but-not-Optimal so a non-certified point is never read as exact.

Step 5 — complete the frontier: measure and fill what the sweep missed

A weighted-sum sweep returns only supported points (Step 3's convex-hull limitation); on MILP frontiers, non-supported points — the ones no weighted-sum weighting returns — often make up much of the non-dominated set. A coarse ε-constraint grid leaves gaps the same way: any finite sweep can miss regions. Before presenting a swept frontier, measure the likely miss and decide whether to fill.

Measure the miss

Sort the swept points by one objective. For each adjacent pair, form the rectangle (in general, the box) between them in objective space; flag any box much larger than the median adjacent box (3× is a reasonable bar) or covering a large share of the frontier's spanned area — a sweep that returned only a handful of points is all gaps, so no box stands out from the median. Large boxes have two causes — non-supported regions (weighted sum cannot reach them, common under fixed-charge structure) and weight clustering (a finite grid re-discovering the same corners, even on a nearly convex frontier). The fill step treats both the same.

If all boxes are small and even, the sweep is likely adequate — say so and stop.

Fill the largest gaps first

For each flagged box, solve one ε-constraint subproblem targeted inside it: optimize one objective with the other bounded at the box midpoint (bi-objective; with more objectives, sort by each objective in turn and place one target per flagged box instead of recursing). Only certified Optimal results settle or steer anything here — a time-limited incumbent is kept as a point (tagged, below) but proves nothing about the gap. A new certified point that survives Step 4's dominance filter means the gap was real (an ε solve can return a weakly optimal point) — bisect: two more targets inside the two sub-boxes it creates. A certified endpoint coming back clears just the probed side of the bound; certifying the whole box as a true discontinuity also needs a known objective step size — all-integer objective coefficients over integer variables give one — to place the bound just inside the far endpoint and match its certified optimum. Without that step size, report the box as a candidate gap, not a proven discontinuity. Stop on a solve budget, or when the remaining boxes fall below the flag bar.

Warm-start each solve (cheap insurance)

Consecutive fill solves differ by one bound, so seed each with its neighbor as a MIP start (Step 4's warm-start note) — one line, and it never changes what is optimal. Expect unchanged solve times; the value is insurance on hard subproblems.

Degrade gracefully, never silently

If a subproblem hits its time limit with a feasible incumbent (FeasibleFound), keep the point — it is feasible, and the solve's reported gap bounds its suboptimality — but record it as approximate. The time-capped solve is the primary fallback: it returns both an incumbent and a bound. Heuristics-only mode (mip_heuristics_only) drops the proof work and returns feasible points with no gap bound — use it when feasible points are all you need, and tag everything it returns approximate.

Report with provenance

Every presented point carries one of two tags:

exact — Optimal at your gap setting, i.e. optimal to that gap (Step 4);
approximate — time-limited incumbent (quote its reported gap) or heuristics-only result (no bound exists; say so).

State the counts with the frontier ("14 points, 11 exact, 3 approximate near the low-cost end, worst gap 2.4%"). Never present a mixed frontier as uniformly optimal.

Step 6 — interpret the frontier

Report tradeoffs, not single numbers. A frontier point means nothing in isolation. Quote the exchange rate — "≈ $4k of extra cost per 1% of added coverage in this region" — so the user can judge whether a move is worth it. On an LP/QP frontier this exchange rate is the swept constraint's dual at that point — the local slope of the frontier, accurate to the solve's optimality tolerance (tighten it before relying on a dual); on MILP, estimate it from the gap to the adjacent frontier point.
Flag knee points; don't auto-pick them. The "knee" is where the curve bends most sharply — beyond it you pay a lot for a little. It's often the best-balanced compromise and worth highlighting, but the final choice is the user's preference, not a rule. At the knee the slope is two-sided — the dual just below differs from just above — so quote the exchange rate there as a range, not one number.
Treat dominated or gappy output as a diagnostic. If dominated points survive filtering, or the frontier is implausibly sparse or perfectly linear, suspect the sweep or the model — most often weighted-sum hiding a concave region (return to Step 5 and fill the gaps) or a normalization mistake.
State the weighting/ε you used. Every reported point is conditional on its scalarization. Make that explicit so a single solve is never mistaken for "the" optimum. On LP/QP, the ε-constraint duals are the implicit weights at that point — the effective price the solution puts on each constrained objective, and the weights a weighted-sum solve would need to reproduce that tradeoff. Reporting them makes the accepted tradeoff ratio explicit.

Interfaces

This skill is solver- and interface-agnostic. The per-solve mechanics — building the objective, adding the ε constraints, passing a warm start, reading status — live in the API skills:

cuopt-numerical-optimization-api — LP, MILP, QP solves (Python, C, CLI).
cuopt-routing-api-python — the same frontier workflow applies to routing tradeoffs (distance vs. vehicles vs. time).

Files (skills)

evals

evals.json 14.7 KB

[
  {
    "id": "multiobj-explore-eval-001-supplier-interpretation",
    "question": "A procurement lead is sourcing a component. The candidate suppliers lie on a cost-vs-reliability tradeoff (cheaper tends to be less reliable): CN03 cost $7.05 reliability 81.1; SEA03 $7.63 / 82.6; LA04 $9.93 / 87.2; EU04 $11.29 / 88.2; NA01 $11.74 / 90.3; NA03 $12.33 / 91.0; NA04 $13.37 / 91.1. She asks: 'Which suppliers should we commit to?' Advise her.",
    "expected_skill": "cuopt-multi-objective-exploration",
    "expected_script": null,
    "ground_truth": "The agent treats this as a two-objective tradeoff with no fixed weighting. It does NOT collapse to a single 'best' supplier; it lays out the cost/reliability tradeoff, quotes the exchange rate (e.g. roughly how much cost per reliability point between adjacent options), flags the knee/balanced region, states the assumption behind any option it highlights, and leaves the final pick to the lead (often a diversified mix rather than one supplier).",
    "expected_behavior": [
      "Frames it as two competing objectives (cost vs reliability) with no agreed weighting",
      "Does NOT declare one supplier as THE answer; preserves a genuine choice across options",
      "Quantifies the tradeoff as an exchange rate (cost per unit of reliability, or vice versa)",
      "Flags a knee / balanced region but leaves the final pick to the lead",
      "States where on the tradeoff any specific option it names sits"
    ]
  },
  {
    "id": "multiobj-explore-eval-002-supplier-exploration",
    "question": "A procurement lead must choose which of 12 candidate suppliers to contract to maximize total supply-chain resilience and minimize total annual cost, while covering required demand. There is no agreed weighting between resilience and cost. Using cuOpt, how would you approach this and what would you report back?",
    "expected_skill": "cuopt-multi-objective-exploration",
    "expected_script": null,
    "ground_truth": "The agent recognizes a multi-objective (resilience vs cost) selection problem with no fixed weighting and a hard demand constraint, builds a payoff table by solving each objective alone for ranges, then traces the Pareto frontier with repeated single-objective cuOpt solves. Because the supplier selection is combinatorial (non-convex), it prefers the epsilon-constraint method (e.g. minimize cost subject to a resilience floor, sweeping the floor) over weighted-sum, which would miss non-supported portfolios. It filters dominated points and reports the tradeoff curve plus the knee, deferring the final pick, and defers per-solve mechanics to the api-* skills and formulation to cuopt-numerical-optimization-formulation.",
    "expected_behavior": [
      "Recognizes two competing objectives with no agreed weighting; does NOT collapse to one weighted optimum",
      "Builds a payoff table (each objective alone) for ranges/normalization",
      "Traces the Pareto frontier via repeated single-objective cuOpt solves; prefers epsilon-constraint over weighted-sum for completeness on a non-convex/MILP problem",
      "Filters dominated and duplicate portfolios",
      "Reports the tradeoff and flags the knee, leaving the final pick to the lead",
      "Since supplier selection is MILP (no duals), estimates the cost/resilience exchange rate by differencing adjacent frontier points, not from constraint duals"
    ]
  },
  {
    "id": "multiobj-explore-eval-004-dual-exchange-rate",
    "question": "An analyst is building a risk-return efficient frontier across a set of assets: minimize portfolio variance and maximize expected return, with no fixed risk appetite. Using cuOpt, how would you trace the frontier, and at each point how would you tell the investor the rate at which they are paying variance for extra return without spending additional solves?",
    "expected_skill": "cuopt-multi-objective-exploration",
    "expected_script": null,
    "ground_truth": "The agent recognizes a two-objective tradeoff (variance vs return) with no fixed weighting and traces the frontier by epsilon-constraint: it keeps the quadratic variance as the objective and sweeps a linear return floor (return >= epsilon), each value a single convex QP solve. At each solved point it reads the dual value on the binding (linear) return-floor constraint as the marginal variance per unit of required return -- the local exchange rate, i.e. the slope (tangent) of the frontier at that point -- taken directly off the solve at no extra cost rather than by differencing two adjacent points, and accurate to the solve's optimality tolerance. It notes the dual reading applies to continuous LP/QP solutions, not MILP, and that the swept constraint must be linear since any quadratic constraint makes cuOpt return no duals for the whole solve. It filters dominated points, flags the knee, and leaves the risk appetite to the investor, deferring per-solve mechanics to the api-* skills and formulation to cuopt-numerical-optimization-formulation.",
    "expected_behavior": [
      "Frames variance vs return as two competing objectives with no agreed weighting",
      "Traces the frontier via epsilon-constraint, keeping the quadratic variance as the objective and sweeping a linear return floor (each a single QP solve)",
      "Reads the swept (linear) constraint's dual as the local exchange rate (marginal variance per unit return) and slope of the frontier, taken straight off each solve rather than by differencing",
      "Notes the dual / exchange-rate reading applies to continuous LP/QP, not MILP, and is accurate to the solve tolerance",
      "Filters dominated points, flags the knee, and leaves the final risk appetite to the investor"
    ]
  },
  {
    "id": "multiobj-explore-eval-003-single-objective-decoy",
    "question": "A procurement lead must contract suppliers to MAXIMIZE total supply-chain resilience, but the annual budget is hard-capped: total cost must not exceed $34 (a firm limit, not negotiable), and the set must cover demand. Which suppliers should we contract?",
    "expected_skill": null,
    "expected_script": null,
    "ground_truth": "DECOY (negative) — the multi-objective-exploration skill should NOT activate. There is a single clear objective (maximize resilience) with the cost as a hard constraint, so there is no tradeoff to explore. The correct response is a single optimization (maximize resilience subject to cost <= 34 and demand coverage) returning ONE recommended supplier set, not a Pareto sweep or a range of options.",
    "expected_behavior": [
      "Recognizes a single objective with a hard constraint, not a tradeoff",
      "Does NOT trace a frontier or sweep the budget as if it were a tradeoff dial",
      "Returns one recommended supplier set (one solve), citing the binding budget and demand coverage"
    ]
  },
  {
    "id": "multiobj-explore-eval-005-latent-objective",
    "question": "A planner runs a multi-period production model to MAXIMIZE priority-weighted finished-goods inventory at the end of a 10-period horizon. The model also carries full cost data — per-item unit and holding costs, per-resource hourly production cost — but the current objective ignores it, and leadership has set no budget. The planner asks: 'Push supply as high as it will go — what's the plan?' Using cuOpt, how would you respond?",
    "expected_skill": "cuopt-multi-objective-exploration",
    "expected_script": null,
    "ground_truth": "The agent recognizes that cost is a SECOND objective sitting latent in the problem — the data is present and no budget pins it down — and does NOT simply return the single maximum-supply plan, nor silently fold cost into a weighted-sum blend (maximize supply minus lambda*cost) with a self-chosen lambda. It surfaces the supply-vs-cost tradeoff and traces the Pareto frontier with cuOpt by epsilon-constraint (cap total cost, maximize supply, sweep the cap from tight to slack). Because the model is a MILP (no usable duals), it estimates the supply-per-dollar exchange rate by differencing adjacent frontier points, reports supply in interpretable units rather than the raw priority-weighted total, flags the knee where supply per dollar collapses, names two or three candidate operating points, and defers the budget decision to leadership. It distinguishes this from a hard-budget case: cost is unconstrained here, so the right move is to expose the tradeoff, not to pick one plan. It defers per-solve mechanics to the api-* skills and formulation to cuopt-numerical-optimization-formulation.",
    "expected_behavior": [
      "Recognizes a LATENT second objective (cost) present in the data but unstated; does NOT optimize the single stated objective (supply) in isolation",
      "Does NOT silently collapse to a weighted-sum blend (maximize supply minus lambda*cost) with a self-chosen weight",
      "Surfaces the supply-vs-cost tradeoff and traces the Pareto frontier via epsilon-constraint (sweep a total-cost cap, maximize supply)",
      "Since the model is MILP (no duals), estimates the supply-per-dollar exchange rate by differencing adjacent frontier points",
      "Reports supply in interpretable units, flags the knee, names candidate operating points, and defers the budget call to leadership",
      "Distinguishes this from a hard-budget case (cf. the decoy): cost is unconstrained here, so it exposes the tradeoff rather than returning a single plan"
    ]
  },
  {
    "id": "multiobj-explore-eval-006-gap-detection-completion",
    "question": "A planner swept 20 weight combinations over cost and coverage for a facility-selection MILP and got only 6 distinct plans, with a big empty stretch in the middle of the curve. She asks: 'Are there really no options in between, or is my sweep missing them?' Advise her.",
    "expected_skill": "cuopt-multi-objective-exploration",
    "expected_script": null,
    "ground_truth": "The agent recognizes the symptom of a weighted-sum sweep on a MILP: weighted-sum reaches only supported points (the convex hull of the frontier), so non-supported plans in between are invisible no matter how many weights are tried. It does NOT recommend simply adding more weight vectors. It measures the miss by forming the boxes between adjacent swept points, treats boxes much larger than the median spacing as candidate gaps, and fills the largest first with targeted epsilon-constraint subproblems (optimize one objective with the other bounded inside the box, bisecting when a new point appears). It notes that only certified Optimal solves settle a gap (a time-limited incumbent proves nothing), that a probe returning an existing endpoint clears just the probed side of the bound, and that certifying a true discontinuity additionally needs a known objective step size (e.g. all-integer objective coefficients over integer variables) to place a bound just inside the far endpoint -- otherwise the region is reported as a candidate gap, not a proven one -- and that filling stops on a solve budget or when the remaining boxes are small. It defers per-solve mechanics to the api skills and formulation to cuopt-numerical-optimization-formulation.",
    "expected_behavior": [
      "Attributes the empty stretch to weighted-sum reaching only supported (convex-hull) points on a MILP, not to the intermediate options being absent",
      "Does NOT prescribe more weight vectors as the fix",
      "Measures the miss via the boxes between adjacent swept points and flags outsized boxes as candidate gaps",
      "Fills the largest gaps first with targeted epsilon-constraint subproblems bounded inside each box, bisecting when new points appear",
      "Does NOT declare a gap empty from a single midpoint probe; certifies a discontinuity only with certified Optimal solves plus a known objective step size (bound just inside the far endpoint), otherwise reports a candidate gap; stops on a solve budget or size threshold"
    ]
  },
  {
    "id": "multiobj-explore-eval-007-provenance-reporting",
    "question": "While tracing a cost-vs-emissions frontier for a plant-scheduling MILP with per-solve time limits, three of an analyst's epsilon-constraint solves hit their limit but returned feasible solutions. He asks: 'Can I include those points in the tradeoff table I hand my team?' Advise him.",
    "expected_skill": "cuopt-multi-objective-exploration",
    "expected_script": null,
    "ground_truth": "The agent says yes, keep the time-limited incumbents — they are feasible and near the frontier — but only with provenance: every point in the table is tagged exact (proved optimal for its scalarization at the gap setting) or approximate (time-limited incumbent or heuristics-only result), each time-limited incumbent quoting its solver-reported remaining gap or bound (a heuristics-only point has no bound, which is itself stated), and the two counts are reported alongside the frontier (e.g. '14 points, 11 exact, 3 approximate near the low-cost end, worst gap 2%'). The mixed frontier is never presented as uniformly optimal; silently including the points and discarding them are both wrong. Optionally it notes that a persistently slow region can be populated with a short heuristics-only run (also tagged approximate) and that a larger per-solve budget can later upgrade approximate points to exact.",
    "expected_behavior": [
      "Keeps the feasible time-limited incumbents rather than discarding them",
      "Tags every reported point exact or approximate and reports the two counts with the frontier",
      "Never presents the mixed frontier as uniformly optimal; approximate points are identified, not silently included",
      "Distinguishes proved-optimal-at-gap (exact) from time-limited or heuristics-only results (approximate), quoting each incumbent's reported gap or bound and noting heuristics-only points carry none",
      "Leaves the tradeoff choice to the team; the table shows options, not one answer"
    ]
  },
  {
    "id": "multiobj-explore-eval-008-single-objective-lp-decoy",
    "question": "A plant manager wants next month's production schedule at MINIMUM total cost, subject to machine capacity, labor hours, and contracted demand — all firm requirements. Report the optimal schedule and its cost.",
    "expected_skill": null,
    "expected_script": null,
    "ground_truth": "DECOY (negative) — the multi-objective-exploration skill should NOT activate, and in particular the front-completion workflow should not. There is a single clear objective (minimize cost) and the requirements are genuinely fixed, so there is no tradeoff to explore, no frontier to trace, and no gaps to measure or fill. The correct response is one optimization solve returning ONE schedule and its cost.",
    "expected_behavior": [
      "Recognizes a single objective with hard constraints, not a tradeoff",
      "Does NOT trace a frontier, sweep weights or epsilon bounds, or run any gap-measurement/fill pass",
      "Returns one optimal schedule and its cost from one solve"
    ]
  }
]

BENCHMARK.md 4.8 KB

# Skill Benchmark: cuopt-multi-objective-exploration

> ✅ **Overall verdict: PASS — Recommended for publication**

## Publication Recommendation

Recommended for publication based on the completed evaluation evidence in this report.

## Evaluation Metadata

- Skill: `cuopt-multi-objective-exploration`
- Evaluation date: 2026-08-05
- Evaluator version: `1.0.0`
- Agents: Claude Code (`aws/anthropic/bedrock-claude-opus-4-8`), Codex (`openai/openai/gpt-5.5`)
- Tasks: 8 evaluation tasks (6 positive, 2 negative)
- Dataset digest: `sha256:45bef5ee60d2a85ef8c4a7175c3d9a15eeac738e7bcf291d44de12ad4a35fff2` (skill-evaluator-dataset-snapshot/1)
- Attempts per task: 1
- Environment: `k8s-sandbox`
- Tier 3 evidence: required for publication

Each task attempt ran in its own isolated sandbox pod.

## What This Report Answers

The three-tier evaluation checks whether the skill:

- is safe to use;
- produces correct answers;
- is discovered and activated when needed;
- helps the agent complete the user's goal and expected workflow; and
- avoids wasted skill and tool usage.

## Results at a Glance

| Measure | Claude Code (Baseline → Skill Uplift) | Codex (Baseline → Skill Uplift) |
|---|---:|---:|
| Overall | 65% → 97% (+33 points) | 67% → 90% (+23 points) |
| Security | 100% → 100% (±0 points) | 100% → 100% (±0 points) |
| Correctness | 95% → 100% (+5 points) | 95% → 100% (+5 points) |
| Discoverability | 25% → 100% (+75 points) | 44% → 84% (+40 points) |
| Effectiveness | 79% → 87% (+8 points) | 73% → 85% (+12 points) |
| Efficiency | 25% → 100% (+75 points) | 25% → 83% (+58 points) |

**How to read this table:** baseline is the same task attempted without the target skill. Uplift is `skill score - baseline score`, shown in percentage points.

Example: `47% → 92% (+45 points)` means the skill-assisted run scored 92%, 45 percentage points above its 47% no-skill baseline.

## Tier Status

| Tier | Purpose | Status | Evidence |
|---|---|---|---|
| Tier 1 | Static validation | **PASSED WITH OBSERVATIONS** | 1 validator(s); 4 finding(s) |
| Tier 2 | Semantic deduplication | **NOT RUN** | No result was recorded |
| Tier 3 | Live agent evaluation | **PASS** | 2 agent(s); 8 task(s) |

## Findings and Observations

<details>
<summary>Show detailed findings and successful checks</summary>

- **MEDIUM** SCHEMA/frontmatter_field_placement: Root field 'version' is ignored; use 'metadata.version' (`skills/cuopt-multi-objective-exploration/SKILL.md`)
- **MEDIUM** SCHEMA/body_recommended_section: Missing recommended section: '## Instructions' (`skills/cuopt-multi-objective-exploration/SKILL.md`)
- **MEDIUM** SCHEMA/body_recommended_section: Missing recommended section: '## Examples' (`skills/cuopt-multi-objective-exploration/SKILL.md`)
- **LOW** SCHEMA/author_format: Author must be of the form 'Name <email@host>' (`skills/cuopt-multi-objective-exploration/SKILL.md`)

</details>

## Scoring Methodology

<details>
<summary>Show dimension definitions, source signals, and thresholds</summary>

| Dimension | Question | Scored signals |
|---|---|---|
| Security | Is it safe to use? | `security` (100%) |
| Correctness | Is the answer correct? | `accuracy` (100%) |
| Discoverability | Was the right skill loaded when needed? | `skill_execution` (100%) |
| Effectiveness | Did the skill help complete the task? | `goal_accuracy` (50%) + `behavior_check` (50%) |
| Efficiency | Did it avoid wasted tool or skill usage? | `skill_efficiency` (100%) |

- Dimension bands: PASS at 50% or above; NEUTRAL from 40% to below 50%; FAIL below 40%.
- Overall Tier 3 lift: PASS at +5 points or more; FAIL at -10 points or less; values between those bands are NEUTRAL.
- Overall verdict: PASS only when every configured dimension passes for at least one supported agent. Lift is reported as diagnostic evidence and does not override this gate.
- The 50% attempt pass threshold is a separate per-task gate; it is not the dimension pass threshold.
- Effectiveness is the equal-weight mean of goal completion (`goal_accuracy`) and expected workflow adherence (`behavior_check`).
- Token efficiency is a separate report-only signal. It does not change a dimension score or the overall verdict.

Signals present in this run:

- `security` (Security): unsafe operations, secret leakage, and unauthorized access.
- `skill_execution` (Skill Execution): whether the expected skill was found and executed.
- `skill_efficiency` (Efficiency): routing quality, workspace-aware skill reads, and productive tool use.
- `accuracy` (Accuracy): final-answer correctness against the reference answer.
- `goal_accuracy` (Goal Accuracy): whether the user's goal was achieved.
- `behavior_check` (Behavior Check): whether the expected workflow behavior was followed.

</details>

## Freshness

Regenerate this benchmark when the skill, evaluation dataset, target agent/model, evaluator version, environment, or scoring policy changes.

skill-card.md 3.9 KB

## Description: <br>
Trace, complete, and interpret the Pareto frontier across competing objectives using repeated single-objective cuOpt solves (weighted-sum and ε-constraint). <br>

This skill is ready for commercial/non-commercial use. <br>

## Owner
NVIDIA <br>

### License/Terms of Use: <br>
Apache 2.0 <br>
## Use Case: <br>
Developers and engineers who need to explore multi-objective tradeoffs (cost vs. service level, return vs. risk, makespan vs. overtime) by generating and interpreting Pareto frontiers from sequences of cuOpt LP, MILP, or QP solves. <br>

### Deployment Geography for Use: <br>
Global <br>

## Requirements / Dependencies: <br>
**Requires API Key or External Credential:** [Not Specified] <br>
**Credential Type(s):** [None identified] <br>

Do not include secrets in prompts/logs/output; use least-privilege credentials; rotate keys as appropriate. <br>

## Known Risks and Mitigations: <br>
Risk: Review before execution as proposals could introduce incorrect or misleading guidance into skills. <br>
Mitigation: Review and scan skill before deployment. <br>

## Reference(s): <br>
- [cuOpt User Guide](https://docs.nvidia.com/cuopt/user-guide/latest/introduction.html) <br>
- [cuopt-examples](https://github.com/NVIDIA/cuopt-examples) <br>


## Skill Output: <br>
**Output Type(s):** [Analysis, Configuration instructions] <br>
**Output Format:** [Markdown with structured tables and code blocks] <br>
**Output Parameters:** [1D] <br>
**Other Properties Related to Output:** [None] <br>

## Evaluation Agents Used: <br>
- Claude Code (`aws/anthropic/bedrock-claude-opus-4-8`) <br>
- Codex (`openai/openai/gpt-5.5`) <br>



## Evaluation Tasks: <br>
8 evaluation tasks (6 positive, 2 negative) run in isolated sandbox pods. <br>

## Evaluation Metrics Used: <br>
Reported benchmark dimensions: <br>
- Security: Checks for unsafe operations, secret leakage, and unauthorized access. <br>
- Correctness: Final-answer correctness against the reference answer. <br>
- Discoverability: Whether the expected skill was found and executed when needed. <br>
- Effectiveness: Whether the skill helped complete the user's goal and expected workflow. <br>
- Efficiency: Routing quality, workspace-aware skill reads, and productive tool use. <br>

Underlying evaluation signals used in this run: <br>
- `security`: Unsafe operations, secret leakage, and unauthorized access. <br>
- `skill_execution`: Whether the expected skill was found and executed. <br>
- `skill_efficiency`: Routing quality, workspace-aware skill reads, and productive tool use. <br>
- `accuracy`: Final-answer correctness against the reference answer. <br>
- `goal_accuracy`: Whether the user's goal was achieved. <br>
- `behavior_check`: Whether the expected workflow behavior was followed. <br>



## Evaluation Results: <br>
| Measure | Claude Code (Baseline → Skill Uplift) | Codex (Baseline → Skill Uplift) |
|---|---:|---:|
| Overall | 65% → 97% (+33 points) | 67% → 90% (+23 points) |
| Security | 100% → 100% (±0 points) | 100% → 100% (±0 points) |
| Correctness | 95% → 100% (+5 points) | 95% → 100% (+5 points) |
| Discoverability | 25% → 100% (+75 points) | 44% → 84% (+40 points) |
| Effectiveness | 79% → 87% (+8 points) | 73% → 85% (+12 points) |
| Efficiency | 25% → 100% (+75 points) | 25% → 83% (+58 points) |

## Skill Version(s): <br>
26.10.00 (source: frontmatter) <br>

## Ethical Considerations: <br>
NVIDIA believes Trustworthy AI is a shared responsibility and we have established policies and practices to enable development for a wide array of AI applications. When downloaded or used in accordance with our terms of service, developers should work with their internal team to ensure this skill meets requirements for the relevant industry and use case and addresses unforeseen product misuse. <br>

(For Release on NVIDIA Platforms Only) <br>
Please report quality, risk, security vulnerabilities or NVIDIA AI Concerns [here](https://app.intigriti.com/programs/nvidia/nvidiavdp/detail). <br>

SKILL.md 15.3 KB

---
name: cuopt-multi-objective-exploration
version: "26.10.00"
description: Trace, complete, and interpret the Pareto frontier across competing objectives using repeated single-objective cuOpt solves (weighted-sum and ε-constraint).
license: Apache-2.0
origin: cuopt-skill-evolution
metadata:
  author: NVIDIA cuOpt Team
  tags:
    - multi-objective
    - pareto
    - epsilon-constraint
    - tradeoff
    - workflow
---


# Multi-Objective Exploration


cuOpt optimizes **one** objective per solve. Many real problems have several objectives that pull against each other — cost vs. service level, return vs. risk, makespan vs. overtime, distance vs. vehicle count. A single solve answers "what's optimal *for one particular weighting*," but it hides the tradeoff the user actually needs to see.

This skill turns a sequence of single-objective cuOpt solves into a **Pareto frontier** — the set of solutions where you can't improve one objective without giving up another — and gives the discipline to read it. It adds no solver features; it orchestrates the LP / MILP / QP solves already covered by the formulation and API skills.

## When this applies

Reach for this workflow when the problem has **two or more objectives with no agreed-upon weighting**, signalled by language like:

- "balance X and Y", "trade off", "as cheap as possible *without* hurting service"
- "minimize cost *and* maximize coverage", "I want options, not one answer"
- any objective the user is willing to relax in exchange for another

If there is a single clear objective (everything else is a hard constraint), this skill does not apply — formulate and solve once.

## Core idea — one solve is one point on a curve

A single optimum encodes **one implicit weighting** of the objectives. Change the weighting and the optimum moves. The frontier is the curve traced by all the non-dominated optima.

A solution **A dominates** B when A is at least as good on every objective and strictly better on one. Dominated solutions are never worth choosing. The **Pareto frontier** is exactly the non-dominated set; the user's job is to pick a point on it, and yours is to show them the whole curve plus where the tradeoff is sharpest.

Do not collapse a multi-objective problem to a single weighted number and report its optimum as "the answer" — that silently makes the tradeoff decision *for* the user. Trace the frontier and let them choose.

Objectives and constraints are interchangeable. A requirement currently treated as fixed — a coverage floor, a fairness cap, a budget — is often a latent objective: its level was assumed, not given. Promoting such a constraint to a parametric ε-constraint and sweeping it reveals a tradeoff you'd otherwise hide, so read a single-objective model's hard constraints as candidate objectives, not just limits — but only when the level was an assumption. A genuinely fixed, non-negotiable limit (a hard budget cap, a regulatory minimum) stays a constraint; don't manufacture a tradeoff that isn't there. Express any promoted quantity linearly so it can serve as an ε-constraint (see `cuopt-numerical-optimization-formulation`).

## Step 1 — define the objectives

An informative frontier needs objectives that genuinely conflict: if they don't pull against each other, it collapses to a single point with nothing to trade off. And each objective has to be formulated correctly, since a wrong form, sense, or scale distorts the tradeoff and shifts where the knee falls. Formulate each one with `cuopt-numerical-optimization-formulation` before sweeping.

## Step 2 — build a payoff table (anchor each objective)

Solve each objective **on its own** first. For *k* objectives this is *k* solves. Record, for each, the value of every objective at that optimum:

```text
              f1        f2        f3
min f1   →   f1*       f2(at f1*) f3(at f1*)
min f2   →   ...       f2*        ...
min f3   →   ...       ...        f3*
```

The diagonal (`f1*`, `f2*`, …) is each objective's best achievable value; the off-diagonals give the **range** each objective spans across the others' optima. This table does double duty:

- It sets the **sweep bounds** for the ε-constraint method (the feasible range of each constrained objective).
- It supplies the **scales** for normalization — objectives in dollars, percent, and hours can't be weighted meaningfully until divided by their ranges.

If any single-objective solve is already infeasible, stop and fix the model before sweeping — the frontier doesn't exist yet.

## Step 3 — choose a scalarization

### Weighted sum

Combine the objectives into one and sweep the weights:

```text
minimize  w1·f1(x) + w2·f2(x) + ... ,   for a grid of weight vectors w
```

Cheap and trivial with any solver. Two limitations to respect:

- **It only finds points on the convex hull of the frontier.** Concave (non-convex) regions of the frontier are unreachable no matter how you choose weights, and for MILP the reachable points can be sparse with large gaps. A frontier that looks suspiciously linear or has only a few clustered points is the symptom.
- **Weights are not priorities until the objectives are normalized.** Divide each `f_k` by its payoff-table range first; otherwise the largest-magnitude objective dominates regardless of intent.

### ε-constraint (preferred for a complete frontier)

Keep one objective; move the rest to constraints and sweep their right-hand sides:

```text
minimize  f1(x)
subject to  f2(x) ≤ ε2
            f3(x) ≤ ε3
            (original constraints)
```

Sweep each `ε_k` across the range from the payoff table. Each `(ε2, ε3, …)` combination is a single standard cuOpt solve. This recovers the **full** frontier, including the concave regions weighted-sum cannot reach, which is why it's the default when completeness matters. The cost is more solves (a grid over the constrained objectives) and bookkeeping of the ε values.

ε-constrain *linear* objectives directly. A quadratic objective (e.g. risk `xᵀΣx`) is simplest kept as the objective `f1` while you ε-constrain the linear ones. A **convex** quadratic objective *can* instead be ε-constrained directly: add it as a quadratic constraint `xᵀQx ≤ ε`, which cuOpt supports. Non-convex or equality quadratic constraints are unsupported, and the MILP path stays linear-constraint only.

Spot it in existing code: a hand-coded loop over a target or budget value (a return target, a cost cap) is already the ε-constraint method — name it as such, filter dominated points, and read the swept constraint's dual (LP/QP only).

**Read that dual as the local exchange rate.** Where the frontier is smooth, the dual on a swept ε-constraint is its slope — how much the kept objective `f1` moves per unit of the bound — at no cost beyond the solve already run; at a kink it gives only a one-sided rate. A **zero** dual usually means the bound is slack — the sweep has run past the frontier's edge (one-way: a slack bound always shows a zero dual, but under degeneracy a binding bound can too). This reading needs LP/QP and a *linear* ε-constraint (MILP optima and problems with quadratic constraints return no duals) — where duals are unavailable, difference adjacent frontier points instead.

**Picking a method:** weighted-sum for a quick convex sketch or when you know the frontier is convex (e.g. a pure-LP/QP tradeoff); ε-constraint when the problem is MILP, when the frontier may be non-convex, or when the user needs a faithful and complete curve.

## Step 4 — sweep, collect, and filter

```text
frontier = []
for each weight vector (or ε vector) in the grid:
    set the combined objective (or ε right-hand sides)
    solve with cuOpt              # reuse the prior solution as a warm start
    if status is Optimal/Feasible:
        record (objective values, solution)
discard dominated and duplicate points
sort the survivors to form the frontier
```

Practical notes:

- **Warm-start LP sweeps.** For an LP frontier, carry the previous solve's PDLP warmstart data into the next to cut solve time. Per cuOpt this is **LP-only**: a MILP solve doesn't take a PDLP warmstart (you can optionally seed a MIP start instead). See `cuopt-numerical-optimization-api` for the calls.
- **Cap each MILP solve.** Set a per-solve time limit on MILP sweeps (see `cuopt-numerical-optimization-api`) — a sweep is many solves, and branch-and-bound can over-spend certifying optimality past a tiny gap, while cuOpt sets no limit by default and won't warn. Report the points as optimal *to the gap you set*, not certified optimal.
- **Filter dominated points.** A correct sweep can still emit dominated points (especially weighted-sum near the hull, or MILP). Drop them; they are not part of the frontier.
- **Resolution is a budget.** Curve fidelity trades against solve count. Start coarse to see the shape, then refine the grid only where the curve bends.
- **Spend the budget where the slope changes (LP/QP).** Because the ε-constraint dual is the frontier's local slope, compare it across solved points: where it barely changes, the curve is nearly straight — interpolate rather than add solves; where it jumps by more than the solve tolerance, the frontier bends between those points — refine there (smaller differences are solver noise, not curvature). This concentrates solves where the curve actually bends instead of spreading them over a uniform grid. On MILP, judge where to refine from the gaps between primal objective values instead.
- **Verify, don't assume.** When you claim one method beats another, measure it — e.g. count the efficient points ε-constraint recovered that weighted-sum missed — rather than asserting it; and flag any solve returning feasible-but-not-`Optimal` so a non-certified point is never read as exact.

## Step 5 — complete the frontier: measure and fill what the sweep missed

A weighted-sum sweep returns only **supported** points (Step 3's convex-hull limitation); on MILP frontiers, non-supported points — the ones no weighted-sum weighting returns — often make up much of the non-dominated set. A coarse ε-constraint grid leaves gaps the same way: any finite sweep can miss regions. Before presenting a swept frontier, measure the likely miss and decide whether to fill.

### Measure the miss

Sort the swept points by one objective. For each adjacent pair, form the rectangle (in general, the box) between them in objective space; flag any box much larger than the median adjacent box (3× is a reasonable bar) or covering a large share of the frontier's spanned area — a sweep that returned only a handful of points is all gaps, so no box stands out from the median. Large boxes have two causes — non-supported regions (weighted sum cannot reach them, common under fixed-charge structure) and weight clustering (a finite grid re-discovering the same corners, even on a nearly convex frontier). The fill step treats both the same.

If all boxes are small and even, the sweep is likely adequate — say so and stop.

### Fill the largest gaps first

For each flagged box, solve one ε-constraint subproblem targeted inside it: optimize one objective with the other bounded at the box midpoint (bi-objective; with more objectives, sort by each objective in turn and place one target per flagged box instead of recursing). Only certified `Optimal` results settle or steer anything here — a time-limited incumbent is kept as a point (tagged, below) but proves nothing about the gap. A new certified point that survives Step 4's dominance filter means the gap was real (an ε solve can return a weakly optimal point) — bisect: two more targets inside the two sub-boxes it creates. A certified endpoint coming back clears just the probed side of the bound; certifying the whole box as a true discontinuity also needs a known objective step size — all-integer objective coefficients over integer variables give one — to place the bound just inside the far endpoint and match its certified optimum. Without that step size, report the box as a candidate gap, not a proven discontinuity. Stop on a solve budget, or when the remaining boxes fall below the flag bar.

### Warm-start each solve (cheap insurance)

Consecutive fill solves differ by one bound, so seed each with its neighbor as a MIP start (Step 4's warm-start note) — one line, and it never changes what is optimal. Expect unchanged solve times; the value is insurance on hard subproblems.

### Degrade gracefully, never silently

If a subproblem hits its time limit with a feasible incumbent (`FeasibleFound`), keep the point — it is feasible, and the solve's reported gap bounds its suboptimality — but record it as approximate. The time-capped solve is the primary fallback: it returns both an incumbent and a bound. Heuristics-only mode (`mip_heuristics_only`) drops the proof work and returns feasible points with no gap bound — use it when feasible points are all you need, and tag everything it returns approximate.

### Report with provenance

Every presented point carries one of two tags:

- **exact** — `Optimal` at your gap setting, i.e. optimal to that gap (Step 4);
- **approximate** — time-limited incumbent (quote its reported gap) or heuristics-only result (no bound exists; say so).

State the counts with the frontier ("14 points, 11 exact, 3 approximate near the low-cost end, worst gap 2.4%"). Never present a mixed frontier as uniformly optimal.

## Step 6 — interpret the frontier

- **Report tradeoffs, not single numbers.** A frontier point means nothing in isolation. Quote the exchange rate — "≈ $4k of extra cost per 1% of added coverage in this region" — so the user can judge whether a move is worth it. On an LP/QP frontier this exchange rate is the swept constraint's dual at that point — the local slope of the frontier, accurate to the solve's optimality tolerance (tighten it before relying on a dual); on MILP, estimate it from the gap to the adjacent frontier point.
- **Flag knee points; don't auto-pick them.** The "knee" is where the curve bends most sharply — beyond it you pay a lot for a little. It's often the best-balanced compromise and worth highlighting, but the final choice is the user's preference, not a rule. At the knee the slope is two-sided — the dual just below differs from just above — so quote the exchange rate there as a range, not one number.
- **Treat dominated or gappy output as a diagnostic.** If dominated points survive filtering, or the frontier is implausibly sparse or perfectly linear, suspect the sweep or the model — most often weighted-sum hiding a concave region (return to Step 5 and fill the gaps) or a normalization mistake.
- **State the weighting/ε you used.** Every reported point is conditional on its scalarization. Make that explicit so a single solve is never mistaken for "the" optimum. On LP/QP, the ε-constraint duals are the *implicit weights* at that point — the effective price the solution puts on each constrained objective, and the weights a weighted-sum solve would need to reproduce that tradeoff. Reporting them makes the accepted tradeoff ratio explicit.

## Interfaces

This skill is solver- and interface-agnostic. The per-solve mechanics — building the objective, adding the ε constraints, passing a warm start, reading status — live in the API skills:

- `cuopt-numerical-optimization-api` — LP, MILP, QP solves (Python, C, CLI).
- `cuopt-routing-api-python` — the same frontier workflow applies to routing tradeoffs (distance vs. vehicles vs. time).