The Right to See Your Digital Profile

What is broken

A person’s digital profile is rarely one file. It is a customer record, a billing record, a support history, a set of event logs, a segment, a score, an embedding, a list of inferred interests and a handful of shadow fields nobody remembers adding. The company can see the shape of it. The person usually cannot.

The subject access request is the tell. It arrives as an email, disappears into a queue, and comes back weeks later as a PDF assembled by hand. It contains the fields the company is comfortable showing: name, address, order history. It rarely contains the derived material — the segment assigned, the risk score, the model’s estimate, the note a support agent wrote. Those are the parts that actually decide what happens to the person.

Even when the export is complete, it is not legible. There is no provenance: which field came from the person, which was inferred, which was bought, which was computed last night by a model that has since been replaced. There is no list of who reads the profile or what it is used for. The person is shown a cupboard and told it is the house.

Correction is worse. A wrong field can be disputed through support, but a wrong inference has no address. It is a number in a feature table, regenerated on the next run.

What the requirement would take to build

Subject access has to be a first-class read API, not a support process. The profile endpoint should return four things together: the source data the person supplied, the derived data the system computed, the provenance of each item, and the consumers that read it. If a field cannot be explained, it should not be silently shipped in an export.

Provenance is the core of the requirement. Each item needs a trail: where it came from, when it was written, by which process or model, and on what basis. That trail is what makes the difference between a profile and a pile. It also makes correction possible, because a wrong inference can be traced to the input and the rule that produced it.

The export must be machine-readable and complete enough to be useful: a documented schema, stable identifiers, and the same view the internal tools use. A separate, prettier customer view is how profiles become invisible again. One API, read by both the person and the company, is the discipline.

Correction needs a route with a state: disputed, reviewed, changed, propagated. A corrected source field should invalidate the derived fields that depend on it, and the person should be able to see that the change reached them. Deletion and visibility grants have to apply to this API too, or the file becomes a back door around the other two rules.

The measure is blunt: can a person open the file, understand every line of it, and point at the line that is wrong? If not, the company is keeping a file it cannot defend.