Mathematics Optimization Problem Classes From Config Dim

Five canonical classes

Optimization is the mathematics of choosing the best option from a set of alternatives. The field classically sorts its problems into families by what makes them hard. The five canonical classes are linear programming, convex nonlinear programming, integer programming, stochastic programming, and dynamic programming. Linear problems have a straight-line objective and straight-line constraints. Convex nonlinear problems allow curves but keep the shape bowl-like, so any local best is global. Integer problems require whole-number answers, which makes them combinatorial. Stochastic problems include randomness in the data. Dynamic problems unfold in stages where decisions at one step shape the next.

This classification is standard operations research, taught in every introductory course. What Recognition Science adds is a claim about why there are exactly five. The framework's library, a machine-checked collection of formal theorems, defines a type called OptimizationClass with exactly those five constructors. A theorem then proves the count: Fintype.card OptimizationClass = 5, established by direct computation. The library also bundles this into a certificate structure, so the fact is packaged as a reusable proof object. The whole file carries zero axioms beyond the kernel's standard three and zero unfinished proofs.

In Recognition Science, the number five is not arbitrary. The framework models recognition events as a discrete record, a ledger, and derives that the configuration dimension of a problem class is forced by the structure of that ledger. The five classes correspond to the five distinct ways a configuration can present itself to an optimizer. The theorem here is the counting result itself: the type has exactly five members. The identification of which classical class maps to which configuration is a modeling choice, not a derived theorem.

The practical consequence is a compact certificate: any optimization problem, whatever its surface form, belongs to one of five families. That is not a claim that the five families exhaust all possible mathematics, nor that the mapping from real problems to classes is always clean. It is a statement that the framework's internal configuration dimension, when it produces an optimization problem class, produces one of these five. The proof is small, but it is complete.

inductive OptimizationClass where
  | linear
  | convexNonlinear
  | integer
  | stochastic
  | dynamic
  deriving DecidableEq, Repr, BEq, Fintype

theorem optimizationClass_count : Fintype.card OptimizationClass = 5 := by decide

structure OptimizationClassesCert where
  five_classes : Fintype.card OptimizationClass = 5

What this page does not claim

The five classes are not claimed to exhaust all possible optimization problem types in conventional mathematics. The mapping from real-world problems to the five classes is not claimed to be unique or always clean. The framework does not claim to derive the five classes from first principles; it defines them and proves the count.

Verify this page

Every tagged claim above names its theorem. To check one yourself rather than trust this page, elaborate the source module with Lean 4 and audit its axiom basis:

$ lake env lean IndisputableMonolith/Mathematics/OptimizationProblemClassesFromConfigDim.lean
expected axiom basis: [propext, Classical.choice, Quot.sound] (the Lean kernel's standard three; no RS-specific axioms)

A page whose claims cannot be reproduced this way does not ship. In production, every anchor links to the exact declaration in the public source release, and this block carries the build receipt for the page itself.

Derived articles

This page is generated by a question-recursion engine: the questions its answers raise become the next pages. The current agenda, with open targets marked red: