How should we send direct debit reminders?
Behind the scenes
Property names follow docs/profile-communication-subscriptions.md, which says its own spelling is illustrative. The shape is what was decided.
Usable destinations
- usable
- sms
- usable
- post
- usable
- in-app
- usable
Seeded by seedChannel() against this fixture — §4.1, the one communication rule with real logic behind it here.
Subscription
- subscriptionId
- sub-ct-direct-debit
- catalogueTopicId
- council-tax.direct-debit-reminder
- state
- active
- basisAtOptIn
- public-task
- noticeVersionAgreed
- v1
- channel
- channelSource
- explicit
- createdBy
- Citizen
- captureChannel
- my-account
- createdAt
- 2026-07-02T09:21:00Z
- deliveryIssue
- none
Not modelled
- Expiry, withdrawal history and officer-captured consent. Examples 6.3, 6.6, 6.7 and 6.8 are not fixtures, so nothing renders them.
- What happens to a Subscription when the contact value it depends on is removed. Phase 1 sends to the primary confirmed destination for the channel, so there are no per-Subscription pointers to repair.
- The material-change flow that forces re-opt-in. §5 lists the event; no owner and no journey exist for it.