---
id: TST-PFM-ELG-492
title: Responsibility responsibilities checks
kind: api-lifecycle
product_area: platform
module: eligibility
revision: 1
status: draft
source_sha:
  services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1
repository: services-platform
files:
  - modules/responsibilities/tests/e2e/responsibilities.e2e.spec.js
implements:
  - ATS-PFM-ELG-013-02
  - ATS-PFM-ELG-013-03
  - ATS-PFM-ELG-013-04
  - ATS-PFM-ELG-013-05
  - ATS-PFM-ELG-013-06
  - ATS-PFM-ELG-013-08
  - ATS-PFM-ELG-013-10
  - ATS-PFM-ELG-013-11
  - ATS-PFM-ELG-014-01
  - ATS-PFM-ELG-014-04
  - ATS-PFM-ELG-014-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/responsibilities/tests/e2e/responsibilities.e2e.spec.js
    cases:
      - 'lists Platform’s definitions, which every tenant may use'
      - leaves out the definitions of an application the tenant may not use
      - creates a user’s direct assignment at a unit
      - 'refuses a second identical active assignment, 409 already_assigned'
      - >-
        answers a replay of the same Idempotency-Key and body with the first
        assignment, same id
      - >-
        refuses the same Idempotency-Key with another body, 422
        idempotency_key_reused
      - does not return the idempotency bookkeeping
      - 'refuses a team with 400, naming team_id'
      - >-
        refuses a scope kind the definition is not held at with 400, naming
        resource_type
      - 'refuses a caller with read alone, 403'
      - 'refuses to end a derived assignment, 409 derived_assignment'
      - 'refuses to end a role default, 409 role_default_assignment'
      - ends a direct assignment at the version read
      - 'refuses a stale version, 409'
      - answers 404 for another tenant’s assignment
      - 'refuses a tenant outside the signed context, 403'
      - 'lists the tenant’s assignments of one definition, paged'
      - removes a role default
      - lets a holder with delegate-own delegate their own assignment
      - 'refuses delegate-own on somebody else’s assignment, 403'
      - lets a manager delegate somebody else’s assignment
      - 'refuses a reader with neither key, 403'
      - delegates every assignment of the caller in one call
      - lets the delegate end a delegation
      - >-
        answers the caller’s own effective rows with via, and the delegations to
        and from them
      - 'answers the holders at a scope chain, the unit’s primary first'
      - 'refuses a malformed chain, 400'
      - answers the unassigned report
      - answers without a context
  - provenance: documented
    source: >-
      services-platform:modules/responsibilities/tests/e2e/responsibilities.e2e.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.
---

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