MAPLE: Memory-Augmented Planning with Language and Evolution

• Practitioners may lack operations-research expertise or specialist support, while changing orders, resources, and priorities require updates that preserve earlier decisions and assess prior candidates.LLM-based optimization agents translate natural-language requirements into models or solver code, but model generation alone does not ensure rapid, consistent adaptation.Source: §1 · p. 2
• Prior work studies multi-turn planning (Oh et al., 2025), LLM-based nonlinear and multi-objective optimization (Thind et al., 2025; Schwanke et al., 2026), and dynamic search adaptation; MAPLE targets their practical intersection.The paper calls adapting executable optimization programs to evolving natural-language requirements while preserving accepted decisions and reusing relevant search state live dynamic optimization.Source: §1 · p. 2
• MAPLE maintains an executable Workbench, input data, accepted plans, update records, and candidate solutions across revisions.Typed Search-Space Scaffolding supports mathematical programming, evolutionary search, and Pareto search; Live Problem Decomposition identifies affected components, while Live State Memory retrieves prior updates and accepted plans. Earlier assignments can be enforced during search, and fixed checks select repaired-history or fresh initialization before revised state is committed.Source: §1 · p. 2
• 0.951 online scalar quality and 0.875 Pareto hypervolume ratio; MAPLE completes all 15 NLDO trajectories.NLDO contains 180 updates across selection, scheduling, rostering, routing, and cloud-resource placement.Source: §1 · p. 2
• NLDO evaluates single- and multi-objective tasks and assesses trajectory continuity separately from resulting-plan quality.It comprises 15 trajectories and 180 natural-language updates spanning selection, scheduling, rostering, routing, and cloud-resource placement.Source: §1 · p. 2

Task definition

• Each episode starts with a request and input tables, then revisions define a feasible set and objective vector; multiobjective tasks require mutually nondominated feasible plans.Evaluation converts objectives to minimization; requests distinguish objectives, hard constraints, and auxiliary diagnostics.Source: §2 · pp. 2–3

State and updates

• MAPLE’s state stores input tables, the optimization program, accepted outputs, and candidate solutions, alongside earlier update records.An accepted update appends an event record; a rejected revision leaves the committed state and event history unchanged.Source: §2 · p. 3

Evaluation criteria

• Evaluation separates recorded protocol continuity from saved-plan quality, using normalized scalar objective quality or a hypervolume ratio for Pareto outputs.A rejection ends the eligible trajectory prefix; remaining states, including unattempted ones, receive zero. Output-protocol failures, infeasible plans, and feasibility among attempted updates are also reported.Source: §2 · p. 3

NLDO coverage

• 15 trajectories, 195 states, and 180 updates span five NLDO families, with disruptive replacements in rostering, routing, and cloud placement at t11–t12.Each sequence has an initial request and twelve updates; update-only analyses use t01–t12, while full-trajectory analyses include initialization.Source: §2 · p. 3

3 METHOD

• MAPLE builds an initial executable state, then locates edits and historical references for later requests, selecting whether evolutionary search reuses candidates or restarts.The fixed runtime checks the program and solver output before committing an updated state.Source: §3 · p. 3
• Typed decision segments bind candidate initialization, variation, and repair to their representations, while the declared formulation selects linear, scalar evolutionary, or multiobjective search.The model declares objectives and decision segments; evaluation decodes candidates into plans and returns objective values and constraint violations. Separate objectives use NSGA-II.Source: §3 · pp. 3–4
• LPD identifies changes to data, decisions, evaluation logic, or historical bindings, applying table edits directly and translating language-only changes into table or function edits.It preserves functions not implicated by the request; a price change may affect only tables, while a new constraint may require an evaluation edit.Source: §3 · p. 4
• LSM resolves requests about earlier assignments by linking stored events to accepted plans, checking the resulting binding against the current decision domain, and enforcing it during search.Events are appended after acceptance; the full Pareto set is stored separately from the saved plan.Source: §3 · p. 5
• The restart gate chooses Full only when assessed reuse risk is high, the recommendation is to reinitialize, and cited changes and causes pass structural checks; otherwise it chooses Warm.Warm maps and repairs prior candidates, prioritizing feasibility and lower penalized scalar fitness; repaired candidates fill at most half the population, with fresh candidates filling the rest. Full initializes all candidates afresh.Source: §3 · pp. 5–6
• Compilation, interface, and small-input errors trigger bounded repair, while invalid solver outputs reject the revision and preserve the prior state; passing outputs commit the revised state and history.Held-out evaluation scores the saved solution after execution.Source: Figure 3 · p. 5, §3 · p. 6

