# Pathrule Pattern: PII and Data Privacy (1.0.0) # ::pathrule:package:pii-data-privacy ### [RULE] Collect only declared personal data (path: /src/api) Every personal-data field has a purpose, lawful basis or user expectation, owner, and retention rule before collection. Convenience fields become permanent liabilities when no service can explain why they exist or when they should disappear. Enforce this boundary in /src/api so invalid work stops before it reaches another subsystem or creates an externally visible side effect. - Reject new PII fields unless the schema change names purpose, consumers, retention, deletion behavior, and whether the value is required. - Separate optional product data from authentication, fraud, billing, and legal records so consent and retention do not bleed across purposes. - Do not infer or enrich sensitive attributes merely because a provider makes them available. - Return only fields required by the caller's operation; never serialize a whole user record into a convenience response. Verification: Trace one field from request through storage and every response; prove a caller lacking the purpose-specific permission cannot submit, read, or export it. --- ### [RULE] Authorize personal data at field and purpose boundaries (path: /src/db) Access to a record does not automatically grant access to every personal field stored on it. Coarse model-level authorization exposes contact, identity, risk, or support information to callers that only need a display name or account state. Enforce this boundary in /src/db so invalid work stops before it reaches another subsystem or creates an externally visible side effect. - Define purpose-specific read models that select only approved fields instead of returning persistence entities. - Separate highly sensitive values and encryption keys from ordinary profile data, with independent access paths and audit signals. - Authorize service-to-service reads with workload identity and declared purpose, not a shared database credential. - Log access decisions using subject and field classes without copying the protected values into the audit event. Verification: Add contract tests for each read model and an adversarial query that requests a forbidden field; confirm the database or service boundary denies it. --- ### [RULE] Make retention and deletion cover every copy (path: /migrations) Retention jobs and subject deletion traverse primary data, derived stores, queues, search, analytics, exports, and restoration paths. Deleting a primary row is misleading when active replicas, attachments, model features, or reprocessed backups recreate the person's data. Enforce this boundary in /migrations so invalid work stops before it reaches another subsystem or creates an externally visible side effect. - Maintain a machine-readable inventory of systems that receive each personal-data class and the key used to locate it. - Define deletion, anonymization, or legal-hold behavior per destination and preserve only the minimum proof that the action occurred. - Apply retention to failed jobs, dead-letter queues, temporary files, debug captures, and generated exports, not only production tables. - When a backup is restored, rerun tombstones or deletion journals before making the recovered system available. Verification: Run a seeded subject through collection, export, deletion, and a restoration drill; query every registered destination and confirm only permitted evidence remains. --- ### [MEMORY] Data classification travels with the field (path: /src/db) A wiki label is not enough because copied values lose context as they move through schemas, events, logs, and analytics. Represent classification, purpose, retention class, and exportability in schema metadata or code that generators and linters can read. Propagate the classification into event schemas and data contracts rather than relying on variable names. Use the metadata to redact logs, block unsafe destinations, select encryption, and require privacy review on changes. Treat derived and joined values as personal when they can identify or single out a person in the product's context. Keep the decision explicit at /src/db; moving it into an incidental caller makes behavior depend on which route happened to execute first. See /src/api for collection controls and /migrations for lifecycle enforcement. That related boundary consumes this decision and carries the evidence that proves it still holds. --- ### [MEMORY] Privacy requests are durable workflows (path: /src/api) Access, correction, portability, and deletion requests cross services and can outlive an HTTP request, so a synchronous controller is not the system of record. This decision has to survive retries, asynchronous work, and future implementation changes instead of living only in a controller or a reviewer's memory. Create a request record with identity-verification evidence, scope, jurisdiction or policy basis, deadlines, and an immutable event history. Fan out idempotent tasks to registered processors and distinguish completed, exempt, failed, and awaiting-human states. Generate the final response from stored evidence and never expose another person's data through weak request verification. Keep the decision explicit at /src/api; moving it into an incidental caller makes behavior depend on which route happened to execute first. See /src/db for field classification and the privacy request skill for execution. That related boundary consumes this decision and carries the evidence that proves it still holds.