Errors need useful but limited detail

A useful error explains the next decision without exposing the internals.

One failure, two audiences

A member needs understandable status and a safe next action. Support needs enough detail to investigate. A correlation identifier connects related events so authorized staff can locate the appropriate diagnostic record. The identifier is a reference, not permission to read that record.

Detailed logs need access restrictions and deliberate data selection. Keeping a message off the public screen does not make passwords, session tokens, or unnecessary personal data acceptable logging material. Retention and responsibility for the record should also be defined.

Fictional failure packet

Assume a club creates reservations and has no documented automatic deduplication for a new attempt.

• E1: The page cannot confirm whether Maya’s reservation completed; it displays “failed, try again.”
• E2: Restricted diagnostics record reference R17, time 14:08, component “reservation response,” and category “timeout.” They do not establish whether the reservation committed.
• E3: An authenticated “My reservations” view provides current booking status. Staff can investigate R17 through their protected support tool.

Rewrite without inventing certainty

The public message should say the result could not be confirmed, then direct Maya to check her reservations before another attempt. Include R17 for support. A timeout establishes missing timely confirmation, not necessarily a failed business operation.

The internal record can retain E2’s diagnostic fields and note that commitment is unknown. Record later verification as a separate observation rather than rewriting uncertainty into a fact. Staff access must remain authorized even when someone knows R17.

Model wording: “We could not confirm the result. Check your reservations before trying again; support reference R17.” Better wording does not repair the underlying failure.