ors-theory-development

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