A library Wi-Fi guest-access script should record whether voucher creation succeeded or failed. Which logging practice best meets that goal without exposing resident PII?

Library Wi-Fi guest-access automation must leave an operational trail that shows whether voucher creation succeeded or failed without exposing resident personally identifiable information. The appropriate practice is to log a success or failure outcome together with a non-identifying voucher request ID and a timestamp. That combination supports troubleshooting, correlation with API traces, and audit of automation health while avoiding unnecessary PII in log stores and SIEM indexes. Printing the full guest name, email, and password to stdout on every attempt creates severe privacy and security exposure: credentials and identity land in console history, shared jump-host transcripts, and centralized logs that many staff can read. Disabling all logging removes the forensic trail needed after outages, so operators cannot tell whether voucher creation failed, hung, or succeeded silently—observability collapses. Emailing the resident's home address to a shared distribution list on API failure spreads PII further and uses the wrong channel for machine diagnostics; distribution lists are not a substitute for structured, minimized application logs. Exam caveat: even request IDs can become quasi-identifiers if they embed account numbers or emails—use opaque IDs issued by the voucher system, and retain detailed payloads only in access-controlled stores when policy explicitly requires them. Operational check: create a test voucher, confirm logs show outcome plus request ID and timestamp without name, email, password, or address; induce a controlled failure and verify failure is logged at an actionable level; scan log pipelines for accidental PII before promoting the script to production library Wi-Fi.