MAPID / methods / hyperparameters

Which knobs mattered

Listing settings is the easy half. The question worth answering is which ones were actually varied, which were inherited from a published budget, and what moved when they changed. One knob in this work dominates everything else.

Evidence class

How each value was arrived at

2

Swept, effect measured

Session prior and posterior threshold. Three operating points, per-pattern catch and benign FPR at each. This is the only genuine sensitivity study in the thesis.

6

Fixed to a published budget

Search iterations, top-k, batch, suffix length, early-stop, and the three loss weights.

15

Set by a design constraint

Cache threshold and floor, LoRA settings, window length, calibration, quantization, temperatures, token budgets. Each follows from a stated requirement rather than a search.

0

Tuned against the metric

Nothing was optimized against attack success. With zero verified successes at every configuration tried, there was no signal to tune toward.

The one real sweep

Prior and threshold, and what calibration exposed

Three operating points against five attack patterns. Switch between the uncalibrated stub ratios and the calibrated ones to see the finding: the headline catch rate was substantially noise, and the false-positive cliff went with it.

Likelihood ratios
prior / threshold Crescendo Foot-in-door RACE Authority Fragment. Mean catch Benign FPR

Production leaves the layer inert because it demands 5.44 log-units of evidence across a three to four turn budget, and the uncalibrated ratios supply about 4.1. That is not a tuning failure, it is an arithmetic one, and it is why the ratios rather than the threshold were the binding parameter.

Was the budget enough

Search iterations, and the loss that fell anyway

The obvious challenge to a fixed iteration budget is that the attack simply ran out of compute. The loss trajectories answer it: optimization made steady progress on every target and still changed no behavior. Only the vulnerable control crossed the early-stop threshold.

Mean loss reduction was about 59 percent on the undefended aligned target and 51 percent on the defended pipeline, with zero verified attack successes in both. The same code drove three of three on the vulnerable control, which is what rules out an implementation defect as the explanation.

Everything else

The full inventory

Parameter Value Basis Effect if changed
Prepared answers

The three gaps to concede first

The loss weights were never ablated

w_domain = 1.0, w_input = w_output = 0.5No weight sweep was run. The defensible reason is that verified attack success was zero at every configuration attempted, so a sweep had no objective to move; the honest limit is that I cannot claim these weights are optimal.

The operating point was selected on the benchmark it is reported on

The headline prior and threshold of 0.10 and 0.3 were chosen because they exercise every detector path, then reported against the same synthesized benchmark. The held-out validation split limits but does not remove this, since the split shares the generator.

Cache and classifier settings rest on single configurations

The 1024-token pressure threshold, the 64-token floor and the five-turn history window were each set once from a design argument and never varied. Their sensitivity is unmeasured, so any claim that they are well chosen is an argument rather than a result.