---
id: TST-PFM-ELG-464
title: Eligibility population run 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/services/population/population-run.integration.spec.js
implements:
  - ATS-PFM-ELG-010-03
  - ATS-PFM-ELG-010-04
  - ATS-PFM-ELG-011-02
  - ATS-PFM-ELG-011-03
  - ATS-PFM-ELG-011-04
  - ATS-PFM-ELG-011-05
  - ATS-PFM-ELG-011-06
  - ATS-PFM-ELG-011-07
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/services/population/population-run.integration.spec.js
    cases:
      - >-
        answers each subject of a SQL-only rule as the per-subject evaluation
        does
      - succeeds and counts every state of the planted contacts
      - >-
        enumerates only the subjects the sql prefix keeps when the run asks for
        the eligible alone
      - pages the run two subjects at a time and keeps its last cursor
      - >-
        calls the provider in batches of its maximum, only for the subjects the
        prefix kept
      - >-
        answers eligible only the subjects both the sql condition and the
        provider hold for
      - prunes no one for an or one of whose branches reads a provider
      - logs one eligibility.population.page event per page with its counts
      - records the first page with its cursor before the job runs
      - >-
        records a retried page once: the second attempt from the old cursor
        changes nothing
      - restarts from the page cursor and counts every subject once
      - >-
        answers the subjects newly eligible against the earlier run, and none no
        longer eligible
      - keeps a run’s ids ninety days
      - >-
        refuses a rule whose provider type cannot be called in batches, and
        creates no run
      - counts each state before and after the change over the same subjects
      - samples who becomes eligible and who stops being eligible
      - 'settles the simulation succeeded, linked to its run, kept thirty days'
      - records the simulation and its delta on the publish that used it
      - records a publish made without a simulation as skipped
      - >-
        queues a reconcile for every subject the simulation found newly eligible
        when the version is published
      - refuses a publish naming a simulation of another version of the draft
      - deletes the cached display decision of the contact a change is about
      - 'queues a reconcile of the contact, and answers the event succeeded'
      - >-
        deletes the contact’s cached display decision when the change arrives
        through the deployed entry, as CRM sends it
      - >-
        queues a reconcile of that contact, and answers the remote-handler
        contract, one result by event_id
      - >-
        does nothing for a change a ttl-only type reads: nothing dropped,
        nothing queued
      - >-
        leaves a stream no events-invalidated type reads alone: nothing dropped,
        nothing queued
  - provenance: documented
    source: >-
      services-platform:modules/eligibility/tests/integration/services/population/population-run.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 population run 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 uses local integration fixtures. Signing, caches, provider responses or outbound delivery may be supplied by fixtures where the source declares a substitution. The source imports and suite header identify the exact dependencies.

## 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.