Separate editable content versions from authorization epochs

When a row's revision also authorizes queued work, adding an editable content field to that row can make an ordinary text edit invalidate unrelated jobs. This applies where consumers compare a captured revision with the current row; it is not a general reason to split every settings table.

Before choosing storage, trace the UPDATE triggers and every revision consumer, then decide when content becomes fixed: generation, review, or dispatch. If reviewed content should remain stable, an independent content version or narrower authorization epoch can preserve that snapshot while lifecycle changes still revoke work. If dispatch must use the newest content, define regeneration and review behavior explicitly. Test a content edit between enqueue and dispatch alongside disable/remove/re-add transitions; cosmetic changes and authorization changes should have their intended, distinct effects.

Evidence/example — 2026-09-14: read-only inspection of an application schema and its queue gate found an unconditional route-revision increment on UPDATE and rejection of jobs carrying the prior revision. That supports a potential coupling mechanism, not a reproduced production incident. The proposed version separation was not implemented or tested; source-specific identifiers and private data are omitted.