---
id: TST-PFM-NOT-071
title: notification submissions table
kind: integration
product_area: platform
module: notifications
revision: 1
status: draft
source_sha:
  services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1
repository: services-platform
files:
  - >-
    modules/notifications/tests/integration/db/notification-submissions.table.integration.spec.js
implements:
  - ATS-PFM-NOT-002-01
  - ATS-PFM-NOT-002-02
  - ATS-PFM-NOT-002-03
  - ATS-PFM-NOT-002-04
environment: local
implementation_state: implemented
latest_result: not-run
latest_run_at: null
latest_run_ref: null
conformance: not-verified
estimated_minutes: 5
isolation: >-
  Suite-owned records in the prepared integration workspaces; seeded workspace
  identities remain shared fixtures.
assertion_bindings:
  - scenario: ATS-PFM-NOT-002-01
    suite: TST-PFM-NOT-071
    assertions:
      - >-
        services-platform:modules/notifications/tests/integration/db/notification-submissions.table.integration.spec.js#accepts
        the caller’s columns into its own tenant, the negative control of the
        refusals
  - scenario: ATS-PFM-NOT-002-02
    suite: TST-PFM-NOT-071
    assertions:
      - >-
        services-platform:modules/notifications/tests/integration/db/notification-submissions.table.integration.spec.js#is
        refused a row in another tenant by the policy, not by the grant
      - >-
        services-platform:modules/notifications/tests/integration/db/notification-submissions.table.integration.spec.js#is
        refused a row when no tenant is set, by the same policy
      - >-
        services-platform:modules/notifications/tests/integration/db/notification-submissions.table.integration.spec.js#may
        not write Platform’s claim column
      - >-
        services-platform:modules/notifications/tests/integration/db/notification-submissions.table.integration.spec.js#may
        not write the order stamp the database fills
      - >-
        services-platform:modules/notifications/tests/integration/db/notification-submissions.table.integration.spec.js#may
        not read, change or delete the queue it writes
      - >-
        services-platform:modules/notifications/tests/integration/db/notification-submissions.table.integration.spec.js#may
        not read or write any other notification table
  - scenario: ATS-PFM-NOT-002-03
    suite: TST-PFM-NOT-071
    assertions:
      - >-
        services-platform:modules/notifications/tests/integration/db/notification-submissions.table.integration.spec.js#refuses
        a second row for the same submitter, key and kind as a duplicate, which
        is how a retried transaction asks once
  - scenario: ATS-PFM-NOT-002-04
    suite: TST-PFM-NOT-071
    assertions:
      - >-
        services-platform:modules/notifications/tests/integration/db/notification-submissions.table.integration.spec.js#refuses
        an id that is not a UUID version 5
      - >-
        services-platform:modules/notifications/tests/integration/db/notification-submissions.table.integration.spec.js#refuses
        a submitter that is not a service name
      - >-
        services-platform:modules/notifications/tests/integration/db/notification-submissions.table.integration.spec.js#refuses
        a kind that is neither publish nor cancel
      - >-
        services-platform:modules/notifications/tests/integration/db/notification-submissions.table.integration.spec.js#refuses
        a definition key that is not three words
      - >-
        services-platform:modules/notifications/tests/integration/db/notification-submissions.table.integration.spec.js#refuses
        a payload that is not an object
      - >-
        services-platform:modules/notifications/tests/integration/db/notification-submissions.table.integration.spec.js#refuses
        a payload over 32 KB
      - >-
        services-platform:modules/notifications/tests/integration/db/notification-submissions.table.integration.spec.js#writes
        a cancel of the same occurrence as a row of its own, under the same
        derived id
evidence:
  - >-
    services-platform:modules/notifications/tests/integration/db/notification-submissions.table.integration.spec.js
  - The file and referenced assertion titles exist at the pinned commit.
dependency_evidence:
  - >-
    Real: PostgreSQL, the migration's grants, checks and policy. Doubled:
    nothing. Never doubled: the database, the grant, the
---

# notification submissions table

## Verification Boundary

This suite exercises the local services and prepared PostgreSQL database. API lifecycle cases use signed test contexts through the real route handler; they do not invoke the deployed gateway.

## What This Suite Proves

Its cases exercise tie publication to business commit; restrict producer access to insertion; deduplicate publication receipts; apply queue constraints to all writers.

The registered scenario bindings identify the assertions this executable file contributes. They retain individual test references so that a composite scenario does not become a claim of complete execution by one file.

## What It Does Not Prove

Local outcomes do not prove deployed queues, external provider acceptance, production credentials or complete browser behavior. No fresh execution or conformance result is claimed.

## Real Dependencies and Test Doubles

The notification fixtures use real PostgreSQL and module logic. Queue publication, visibility changes, nudges and installed channel adapters are recorded at their seams when the suite needs them. Signed API contexts replace the authorizer key in API suites.

## Must Not Be Doubled

Database constraints, workspace policy, state guards and the service operation under test must remain real. Recording a provider or queue call must not replace the submission, claim or outcome logic being checked.