A permitting desk requires every model status line to be exactly one of Approved, Needs revision, or Denied. Which wrapping technique best enforces that consistency?
Select an answer to reveal the explanation.
Short Explanation
If the desk only accepts three stamps, don’t let the model invent a fourth. Constrained decoding is the stamp pad that only has Approved, Needs revision, and Denied.
Full Explanation
Constrained decoding is the wrapping technique that best enforces permitting status consistency because it restricts the generator so only allowed status tokens—Approved, Needs revision, or Denied—can be emitted at the status field. The permitting desk's workflow depends on an exact closed set; soft prompting alone cannot guarantee that closure under all inputs. Constrained decoding (grammar, FSM, or allow-list masking) hardens the contract between model output and downstream municipal systems that parse status lines. Raising temperature and hoping the model eventually samples an allowed status increases entropy and makes invalid statuses more likely, which is the opposite of enforcement. Asking the model in free text to invent new status categories for edge cases deliberately breaks the three-stamp schema and creates statuses no clerk queue or integration will accept. Stripping the status field from the schema and burying it in a long narrative removes the structured signal the desk needs and forces brittle human parsing of prose. Exam caveat: constraints enforce format membership, not semantic correctness—an application can still be wrongly labeled Denied while using a legal token—so pair constrained decoding with retrieval of permit rules or human review for contested cases. Operational check: fuzz the wrapper with messy applicant narratives and assert every status line is exactly one of the three allowed strings; reject builds that only 'prefer' those strings in the prompt without decoding constraints.