4.1 Q1: CAN THE AGENT SOLVE THE INITIAL REQUEST?

• 59.3% on NLP4LP-hard, 80.0% on BWOR20, scalar quality 1.000, and Pareto HV 0.832 are MAPLE’s initial-state results.Table 1 reports execution and reference-objective agreement for the initial request.Source: §4.1 · p. 6, Table 1 · p. 7

4.2 Q2: CAN THE AGENT FOLLOW A SEQUENCE OF REVISIONS?

• 0.951 scalar online quality and 0.875 Pareto HV are achieved by MAPLE across revisions, versus 0.501 and 0.042 for Persistent ReAct; MAPLE completes every main-run trajectory.Persistent ReAct’s scores rise to 0.763 and 0.185 under the mathematical-prefix protocol, while MAPLE’s remain unchanged. Across additional runs, program generation, editing, and repair use 51.6k tokens per MAPLE trajectory versus 72.8k without TSS.Source: Table 2 · p. 7, §4.2 · p. 7

4.3 Q3: WHAT HELPS THE AGENT HANDLE REVISIONS CORRECTLY?

• Removing TSS lowers feasibility from 100.0% to 80.6% and mean HV from 0.879 to 0.665 over Pareto updates.The no-TSS version returns 140 invalid outputs among 720 update–seed results, including routing and cloud-placement constraint-check omissions; its valid outputs have mean HV 0.826.Source: §4.3 · pp. 7–8, Table 3 · p. 8
• Mean HV falls from 0.774 to 0.618 when decision-tailored search operations are replaced by copying complete decision blocks or generating valid blocks at random.The comparison holds the optimization program, repair procedure, starting population, and restart choice fixed and covers twelve updates across routing and cloud placement.Source: §4.3 · p. 8
• With earlier update records and accepted plans together, LSM resolves all 18 assignment requests; either information source alone resolves only its six directly answerable requests.LSM also resolves all 30 entity-reference requests, including six requiring a chain of three references; in six replay cases, full LSM and a control given the assignment directly each produce 18 valid results.Source: §4.3 · p. 8

4.4 Q4: WHEN SHOULD SEARCH REUSE PREVIOUS SOLUTIONS?

• 0.708 routing HV and 0.022 cloud-placement HV are Warm’s gains over Full when adding low-demand tasks; MAPLE selects Warm in all four rename-or-add tests.A changed-table-cell rule selects Full in all four added-task tests, while mapping identifiers before re-evaluating old candidates makes all six decisions Warm.Source: Table 4 · p. 9, §4.4 · p. 9
• 0.879 mean update HV for MAPLE compares with 0.868 for Always Warm and 0.824 for Always Full; after disruptive updates, MAPLE obtains 0.696 versus 0.636 for Always Warm.MAPLE and Always Warm both score 0.915 on the first ten updates; the mean paired gain is 0.010 with a 95% episode-bootstrap interval of [0.001, 0.021], and five of six differences are positive (p = 0.219).Source: §4.4 · pp. 8–9, Figure 5 · p. 9

Natural-language optimization for domain practitioners

• MAPLE extends natural-language optimization agents from formulation generation and solver-code revision to continued problem revision as operations change.Prior work includes NL4Opt, optimization agents using execution feedback, and MIRROR and ORPilot with elicitation and operational data handling.Source: §5 · p. 9

Interactive and dynamic language agents; Multi-objective and dynamic numerical optimization

• MAPLE retains executable optimization state across requests, while NLDO evaluates continuity and solution quality; its language-driven revisions run established solvers such as NSGA-II.Related interactive agents retain dialogue or experience, Flex-TravelPlanner introduces constraints across turns, and Gaia2 tests asynchronous environmental changes. Dynamic optimization also uses population repair, transfer, and restart, while MOHOLLM uses LLM surrogate models and samplers for hierarchical multiobjective search.Source: §5 · p. 9

