Local state
Observations, trial manifests, and suggestion logs remain file-backed so the optimization state stays transparent and resumable.
How the loop runs
Use completed results to choose the next expensive trial.
Looptimum is a lightweight optimization controller. It selects bounded candidates while your evaluator continues to run in your own scripts, clusters, or workflows.
Suggest, evaluate, and ingest workflow
- 01
Suggest
Looptimum uses the campaign's completed results to select the next bounded candidate instead of scheduling a broad sweep.
- 02
Evaluate
Your evaluator runs where it already lives: cluster jobs, scripts, CI runners, solver hosts, or lab workflows.
- 03
Ingest
The result—or a declared failure—is recorded in local files so the campaign can resume after interruptions and preserve an auditable decision trail.
What stays local
The controller stays small because it does not run the evaluator.
Looptimum keeps state and decision trace in local files so the loop survives interruptions, audit questions, and restricted deployment environments without requiring a hosted optimization service.
Thin contract
The evaluator only needs to accept bounded parameters and return a scalar objective or explicit failure outcome.
Failure-aware
Failed or timed-out evaluations are recorded rather than lost, which matters when each run is expensive.
Decision trace
The loop exposes why a trial was suggested and what had been learned so far, instead of hiding the state behind a service boundary.
Decision boundaries
Feasibility, preference, and failure are different signals.
Keeping these signals separate makes suggestions easier to explain and prevents an invalid run from being mistaken for an ordinary objective measurement.
Hard constraints
Bounds and declared feasibility rules filter invalid candidates before a suggestion is issued.
Objective shaping
Acceptable candidates are ranked by a scalar objective or explicit scalarization rule. Soft preferences belong in that score.
Failure outcomes
Failed and timed-out evaluations are recorded as terminal outcomes with reasons instead of being silently treated as successful runs.
Continue
See the loop in practice.
The evidence library shows how the same controller pattern applies to engineering and model-training workflows, with each result presented against its own validation boundary.