T2.04.3Safe error abstraction with support correlationdesignresearch

Do not expose internal technical detail

Aliases: error abstraction · safe disclosure · public reference ID

What it is

Safe error abstraction with support correlation keeps stacks, queries, paths, internal service names, policy detail, and raw reason codes in a controlled diagnostic layer while the user layer states a safe, understandable condition and action. A non-sensitive public reference ID may let users and support point to the same event. The ID is a correlation token, not a cause explanation, and must reveal no account, resource, or security-rule semantics.

Why it happens

A raw exception adds cognitive noise and can expose architecture or exploitable conditions. Erasing all diagnostic linkage instead prevents support from finding the incident and makes users repeat their story. A mapping layer chooses public copy from an internal reason code, retains detailed telemetry behind authorization, and joins the layers with an indirect reference. An unknown error still resolves to a reviewed safe state rather than passing through a message field or inventing a precise cause.

Studying it

Map error data through backend, SDK, frontend, localization, notifications, and support. Inject known, unknown, degraded, and adversarial inputs and inspect final rendering and logs. Verify that users can act without internals and that support can locate the event from the reference within authorization. Security review covers enumerability, semantic leakage, retention, and access logging. Do not probe public production errors to gather attack evidence.

Where it stops holding

Developer APIs, CLIs, and operator tools may expose more technical detail to authorized audiences, but never secrets, credentials, or cross-tenant data. A diagnostic bundle needs explicit action and redaction; “advanced user” is not blanket permission. Security copy may withhold exploitable thresholds and decision logic while still stating that the request did not complete, the data state, and a viable support path. A public reference is not an authentication credential.

Applying it

  • Map internal reason code to public message key and safe recovery action; send raw exceptions only to controlled telemetry. Alert on unknown codes and show a reviewed fallback.
  • Generate a separate reference ID with no business semantics or resource-access power and make it copyable. Protect support lookup with authorization, rate limits, retention, and audit.
  • Scan CI and runtime output for stacks, paths, SQL, service names, tokens, policy reasons, and unresolved localization keys across toasts, email, status pages, and fallbacks.
  • Exercise both ends: users act without internals and support correlates the event. Fix the supply-chain mapping when a leak appears rather than masking one rendered string.

Related

  • Same group: T2.04.1 Say what happened, why, and what to do · T2.04.2 Do not blame the user in error messages · T2.04.4 Do not joke away real losses · T2.04.5 Same-class errors need consistent wording
  • Adjacent: T1.05.3 Internal codenames must never reach the user interface · T3.04.2 Multi-channel content needs a single source of truth
  • Search terms: safe error disclosure · reference ID · support correlation

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/T2.04.3