• MAPLE completes all 15 NLDO trajectories with online scalar quality of 0.951 and Pareto HV of 0.875.It maintains executable optimization state across natural-language revisions.Source: §6 · p. 9
• Controls show TSS reduces invalid outputs; historical requests may need both update records and accepted plans, while fresh initialization and repaired candidates help under different revisions.Fresh initialization helps after disruptive routing changes; repaired candidates remain useful in renaming and task-addition controls.Source: §6 · p. 9
• NLDO uses synthetic data, and the supplement provides tasks, prompts, settings, seed-level evidence, and offline scoring with references separate from agent inputs.The offline-scoring materials are in Appendix A.10.Source: §6 · p. 10

A APPENDIX

• The appendix begins with mechanisms, metrics, and execution setup, then presents supplementary experiments.Table 5 maps appendix contents to their evidence locations.Source: A APPENDIX · p. 12, Table 5 · p. 12
• The Harness walkthrough follows the supplementary experiment results.Source: A APPENDIX · p. 12
• Prompt interfaces and recorded benchmark requests appear last in the appendix.Source: A APPENDIX · p. 12

A.1 MAPLE INITIALIZATION AND UPDATE PROCEDURE

• MAPLE uses LPD, TSS, a reuse assessment, a structural gate, and a fixed optimizer to process requests and persist accepted state.For earlier-assignment requests, a fixed runtime procedure resolves the requested relation from stored events and accepted decisions, then enforces it during evaluation.Source: §A.1 · p. 12
• MAPLE w/o TSS generates its own representation, evaluation, search, and repair functions, then carries its Workbench, accepted state, and search archives through the sequence.Its fixed optimization loop still performs selection, maintains the archive, records metrics, and checks stopping.Source: §A.1 · p. 12
• The saved state St = (Dt, Wt, At, Pt) carries accepted data, Workbench functions, plans or archives, and the evolutionary population when applicable.After public-check failure, the repair limit B counts additional model attempts (B = 3 in reported runs); a smoke test checks data access, function calls, and output structure before numerical search.Source: §A.1 · p. 12
• LLM calls depend on requested data translation, function edits, or repair; restart assessment precedes population construction, while feasibility checks and reference scores follow execution.Restart assessment uses the public update history and change digest.Source: §A.1 · p. 12

A.2 CHECKS FOR RESTART RECOMMENDATIONS

• The parser normalizes risk and paths, removes unrecognized or duplicate mechanisms, and retains cited paths only when they belong to the changed-field set.Five mechanism identifiers are allowed: decision_support_replacement, objective_preference_reversal, constraint_regime_change, resource_role_reversal, and distant_basin_risk.Source: §A.2 · p. 12
• A fresh start requires high risk, a Full vote, and at least one cited changed path; fixed checks determine whether earlier candidates are reused.Table 6 identifies these requirements for the fixed restart gate.Source: §A.2 · p. 12, Table 6 · p. 14
• Path and mechanism tests are separate, the reason string does not affect the gate, and missing fields or ordinary parsing errors default to Warm.A detected quota-limit error is passed back to the caller; the implementation converts full_vote using Python boolean conversion.Source: §A.2 · p. 14

A.3 TSS WORKBENCH AND AVAILABLE CHOICES

• The model edits only decision-definition and evaluation functions; fixed runtime code supplies checks and restart actions.The decision-definition function reads public tables, declares typed decisions, chooses a solver, and names outputs; the evaluation function checks candidates against public constraints and objectives.Source: §A.3 · p. 14, Table 7 · p. 15
• The Workbench routes declared linear variables, objectives, and constraints through fixed HiGHS solvers and validates extracted outputs.Its construction call produces both the numerical formulation and data-access code; the runtime retains solver status and objective.Source: §A.3 · p. 14
• TSS rejects unsupported decision spaces, preserves public objective names and Pareto tasks, and uses catalog entries to specify solver inputs, outputs, conditions, and failures.Adding a decision type requires implementing and registering initialization, variation, and repair operators; after an update, Warm migrates historical candidates into current domains and re-evaluates feasibility.Source: §A.3 · p. 14, Table 7 · p. 15
• Warm seeds search from prior population and archive candidates, migrates them to current decision domains, evaluates feasibility, and fills remaining population slots with fresh candidates.For multiple objectives, seed ordering includes objective extremes, knee candidates, and nondominated selection with crowding; local search tests type-specific moves, while Warm uses up to 8,200 additional evaluation calls with population 200 and at most 100 historical candidates.Source: §A.3 · pp. 14–15

