cuopt-numerical-optimization-formulation
Skill1.1k starsChanged 5 months agoApache-2.0View on GitHub
LP, MILP, QP — concepts, problem-text parsing, and formulation patterns (parameters, constraints, decisions, objective). Concepts only; no API.
1 other project uses a version of this, 1 of them edited.
Adopted by
Steady: 0 new projects took it in the last 4 weeks, none the 4 weeks before.thin data
Most recently taken up by
- NVIDIA/skillsedited, first seen Oct 1, 2026
Who's talking about NVIDIA/cuopt
- jump-dev/cuOpt.jl“Support QP interface via MOI”GitHub · Jan 10, 2026 · 4 reactions
- rapidsai/build-planning“Add `zizmor` to all RAPIDS projects and address all warnings”GitHub · Apr 30, 2026 · 3 reactions
- rapidsai/build-planning“Add `shellcheck` across `RAPIDS`”GitHub · Jan 16, 2025 · 3 reactions
- rapidsai/build-planning“use ruff instead of `black` / `flake8` / `isort` across RAPIDS”GitHub · Dec 30, 2024 · 3 reactions
- rapidsai/build-planning“Python 3.14 support”GitHub · Jul 30, 2025 · 2 reactions
The biggest 5 of 45 mentions linking to the repository that our crawl found. Each line is their own headline.
See all 45
Talked about on GitHub (45 times).
On GitHub · 45
- Jan 10, 2026Support QP interface via MOI — jump-dev/cuOpt.jl4 reactions · 15 comments
- Apr 30, 2026Add `zizmor` to all RAPIDS projects and address all warnings — rapidsai/build-planning3 reactions · 9 comments
- Jan 16, 2025Add `shellcheck` across `RAPIDS` — rapidsai/build-planning3 reactions · 13 comments
- Dec 30, 2024use ruff instead of `black` / `flake8` / `isort` across RAPIDS — rapidsai/build-planning3 reactions · 10 comments
- Jul 30, 2025Python 3.14 support — rapidsai/build-planning2 reactions · 17 comments
40 more on GitHub
- Oct 6, 2026Drop Python 3.11 support — rapidsai/build-planning1 reaction
- Jul 23, 2026Add isolated load_library() smoke tests for library wheels — rapidsai/build-planning1 reaction · 1 comment
- Apr 17, 2026Consistent artifact naming across wheels and conda packages — rapidsai/build-planning1 reaction · 3 comments
- Apr 1, 2026install libgrpc-dev into pip devcontainers for cuopt — rapidsai/devcontainers1 reaction · 5 comments
- Dec 16, 2025Add cuOpt to unified devcontainers — rapidsai/devcontainers1 reaction · 5 comments
- Dec 11, 2025Update to CCCL 3.2 — rapidsai/build-planning1 reaction · 2 comments
- Dec 9, 2025Switch RAPIDS to static linking of libcudart by default — rapidsai/build-planning1 reaction
- Aug 5, 2025Add CUDA 13.0 Support across all of RAPIDS — rapidsai/build-planning1 reaction · 12 comments
- Jul 15, 2025Adding GAMSPy transportation model example as Jupyter notebook — NVIDIA/cuopt-examples1 reaction · 2 comments
- Jun 4, 2025integrate cuOpt solver into cvxpy — cvxpy/cvxpy1 reaction · 37 comments
- Feb 11, 2025Use SPDX license tags in pyproject.toml — rapidsai/build-planning1 reaction · 13 comments
- Nov 8, 2026agent-skills.github.nvidia.cuopt: init at 26.10.00 — sudosubin/agents.nix0 reactions
- Nov 1, 2026Bump the python-dependencies group across 1 directory with 3 updates — Amirhosseinheidari/SolverPilot0 reactions
- Oct 28, 2026claude-code-plugins.github.nvidia.cuopt: init at 26.10.00 — sudosubin/agents.nix0 reactions
- Oct 28, 2026claude-code-marketplaces.github.nvidia.cuopt: init at 26.10.00 — sudosubin/agents.nix0 reactions
- Oct 25, 2026SAE Engineer: P7A GPU LP solver landscape and isolated compatibility experiment — JohnnyZPiggy/AccelSched0 reactions · 8 comments
- Oct 21, 2026Integrate cuOpt as a GPU UDTF family — algeon-dev/algeon0 reactions
- Oct 18, 2026Exploration: GPU-accelerated MILP (NVIDIA cuOpt) as a solver backend? — UBC-FRESH/fhops0 reactions · 5 comments
- Oct 2, 2026docs: add sphinx-llm for agent docs support to libraries — rapidsai/build-planning0 reactions · 1 comment
- Oct 1, 2026CI: use proxy cache for pypi.anaconda.org — rapidsai/build-planning0 reactions · 2 comments
- Sep 10, 2026Update RAPIDS to CUDA 13.4 — rapidsai/build-planning0 reactions · 3 comments
- Sep 9, 2026Properly leverage pre-commit cache — rapidsai/build-planning0 reactions · 7 comments
- Sep 8, 2026Adding Python 3.15 — rapidsai/build-planning0 reactions · 8 comments
- Aug 29, 2026Migrate stream APIs from rmm::cuda_stream_view to cuda::stream_ref — rapidsai/build-planning0 reactions · 1 comment
- Aug 21, 2026Skip duals when quadratic constraints are present — jump-dev/cuOpt.jl0 reactions
- Aug 6, 2026wheels: run 'abi3audit' for limited ABI wheels — rapidsai/build-planning0 reactions · 2 comments
- Aug 4, 2026Update rapids-logger pins to 0.3 — rapidsai/build-planning0 reactions · 1 comment
- Aug 3, 2026Migrate constraint generation to `constraints` output type in DFG — rapidsai/build-planning0 reactions · 1 comment
- Jul 31, 2026Fix GB300 failures — rapidsai/build-planning0 reactions · 1 comment
- Jul 20, 2026use `yamllint` for any projects using `rapids-dependency-file-generator` — rapidsai/build-planning0 reactions · 1 comment
- Jul 1, 2026Use NVIDIA theme in library docs — rapidsai/build-planning0 reactions · 3 comments
- Jun 10, 2026cuOpt barrier/PDLP wrong result on a ranged constraint with a large finite bound (worked around; upstream #1806 filed) — spoorendonk/mcfcg0 reactions · 2 comments
- Jun 2, 2026Migrate off of `cuda-python` metapackage to `cuda-bindings` and friends — rapidsai/build-planning0 reactions · 3 comments
- Apr 22, 2026Add support for MOI.ConstraintDual — jump-dev/cuOpt.jl0 reactions · 3 comments
- Apr 13, 2026Add CUDA support — ctlab/virgo-solver0 reactions
- Mar 12, 2026Standardize on `pyproject.toml` for pytest settings — rapidsai/build-planning0 reactions · 1 comment
- Feb 14, 2026Integration with cuopt (open source) — google/or-tools0 reactions · 2 comments
- Oct 29, 2025Bindings for cuOpt solver — PyPSA/linopy0 reactions · 4 comments
- Oct 7, 2025[FEA]: SoL on cub::Transform for custom/zip input and output iterator — NVIDIA/cccl0 reactions · 1 comment
- Sep 23, 2025ensure every repo has fallback CODEOWNERS — rapidsai/build-planning0 reactions
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 1
- NVIDIA/skills★ 3.9k100% same
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository9 other files it gives its agents.
- AGENTS.mdAGENTS.md
- cuopt-developerSkill
- cuopt-installSkill
- cuopt-multi-objective-explorationSkill
- cuopt-numerical-optimization-apiSkill
- cuopt-routing-api-pythonSkill
- cuopt-server-api-pythonSkill
- cuopt-skill-evolutionSkill
- cuopt-user-rulesSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
13 rules. About 0 are common, 11 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈11
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 39
If the objective is purely linear, prefer LP/MILP — do not artificially introduce quadratic terms.
- Distinctive: line 45
Ask these if not already clear:
- Distinctive: line 71
When the user gives problem text, classify every sentence and then summarize before formulating.
- Distinctive: line 75
Ambiguity: If anything is still ambiguous, ask the user or solve all plausible interpretations and report all outcomes.
- Distinctive: line 79
If there is any doubt about whether a constraint or value should be included, ask the user and state the possible interpretations.
- Distinctive: line 83
When the user asks to run the complete path (e.g., end-to-end, full pipeline), run all plausible variants and report all outcomes so the …
- Distinctive: line 181
When modeling concave piecewise-linear profit/cost functions (e.g., decreasing marginal profit for bulk sales), the standard approach uses …
- Distinctive: line 249
Include it: when the problem states or implies that purchases are received before sales happen within a period (sequential operations), or …
- Distinctive: line 250
Omit it: when buying and selling are concurrent within a period (common in textbook trading/inventory problems) and the capacity applies …
- Very specific: line 254
Default: If the problem does not specify timing within a period, use only end-of-period capacity (stock[t] <= capacity).
- Distinctive: line 270
Scenario enumeration: When only 2–3 products exist, enumerate which products receive the intermediate (all-to-A, all-to-B, split).
- Distinctive: line 274
Before formulating, check whether using the intermediate in each product is profitable:
- Very specific: line 276
If cost_intermediate > sell_price[j] for some product j, the intermediate should not be allocated to product j.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Numerical Optimization Formulation
Concepts and workflow for going from a problem description to a clear formulation across LP, MILP, and QP. No API code here.
What is LP / MILP / QP
- LP: Linear objective, linear constraints, continuous variables.
- MILP: Same as LP plus some integer or binary variables (e.g., scheduling, facility location, selection).
- QP: Quadratic objective (e.g., x², x·y terms — portfolio variance, least squares), linear constraints. QP support in cuOpt is currently in beta.
Identifying problem type
| Property | LP | MILP | QP |
| Objective | Linear | Linear | Quadratic (xᵀQx + cᵀx) |
| Constraints | Linear | Linear | Linear + convex quadratic (inequality only) via second-order cones |
| Variables | Continuous | Mixed: continuous + integer/binary | Continuous |
| Sense | min or max | min or max | minimize only (negate to max) |
| Duals / sensitivity | Dual values + reduced costs | None (integer optima) | Dual values + reduced costs |
If the objective is purely linear, prefer LP/MILP — do not artificially introduce quadratic terms. If any variable is integer or binary, the problem is MILP regardless of the rest.
Post-solve sensitivity (LP / QP only). Continuous LP and QP solutions expose dual values (the marginal objective change per unit a binding constraint is relaxed: where to invest to improve the outcome) and reduced costs (for a variable the optimizer left at zero, how far it must improve to enter the solution: a near-miss). MILP solutions have no duals — integer optima are not continuous, so there are none to return. Duals are also unavailable when the model includes quadratic constraints — the second-order cone path returns primal values only. See the language-specific API skills for how to retrieve them after a solve.
Required formulation questions
Ask these if not already clear:
- Decision variables — What are they? Bounds?
- Objective — Minimize or maximize? Linear or quadratic? For QP: any squared or cross terms (x², x·y)? If maximize a quadratic, the user must negate and minimize.
- Constraints — Linear inequalities/equalities? Convex quadratic constraints (inequality only) are also supported, handled as second-order cones; non-convex or equality quadratic constraints are not.
- Variable types — All continuous (LP / QP) or some integer/binary (MILP)?
- Convexity (QP only) — For minimization, the quadratic form (matrix Q) should be positive semi-definite for well-posed problems.
Typical modeling elements
- Continuous variables — production amounts, flow, allocations, portfolio weights.
- Binary variables — open/close, yes/no (e.g., facility open, item selected).
- Linking constraints — e.g., production only if facility open (Big-M or indicator).
- Resource constraints — linear cap on usage (materials, time, capacity).
- Quadratic objective terms — variance (xᵀQx), squared error (‖Ax − b‖²), interaction terms.
Typical QP use cases
- Portfolio optimization — minimize variance subject to return and budget.
- Least squares — minimize ‖Ax − b‖² subject to linear constraints.
- Other quadratic objectives with linear constraints.
Problem statement parsing
When the user gives problem text, classify every sentence and then summarize before formulating. The parsing framework below applies regardless of LP / MILP / QP.
Classify every sentence as parameter/given, constraint, decision, or objective. Watch for implicit constraints (e.g., committed vs optional phrasing) and implicit objectives (e.g., "determine the plan" + costs → minimize total cost).
Ambiguity: If anything is still ambiguous, ask the user or solve all plausible interpretations and report all outcomes; do not assume a single interpretation.
🔒 MANDATORY: When in Doubt — Ask
- If there is any doubt about whether a constraint or value should be included, ask the user and state the possible interpretations.
🔒 MANDATORY: Complete-Path Runs — Try All Variants
- When the user asks to run the complete path (e.g., end-to-end, full pipeline), run all plausible variants and report all outcomes so the user can choose; do not assume a single interpretation.
Three labels
| Label | Meaning | Examples (sentence type) |
| Parameter / given | Fixed data, inputs, facts. Not chosen by the model. | "Demand is 100 units." "There are 3 factories." "Costs are $5 per unit." |
| Constraint | Something that must hold. May be explicit or implicit from phrasing. | "Capacity is 200." "All demand must be met." "At least 2 shifts must be staffed." |
| Decision | Something we choose or optimize. | "How much to produce." "Which facilities to open." "How many workers to hire." |
| Objective | What to minimize or maximize. May be explicit ("minimize cost") or implicit ("determine the plan" with costs given). | "Minimize total cost." "Determine the production plan" (with costs) → minimize total cost. |
Implicit constraints: committed vs optional phrasing
Committed/fixed phrasing → treat as parameter or implicit constraint (everything mentioned is given or must happen). Not a decision.
| Phrasing | Interpretation | Why |
| "Plans to produce X products" | Constraint: all X must be produced. | Commitment; production level is fixed. |
| "Operates 3 factories" | Parameter: all 3 are open. Not a location-selection problem. | Current state is fixed. |
| "Employs N workers" | Parameter: all N are employed. Not a hiring decision. | Workforce size is given. |
| "Has a capacity of C" | Parameter (C) + constraint: usage ≤ C. | Capacity is fixed. |
| "Must meet all demand" | Constraint: demand satisfaction. | Explicit requirement. |
Optional/decision phrasing → treat as decision.
| Phrasing | Interpretation | Why |
| "May produce up to …" | Decision: how much to produce. | Optional level. |
| "Can choose to open" (factories, sites) | Decision: which to open. | Selection is decided. |
| "Considers hiring" | Decision: how many to hire. | Hiring is under consideration. |
| "Decides how much to order" | Decision: order quantities. | Explicit decision. |
| "Wants to minimize/maximize …" | Objective (drives decisions). | Goal; decisions are the levers. |
Implicit objectives — do not miss
If the problem asks to "determine the plan" (or similar) but does not state "minimize" or "maximize" explicitly, the objective is often implicit. You MUST identify it and state it before formulating; do not build a model with no objective.
| Phrasing / context | Likely implicit objective | Why |
| "Determine the production plan" + costs given (per unit, per hour, etc.) | Minimize total cost (production + inspection/sales + overtime, etc.) | Plan is chosen; costs are specified → natural goal is to minimize total cost. |
| "Determine the plan" + costs and revenues given | Maximize profit (revenue − cost) | Both sides of the ledger → optimize profit. |
| "Try to determine the monthly production plan" + workshop hour costs, inspection/sales costs | Minimize total cost | All cost components are given; no revenue to maximize → minimize total cost. |
Rule: When the problem gives cost (or cost and revenue) data and asks to "determine", "find", or "establish" the plan, always state the objective explicitly (e.g., "I'm treating the objective as minimize total cost, since only costs are given."). If both cost and revenue are present, state whether you use "minimize cost" or "maximize profit". Ask the user if unclear.
Parsing workflow
- Split the problem text into sentences or logical clauses.
- Label each: parameter/given | constraint | decision | objective (if stated).
- Identify the objective (explicit or implicit): If the problem says "minimize/maximize X", that's the objective. If it only says "determine the plan" (or "find", "establish") but gives costs (and possibly revenues), the objective is implicit — state it (e.g., minimize total cost, or maximize profit) and confirm with the user if ambiguous.
- Flag implicit constraints: For each sentence, ask — "Does this state a fixed fact or a requirement (→ parameter/constraint), or something we choose (→ decision)?"
- Resolve ambiguity by checking verbs and modals:
- "is", "has", "operates", "employs", "plans to" (fixed/committed) → parameter or implicit constraint.
- "may", "can choose", "considers", "decides", "wants to" (optional) → decision or objective.
- 🔒 MANDATORY — If anything is still ambiguous (e.g., a value or constraint could be read two ways): ask the user which interpretation is correct, or solve all plausible interpretations and report all outcomes. Do not assume a single interpretation.
- Summarize for the user: list parameters, constraints (explicit + flagged implicit), decisions, and objective (explicit or inferred) before writing the math formulation.
Parsing checklist
- Every sentence has a label (parameter | constraint | decision | objective if stated).
- Objective is identified: Explicit ("minimize/maximize X") or implicit ("determine the plan" + costs → minimize total cost; + revenues → maximize profit). Never formulate without stating the objective.
- Committed phrasing ("plans to", "operates", "employs") → not decisions.
- Optional phrasing ("may", "can choose", "considers") → decisions.
- Implicit constraints from committed phrasing are written out (e.g., "all X must be produced").
- 🔒 MANDATORY — Ambiguity: Any phrase that could be read two ways → I asked the user or I will solve all interpretations and report all outcomes (no silent single interpretation).
- Summary is produced before formulating (parameters, constraints, decisions, objective).
Example
Text: "The company operates 3 factories and plans to produce 500 units. It may use overtime at extra cost. Minimize total cost."
| Sentence / phrase | Label | Note |
| "Operates 3 factories" | Parameter | All 3 open; not facility selection. |
| "Plans to produce 500 units" | Constraint (implicit) | All 500 must be produced. |
| "May use overtime at extra cost" | Decision | How much overtime is a decision. |
| "Minimize total cost" | Objective | Drives decisions. |
Result: Parameters = 3 factories, 500 units target. Constraints = produce exactly 500 (implicit from "plans to produce"). Decisions = production allocation across factories, overtime amounts. Objective = minimize cost.
Implicit-objective example: A problem that asks to "determine the production plan" (or similar) and gives cost components (e.g., workshop, inspection, sales) but does not state "minimize" or "maximize" → Objective is implicit: minimize total cost. Always state it explicitly: "The objective is to minimize total cost."
QP rule: minimize only
QP objectives must be minimization. To maximize a quadratic expression, negate it and minimize; then negate the optimal value.
For minimization to be well-posed, the quadratic form Q should be positive semi-definite. If Q is indefinite, the problem is non-convex and may not have a finite optimum.
Common patterns
The remaining sections cover specific LP/MILP modeling patterns. Each is independent — read the one that matches your problem.
Piecewise-linear objectives with integer production
When modeling concave piecewise-linear profit/cost functions (e.g., decreasing marginal profit for bulk sales), the standard approach uses continuous segment variables with upper bounds equal to each segment's width. For a maximization with concave profit, the solver fills higher-profit segments first naturally.
Gotcha: If the quantity being produced is discrete (pieces, units, items), the total production variable must be INTEGER, even though segment variables can remain CONTINUOUS. Without this, the LP relaxation may yield a fractional total that produces a different (higher or lower) objective than the true integer optimum.
Pattern
x_total — INTEGER (total production of a product)
s1, s2, … — CONTINUOUS (amount sold in each price segment, bounded by segment width)
Link: x_total = s1 + s2 + …
Resource constraints use x_total.
Objective uses segment variables × segment profit rates.Cutting stock / trim loss problems
In cutting stock problems, waste area includes both trim loss (unused width within each cutting pattern) and over-production (excess strips produced beyond demand). Minimizing only trim loss (waste width × length per pattern) ignores over-production and yields an incorrect objective.
Correct objective
Since the total useful area demanded is a constant, minimizing waste is equivalent to minimizing total material area consumed:
minimize sum_j (roll_width_j × x_j)where x_j is the length cut using pattern j. The waste area is then:
waste = total_material_area − required_useful_areawhere required_useful_area = sum_i (order_width_i × order_length_i).
Gotcha
Using sum_j (waste_width_j × x_j) as the objective only captures trim loss — the unused strip within each pattern. It does not penalize over-production of an order. The solver will over-produce narrow orders to fill patterns efficiently, but that excess material is still waste. Always use total material area as the objective.
Goal programming (preemptive / lexicographic)
Goal programming optimizes multiple objectives in priority order. Implement it as sequential solves — one per priority level.
Formulation pattern
- Hard constraints — capacity limits, non-negativity, etc. These hold in every phase.
- Goal constraints — for each goal, introduce deviation variables (d⁻ for underachievement, d⁺ for overachievement) and write an equality:
expression + d⁻ − d⁺ = target. - Solve sequentially by priority:
- Phase 1: minimize (or maximize) the relevant deviation for the highest-priority goal.
- Phase k: fix all higher-priority deviations at their optimal values, then optimize priority k's deviation.
Variable types in goal programming
Deviation variables (d⁻, d⁺) and slack/idle-time variables are always continuous. However, decision variables must still be INTEGER when they represent discrete/countable quantities (units produced, vehicles, workers, etc.). Do not let the presence of continuous deviation variables cause you to make all variables continuous — the integrality of decision variables directly affects feasibility and objective values.
Multi-period inventory / purchasing models
In problems with buying, selling, and warehouse capacity over multiple periods, decide which capacity constraints to include based on the problem's timing assumptions.
Pattern
For each period t with inventory balance stock[t] = stock[t-1] + buy[t] - sell[t]:
- End-of-period capacity (variable bound):
stock[t] <= capacity— always needed. - After-purchase capacity (explicit constraint):
stock[t-1] + buy[t] <= capacity— prevents buying more than the warehouse can hold before any sales occur within the period.
When to include the after-purchase constraint
- Include it when the problem states or implies that purchases are received before sales happen within a period (sequential operations), or when the warehouse physically cannot exceed capacity at any instant.
- Omit it when buying and selling are concurrent within a period (common in textbook trading/inventory problems) and the capacity applies only to end-of-period stock. Many classic problems only constrain end-of-period inventory.
Key interaction with the sell constraint: If the model already has sell[t] <= stock[t-1] (grain bought this period cannot be sold this period), the model is bounded even without the after-purchase constraint. The sell constraint prevents unbounded buy-sell cycling. The after-purchase constraint is then an additional physical restriction, not a mathematical necessity.
Default: If the problem does not specify timing within a period, use only end-of-period capacity (stock[t] <= capacity). Add the after-purchase constraint only if the problem explicitly requires it.
Blending with shared mixing / intermediate processing
In some blending problems, a subset of raw materials must be mixed together first (e.g., in a mixing tank) before being allocated to different products. The resulting intermediate has a uniform composition — you cannot independently assign different raw materials to different products.
Why the standard blending LP is wrong here
The standard blending LP uses variables x[i][j] (amount of raw material i in product j) and freely allocates each raw material to each product. When raw materials share a mixing step, the proportions of those raw materials must be identical in every product that receives the intermediate. This proportionality constraint is bilinear (x[A,1]*x[B,2] = x[B,1]*x[A,2]) and cannot be directly expressed in an LP.
Linearization strategies
- Single-product allocation: If analysis shows the intermediate is profitable in only one product, allocate all intermediate to that product (set intermediate allocation to other products to zero). The proportionality constraint becomes trivially satisfied. This is the most common case — check profitability of intermediate in each product before attempting a general split.
- Parametric over intermediate concentration: Fix the sulfur/quality concentration of the intermediate as a parameter
σ. For each fixedσ, the problem is a standard LP (intermediate becomes a virtual raw material with known properties). Solve for a grid ofσvalues or use the structure to find the optimum analytically. - Scenario enumeration: When only 2–3 products exist, enumerate which products receive the intermediate (all-to-A, all-to-B, split). For each scenario with a single recipient, the LP is standard. For split scenarios, use strategy 2.
Profitability check
Before formulating, check whether using the intermediate in each product is profitable:
- Compare the minimum cost per ton of the intermediate (using cheapest feasible raw material mix) against each product's selling price.
- If
cost_intermediate > sell_price[j]for some productj, the intermediate should not be allocated to productj. Raw material C (or other direct inputs) alone may also be unprofitable ifcost_C > sell_price[j]. - This analysis often eliminates the need for a bilinear split entirely.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

