Module sampling_discards 

Which parameters a caller named and the ladder then passed over.

The gap this closes

presence_penalty, repeat_penalty and min_p travel with whichever rung claims temperature — see InferenceConfig::resolve_layers_with_sources. So --profile chat --presence-penalty 1.2 with no --temperature silently discards the penalty: the profile claimed the temperature, and the coupled trio comes only from the rung that did.

That is correct, and it is invisible. A resolved config cannot show it — a discarded value and a value nobody ever named look identical once the ladder has folded. Only the provenance distinguishes them.

Why the rung is a parameter

There is more than one ladder. The stored ladder (InferenceConfig::resolve_with_profile) puts the request at rung 0; the request pipeline’s puts cli at 0 and the client at 1. A helper that hardcoded 0 would be right on one and quietly wrong on the other, reporting the client’s losses as the operator’s.

Why FloorCoupled alone is not the test

ParamSource::FloorCoupled says the coupling rule fired — not that this caller lost. When the claiming rung supplied its own value the field reports ParamSource::Layer instead, and the caller’s value is just as gone. The test is therefore “did my rung win”, not “which rule ran”.

Functions

discarded_from_rung

The parameters named set that did not survive to the resolution.

non_finite_fields 🔒

Float fields the caller set to a value JSON cannot carry.

won 🔒

Whether the value at rung is the one that reached the resolution.