Limitations and ethics

• MAPLE’s fixed catalog limits new decision types or numerical operators without runtime extensions, and typed operators do not guarantee feasibility beyond the generated evaluation function.The catalog covers decision types, solver routes, and restart actions.Source: §A.4 · p. 15
• LSM needs clarification for ambiguous references or unspecified constraints, while the semantic restart gate depends on the model’s interpretation of an update.LSM grounds references in retained events and accepted results.Source: §A.4 · p. 15
• Evolutionary routes operate within finite budgets, and repairing retained candidates adds pre-search work, making reuse versus fresh initialization dependent on available latency.Source: §A.4 · p. 15
• Operational deployment requires stronger isolation of generated Python files, imports, credentials, and network access; MAPLE is intended for batch or supervised use, with inspection, approval, and rollback for high-impact decisions.Source: §A.4 · p. 15

A.5 METRIC DEFINITIONS

• Scalar quality is bounded from 0 to 1: infeasible outputs score zero, and outputs matching the exact or best-known reference score one.Scalar tables use this normalized quality; the reference is defined after sign conversion.Source: §A.5 · p. 16
• Online quality averages state quality across trajectory states, while solve rate averages recorded acceptance eligibility multiplied by mathematical feasibility.Unattempted states contribute zero and remain in the denominator; MAPLE quality is averaged across ten search seeds at each state and then across states. DS and DM denominators are 9 × 13 and 6 × 13 states, respectively; update-only denominators are 108 and 72.Source: §A.5 · p. 16
• Each Pareto-state reference archive pools ten hidden runs of 500-member populations evolved for 500 generations, then rechecks feasibility and retains the nondominated set.This yields 5,000 candidates before filtering and deduplication; all 78 Pareto-state references are searched afresh, independently of submitted methods, including disruptive updates.Source: §A.5 · p. 16
• Pareto archives share state-specific ideal and reference points, and normalized coordinates clip values to the ideal while values beyond the reference bound add no volume inside the unit hypervolume box.For two- or three-objective profiles, hypervolume is computed exactly; the bounds are shared across methods at each stage and remain fixed during search.Source: §A.5 · p. 16
• The evaluator reports raw hypervolume ratio, IGD, and ideal gap; archives without feasible candidates receive zero hypervolume ratio, and IGD is reported only for eligible archives with feasible candidates.Ideal gap is better when smaller and measures distance from the submitted archive to an ideal point placed 10% beyond each objective’s best reference value.Source: §A.5 · pp. 16–17

Benchmark scope

• NLDO contains 180 updates across five profiles and 15 episodes, covering selection, scheduling, rostering, routing, and cloud placement.Each profile contributes 36 updates; 30 updates require information from earlier requests, and 103 first paragraphs have distinct wording. Rostering, routing, and cloud placement each include six disruptive t11–t12 states.Source: §A.6 · p. 17, Figure 7

References and inputs

• Compact scalar tasks use exact references, larger scalar tasks use best-known solutions, and Pareto tasks use held-out archives.The agent receives problem descriptions and input tables; separate evaluation annotations identify intended entities and reference chains.Source: §A.6 · pp. 17–18

Benchmark views

• The four NLDO views cross static or dynamic evaluation with single- or multi-objective tasks, covering allocation, scheduling, rostering, routing, and cloud placement.Dynamic views span t00–t12, including initialization; update-only analyses exclude t00 and are labelled separately.Source: Table 8 · p. 17, §A.6 · p. 17

Scoring rules

