# S38-002 Assumptions — PDPA Data Inventory (Across Model)

## What was implemented

`pdpa_data_inventory` table: maps every personal data field (table + column) to a data
category, plus metadata about how it's protected (encrypted, hashed).

Model `Across` — named for "data inventory across the schema". Platform-scoped (no tenant_id).

Columns: `table_name`, `column_name`, `data_category` (slug, matches pdpa_data_register),
`is_encrypted`, `is_hashed`, `is_nullable`, `notes`, `is_active`.

UNIQUE(table_name, column_name) — one inventory entry per schema field.

## Assumptions

- **No FK to pdpa_data_register:** `data_category` is a VARCHAR(64) slug, not a FK.
  This avoids a hard dependency on S38-001 being merged first. The relationship is
  enforced by convention (use register slugs); a FK can be added once S38-001 is merged.
- **No seeder included:** The actual classification of every field (members.ic_no_encrypted,
  users.email, etc.) is data, not code. A seeder populating known PII fields should be
  added in a future task or via migration when the full inventory is confirmed.
- **AC mismatch:** The AC describes breach detection (PDPA-SYS-01). This task's
  files_touched defines the data inventory schema only. Implemented schema only.
- **`Across` naming:** Model named `Across` per the task's files_touched
  (`app/Domain/Pdpa/Models/Across.php`). The table is `pdpa_data_inventory` for clarity.
- **`is_hashed` implies `is_encrypted`:** Per the E3 two-column pattern, fields using
  the hash lookup always also have an encrypted ciphertext column. The factory's
  `hashed()` state sets both flags.