Hashed Developer Identity: How a DX Probe Should Talk About People

A DX inbox is useless if you cannot tell that fourteen unique developers hit ERR_DOCKER_OOM this week. It is also dangerous if every stack is glued to a real email, GitHub handle, and laptop serial 'for context.' Product analytics already struggle with this line. Error probes sit even closer to the metal.

AethelLayer’s default is hashed or opaque developer identifiers. We remember that a runtime, a container, and an error code belong together. We do not need the person’s legal name to draft a ticket you still approve.

Hashing is not a license to stuff secrets into metadata. If you send a session cookie or a private key in the probe payload, hashing the identifier does not save you. Data minimization still applies: stack, command, OS, taxonomy, endpoint.

Your security review should ask: can we reconstruct a human from this row without the customer’s own CRM? If yes, the probe is too chatty.

Growth workspaces can attach PostHog or Mixpanel deep links next to a thread. Those links use identifiers you already operate in your analytics project. We are a pointer, not a second behavioral graph for advertising.

Read the security page for what a probe may contain, and keep Memory Graph on Growth+ as a graph of failures and fixes — not a people graph.