---
id: TST-PFM-ELG-420
title: Eligibility decisions table checks
kind: integration
product_area: platform
module: eligibility
revision: 1
status: draft
source_sha:
  services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1
repository: services-platform
files:
  - >-
    modules/eligibility/tests/integration/db/eligibility-decisions.table.integration.spec.js
implements:
  - ATS-PFM-ELG-009-02
  - ATS-PFM-ELG-009-03
  - ATS-PFM-ELG-009-05
environment: local
implementation_state: implemented
latest_result: not-run
conformance: not-verified
estimated_minutes: 5
isolation: Prepared local test database with suite-owned fixture keys and cleanup.
evidence:
  - provenance: test
    source: >-
      services-platform:modules/eligibility/tests/integration/db/eligibility-decisions.table.integration.spec.js
    cases:
      - modules/eligibility/db/eligibility-decisions.table.ts
      - is partitioned by range on evaluated_month
      - has this month’s partition and each of the next two
      - routes a row to the partition of its month
      - >-
        refuses a month that is not the month of the evaluation, by the month
        check
      - 'refuses a row whose month has no partition, so nothing lands outside one'
      - >-
        refuses the same id twice in a month, by the partition’s copy of the
        primary key
      - 'refuses a state outside the three, by the state check'
      - 'refuses a consistency outside the three, by the consistency check'
      - 'refuses more than fifty reasons, by the reasons check'
      - 'refuses a tenant that does not exist, by the tenant foreign key'
      - >-
        trims the subject id through the parent’s trigger, cloned onto the
        partition
      - carries no row-level security at all
      - >-
        answers another tenant’s decision to a statement that names no tenant,
        which is why every read of the service names one
      - >-
        grants the application role SELECT and INSERT and nothing else, and no
        other role anything
      - refuses an update from the application role
      - refuses a delete from the application role
      - >-
        gives the application role no function that adds a partition: the
        maintenance keeps them
      - >-
        is in the partition registry by its date column, two months ahead and
        thirteen retained
      - >-
        creates December 2026 and the two months after it under the registry’s
        names
      - >-
        bounds a partition of the date column by the first days of its month and
        the next
      - 'detaches and drops October 2025, fourteen months old'
      - 'keeps November 2025, the oldest of the thirteen retained months'
      - >-
        gives a partition it creates its parent’s grants: SELECT and INSERT to
        the application role, nothing to anyone else
  - provenance: documented
    source: >-
      services-platform:modules/eligibility/tests/integration/db/eligibility-decisions.table.integration.spec.js:suite
      header
    note: >-
      The source header describes the verification boundary and declared
      substitutions.
proof_limit: >-
  Only the named scenario checkpoints have a verified source binding; execution
  has not been attempted.
---

# Eligibility decisions table checks

## Verification Boundary

This suite checks the module through real local service and database code at the entry points used by its test cases.

## What This Suite Proves

The mapped scenarios identify the capability and feature checkpoints this file exercises. The source test titles preserve the assertion-level evidence.

## What It Does Not Prove

Registration supplies no execution result or conformance decision. Checks beyond the file’s reachable assertions remain unverified, including production configuration.

## Real Dependencies and Test Doubles

The suite exercises its real module dependencies and declares no test doubles. Its source header and imports identify the database, transaction and service boundaries it uses.

## Must Not Be Doubled

The module behavior under assertion, transaction boundary and database constraint being checked remain real. Fixture setup cannot stand in for the asserted write or refusal.