• Saved-plan scoring recomputes objectives using public formulas, including routing travel time as distance divided by speed and cloud energy from used-machine idle charges and assigned CPU demand.A 25% speed reduction multiplies affected travel time by 4/3 without changing physical distance; available but unused machines contribute zero utilization to the cloud imbalance mean.Source: §A.6 · p. 18

Evaluation versions and limitations

• The primary comparison, complete TSS ablation, and full-sequence restart comparison use public-formula scores and common formal references, unlike several controls that retain original run evaluators.Original hidden routing and cloud evaluators differed from the public definitions; persistent ReAct’s prior scores also included inconsistent objective vectors. Across 4,368 Pareto state–seed records, all originally eligible outputs remained feasible on re-evaluation, while 16 additional feasible outputs received zero strict-prefix quality.Source: §A.6 · p. 18

A.7 STATIC SOLVING SETUP

• The static benchmarks test one-shot optimization from problem text and public parameters, with each method producing executable Python solver code according to its published process when available.The tasks exclude updates, memory, restart choice, and predecessor populations.Source: §A.7 · p. 18
• Evaluation reports execution rate and Objective, the fraction of all cases whose returned objective agrees with the reference under the recorded numeric tolerance.Alternative optimal decision vectors are accepted; NLP4LP-hard uses absolute and relative tolerances of 10^-6, while BWOR20 uses an absolute tolerance of 0.1 and relative tolerance of 0.Source: §A.7 · pp. 18–19
• Joint Match requires compilation and execution plus reference-objective agreement or correct reference status for status-only cases, with execution failures included in its denominator.Separate diagnostics include compilation, execution, objective agreement, and workflow-specific output and named-variable checks; checks can overlap, and Joint Match is unreported for ReAct and OptimAI.Source: §A.7 · p. 19
• The fixed evaluation sets contain 59 NLP4LP-hard instances with nonempty reference solutions and a seeded, sorted 20-case sample from BWOR20’s 82 cases.NLP4LP-hard comes from the dataset released with OptiMUS (AhmadiTeshnizi et al., 2024); BWOR20 comes from the collection distributed with OR-LLM-Agent (Zhang et al., 2025).Source: §A.7 · p. 19

A.8 BASELINE INTERFACES AND EXECUTION

• At each update, Persistent ReAct uses the initial public tables, cumulative dialogue, and carried workspace to revise its solver program before solving.At initialization, the model writes a complete Python solver program using public parameters and solver libraries.Source: §A.8 · p. 19
• The runtime parses, compiles, and executes the program, returning actual errors and available output for up to three code-output repairs when failures occur.Missing auxiliary reasoning or tool-plan fields are checked separately and did not trigger code repair in saved runs.Source: §A.8 · p. 19
• After public execution succeeds and a solution is extracted, the workspace retains the preceding solver code and compact final answer, while history stores the preceding plan and cumulative updates.Nothing is carried at t00; although a stage may produce multiple candidates and a Pareto set, no separate population or Pareto archive is retained across stages.Source: §A.8 · p. 19

A.9 NUMERICAL SETTINGS AND RELEASED MATERIALS

• Main evolutionary runs stop by 200 generations, with eligible early stopping after 25 generations without sufficient improvement from generation 40 onward.Scalar stopping requires relative feasible-objective improvement above 5 × 10−4; Pareto stopping requires at least eight feasible archive members and uses internal HV, front-cell, and ideal-point signals. Held-out HV and IGD are computed from saved candidates for final scoring and plots.Source: §A.9 · p. 21

A.10 REPRODUCIBILITY MATERIALS

• The release includes public requests and tables, prompts, Workbench examples, numerical settings, saved records, and versioned scoring code with state-specific references.The evaluation package contains 195 states, scalar references, and 78 Pareto references; the original DeepSeek-V4-Pro (Preview) checkpoint is unavailable for reruns, so supplementary joint-Match measurements were not obtained for ReAct and OptimAI.Source: §A.10 · p. 21

A.11 AGGREGATE AND PER-PROBLEM RESULTS

