What the compiler checks

• Marked fields nothing reads. A personal field that no query, output or action reads is an error, because you are holding data you don't use (data minimisation, Article 5). You can decline it, with a reason, because a field kept for a legal reason may be read only by export.
• Erasure is complete. Every reference into a person's records has an erasure outcome: a restricted one into records erasure deletes says what it does (data.erase_required). Erasure.anonymised and Erasure.retained, on a reference or on the person's own field, have the nullable fields (data.erase_field_required) and retention (data.erase_retention_required) they need. An erase: erasure never reads is refused (data.erase_unreached), and so is one on the person's own field that says anything but Erasure.retained, or on an unmarked one (data.erase_own_field).
• What is kept is read only for the reason it is kept. A query saying include_erased: true reads only id and the retained fields (query.include_erased_reads), on an entity that keeps someone's record (query.include_erased_unused).
• No personal data erasure can't reach. A marked field on an entity erasing a person never reaches is data.personal_unreachable. Erasure reaches a person, the records that refer to them, and the records that refer to what it deletes, never past a record it keeps. So a marked field that erasure can't find needs you to refer to the person, or to mark the entity person: true. A field is marked here only by its personal:: a standard type that is personal data whatever holds it, such as a PhoneNumber, an Email or a PersonName, is hashed in logs and its reads recorded, but a shop's own phone number, address or manager's name doesn't make the shop a person. With the completeness check above, every stored copy of what is marked can be reached.
• What leaves can be erased. A connection that receives personal data and can't erase it needs a person's acceptance (Erasure at providers, acceptance.missing). A project's first commit has nothing to compare with, so there it is a notice for a person, and the next change is refused until one accepts it (What a first record holds).
• Sensitive fields stay out of caches. A cache on an entity that holds one leaves those fields out.
• A public cache keeps no personal data. A route saying cache: immutable can't give a marked field, sensitive or not, or a standard type that is personal data, such as PhoneNumber or Email, marked or not, directly or through what it calls (route.cache_invalid), since no erasure reaches a copy a CDN holds. It counts what the report counts.
• A person decides what anyone may read. Personal data on an entity whose read: lists Access.public has nothing to compare with in a project's first record, so it is a notice for a person, and check still passes (What a first record holds).
• Retention can be carried out. A field's retention clears a field that can be none and that no lifecycle owns or reads, an entity's deletes records nothing restricted holds, and every period is a Duration setting (Retention).

There is no purpose: setting and no consent model in the language. Purposes and lawful bases belong in your privacy notice, which you write from the report. Consent is ordinary application data, such as a Consent entity holding the purpose and when it was given and withdrawn.