authoring-data-model

Derive entities from the feature-spec's nouns and access patterns, type every attribute, assign a primary key per entity, and state cardinality plus the on-delete rule for each relationship. Then enumerate access patterns and justify every index against one before self-checking against the nine-condition quality bar.

Relational modeling maps entities to normalized tables with foreign keys and referential integrity. NoSQL modeling is access-pattern-first: the query list determines the schema, using embedding versus referencing and single-table design with overloaded partition and sort keys.

Denormalize deliberately when a read access pattern requires it, and record the read pattern served, the write-cost and staleness tradeoff accepted, and how the redundant copy stays consistent. Normalization to 3NF or BCNF is the starting point, not the goal.

No. The deliverable is the design document — entities, constraints, and a migration plan — not executable DDL. Breaking changes are planned as expand-and-contract sequences with backward and forward compatibility analysis, but the actual scripts are implementation work.

The data model defines the stored persistence shape; the API spec defines the wire contract with request and response DTOs. The API spec is a downstream consumer that references the data model's entities — the dependency is one-directional, so never model from DTOs.

Classify the change as additive or breaking, then run breaking changes as expand-and-contract: add the new structure, backfill data, transition reads, then contract by removing the old structure. Each step stays backward-compatible so old and new code coexist during rolling deploys.