---
id: TST-PFM-ELG-433
title: Eligibility lifecycle 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/governance/lifecycle.integration.spec.js
implements:
  - ATS-PFM-ELG-005-05
  - ATS-PFM-ELG-005-06
  - ATS-PFM-ELG-005-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/governance/lifecycle.integration.spec.js
    cases:
      - names the replacement and moves the definition to deprecated
      - reports the following binding as moved
      - points the moved binding at the replacement
      - >-
        lists the pinned binding for a person to move, and leaves it on the
        deprecated definition
      - >-
        keeps a binding whose consumer already binds the replacement, and one
        the replacement does not fit, with each reason
      - records the move in the audit trail of the binding
      - reports the follower republished as its next version
      - >-
        publishes the follower’s new version naming the replacement, with the
        migration’s change note
      - >-
        records the new version’s reference to the replacement in the dependency
        graph
      - >-
        supersedes the follower’s version that referenced the deprecated
        definition, which stays as it was
      - leaves the follower’s draft as it was
      - lists the pinned reference for a person to move
      - refuses no reference
      - >-
        records the migration in the audit trail of the follower and of the
        deprecated definition
      - >-
        still refuses the archive while the pinned binding and the pinned
        reference remain
      - >-
        restores the deprecated definition to active, clearing its replacement
        (the record carries no empty column)
      - >-
        records each write to it in order: created, published, deprecated,
        migrated, restored
      - refuses a replacement that was never published
      - refuses a definition as its own replacement
      - 'refuses an archived replacement, and moves nothing'
      - 'answers its id (key) and deleted: true'
      - deletes the definition and its draft version
      - 'deletes the draft’s dependency rows, which it had'
      - records the deletion in the audit trail of the definition
      - >-
        refuses a published definition, naming the archive instead, and leaves
        it as it was
      - >-
        refuses a definition a binding uses, naming the binding, and leaves it
        as it was
      - >-
        refuses a definition another definition’s draft references, naming it,
        and leaves it as it was
      - 'refuses a definition the tenant does not have, RecordNotFound'
  - provenance: documented
    source: >-
      services-platform:modules/eligibility/tests/integration/services/governance/lifecycle.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 lifecycle 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.