persistence domain

durable facts outlive every process that reads or writes them, so their invariants must live in the storage itself, not in whichever code last touched them. naming, keys, constraints, transactions, and forward-only history are one concern: they decide whether a stored fact can be trusted years later without reading the application that produced it.

owns a decision when the question is how a fact is stored and stays trustworthy over time — table shape, keys and identifiers, constraints, transactions, migrations, retention, or reconciliation. in-process execution rules belong to the execution domain.

• database design
• computed state
• table consolidation
• table naming
• identifiers and keys
• tenant isolation
• schema migrations
• transaction boundaries
• concurrency and conflict control
• aggregate design
• lifecycle retention and history
• data quality and reconciliation
• storage scaling and topology
• prefixed nanoid identifiers

bad

metadata JSON stores relationship, status, and ownership details.

durable invariants and query paths are invisible to the database. no CHECK constraint catches corrupted JSON. queries need full-table scans plus application-layer filtering. uniqueness and relationships cannot be enforced, corrections need custom scripts, audit is impossible.

good

workflow_step_record has typed columns, foreign keys, checks, and indexes.

the schema proves the durable fact and its relationships. foreign keys prevent orphans. CHECK constraints reject invalid status values before the application sees them. indexes make queries constant-time by status or owner. the schema is the source of truth; auditable history is kept.