What is ciphertext, what is plaintext, and why each line sits where it does.
Updated
| Data | Why |
|---|---|
Record data | The vertical's actual content — the default is private. |
| Customer PII | Names, emails, phones; email lookups go through a hash column. |
Platform config | Free-form settings are exactly where a third-party token or webhook secret ends up when someone is in a hurry — so the whole blob is encrypted. |
| Key material | An encrypted copy (for verified re-reveal) plus a SHA-256 hash for lookups. |
| Log IPs & user agents | An IP is personal data; a hash column still supports "everything from this address". |
| Audit detail, billing notes | Human-written context about money and access decisions. |
| Data | Why |
|---|---|
Record status | Workflow state must be a WHERE clause. If something sensitive lands here, that's a schema mistake, not a storage one. |
index_data / search_text | The opt-in projection — the schema explicitly traded privacy for queryability on those named fields, and nothing else. |
| The module allowlist | The permission check and "which platforms use this module" both filter on it; it holds no secrets — it is a list of names we defined. |
| Platform monthly price | Revenue reporting has to SUM it in SQL; it is our own pricing, not customer data. |
| Request origin in logs | It is the domain a request came from, and allowlists are debugged by reading it. |
Every plaintext column has a stated reason to exist, and the reasons are operational (a query someone actually runs), never convenience. When you design schemas on the records engine you inherit the same rule: filterable/searchable are the only doors out of the ciphertext, they default shut, and they only pass scalars.
One operational footnote: encryption keys come from the deployment environment, and a malformed key (for example, quotes preserved by a hosting panel's env editor) fails loudly at startup rather than storing garbage.