Publish a notification with its business change

Purpose

Applications announce business events without separating notification publication from the transaction that records the event.

How It Works

A producer prepares a publish or cancellation envelope for its own workspace. Validation happens before queue insertion. The producer inserts notification work through a restricted database role alongside its business update. Commit makes both available; rollback makes neither available. Repeating the key returns the existing request identity. A post-commit nudge accelerates dispatch, with scheduled dispatch available for recovery. The receipt acknowledges submission rather than promising that an audience was reached. History later supplies the processing outcome.

The rule rows define this outcome; the acceptance set identifies existing proof and proposed checks. Implementation evidence alone does not approve the observed details.

Relationships

Registration supplies the event contract that later work validates and renders.

Show evidence (sources, provenance, origins, pinned commits)

The Formal Contract

The narrative above explains; the sections below are authoritative — the rules, scenarios and tests this document binds.

Outcomes: A business transaction publishes a durable notification request.A repeated idempotency key returns the existing submission.
Surfaces: apijob
Intent sources: services-platform:docs/proposals/notifications/23-decisions.md#D-01services-platform:docs/milestones/plans/PLAT-M23-plan.humanized.md#2. Scopeservices-platform:docs/milestones/plans/PLAT-M23-plan.humanized.md#PLAT-M23-S06

Controls

32 controls apply, from the corpus control catalogue.

TC-AVL-001 TC-AVL-004 TC-AVL-005 TC-AZ-001 TC-AZ-002 TC-AZ-003 TC-AZ-004 TC-CRY-001 TC-CRY-002 TC-CRY-003 TC-CRY-004 TC-IAM-001 TC-IAM-002 TC-IAM-004 TC-IAM-005 TC-IAM-006 TC-LOG-002 TC-LOG-003 TC-LOG-004 TC-LOG-005 TC-MON-001 TC-PI-001 TC-PI-002 TC-PI-003 TC-PI-004 TC-PI-005 TC-TEN-001 TC-TEN-002 TC-TEN-003 TC-VEN-001 TC-VEN-002 TC-VEN-003

Permissions

Key	Checked at	Scope
`platform.notifications.publish`	api	tenant

Business Rules

10 rules, 7 to be proved before approval. A rule's product intent is derived from its origin: 0 confirmed by a product decision, the rest inheriting this capability's proposed.

Id	Rule	Kind	Enforced at	Provenance
`01`must prove Proposed	Publishing inserts a queue entry in the producer's transaction; its availability follows the same commit or rollback as the business change. origin: services-platform:docs/milestones/plans/PLAT-M23-plan.humanized.md#2. Scope no proof recorded yet	invariant	database, service	test services-platform:modules/notifications/tests/integration/services/dispatch/dispatch-notifications.integration.spec.js#leaves nothing to claim when the producer’s transaction rolled back, and one row when it committed
`02`must prove Proposed	The producer capability role inserts only caller-owned queue fields in its own workspace; it cannot set claim or ordering fields, inspect or mutate existing entries, or access other notification tables. no proof recorded yet	permission	database	test services-platform:modules/notifications/tests/integration/db/notification-submissions.table.integration.spec.js#may not read, change or delete the queue it writes
`03`must prove Proposed	The combination of submitting service, idempotency key and request kind identifies one request; Repeating it returns the same identifier with a duplicate receipt and leaves one queue entry. no proof recorded yet	invariant	database, service	test services-platform:modules/notifications/tests/integration/services/requests/submit-notification-request.integration.spec.js#answers the same request id and a duplicate for a repeat, writing one row
`04`must prove Proposed	Queue payloads are objects limited to 32 KB; Entries identify a publish or cancel operation, a service submitter, a three-segment definition key and a derived version-five identifier; Occurrence cancellation uses the publish identifier but a separate entry. no proof recorded yet	validation	database	test services-platform:modules/notifications/tests/integration/db/notification-submissions.table.integration.spec.js#refuses a payload over 32 KB
`05`must prove Proposed	Submission validates the complete envelope before writing or nudging dispatch; invalid or extra fields produce path-specific refusals; audience reasons occupy one line and at most 200 characters. no proof recorded yet	validation	api, service	test services-platform:modules/notifications/tests/integration/services/requests/submit-notification-request.integration.spec.js#refuses a malformed envelope naming each path, with nothing written and nobody nudged
`06`must prove Proposed	HTTP publication and cancellation require a Rhythm system caller with publish permission; console callers are rejected even with all Platform permissions; IAM invocation requires the assigned invoke policy. no proof recorded yet	permission	api	test services-platform:modules/notifications/tests/e2e/notifications.e2e.spec.js#refuses the system door and Rhythm HQ’s routes to a console caller, even one holding every platform key
`07` Proposed	A receipt supplies the identifier derived from service and key and indicates duplication; Processing later determines the outcome displayed in History.	policy	service	test services-platform:modules/notifications/tests/integration/services/requests/submit-notification-request.integration.spec.js#writes the queue row the library writes and answers the receipt, nudging the dispatcher afterwards
`08`must prove Proposed	Cancellation identifies the request to withdraw; unknown identifiers are not found, and a reason is required. no proof recorded yet	validation	api, service	test services-platform:modules/notifications/tests/e2e/notifications.e2e.spec.js#answers a cancel of an unknown request 404 and one without a reason 400
`09` Proposed	A post-commit nudge starts dispatch; Minute-by-minute scheduling supplies another chance when a nudge is lost, without imposing a delivery deadline.	policy	service	observed services-platform:modules/notifications/services/dispatch/dispatch-notifications.ts:dispatchNotifications
`10` Proposed	IAM submissions use the service named by the event and return the same publish or cancel receipt as HTTP.	policy	service	test services-platform:modules/notifications/tests/integration/services/requests/submit-notification-request.integration.spec.js#submits as the service the event names

Scenarios

Id	Given	When	Then	Provenance
`01`	The responsibilities integration assigns Jane Batch posting within its business transaction.	That transaction commits and publication repeats using its event key.	The queue contains one entry and the repeated submission returns the original identity as a duplicate.	test react-console:acceptance/notifications/playwright/journeys/pipeline/NT-ACC-0200.spec.ts#NT-ACC-0200
`02`	A console administrator possesses all Platform permission keys.	The administrator invokes system publication.	System-route access rejects the console caller.	test services-platform:modules/notifications/tests/e2e/notifications.e2e.spec.js#refuses the system door and Rhythm HQ’s routes to a console caller, even one holding every platform key

Planning

Publish a notification with its business change ​

Purpose ​

How It Works ​

Relationships ​