Data minimization as law, not policy

Most data-protection programs start with a policy and hope the systems follow. We invert that. Minimization is a constraint on the data model itself: a field that the legal form does not require does not exist in the schema, so it cannot be collected, logged, leaked, or subpoenaed. You cannot lose what you never held.

Four rules we enforce in the schema, not the wiki

1. 01Collect only what the legal form requires. Every field traces to a specific legal obligation, or it is removed.
2. 02Never persist raw identity documents or biometric captures. A document is read, parsed, and the image is discarded; the platform stores normalized fields, not pictures.
3. 03Hash or tokenize lookups. The value a traveler uses to recall a submission is never stored in a form that can be reversed into the underlying identity.
4. 04Field-level-encrypt the most sensitive PII. The database alone never yields plaintext for the fields that would hurt most if exposed.

No PII in the places it leaks from

Breaches rarely begin in the encrypted database. They begin in the exhaust: a log line, a stack trace, an analytics event, a URL with an identifier in the query string. So those surfaces carry a flat prohibition. No PII in logs, errors, analytics, or URLs. When analytics are eventually introduced, they are architected to carry zero PII from the first event.

A retention schedule you have to remember to run is a retention schedule you will eventually forget. Make deletion the default, not the chore.

Why this is also good engineering

Minimization is usually framed as a privacy obligation, and it is. It is also a simplification. A smaller schema is easier to encrypt correctly, faster to reason about, cheaper to audit, and less expensive to store across hot, cold, and immutable tiers. The privacy-respecting design and the well-engineered design turn out to be the same design.