• Overall HV is 0.875 for MAPLE, compared with 0.866 for own-history Warm and 0.825 for own-history Full; adaptive reuse helps routing, while Full is slightly stronger in cloud placement.The untyped Workbench finds strong cloud plans but loses validity on routing.Source: §A.11 · p. 21, Table 11 · p. 21
• Ignoring auxiliary fields raises Persistent ReAct’s solve rate from 51.3% to 85.5% for scalar tasks and from 11.5% to 42.3% for Pareto tasks.Three feasible rosters were rejected because required auxiliary fields were missing; those omissions did not trigger code repair.Source: §A.11 · pp. 22–23, Table 17 · p. 23

A.12 CASE STUDY AND VISUAL RESULT ATLAS

• Figures 8–9 trace routing and cloud-placement fronts and plans across t01–t12; cloud fronts show initial quality loss and recovery at t11/t12.Accepted plans can remain feasible yet lose normalized quality after revisions, including when objectives change or workloads and resource properties change.Source: §A.12 · p. 24, Figure 8 · p. 24, Figure 9 · p. 25

A.13 COMPONENT AND RESTART EVIDENCE

• Full LSM resolves all 18 requests. Numerically, Full LSM and supplied-assignment control each produce 18 valid results (mean HV 0.825), versus six (0.261) for earlier-records-only and six (0.258) for accepted-plan-only.Earlier records resolve the six requests answerable from them, while the accepted plan resolves six requests explicitly naming the relevant entities; neither resolves the six requiring both information sources.Source: §A.13 · p. 27
• Across three Workbench runs, MAPLE’s mean online quality is 0.669 in routing and 0.728 in cloud, versus 0.336 and 0.513 without TSS.All three typed routing runs remain valid, but two additional typed cloud runs fail the held-out check at t11–t12. With TSS, code generation averages 19.1k tokens versus 26.0k without it, and code modification averages 32.5k versus 46.9k.Source: §A.13 · pp. 29–30, Table 23 · p. 29, Table 25 · p. 30
• Across six episodes, MAPLE’s mean paired gain is 0.010 over Always Warm and 0.054 over Always Full; the Always Warm gain has interval [0.001, 0.021] and p = 0.219.The selector chooses Warm for all nine episodes at t01–t10 and Full for all nine at t11; at t12 it chooses Full for P008 and P010–P015, and Warm for P007/P009.Source: §A.13 · pp. 30–31, Table 27 · p. 31
• The table-change rule matches all 12 Full decisions on P010–P015 and achieves the same 0.779 HV as the restart selector.Ordinary updates have change ratios of 0–0.060, while t11–t12 ratios are 0.705–1.000; the rule averages 162.8 generations without a model call or new optimizer run.Source: §A.13 · p. 31
• 0.862 mean HV for Warm versus 0.682 for Full across six rescaling, relabeling, and task-addition cases, with the largest Warm difference at +0.708.Warm uses fewer generations in five of six branches; all three routing task-addition differences are positive, ranging from 0.442 to 0.892.Source: §A.13 · p. 32, Table 28 · p. 32

Appendix A.15 reports the threshold comparison

• 0.013 normalized HV is MAPLE’s gain over Matched Warm on P010–P015; its mean HV gain over Matched Full is 0.048.All six episode means favor MAPLE over Matched Warm; at t11–t12, MAPLE selects Full and matches Matched Full. MAPLE averages 162.8 generations versus 199.0 for Matched Full. Routing disruptive-update gains are 0.122–0.168 HV, compared with 0.002–0.011 for cloud episodes.Source: Table 33 · p. 34, Appendix A.15 · p. 34, Table 35 · p. 36

A.14 STATIC SOLVING RESULTS

• On BWOR20, all 20 MAPLE rows compile and run and 16 match the reference objective; on NLP4LP-hard, 55 of 59 run and 35 match.On NLP4LP-hard, 20 rows also pass the additional historical output check.Source: Table 37 · p. 37, Table 38 · p. 37, §A.14 · p. 37

A.15 REFERENCE AND ARCHIVE SENSITIVITY

