the write path that was meant to be open

Privacy law gives any person the right to ask what a business holds about them, and to have it exported or erased. On a platform where most orders come from guests who never created an account, the intake surface for those requests cannot require a login, because the person asking frequently has no identity on the system at all. That is a genuine constraint rather than a shortcut, and the design honoured it explicitly.

The public intake accepts a request and answers identically every time: accepted, nothing more. It issues a single verification token, stored only as a one-way digest, with an expiry, burned on use. The requester can poll the status of their own request by presenting that token — a capability, not a credential — and can see nothing else. Every transition appends a metadata-only log row.

The execution half is the inverse. Listing requests, exporting, erasing or restricting data, closing a case: all behind a role check for management and administration, in a different database from the one facing the public, with erasure executed as anonymization because fiscal retention forbids a hard delete. Each action is attributed and logged.

The two halves together are the point. One feature deliberately contains an unauthenticated write path and a tightly gated read path, and the difference between them is not an oversight waiting to be closed — it is the threat model written down where the code can be held to it. What it proves is that this team can hold a distinction most systems blur: public by necessity is not public by accident, and the enforcement sits on the side where the data actually leaves.