PII and Data Privacy

Pathrule3 Rules • 2 Memories

PII and data privacy fail when personal information spreads through databases, logs, analytics, queues, exports, and backups without a shared lifecycle. This bundle establishes data classification, purpose-limited collection, field-level access, safe observability, retention, deletion, and subject-request evidence. Unlike Postgres Schema, it governs personal data across every processor rather than relational structure and migration mechanics.

Suggested path map

Pathrule places each piece on the matching path, so your assistant only sees it where it belongs. This is the scoping you get on import; you can adjust it in your workspace.

/ workspace root

src/

api/

Collect only declared personal data

Privacy requests are durable workflows

db/

Authorize personal data at field and purpose boundaries

Data classification travels with the field

migrations/

Make retention and deletion cover every copy

Rules

Collect only declared personal data/src/apihighstrictEvery personal-data field has a purpose, lawful basis or user expectation, owner, and retention rule before collection.

1	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.
2
3	- Reject new PII fields unless the schema change names purpose, consumers, retention, deletion behavior, and whether the value is required.
4	- Separate optional product data from authentication, fraud, billing, and legal records so consent and retention do not bleed across purposes.
5	- Do not infer or enrich sensitive attributes merely because a provider makes them available.
6	- Return only fields required by the caller's operation; never serialize a whole user record into a convenience response.
7
8	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.

Authorize personal data at field and purpose boundaries/src/dbhighstrictAccess to a record does not automatically grant access to every personal field stored on it.

1	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.
2
3	- Define purpose-specific read models that select only approved fields instead of returning persistence entities.
4	- Separate highly sensitive values and encryption keys from ordinary profile data, with independent access paths and audit signals.
5	- Authorize service-to-service reads with workload identity and declared purpose, not a shared database credential.
6	- Log access decisions using subject and field classes without copying the protected values into the audit event.
7
8	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.

Make retention and deletion cover every copy/migrationshighstrictRetention jobs and subject deletion traverse primary data, derived stores, queues, search, analytics, exports, and restoration paths.

1	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.
2
3	- Maintain a machine-readable inventory of systems that receive each personal-data class and the key used to locate it.
4	- Define deletion, anonymization, or legal-hold behavior per destination and preserve only the minimum proof that the action occurred.
5	- Apply retention to failed jobs, dead-letter queues, temporary files, debug captures, and generated exports, not only production tables.
6	- When a backup is restored, rerun tombstones or deletion journals before making the recovered system available.
7
8	Verification: Run a seeded subject through collection, export, deletion, and a restoration drill; query every registered destination and confirm only permitted evidence remains.

Memories

Data classification travels with the field/src/dbA wiki label is not enough because copied values lose context as they move through schemas, events, logs, and analytics.

1	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.
2
3	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.
4
5	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.

Privacy requests are durable workflows/src/apiAccess, correction, portability, and deletion requests cross services and can outlive an HTTP request, so a synchronous controller is not the system of record.

1	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.
2
3	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.
4
5	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.

Why this pattern

Agents add a field for convenience without tracing where it is copied, logged, exported, retained, or deleted, creating undocumented personal-data processing.

Built for Teams whose products collect, derive, transmit, or retain personal information.

Keeps your assistant from:

Collecting personal data without a named purpose and owner
PII leaking into logs, analytics, prompts, or support exports
Deletion that clears one table while copies remain active elsewhere

View as markdown

License: Apache-2.0
Version: 1.0.0
Updated: 2026-08-25