How should we send council tax bills and recovery notices?

You have to receive these, but you can choose how. Changing this is recorded, so there is a record of when you asked us to stop sending them by post.

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: 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-billing
catalogueTopicId: council-tax.billing-and-recovery
state: active
basisAtOptIn: statutory
noticeVersionAgreed: — nothing was agreed
channel: post
channelSource: catalogue-fallback
createdBy: Service
captureChannel: service-api
createdAt: 2026-06-29T08:02:00Z
context: {"originatingService":"council-tax","accountReference":"CT-4471902"}
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.