What we store — Status Post

We keep	Why
A verification result — yes, and nothing more	To know you belong here
A coarse role class (for example: nursing, allied health, support services)	To scope rooms and to show a tier badge
A method code — how you were verified	So your badge can say "peer-vouched" or "license-verified" honestly
A timestamp	To expire and re-check verification over time
Who invited you, if you came in on an invite	So that vouching means something and a capped invite system can be capped. It links two accounts to each other, never an account to a story
Your page, if you make one	It is a thing you chose to have
Your stories, each under a name that belongs to its conversation and nothing else	So a story can be read and replied to. We cannot tell you which ones are yours — see below
A salted hash of your work email domain, if you used that tier	To rate-limit abuse from a single employer domain without storing your address
Before launch only: the email you gave on the Clock In form, and the role and location if you added them	To tell you when your unit opens. This is the only record that exists today — there are no member accounts yet

The last row is the one that is real right now. Status Post has not opened, so nobody has a verification result, a story or a page yet — the pre-launch list is the whole of what we hold. It is not verification, it is never sold or shared, and it is deleted when your account is created or whenever you ask, whichever comes first.

What we deliberately do not have

Your licence number or NPI.
Your employer, as a stored field. The role class is computed at verification time and the input is discarded — so there is no column to query, and no way to hand a hospital a list of its own staff.
Your badge image, or any hash of it. A hash is still a linkable identifier.
Your legal name, unless you choose to put it on your own page.
Any face template, from any image, ever.
A health-interest profile, an affinity graph, or any inference drawn from what you read or post. See the Consumer Health Data Policy.

You do not have one name here

There is no handle. Every story you write in Recovery, Huddle or Consult carries a name that belongs to that conversation and to nothing else — stable inside the thread, so people can follow a reply, and connected to none of your other threads. The key that makes those names lives on your device, not on our servers. That is why the row above says we cannot tell you which stories are yours: we genuinely cannot work it out.

Two different things can put a story on a page, and only one of them says who wrote it.

Sharing puts a story on a page. Anyone can share anyone's story, if its author marked it shareable when they wrote it — so a story sitting on a page is not evidence that the page's owner wrote it. Including when they did.
Claiming is you saying "this one is mine", proved with your own key, one story at a time. Claiming one story tells nobody anything about any other.

We do not generate "more from this author" links, do not share an avatar or display name across surfaces, and do not index one to resolve another.

This matters more than it looks. A badge shows a legal name, a face, an employer, a job title and a department. The whole point of discarding it is that nobody can ask us who wrote something and get an answer. Under the old design, where only you could put your own story on your own page, putting it there proved it was yours — the bridge was the leak. Sharing anyone's story fixes that, because the set of stories on your page no longer means anything about what you wrote.

One honest limit: a name rotates, but a tier badge, a role class and a unit do not. On a small unit, "license-verified RN" posting at 3am narrows things down whatever the story is called. This design raises the cost of working out who you are. It does not make it impossible, and we would rather say so than let you find out.

Logs

IP logs are rotated aggressively rather than retained. Operational logs that must exist for security do not carry post contents.

Deleting your account

Deletion removes your page, your verification record and the credential your device signs with. Stories you claimed stop being claimed and go back to being anonymous — they stay up, under their per-conversation names, as they were before you put your name to them.

Your unclaimed stories are not linked to your record in the first place, so deletion does not reach them. The delete flow will let you take them down before you go, using the key on your device, because once that key is gone neither you nor we can find them again. That is the same property that protects you, seen from the other side: if you lose the device without a recovery phrase, you lose the ability to manage your own stories. We cannot do it for you, and an operator who could would be an operator who could be compelled to.