Model & Result Development (ors-theory-development)
When to trigger
- You are turning an OR problem into a precise mathematical model.
- You need to decide what to claim — and as what (theorem vs. proposition vs. conjecture).
- A reviewer will ask whether your assumptions are necessary or merely convenient.
Build the model the OR way
Operations Research rewards a clean mathematical object and provable results.
For the dominant OR/MS methodologies:
- Optimization model: state decision variables, objective, constraints, and the
feasible region precisely. Identify structure (convexity, total unimodularity,
submodularity, conic representability) — structure is what enables theorems and
efficient algorithms.
- Stochastic / probabilistic model: specify the probability space, the process
(Markov chain, queue, MDP), the information/filtration, and the performance measure
(steady-state cost, regret, tail probability). State stability/ergodicity conditions.
- Simulation model: specify the stochastic dynamics and the estimand, and how a
consistent estimator with quantifiable error will be obtained.
- Decision-analytic model: specify the utility/risk measure, the information
structure, and the optimality criterion.
State results at the right strength
| Claim type |
Use when |
| Theorem |
A central, fully proved result (optimality, complexity, convergence rate, bound) |
| Proposition |
A supporting proved result of lesser scope |
| Lemma |
A technical step used inside a proof |
| Corollary |
An immediate consequence |
| Conjecture |
Stated explicitly as unproven; never disguised as a theorem |
Each formal statement needs explicit hypotheses; tie every assumption to where the
proof uses it (this is what ors-methods will then discharge).
Assumptions discipline
- Justify, don't smuggle. For every assumption, say why it holds in the motivating
application or why it is standard, and whether results degrade gracefully without it.
- Minimality. Reviewers probe whether an assumption is necessary; pre-empt with a
counterexample showing the result fails when it is dropped, or a remark that it can be
relaxed.
- Tightness. Where you prove a bound or rate, indicate whether it is tight (a
matching instance) — tightness is a strong OR contribution.
Frame significance without equations (for the intro)
OR requires an equation-free introduction: articulate the problem, the results,
and their significance in words. Develop the model here, but draft the plain-language
version of each result so the intro can state "we show that ..." without notation.
Model-level pushback patterns and the OR fix
| Referee/AE remark |
What it flags |
Fix that meets the OR bar |
| "Model too stylized to matter" |
structure stripped to triviality |
restore the feature that makes the decision realistic; reprove |
| "Model too general to say anything" |
no exploitable structure |
impose convexity/submodularity/ergodicity that the application supports |
| "Assumption is convenient, not necessary" |
proof-driven hypothesis |
add a counterexample showing the result fails without it, or relax it |
| "This is a conjecture, not a theorem" |
numerically-supported claim labeled Theorem |
downgrade to Conjecture, or supply the proof in ors-methods |
| "Structural result not connected to the application" |
theorem floats free of the decision |
state which operational policy the structure prescribes |
Because Operations Research is the INFORMS flagship for rigorous OR/MS methodology,
the editorial bar is a clean mathematical object whose structure both enables a
theorem and maps to a decision. A model that admits no theorem reads as
under-specified; one that admits a theorem but no operational reading reads as elegant
but irrelevant — the two failure modes the table above pre-empts.
Worked formulation vignette (illustrative)
Stochastic-inventory control under correlated demand. Model: state = on-hand
inventory; action = order quantity; objective = expected discounted holding + backorder
cost; demand a Markov-modulated process (illustrative). Structure exploited:
K-convexity of the value function under the modulation. Result strength: Theorem 1
states an (s,S)-type policy is optimal (a proved central result); Proposition 1 gives
monotone comparative statics in the modulation rate (supporting); a Conjecture flags the
multi-product extension as unproven. Assumptions discipline: the bounded-demand
hypothesis is justified by capacity limits in the application and shown necessary via a
counterexample where unbounded demand breaks K-convexity. Plain-language for the
intro: "we show the optimal replenishment rule reduces to ordering up to a single
critical level that depends on the demand regime" — no notation, decision-relevant. This
gives ors-methods an explicit theorem-to-machinery handoff and keeps the structure
tethered to the operational policy.
Anti-patterns
- A model so general it admits no theorem, or so special it is uninteresting.
- Assumptions chosen to make a proof easy with no application grounding.
- Calling a numerically supported regularity a "theorem."
- Hiding the key assumption in notation rather than stating it.
Output format
【Model】variables / objective / constraints / process / estimand ...
【Structure exploited】convexity / submodularity / ergodicity / ...
【Results】Thm/Prop/Lemma list with one-line plain-language each
【Assumptions】each justified + necessity noted
【Plain-language for intro】"we show ..." (no notation)
【Next step】ors-methods
Source: brycewang-stanford/Awesome-Journal-Skills → Operations-Research-Skills/skills/ors-theory-development/SKILL.md
1---2name: ors-theory-development3description: Use when formulating the model and stating results for an Operations Research (OR) manuscript — defining the optimization/stochastic/simulation model, assumptions, and the theorems, propositions, and lemmas that carry the contribution. Builds the mathematical object and its claimed results; it does not prove them in detail (ors-methods) or run the computational study (ors-data-analysis).4---567# Model & Result Development (ors-theory-development)89## When to trigger1011- You are turning an OR problem into a precise mathematical model.12- You need to decide what to claim — and as what (theorem vs. proposition vs. conjecture).13- A reviewer will ask whether your assumptions are necessary or merely convenient.1415## Build the model the OR way1617*Operations Research* rewards a clean mathematical object and **provable** results.18For the dominant OR/MS methodologies:1920- **Optimization model:** state decision variables, objective, constraints, and the21 feasible region precisely. Identify structure (convexity, total unimodularity,22 submodularity, conic representability) — structure is what enables theorems and23 efficient algorithms.24- **Stochastic / probabilistic model:** specify the probability space, the process25 (Markov chain, queue, MDP), the information/filtration, and the performance measure26 (steady-state cost, regret, tail probability). State stability/ergodicity conditions.27- **Simulation model:** specify the stochastic dynamics and the estimand, and how a28 consistent estimator with quantifiable error will be obtained.29- **Decision-analytic model:** specify the utility/risk measure, the information30 structure, and the optimality criterion.3132## State results at the right strength3334| Claim type | Use when |35|------------|----------|36| **Theorem** | A central, fully proved result (optimality, complexity, convergence rate, bound) |37| **Proposition** | A supporting proved result of lesser scope |38| **Lemma** | A technical step used inside a proof |39| **Corollary** | An immediate consequence |40| **Conjecture** | Stated explicitly as unproven; never disguised as a theorem |4142Each formal statement needs explicit hypotheses; tie every assumption to where the43proof uses it (this is what `ors-methods` will then discharge).4445## Assumptions discipline4647- **Justify, don't smuggle.** For every assumption, say why it holds in the motivating48 application or why it is standard, and whether results degrade gracefully without it.49- **Minimality.** Reviewers probe whether an assumption is *necessary*; pre-empt with a50 counterexample showing the result fails when it is dropped, or a remark that it can be51 relaxed.52- **Tightness.** Where you prove a bound or rate, indicate whether it is tight (a53 matching instance) — tightness is a strong OR contribution.5455## Frame significance without equations (for the intro)5657OR requires an **equation-free introduction**: articulate the problem, the results,58and their significance in words. Develop the model here, but draft the plain-language59version of each result so the intro can state "we show that ..." without notation.6061## Model-level pushback patterns and the OR fix6263| Referee/AE remark | What it flags | Fix that meets the OR bar |64|-------------------|---------------|----------------------------|65| "Model too stylized to matter" | structure stripped to triviality | restore the feature that makes the decision realistic; reprove |66| "Model too general to say anything" | no exploitable structure | impose convexity/submodularity/ergodicity that the application supports |67| "Assumption is convenient, not necessary" | proof-driven hypothesis | add a counterexample showing the result fails without it, or relax it |68| "This is a conjecture, not a theorem" | numerically-supported claim labeled Theorem | downgrade to Conjecture, or supply the proof in `ors-methods` |69| "Structural result not connected to the application" | theorem floats free of the decision | state which operational policy the structure prescribes |7071Because *Operations Research* is the INFORMS flagship for rigorous OR/MS methodology,72the editorial bar is a clean mathematical object whose structure **both** enables a73theorem **and** maps to a decision. A model that admits no theorem reads as74under-specified; one that admits a theorem but no operational reading reads as elegant75but irrelevant — the two failure modes the table above pre-empts.7677## Worked formulation vignette (illustrative)7879Stochastic-inventory control under correlated demand. **Model:** state = on-hand80inventory; action = order quantity; objective = expected discounted holding + backorder81cost; demand a Markov-modulated process (illustrative). **Structure exploited:**82K-convexity of the value function under the modulation. **Result strength:** Theorem 183states an `(s,S)`-type policy is optimal (a *proved* central result); Proposition 1 gives84monotone comparative statics in the modulation rate (supporting); a Conjecture flags the85multi-product extension as *unproven*. **Assumptions discipline:** the bounded-demand86hypothesis is justified by capacity limits in the application and shown necessary via a87counterexample where unbounded demand breaks K-convexity. **Plain-language for the88intro:** "we show the optimal replenishment rule reduces to ordering up to a single89critical level that depends on the demand regime" — no notation, decision-relevant. This90gives `ors-methods` an explicit theorem-to-machinery handoff and keeps the structure91tethered to the operational policy.9293## Anti-patterns9495- A model so general it admits no theorem, or so special it is uninteresting.96- Assumptions chosen to make a proof easy with no application grounding.97- Calling a numerically supported regularity a "theorem."98- Hiding the key assumption in notation rather than stating it.99100## Output format101102```103【Model】variables / objective / constraints / process / estimand ...104【Structure exploited】convexity / submodularity / ergodicity / ...105【Results】Thm/Prop/Lemma list with one-line plain-language each106【Assumptions】each justified + necessity noted107【Plain-language for intro】"we show ..." (no notation)108【Next step】ors-methods109```110111---112113**Source:** [`brycewang-stanford/Awesome-Journal-Skills`](https://github.com/brycewang-stanford/Awesome-Journal-Skills) → `Operations-Research-Skills/skills/ors-theory-development/SKILL.md`
thedixitjain