Mathematics Optimization Problem Classes From Config Dim Optimization Class Coun

The five classes

Optimization problems ask for the best choice among many: the cheapest route, the strongest beam, the fastest schedule. Operations research, the field that studies such problems in practice, has long organized them into families by their mathematical shape. Linear problems have straight-line constraints and a straight-line goal. Convex nonlinear problems allow curved goals but keep a guarantee that any local best is the global best. Integer problems require whole-number answers, as when a crew count must be an integer. Stochastic problems include randomness in the data. Dynamic problems unfold in stages, where each decision changes what comes next.

These five families are the classical working set of the field. The Recognition Science framework, a system that derives structure from a forced cost of recognition, contains a machine-checked library of formal theorems. One small theorem in that library, optimizationClass_count, states that the number of these classes is exactly five. The proof is a direct check: the library defines the type of optimization classes with exactly those five members, and the theorem verifies that the count is five. The library reports the proof with zero unproved assumptions and zero added axioms, meaning the claim rests only on the standard logical foundations of the formal system.

The theorem does not say that these five classes are the only possible optimization problems, nor that every real problem fits neatly into one. It does not rank the classes by importance or difficulty. It does not claim that the framework itself solves any of these problem classes. What it establishes is a naming and a count: when the framework speaks of optimization problem classes, it means these five, and there are five of them. That is the whole content, and it is a fact a reader can check by counting the list.

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

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

What this page does not claim

The theorem does not claim these five classes are exhaustive for all possible optimization problems. The theorem does not claim the framework can solve any of these problem classes. The theorem does not claim the five classes are mutually exclusive or that every real problem fits exactly one.

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: