Make the Fake Impossible

Every patient in the public tour of my care platform is a computer science pioneer. Ada Lovelace has a pain score. Alan Turing is due for a check-in. And every one of them has a patient ID no real system could ever issue, an ID that is wrong the way a date in month thirteen is wrong. None of this is an accident. It is the most useful compliance idea I have had this year.

01A good fake is a liability

Here is the problem with realistic demo data. Under HIPAA, nobody can tell a well-made fake from the real thing by looking. A screenshot of a fake patient named John Smith with a plausible ID looks exactly like a screenshot of a real one. So when that image turns up in a deck, or a tweet, or a forwarded email, someone has to prove it is clean. And the only way to prove it is to go back to the database and show the record does not exist. That is an audit. Every plausible fake carries a future audit inside it.

So a good fake does not reduce your risk. It just moves it. The better the fake looks, the more it costs to prove it is one. The safety of a fake is not in how real it looks. It is in how obviously fake it is.

A plausible fake needs an audit to clear it. An impossible fake clears itself.

The fix is to stop making fakes plausible and start making them impossible. A patient named Grace Hopper with an ID that breaks the format on sight cannot be a real record. Anyone can check that from the pixels alone. No lookup, no audit trail, no meeting.

02Zero pixels

The public showcase at clearpathcare.ai contains zero pixels from the production console. Every screen is a React recreation, rebuilt by hand to look like the product without ever touching it.

The rebuilt screens pull from a single file, lib/demo-data.ts, and every record in it follows two rules. The name is a computer science pioneer, so a human reads it as symbolic at a glance. The ID is structurally impossible, so a machine rejects it on format alone. Two tells, one for people and one for systems.

The same records feed the guided demo inside the product: nine chapters, about forty steps, following one patient from enrollment to an audit-proof claim. A transparent layer over the screen keeps it watch-only; you can see everything and click nothing. The patient app has a matching demo mode running on the same impossible data.

03One idea, three rooms

I keep finding the same shape in different rooms. In healthcare, the fake has to be impossible, so a screenshot cannot be PHI. In compliance, the proof has to live in the artifact, because a process can be skipped and a pixel cannot. In marketing, the demo has to travel, and the only demo that travels freely is one that carries its own innocence with it. Three rooms, one idea: put the proof inside the thing itself.

I run businesses in more than one industry, and this keeps happening. A small idea from one room turns out to be the whole point in another.

I wrote a while ago that a green checkmark is a timestamp. It proves things were fine when you looked. A database lookup is the same kind of proof; it shows the screenshot was clean at the moment someone checked. An impossible ID is different. It is not a record of a check. It is a property of the thing. It cannot go stale.

04Make it impossible

If you run anything regulated and you ever have to show it to strangers, here is what I would do:

1. 1Never let production pixels into public material. Rebuild the screen; do not screenshot it.
2. 2Give every fake record two tells: a name a human reads as symbolic, and an ID a machine reads as invalid.
3. 3Put the proof in the artifact, not in a process. Processes get skipped. Pixels do not.
4. 4Treat plausible fakes as real, because if you cannot tell them apart at a glance, neither can an auditor.

The strange part is that the impossible data made the demo better, not worse. Nobody watching the tour wonders whose chart they are looking at. The question never comes up, because the answer is already on the screen.

Ada Lovelace never had a pain score. That is exactly why I can show you hers.