Complete EMAIL-WP-0004 transactional invitation mail delivery.

Ship the railiance01 deploy package (OpenBao/ESO custody, NetworkPolicy,
probes), provider failure classification and suppression, T04 unit and live
proof, and non-secret NK-WP-0024 hand-back evidence. Workplan finished.

DECISIONS.md

@@ -2,6 +2,78 @@
 
 _Auto-generated by the Custodian State Hub._
 
+## Defer daily send-quota privilege tiers (anti-spam / abuse)
+
+**Date:** 2026-08-12  
+**Decided by:** human (via agent note)  
+**Status:** deferred — do not implement in EMAIL-WP-0004
+
+### Idea
+
+Outbound email is high-abuse surface if credentials or a caller is compromised.
+The platform should treat **daily send volume** as a privilege, not an
+unlimited side effect of holding a send token.
+
+Proposed daily ceilings (per sender / tenant / grant — exact subject TBD):
+
+| Tier | Mails / day |
+| --- | ---: |
+| minimal | 10 |
+| low | 100 |
+| standard | 1_000 |
+| elevated | 10_000 |
+| high | 100_000 |
+| bulk-capable | 1_000_000 |
+| unlimited | unlimited (explicit break-glass only) |
+
+Default for ordinary transactional use (e.g. invitation/verification) should
+land at the low end of the scale until a use case justifies more.
+
+### Why not now (EMAIL-WP-0004)
+
+Current scope is a **single approved caller** (user-engine), **fixed templates**,
+NetworkPolicy ingress lock, and one shared ingest bearer. Abuse surface is real
+but narrow. Building the full tier model inside T03 custody/deploy or T04
+failure proof would delay the invitation path without a multi-tenant grant
+story.
+
+Existing interim controls that stay:
+
+- template allow-list (no arbitrary body/sender)
+- NetworkPolicy: user-engine only
+- bearer ingest token (OpenBao custody, CCR-2026-0010)
+- idempotency on event id
+
+### When to revisit
+
+Promote to a dedicated workplan when any of:
+
+- a second caller / tenant may send through email-connect
+- the ingest token is treated as a long-lived platform grant
+- marketing-adjacent or high-volume notification use appears
+- flex-auth or credential-broker can bind a **send quota claim** to the caller
+
+### Design sketch for later (not committed)
+
+- Enforce in **email-connect** at accept time (before provider call), with a
+  durable counter (not only in-process).
+- Classify over-quota as **permanent denial** for the day (or retryable after
+  window), redacted diagnostics, no SMTP detail leak.
+- Bind tier via platform auth/grant (flex-auth / OpenBao policy metadata /
+  caller registration), not a free-form request field the client can raise.
+- Unlimited is operator-issued break-glass, audited, not a default.
+- Coordinate with suppression/complaint handling so quota and reputation share
+  one abuse narrative.
+
+### Home for implementation later
+
+New workplan under `email-connect` (suggested slug theme:
+`send-quota-privilege-tiers` / `EMAIL-WP-00xx`), with a hand-off to
+flex-auth / railiance-platform if the tier is a platform grant claim rather
+than a local ConfigMap.
+
+---
+
 ## Operate at build-stage security posture; defer production policy enforcement
 
 **Date:** 2026-07-02