After a model upgrade, security must confirm the housing assistant still refuses SSN disclosure. Which practice best validates that control?

Retesting guardrails after a model upgrade to verify SSN disclosure is still refused is the validation practice that confirms the housing assistant's safety control still works. Model upgrades, prompt-template changes, and configuration drift can weaken or remove refusal behavior even when earlier tests passed. For a municipal housing assistant that must not disclose Social Security numbers, re-running disclosure refusal cases after the upgrade is how security proves the control remains effective before returning the service to production casework.

Reinspecting guardrails after the upgrade to verify SSN disclosure is still refused fails because inspection alone does not prove behavior; the setup can look right while the upgraded model still discloses SSNs, so only a live refusal retest confirms the control.

Retesting guardrails before the upgrade to verify SSN disclosure is still refused fails because timing matters; a passing test before the upgrade does not prove the upgraded model still refuses, so the refusal suite must be rerun after the upgrade.

Reviewing retained logs after the upgrade to verify SSN disclosure is still refused fails because it validates history rather than live refusal; clean stored logs do not prove the assistant still refuses to disclose SSNs to the requester.

Exam caveat: Guardrail validation is change-driven. After model or policy changes, retest the specific refusal or disclosure requirements in the stem; do not treat old green tests as permanent or disable checks for performance experiments.

Operational check: After the housing assistant upgrade, run the SSN-disclosure refusal suite (direct asks, indirect extraction, jailbreak-style prompts), confirm refusals and logging, leave disclosure checks enabled during performance testing, and ensure no sample SSNs were added to production prompt templates.