# S38-001 Assumptions — PDPA Data Register Schema

## What was implemented

`pdpa_data_register` table: a platform-level catalog of personal data categories
processed by the AMIR system. Not tenant-scoped — data categories are system-wide.

Columns: `data_category` (unique slug), bilingual display names (BM/EN),
bilingual descriptions, `lawful_basis` (6 values), `retention_class` (5 values),
optional `retention_days` override, `is_sensitive`, `source_tables` (JSONB array),
`is_active`, timestamps.

DB CHECK constraints enforce valid `lawful_basis` and `retention_class` values.
`LawfulBasis` and `RetentionClass` backed enums enforce the same at the application layer.

## Assumptions

- **Platform-scoped (no tenant_id):** The data register describes system-wide data
  categories. Individual koperasi (tenants) do not have different data categories —
  the PDPA compliance posture is system-level. Comment `// platform-scoped` placed
  on the model per CLAUDE.md convention.
- **AC mismatch:** The AC describes a full breach detection workflow (PDPA-SYS-01).
  This task's `files_touched` is the schema for `pdpa_data_register`. Implemented
  schema only; breach detection is a separate future task.
- **Enum cast intercepts invalid values:** Tests for invalid `lawful_basis`/`retention_class`
  catch `ValueError` (PHP enum cast) not `QueryException` (DB CHECK) — the cast fires
  before the DB write. The DB CHECK still provides defence-in-depth for direct SQL writes.
- **`source_tables` is JSONB array:** Stores list of table names (e.g. `['members', 'users']`)
  that contain this data category. Useful for S38-002 data inventory classification.