# Decision Log

_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  
**Decided by:** human  

We are in build stage with the infrastructure as a whole. We will tighten security step by step but it is not yet strictly necessary.

---

## SECRETS-WP-0004 — approve warden-sign auth-capability lane prod apply

**Date:** 2026-07-02  
**Decided by:** human  

I want to move to more automation, this is one step needed to go on.

---

## Defer consumer-side contract-parity drift mode (WHYNOT-WP-0003 T09)

**Date:** 2026-07-02  
**Decided by:** human  

Sufficient for now

---

## DR-3: External identity path for business clients (lightweight vs NK-WP-0011 Keycloak)

**Date:** 2026-07-09  
**Decided by:** human  

We will go with A for the lightweigt version and just follow up with B if we meet actual demand later.

---

## DR-1: Tenancy model for vergabe-teilnahme commercial offering

**Date:** 2026-07-09  
**Decided by:** human  

We will do C and allow for early customers to easy starting serving customere but move on to resource cost optimization early.

---

## DR-2: coulomb.social rebuild architecture (Core Hub extension vs standalone app)

**Date:** 2026-07-09  
**Decided by:** human  

We will go for B as Coulomb Social is it's own Application. Managed by connecting it with our infrastructure but destinct in its purpose and operations model. It is an Application for the Binky Hedgehog GmbH as another App might be provided to other clients. It should not be relevant the the ecosystem as a whole is provided by Binky Hedgehog as the organization creating coulomb and holding the domain and forgejo repos.

---