Status. Proposed design only. Nothing in this vault is GGA client approval. The GGA client documents are supplied drafts: see GGA-Source-Digest. No application, service or test has been executed; every scenario is Not executed. Delivery fees and dates are open.
Notifications, jobs and safe retry
Sources: Blueprint pp. 11, 15 to 17 (GGA-Requirement-Register); retained 1.3 outbox findings.
flowchart LR R[Authorised business change] --> T[ONE transaction<br/>state change + audit entry + outbox event] T --> W[Worker claims committed job] W --> A[Recheck recipient, consent and scope] A --> S[Send non-sensitive message<br/>link to authenticated portal] S --> D[Delivery record<br/>sent, failed, skipped, provider id, bounce] S -.transient failure.-> RT[Retry 1 min, 5 min, 30 min, 2 h] --> W RT -.exhausted or permanent.-> Q[Operations exception queue]
- Commit the state change, audit entry and outgoing event together; external messages run afterwards.
- A worker lock prevents concurrent claims but does not by itself guarantee exactly-once delivery. Processing is at-least-once with duplicate protection (unique business key, durable attempt history, provider idempotency where available). Reconcile uncertain delivery before resending. Duplicate external email cannot be categorically ruled out.
- Do not retry permanent permission or validation errors. A failed notification never bypasses consent, reactivates a listing or marks a contribution paid.
- Messages are non-sensitive: no confidential profile, document, contact package or private content; the link re-authorises.
- Operations see queue age, failures and a safe retry action.
Job catalogue (Blueprint p. 16)
| Job | Behaviour |
|---|---|
| Profile reminders | Daily due-date scan; at due date and grace days 7 and 13; dedupe by company, attestation cycle and type; stop old-cycle jobs after confirmation |
| Listing expiry and refresh | Regular expiry check; remove expired from projections; APIs enforce expiry independently; notify owner; review before republishing a material change |
| Interest and consent | Notify owner of a new pitch; remind only while pending; expire unanswered consent after 14 days; recheck recipient and scope before delivery |
| Outcome follow-up | Prompts 14 and 45 days after introduction; progress, not assumed success; stop on closure or opt-out of research messages |
| Sessions and events | Recordings and speaker material only with permission, never a condition of participation; confirmation, calendar file, 24-hour and 1-hour reminders from the current occurrence version; updates cancel obsolete jobs and send a replacement notice |
| Contribution and renewal | Finance tasks only after valid opt-in; renewal invitation proposed 30 days before expiry; never a renewal charge without a fresh decision |
| Email and calendar | Transactional email service; calendar files or an existing meeting provider; retain provider IDs, outcomes and bounces; email is the pilot default |
| Optional channels and AI | WhatsApp, social publishing and AI are separate adapters needing approved consent and configuration; absence must not block the core journey |
Intervals, reminder points, retry delays and prompt timings are proposed defaults and configuration values (Blueprint p. 1). The behaviours themselves are design requirements: APIs enforce expiry independently of the job, jobs read the current occurrence version, and old-cycle jobs stop after a fresh confirmation.
Retained from revision 1.3
One-transaction outbox, no exactly-once promise, unique event-recipient key, ambiguous-send reconciliation, recipient re-check, generic email, in-app record survives email failure, callbacks verified and deduplicated.
Superseded
The four immediate business events (new interest, assigned question, accepted discussion, material revision) and the 1.3 exclusion of digests, quiet hours and overdue reminders (Q07): the GGA catalogue above replaces them. Quiet hours and digests received no GGA feedback; Proposed carry-forward only.