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

email: no usable destination
sms: no usable destination
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: email
channelSource: explicit
createdBy: Citizen
captureChannel: my-account
createdAt: 2026-07-02T09:21:00Z
deliveryIssue: We do not have a confirmed email address to send this to.

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.