Know what personal information your application holds
Contact details, identity information and free text need more precise descriptions than “sensitive data.” Wildo attaches categories to the fields that hold them and makes those declarations available to the application’s information inventory.
The classification sits beside the field’s other rules, so understanding the data is part of defining it.
Example — Describe a contact accurately
A contact’s name is identity information; the company they work for is professional information. Classifying each field preserves that distinction when the application explains its data practices.
For engineers
This actual Wonder CRM contact schema shows category and erasure declarations on two fields. They answer different questions: what the value contains and what an erasure does to it. The source comment explains why the retained contact keeps a replacement name:
Source: contact.schemas.ts (selected excerpt).
companyId: z.string().min(1).optional().isDBIndexed().isForeignKey().isSummaryField()
.impersonalizeWith(RedactionType.REMOVE)
.dataCategories(PersonalDataCategory.PROFESSIONAL),
/*
* A contact's NAME is the personal data this resource exists to hold, and it is scrubbed on
* erasure rather than removed: the row is retained (see `retentionPolicy` on the config), and a
* retained row whose name is null reads as corrupt where a masked one reads as erased.
*/
name: z.string().min(1).max(120).isSummaryField()
.impersonalizeWith(RedactionType.MASK, { maskValue: '[erased]' })
.dataCategories(PersonalDataCategory.IDENTITY),
PersonalDataCategory is the named vocabulary for identity, contact details, credentials, financial data, usage and the other supported categories. Declare the specific category rather than a general sensitivity level. The factory validates declared members. There is no resource-wide category default because one row can contain several kinds of information.
The inventory derives from declarations, not identifiers such as email. Credential decorators provide their own category signal. Introspection reports fields that already have a privacy declaration but lack a category, and distinguishes those omissions from resources whose personal-data question is unanswered.
These declarations feed the compliance facts consumed by application documentation work. They do not discover personal data hidden in arbitrary free text or verify the lawfulness of collecting it. Review actual fields and purposes, then keep that decision close to the schema as the application evolves.