What is built: Personal data

Feature	Status
`personal: PersonalData.<category>` on an entity's, an event's or an email's field, or an object's, input's or output's a package declares	Partly built: it is read and checked against the fourteen categories for the AI page's check of what reaches a model and for where personal data goes, and a marked field on an entity erasure never reaches is `data.personal_unreachable`. On an app's own object, input or output it is `type.unknown_setting`. Not built yet: the rest of what this page says marking does. A marked field nothing reads compiles without an error, and no log or access record uses the marking.
`person: true`	Built: an entity marked `person: true` is a person, and every record that refers to one directly belongs to them. The build's manifest shows each person under its entity as a `person` node, listing the references its records belong through (`through`) and the fields erasure keeps of their record (`retained`).
`retention:` on a field or an entity	Partly built. Built: the entity's hourly purge schedule clears a nullable field's value, or deletes the record with what cascades from it and the sign-in state of everyone it deletes who signs in, cascades included, at the first run once `since:` is longer ago than `after:`, a `Duration` setting; a `File`'s bytes go once no record holds it (Files); each problem under Retention is an error where it is written. The graph holds a `retention` node for each, under its field or entity, with its period and `since:`. Not built yet: `retention:` on an event's or an email's field, `toolchain.not_built_yet` where it is written.
`erase:` on a reference or the person's own field	Partly built: each problem under Erasure and "Erasure is complete" is an error where it is written. Not built yet: a reference to a person from another store, which stays `data.reference_across_stores` until a generated subscriber can apply it.
`include_erased:` on a query	Built: it finds the people erasure keeps a record of too, and is held to what they keep.
`User.erase(id)`	Partly built. Built: for a caller with `delete` on the person's record, one statement deletes the record, hidden or not, with the sign-in state of anyone it deletes who signs in, and deletes, anonymises or keeps each record of theirs as its reference says, however deep, records with a lifecycle removed outright. A record that belongs to several people keeps its marked fields until the last of them is erased, and another person's own record loses only the reference (Records that belong to several people). The person's own record stays field by field, hidden, where one of their fields says so (The person's own record). The bytes of each `File` it deletes or clears go once it commits (Files), and an audited record it deletes takes its history with it. Not built yet: one that would keep an audited record, whose history still refers to the person (Audit trail), `toolchain.not_built_yet` where `erase` is called, so no erasure is ever partial; and records in another store, `PersonErased`, the erasure log and providers' erasure, which nothing emits or calls.
`User.export(id)`	Not built yet: it is `toolchain.not_built_yet` where it is called.
`privacy:` in `application { }`	Not built yet: it is `toolchain.not_built_yet` where it is written. Nor is `jadpo privacy requests`, which lists the requests it starts.
Encrypted fields	Built: `encrypted: true`, key-type, `TotpSecret` and `SecretText` fields, sealed on write and opened on read, interpreted, compiled and on Workers; each refusal above; rotation through `_PREVIOUS`, with `field_encryption.reseal` and `jadpo config rotation`.
The personal-data report	Partly built: `jadpo check` writes `build/report/personal-data.md` and `.json`, for a project with no errors, listing where personal data goes, and `jadpo package check` shows the same for a package. Each connection says whether its copy is erased or kept for an accepted reason, and the approval review shows its difference from the before side's, a connection at a time. Not built yet: the rest of its list, each person entity's fields, category, store and readers, the queries that say `include_erased: true`, retention, what erasure does, keys in the outbox, step records and OAuth grants.
`erasure:` on a package and on a connection	Partly built. Built: each is read and checked, and a connection that receives personal data and can't erase it needs an `ErasureNotPossible` acceptance (Erasure at providers). Not built yet: calling the package's `erasure:`, so a connection that declares one is not yet asked to erase anyone.
Everything else on this page	Not built yet.

Related