• Archive limits of 100, 200, and 500 yield mean HV ratios of 0.775, 0.776, and 0.774, while expanding the evaluation box reduces w/o-TSS ratios above 1 from five to one.The 500-member archive cap is inactive for MAPLE in the reference-set analysis; smaller caps change individual fronts despite stable mean HV.Source: §A.15 · p. 37, Table 40 · p. 38, Table 39 · p. 38
• Numerical-selector thresholds 0.25, 0.50, and 0.75 yield HV ratios of 0.755, 0.765, and 0.767, all below MAPLE’s 0.779.The table-change rule gives identical decisions for thresholds in [0.3, 0.7]. Extending congestion to adjacent routing legs changes HV from 0.7471 to 0.7466 without changing MAPLE’s ordering; enforcing the return deadline leaves aggregate HV unchanged.Source: §A.15 · p. 38

A.16 USING MAPLE THROUGH AN INTERACTIVE INTERFACE

• The MAPLE Harness retains the Workbench, candidate plans, objective traces, and restart actions so users can inspect solutions and revise the same planning session.The service runs MAPLE through MCP, displays search progress by job identifier, saves accepted updates, and supports CSV or JSON export.Source: §A.16 · p. 38

A.17 PROMPT INTERFACES AND EXECUTION RULES

• The TSS prompt asks the model to edit build_problem(public_context) and evaluate(genome, data), while framework-owned code handles the search and optimization loop.The response must provide exactly two slot blocks; prompts prohibit benchmark-specific hard-coding, and repair turns include the prior error and slot contents.Source: §A.17 · pp. 39–40
• The update localizer separates public-data changes from code changes, while typed assignment-lock queries preserve accepted cross-stage assignments without unnecessary patches.It uses a distinct reuse-risk assessment to select Warm or Full restarts; Full requires high reuse risk, a Full vote, a supported structural mechanism, and a changed-field citation.Source: §A.17 · p. 40
• Public-table updates use constrained JSON operations, and Workbench edits are limited to requested slots and validated by compilation and a public-example run.The table updater writes only public_context tables and can repair malformed operations; editors preserve objective names and vector order, read policy values from data, and avoid hard-coding update constants.Source: §A.17 · p. 41
• The no-TSS workflow generates a persistent optimization artifact, while external baselines receive public information and only their own prior state, not hidden evaluation state.The generated artifact supplies required callbacks while the optimization loop remains fixed; external outputs are executable solver code, with limited repairs based on public execution feedback.Source: §A.17 · pp. 41–43

A.18 RECORDED PUBLIC NLDO REQUESTS AND UPDATES

• Recorded requests classify updates as feasibility changes, objective-order changes, dominance-preserving rescaling, diagnostic-only changes, or unchanged problems, with historical-reference requirements tracked independently.The labels are excluded from agent prompts, and the requests, tables, output contracts, and checksums support exact reproduction.Source: §A.18 · p. 43

NLDO-P001 (NLDO; COBENCH)

• The portfolio trajectory changes item values and includes memory-dependent references, unchanged feasibility checkpoints, and a late multi-item value reset.Capacity and eligibility remain fixed across the stated updates; later stages request revalidation without changing the problem.Source: NLDO-P001 (NLDO; COBENCH) · p. 43

NLDO-P002 (NLDO; COBENCH)

• The facility-assignment trajectory revises opening and service costs, then changes the scalar objective from monetary cost to total service time while retaining capacities and demand.Updates also include memory-dependent references and routine revalidation stages.Source: NLDO-P002 (NLDO; COBENCH) · p. 44

NLDO-P003 (NLDO; COBENCH)

• The set-cover trajectory revises set costs, includes memory-dependent references, and follows with maintenance and revalidation requests under the unchanged coverage requirements.The updates do not add or remove coverage requirements or alter set eligibility.Source: NLDO-P003 (NLDO; COBENCH) · pp. 44–45

NLDO-P004 (NLDO; FJSP)

• The flexible job-shop request requires eligible-resource assignments, job precedence, and resource capacity, minimizes weighted tardiness, and reports disruption only as a diagnostic.Updates may revise soft due or priority values or machine cost rates, but not availability, eligibility, or processing requirements.Source: NLDO-P004 (NLDO; FJSP) · p. 45
• A late accounting reset changes the flexible job-shop objective from minimizing tardiness to minimizing machine operating cost, amid earlier cost-rate and urgency updates that require recalling prior entities.Checkpoint and routine-review updates also ask to revalidate plans under the unchanged public contract.Source: NLDO-P004 (NLDO; FJSP) · p. 45

