[F16] Methodology: DESIGN agent must enumerate UNLOCKED parameters and justify defaults

[sriumcp]

Problem

In paper-memorytime-mirage, the campaign's locked-parameters table grew reactively across 5 reviewer rounds: concurrency, duration, warmup, model (after F1), then total_kv_blocks (after F13), then output_tokens / D (after iter-1 findings). At each step a new bug surfaced and a new parameter was added.

At no point did the campaign author produce a systematic inventory of every BLIS parameter that could affect the experiment — even though the parameter space is large and well-known:

• Latency model: MfuPrefill, MfuDecode, TP factor.
• Batching: MaxModelLen, MaxOutputLen, max_num_seqs, max_batched_tokens.
• Admission: AdmissionLatency, RoutingLatency.
• Gateway: FlowControlEnabled, FlowControl*.
• KV: gpu_memory_utilization, BlockSize.
• Disaggregation: PDDecider, PDTransfer*.
• Network: rtt_ms, bandwidth.
• Streaming.

Reactive locking means parameters that would have caused issues (e.g., MaxModelLen < P_max silently dropping requests, MaxOutputLen overriding D=1, max_num_seqs < 2 × concurrency throttling closed-loop) didn't bite us only because the agent happened to pick consistent defaults — not because the campaign anchored them.

Desired behavior

Two complementary changes:

(1) DESIGN methodology prompt asks for an UNLOCKED-parameters audit. The DESIGN agent must enumerate every target-system parameter it's leaving at default and justify each:

For every parameter in the target system's configuration that could plausibly affect experiment outcomes, declare in bundle.experiment_spec.unlocked_parameters_audit:

• Name of the parameter.
• Default value being inherited.
• Why this default is acceptable for this experiment (one sentence).

If you cannot confidently justify a default, flag it for the campaign author rather than silently inheriting.

(2) Campaign-authoring template includes a parameter-inventory table. Provide a structured template the campaign author fills in before locking — one row per parameter category with columns: default value, lock?, why-or-why-not.

(1) puts the discipline on the agent; (2) puts it on the campaign author. Both reinforce the same lesson: enumerate what you're inheriting, don't inherit silently.

Suggested implementation sketch

For (1):

1. Extend the bundle schema with unlocked_parameters_audit: List<{name, default_value, justification}>.
2. Add the requirement to the DESIGN methodology prompt.
3. The validator warns (not fails) if the audit is empty or perfunctory.

For (2):

1. Add a parameter-inventory template to docs/campaign-authoring-guide.md (or wherever the canonical authoring guide lives).
2. The nous create-campaign scaffold seeds an empty locked_parameters block with a comment pointing the author to the inventory exercise.

Acceptance criteria

• Bundle schema documents unlocked_parameters_audit.
• DESIGN methodology prompt requires the audit when relevant.
• Campaign-authoring docs include a parameter-inventory template.
• Friction report F16 row in the tracking issue checks off.

Severity

HIGH — drives the F1, F13 deviation classes; locked-parameter sets grew reactively rather than being audited up front.

Source

friction-report.md F16, paper-memorytime-mirage campaign (2026-05).

---

Part of friction-report tracking issue #245.