The personal-data report

jadpo check writes build/report/personal-data.md and a .json twin, in the same form as its other reports (The suggestions report). For each person entity it lists:

• every marked field, with its category, entity, store and caches;
• the queries that say include_erased: true;
• who may read it, from policy;
• its retention, or "kept until erased";
• what erasure does to each record that belongs to the person;
• every connection a marked field is sent to, and whether its copy is erased by the provider's erasure: or kept for an accepted reason;
• keys copied into the outbox for erasure at providers, while they wait;
• the step records of actions with several changing calls, which hold providers' answers, encrypted, until the action commits (an answer over 1 MB is a fault);
• connections holding OAuth grants, and whose grants they are;
• sensitive fields, flagged.

That is most of a record of processing activities (Article 30). Your team adds what the compiler can't know: the purpose of each use, the lawful basis, and the organisation's details.

Changes to the report appear in the approval review, the summary of a change a person signs off before it ships (Review and sign-off). So a pull request that starts sending email addresses to a new provider is seen by a person before it ships.

Where personal data goes

So far the report lists each connection personal data leaves through, the hosts that connection reaches and, for each one, every marked field and every standard type that is personal data sent through it, by what sends it. It is build/report/personal-data.md, with a .json twin, and jadpo check writes it only for a project with no errors. Where a body doesn't check, nothing can say what it sends, so a check that fails takes the last report away rather than leave one that says less than the code does.

A connection is listed for each of the ways a value leaves the app:

The report never says data stays when it may leave. When the compiler can't tell, it counts as reaching:

• The compiler follows a value as it does for what reaches a model: through variables, your app's functions and actions, standard operations, lists, objects, a batch's items and a query's Output. A parameter is followed to what every caller passes, and an event's part to what every emit put there.
• What decided a value leaves with it. A value made under an if or a match on a marked field, or a call made under one, sends that field, and the report says it only decided what was sent.
• A value counts for what its type says, however it got there: a value of a marked field's type, caller.subject among them, and a whole parameter by everything its type holds. So an action only a route calls counts for its input's type.
• A library's function gives back anything it was given, in any part, since nothing follows that code.
• A provider's answer may hold anything its call was sent, in any part. So an id a provider made counts as the name it was made from when it is sent on to another connection, and its row says "may be in a provider's answer" rather than "sent". This is for the report and the acceptance alone: storing that id or sending it to a model doesn't need the name's marks.

Stores and caches aren't in this list. What each keeps comes with the rest of the report.

Each connection says what becomes of its copy when a person is erased: the provider's call and the field holding its key, the app's own store, or kept, with why and an acceptance's reason. Jadpo doesn't call a provider's erasure: yet, and the report says so.

jadpo package check shows the same for a package, whoever calls it: what each of its operations sends, from its input's type and what its actions and subscribers read off marked fields, and the hosts it goes to (What a release shows).