NLDO-P005 (NLDO; FJSP)

• The flexible job-shop trajectory schedules three jobs’ operations on eligible machines under precedence and capacity constraints, then updates machine costs and soft urgency while retaining the feasible schedule space.Later stages include checkpoint and routine refreshes under the current public state.Source: NLDO-P005 (NLDO; FJSP) · pp. 45–46

NLDO-P006 (NLDO; FJSP)

• A separate flexible job-shop trajectory sets machine eligibility, precedence, and capacity as scheduling requirements, while treating disruption only as a diagnostic and allowing soft due-time and cost-rate updates.The sequence includes remembered updates and repeated feasibility checkpoints.Source: NLDO-P006 (NLDO; FJSP) · pp. 46–47
• The initial task specifies a one-week roster for 30 nurses across 7 days and day, evening, and night shifts, satisfying fixed coverage and one shift per nurse per day while optimizing workload fairness and soft preferences.Later updates replace the current coverage, active-nurse, absence, preference, nurse max-shift, and policy tables with regime-A rows, then regime-B rows.Source: NLDO-P006 (NLDO; FJSP) · p. 47

NLDO-P010 (NLDO; GREEN_VRP_MULTIOBJECTIVE)

• The first multiobjective routing trajectory updates order urgency, congestion, vehicle emissions, and carbon policy, then replaces the workload and public parameters with regime A and regime B cohorts.It evaluates distance, lateness, and emissions while treating disruption and priority-customer penalties as auxiliary diagnostics.Source: NLDO-P010 (NLDO;… · p. 49

NLDO-P011 (NLDO; GREEN_VRP_MULTIOBJECTIVE)

• The second routing trajectory likewise revises soft delivery targets, priorities, emissions, and carbon policy before full cohort resets, while preserving the route encoding and three objective definitions.Every active order is to be served once under vehicle-capacity constraints.Source: NLDO-P011 (NLDO;… · p. 50

NLDO-P012 (NLDO; GREEN_VRP_MULTIOBJECTIVE)

• The third routing trajectory applies congestion, emission, carbon-policy, priority, and due-time updates, followed by regime-A and regime-B replacements of workload and public parameters.Its objective definitions and route encoding remain unchanged through the resets.Source: NLDO-P012 (NLDO;… · pp. 50–51

NLDO-P013 (NLDO; CLOUD_SCHEDULING_MULTIOBJECTIVE)

• The cloud-placement trajectory assigns active jobs to available machines under public CPU, memory, accelerator, and availability requirements, optimizing energy and imbalance while reporting SLA, latency, and migration diagnostics.Later updates may revise workloads, machine profiles, soft SLAs, priorities, energy, or carbon parameters.Source: NLDO-P013 (NLDO;… · p. 51
• The cloud-placement instance optimizes energy and load imbalance, then changes burst priorities, soft SLAs, and energy conditions before full workload-and-hardware regime resets.The remembered burst-0 group receives premium priority; regimes A and B activate late-window jobs and replace resource and job fields while keeping placement encoding and objective definitions unchanged.Source: NLDO-P013 (NLDO;… · pp. 52–53

NLDO-P014 (NLDO; CLOUD_SCHEDULING_MULTIOBJECTIVE)

• This trajectory updates energy and balance priorities, burst-1 and analytics-job service settings, then resets hardware and workload for regimes A and B without changing the placement encoding or objectives.The burst is J002–J006, while J019 becomes less urgent before the late-window jobs are activated.Source: NLDO-P014 (NLDO;… · pp. 53–54

NLDO-P015 (NLDO; CLOUD_SCHEDULING_MULTIOBJECTIVE)

• This trajectory reprioritizes burst-2 and service targets, shifts the energy-versus-balance trade-off, and ends with two cluster-wide resets that preserve the placement encoding and objectives.The initial criteria are energy and load imbalance; SLA, latency, and migration measures are diagnostics, not feasibility constraints.Source: NLDO-P015 (NLDO;… · p. 55