• workshop_dense_100#slide 47

In RAIDT terms, decoding parameters are run-time generation settings that shape how a model produces an output in a specific configured use. The item definition names typical examples: temperature, top-p, maximum tokens, and seed. The listed papers discuss these more generally as decoding settings or configuration parameters that affect run behaviour and output variability. Their governance significance is that they form part of configuration provenance within the run-level evidence pack. They therefore belong to the evidential record for one configured use, rather than being left as undocumented background engineering choices.

A simple example is temperature in a high-stakes workflow. With the same prompt and model deployment, a lower temperature may produce a more stable and bounded answer, while a higher temperature may produce greater variation across repeated runs. The Foundations paper explicitly links dependability to repeat-run stability, controlled settings, and one-factor-at-a-time sensitivity testing, including temperature. The Evidence Review paper likewise treats decoding settings as a core element of configuration provenance. The Technical Foundation paper strengthens the point by arguing that a run may remain unreconstructable if prompt version is known but decoding settings are omitted.

This is why decoding parameters matter in RAIDT across the five pillars (Responsibility, Auditability, Interpretability, Dependability, Traceability). They help reviewers understand how an output was generated, whether a result is reproducible enough for the task, and whether a disputed run can be reconstructed for challenge or assurance. They also affect the score profile because RAIDT uses anchors 1=missing / 3=partial / 5=audit-ready, and missing configuration evidence constrains how strongly an organisation can claim dependable, auditable use. In that sense, decoding parameters are influence methods as governance interventions, recorded because governance must attach to the configured run, not to the model in the abstract.

Consider a public-service eligibility advice assistant that drafts an explanation for a claimant. Two runs use the same policy text and the same prompt template, yet one answer is concise and cautious while the other is more expansive and introduces speculative wording. If the record includes temperature, top-p, maximum tokens, and seed, reviewers can determine whether the divergence arose from the decoding configuration rather than from a hidden policy change or a retrieval problem.

That matters operationally because RAIDT is built for contested organisational uses. A reviewer examining the run-level evidence pack needs to know not only which sources and model were involved, but also which generation settings were active when the answer entered the workflow. Without those fields, the run may still look documented, yet it will not be fully reviewable under a governance lens, especially on Dependability and Auditability.

• 08-RAIDT_Foundations_M_V50
• 13-RAIDT-Evidence-Review_M_v10
• 18-RAIDT-Technical-Foundation_M_v04