Sequence templates reusable across campaigns

When sequence steps live as a JSON blob inside a campaign record, every campaign that wants the same nurture cadence requires its own copy. Copies diverge — a fix to step 2 is applied to Campaign A but not Campaign B, the mistake is caught in production, and there is no authoritative source to determine which version is correct. iso-25010:2011 maintainability.reusability grades this failure mode: the architecture forces copy-paste duplication of business logic, making future changes error-prone and audit trails inconsistent. This is a low-severity architectural debt issue, not a runtime defect — the harm accrues gradually as sequences accumulate.

Store sequence definitions as first-class rows in a sequences table, referenced by campaigns via a foreign key. Step logic lives in sequence_steps, not in campaign records.

// sequences table:       id, name, description, created_at
// sequence_steps table:  id, sequence_id (FK), step_index, template_id, delay_days, branch_conditions
// campaigns table:       id, name, sequence_id (FK to sequences)
// contact_sequences:     id, contact_id, campaign_id, sequence_id, current_step_index

With this schema, updating step 2 of a shared sequence propagates to every campaign referencing it — no copy-paste sync required. When a campaign needs a unique variation, clone the sequence and modify the clone rather than embedding divergent step data in the campaign row.