11.4 Notification mandates and delivery evidence

packs:security-governance

After this you can: mandate a subscription members cannot silence, read the delivery evidence, and close the loop in the ledger.

Before you start — tick each one:

• Lesson 11.2 — Controls and the evidence ledger (opschain learn 11.2)

In the GUI: Governance → Notifications governance — the mandates and the delivery evidence that proves members were told; a mandated notification reaches the bell like any other, marked "mandated by".

Ordinary notification subscriptions (lesson 5.5) are personal: each user chooses what to hear about and may mute it. Governance needs the opposite shape for a small set of signals — the security team will be told about every break-glass, and no member can opt out — plus the evidence that the telling actually happened. That is a mandate, and its receipt trail is the delivery evidence query. The resource reference is opschain docs resources/notification; the RPC surface is NotificationAdminService on opschain docs api-v2.

Licence entitlement. The mandate admin surfaces, the delivery evidence query and the retention tunables require the packs:security-governance entitlement (see opschain docs entitlements). Enforcement of existing mandates — the engine's matching, the member-verb refusals — and the retention reaper never consult the pack: the controls stay ungated, the admin surfaces are the pack.

Who can do this. All verbs here are admin-plane (/admin updatable), under the opschain admin notifications noun; members meet mandates in the GUI and through NotificationService.

1. Mandate a subscription

A mandate is a subscription shape targeted at one group, whose members cannot delete, mute, snooze or disable it. Mandate break-glass and approval-funnel warnings onto the security administrators:

opschain admin notifications mandates create \
  --name 'Security: approvals exceptions' \
  --group security_admins --scope-domain estate --scope-path /projects \
  --event-kind warn:approvals:break_glass \
  --event-kind warn:approval_policies:degraded \
  --severity-floor warning

mandate "Security: approvals exceptions" created (01a2f9a0-3d4e-7f50-9a6b-7c8d9e0f1a2b) — group security_admins, estate scope

opschain admin notifications mandates list

ID                                    NAME                            GROUP            DOMAIN  SCOPE      SEVERITY  ENABLED
01a2f9a0-3d4e-7f50-9a6b-7c8d9e0f1a2b  Security: approvals exceptions  security_admins  estate  /projects  warning   yes

• The selector grammar is the ordinary subscription one: scope (the authz-rule path grammar; "" is root), object kinds, event kinds, state predicates, severity floor. The scope domain (estate or platform) is fixed at create; names are unique instance-wide.
• Group membership resolves through the provider-group snapshots, so directory moves take effect without touching the mandate.
• Members see it marked "mandated by" in their subscription list, and the member verbs refuse with the typed MANDATED_SUBSCRIPTION reason.
• Writes are audited: api:notification_mandates:create|update|destroy. Deleting a mandate keeps its dispatched evidence rows (their mandate attribution clears).

2. Query the delivery evidence

Who was told what, when, on which channel, with what outcome — metadata only, never rendered secret content:

opschain admin notifications deliveries --mandate <mandate-id> --status failed

RECIPIENT  CHANNEL  STATUS  SEVERITY  EVENT                        CREATED AT            SUMMARY
priya      webhook  failed  warning   warn:approvals:break_glass   2026-10-27T11:02:40Z  Break-glass release on /projects/limebank/environments/prod

opschain admin notifications deliveries --username thomas --from 2026-10-01T00:00:00Z

Filters compose: username, channel_kind, delivery_status, subscription_id, mandate_id, from/to; results page newest first. A failed delivery row is a finding — the mandate said this person must know, and the channel did not deliver.

3. Evidence retention

Delivery evidence outlives the feed on purpose. The policy is fixed on the Basic tier (30d feed / 90d evidence) and tunable on Enterprise (defaults 90d / 400d, 1–3650 days, evidence ≥ feed enforced at write):

opschain admin notifications retention show

feed 90 day(s), evidence 400 day(s) — tier enterprise, tunable true

opschain admin notifications retention set --feed-days 90 --evidence-days 400

retention set — feed 90 day(s), evidence 400 day(s)

The reaper mechanics (and the full resource shape) are on opschain docs resources/notification.

4. Close the governance loop

A mandate is an enforcement instrument — wrap it in a control and attest it with its own delivery evidence (lesson 11.2):

opschain admin governance controls create \
  --key breakglass-notification --name "Break-glass notification mandate" \
  --domain security --owner-role "Security administrator" \
  --instrument notification_mandate:<mandate-id>

created control breakglass-notification (01a2f9b0-…)

Check yourself

• Does opschain admin notifications mandates list show the mandate named for your group — the api:notification_mandates:create event the Academy's first-mandate exercise reads?
• What is the difference between a watch and a mandate, and which typed reason does a member meet when muting one? Then: what does a failed row in the delivery evidence prove?
• Verified version: opschain academy runs the first-mandate exercise against this lesson.

What you learned

• A mandate is a group-targeted subscription its members cannot silence; enforcement is base, administration is packs:security-governance.
• opschain admin notifications deliveries is the receipt trail — who was told what, with what outcome — and failed rows are findings.
• Evidence retention is governed separately from the feed, and the mandate itself is an instrument a control can cite.

Next: this closes the module Security governance — back to your track (opschain learn).