Semantic Debt - When “No One” Becomes Someone

Relearning yesterday's lesson, today: If it looks like an email address, it might act like one.

Why This Post Exists

Semantic debt often begins as a responsible shortcut: A team has a real constraint. A production system requires a valid-looking email address. Business rules check domains. Reports, alerts, and notifications assume every user record has an email. Nobody wants to weaken validation just to make deletion, anonymization, or testing easier.

So someone reaches for a placeholder.

That placeholder carries a human meaning: “This is not a real person.”

But the system hears something else: “This is a valid address.”

That gap is the trap of semantic debt.

The Modern Version: `deleteduser.com`

The recent deleteduser.com story is a great example.

Some organizations used email addresses at deleteduser.com as placeholders when deleting or anonymizing users. The intended meaning was obvious enough: the user was gone.

But nobody owned the domain. Then someone bought it.

Once deleteduser.com became real internet property, those placeholder addresses became externally routable. The new domain owner began receiving emails that companies never intended to send outside their walls. Some reportedly contained sensitive information, including operational reports, delivery details, guest information, and password reset messages.

The failure was not that the word “deleteduser” was unclear to humans. The failure was that systems do not route based on human intention. They route based on addresses, records, subscriptions, jobs, and integrations.

The user was “deleted” in one field, but still alive in the workflows.

The Older Version: `noone@company.com`

Twenty-one years ago, I ran into an earlier version of the same pattern back in the Lotus Notes days.

We were load testing a system before deployment. We had real data, and the system enforced domain checks on email addresses. We did not want to change the business rules just to make testing easier, so we obfuscated the addresses into something that looked harmless: noone@company.com

To us, it meant: “Send this to no one.” But Lotus Notes tried to be helpful. Its routing logic made a best guess.

That best guess was a real employee who happened to be on paternity leave for a few months. When he returned, he found the messages. He was not happy. And he may have seen internal information that was not intended for him. This could have been much worse.

The embarrassing part is that we were trying to do the right thing. We were preserving business rules, using realistic data, and avoiding changes to production logic. But our safe-looking placeholder still participated in the system.

The Pattern

This user is deleted: Send mail to this valid domain.
This is anonymized data: This record still has subscriptions.
This goes to no one: Find the closest matching person.
This is just a test: Execute the same routing logic as production.
We preserved the business rules: We created a new leakage path.

Semantic debt is not always caused by carelessness. Sometimes it is caused by practical people solving practical problems with the tools available at the time.

What the Solution Should Have Looked Like

In the case of email domains, safer solutions are not just better fake domains. Safer solutions have a better lifecycle model.

A deleted or anonymized user should not remain a normal recipient in the system. Their record should move into a state that disables routing, notifications, reports, password resets, marketing, and scheduled jobs.

The system should distinguish between:

identity data
account state
communication eligibility
report subscriptions
security credentials
audit/history requirements
legal retention requirements
downstream integrations

Deletion should not mean “replace the email field with a magic string.” It should mean “change what the system is allowed to do with this record.” As GenAI agents begin acting on records and workflows, this matters even more: if an agent can find a record and send an email, it may do exactly that, even when it should not.

Practical Best Practices

For modern systems:

Never use a public domain you do not own as a placeholder.
Do not encode lifecycle state inside an email address.
Disable outbound communication before anonymizing identity fields.
Remove deleted users from distribution lists, report subscriptions, alerts, and scheduled jobs.
Separate legal/audit retention from operational availability.
Use explicit account states such as Deleted, Anonymized, Disabled, or RetainedForAuditOnly.
Test deletion as an end-to-end workflow, not a field update.
Use domains you control for test routing.
Use reserved names such as .invalid, .test, or example.com when you need documentation examples or deliberately non-routable values.
Use dedicated test inboxes, mail sinks, or sandbox email services for non-production environments.
Audit outbound mail after anonymization or deletion to prove nothing still routes.

Back in the Lotus Notes case, some of today’s best practices were not available or common. We would have been better off using one of our own controlled email addresses, creating a dedicated test address, or routing all test mail into a mailbox designed for that purpose.

The deeper lesson still holds: A fake value is not safe because it looks fake to humans. It is safe only if every connected system treats it safely.

Semantic debt begins when we assume the system understands what we meant. It comes due when the system does what we told it to do.