#Appendix D: Configuration and Result Files

This appendix lists what is needed to reproduce the results of Chapter 6: the environment, the settings behind each named configuration, the repair call, the names of files and settings, the result file behind every reported cell, the sources of computed facts in other chapters, and the runs excluded from Chapter 6. The commands that run each configuration are documented in the framework's repository.

#D.1 Environment

The framework is available at https://github.com/thetobysiu/mt-ai-lab. It requires Python 3.12; the web front end requires Node.js 20.9 or later, and the exact solver a Java development kit. All commands run from the framework's root directory. The models are accessed through an OpenAI-compatible endpoint, by default the GWDG SAIA service. The API key is read from the environment variable SAIA_API_KEY (a template .env.example lists every variable), and SAIA_BASE_URL selects another endpoint. Table D.1 maps the model names of this thesis to the framework's presets.

Table D.1: Model presets.

#D.2 Settings

The engine is configured by environment variables. Table D.2 lists those that distinguish the configurations of Chapter 6.

Table D.2: Settings. Final = value in the final configuration.

#D.3 The Repair Call

When an answer contains no valid action number, or a tower answer is truncated (Section 5.3), the engine repeats the request once with reasoning disabled and a budget of 256 output tokens; a truncated single-floor answer is first sent again. The answer must be a JSON object whose single integer field action_id is restricted to the listed action numbers, excluding those the mechanical overrides would replace. The schema is enforced by the service's structured-output interface. If the service rejects the schema, the engine falls back to a list of allowed answers and then to an unconstrained short prompt. If all routes fail, the turn counts as a parse error. If no valid action is obtained in three consecutive attempts, the engine takes the rule-based heuristic's action for that turn (Section 5.3). The mechanism can therefore only reduce the number of failed turns; MOTA_DISABLE_STRUCTURED_OUTPUT=1 switches it off.

#D.4 Names and Labels

Table D.3: Names used in this thesis and the corresponding internal labels.

#D.5 Result Files

Table D.4 gives the result file behind each reported table, figure and paragraph of Chapter 6. Each file stores the configuration and, for every episode, its outcome and the name of its run log. The run logs are archived as a release asset of the public repository (run_logs.zip). <m> stands for the model's file tag: qwen3.5-397b, qwen3.6-35b, qwen3.8-27b, deepseek-v4-flash or mistral-medium-3.5.

Table D.4: Result files (in results/reliability/ unless stated).

Table D.5: Tower observations (Section 5.5.3, Table 6.13) and their result-file labels. Flags = settings added to the row above, relative to the defaults of the code at the time of the runs (the defaults have since changed, so that Table D.2 lists some of these settings as unset). Every tower run also uses the settings of the final configuration and lookahead depth 2; reactive runs use a reasoning cap of 8,192 tokens. The first tower observation ran under the single-floor final configuration of its time, whose result files share the label final2.

The continuations from MT18 resume the run log 20261004_052939_498308_MT0-MT23w_llm.json, a run of Qwen3.5-397B with a predecessor of the final observation (label final10). That run was played before the hidden staircases of MT18 and MT20 were modelled; its result file records MT21, and MT18 is its highest floor on the current engine (Appendix E, incident 17).

For tower runs, the field llm_calls of a result file counts every turn not taken by the engine, including executed plan steps (Appendix E, incident 15). The number of model calls reported in Table 6.9 is the number of thinking events in the run log (analysis/tower_calls.py). Later result files also store it as model_calls.

Table D.6 gives the sources of facts that were computed or checked rather than read from a result file.

Table D.6: Sources of computed facts.

#D.6 Results Excluded from Chapter 6

Results whose harness or setup was defective are kept under a file-name prefix that names the defect and are not pooled with valid results (Table D.7). Most of them come from the planning study (Section 6.6). After a first trial in which the plan line was not yet parsed, the plan harness was corrected four times before valid data were obtained: a plan line was discarded when reasoning preceded it, the parser of an earlier single-plan mode matched almost no plan, models repeated the chosen action as the first planned step, and a planned step that had become unwinnable was handed to the heuristic instead of ending the plan. In addition, the reasoning cap was raised, because short caps truncated plan answers. The earlier episodes of Qwen3.8-27B at temperature 0 are not reported, because their committed plans exist only in the defective _v1next_ version; Table 6.9 reports this model from later episodes at temperature 0.6.

Table D.7: Excluded results (prefixes in results/reliability/).