Workflow state lives outside the blob; links make records an application.
Updated
Workflow state (open / closed, draft / active, planned / doing / done) rides on the record's own plaintext column so Postgres can filter on it directly. It is workflow state, not customer data — if a vertical puts something sensitive in there, that is a schema mistake, not a storage one.
statusStatuses are free strings, so a lifecycle is a convention your front end renders — e.g. an agency platform's projects move through discovery → in-build → updating → live → paused/done/cancelled, and its products gate serving on draft → active.
A record can point at a platform customer. That single link is what makes a client portal possible: the portal asks for "this customer's records" and the data layer enforces the scope, so a guessed record id belonging to someone else behaves exactly like a missing one. Ownership checks live in the data layer, not in hidden buttons.
record_ref fields hold record ids, which is how one entity anchors another without joins in your front end: a website record names its project; a task optionally names a project; a site key hangs off a website record. Store the id, not the name — renaming a project must never orphan its sites — and resolve display names at render time.