---
id: TST-PFM-SEC-055
title: Grant checks request checks
kind: api-lifecycle
product_area: platform
module: security
revision: 2
status: draft
source_sha:
  services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1
repository: services-platform
files:
  - modules/security/tests/e2e/grant-checks.e2e.spec.js
implements: []
environment: local
implementation_state: implemented
latest_result: not-run
latest_run_at: null
latest_run_ref: null
conformance: not-verified
estimated_minutes: 5
isolation: Use the prepared test database and suite-owned fixture rows; retain shared seed records.
assertion_evidence:
  - provenance: test
    source: >-
      services-platform:modules/security/tests/e2e/grant-checks.e2e.spec.js#the read-only grant
      check, through the authorizer: may this caller grant this role at this scope
  - provenance: test
    source: >-
      services-platform:modules/security/tests/e2e/grant-checks.e2e.spec.js#the manifest the
      registry is given
  - provenance: test
    source: >-
      services-platform:modules/security/tests/e2e/grant-checks.e2e.spec.js#declares the customer
      form as its neighbours are declared: the read key required, the manage key evaluated
  - provenance: test
    source: >-
      services-platform:modules/security/tests/e2e/grant-checks.e2e.spec.js#declares the tenant form
      the same way
  - provenance: test
    source: >-
      services-platform:modules/security/tests/e2e/grant-checks.e2e.spec.js#a tenant administrator,
      on the tenant form
  - provenance: test
    source: >-
      services-platform:modules/security/tests/e2e/grant-checks.e2e.spec.js#is allowed a
      resource-scoped role at the scope of their own tenant, and told what the role is
  - provenance: test
    source: >-
      services-platform:modules/security/tests/e2e/grant-checks.e2e.spec.js#is allowed it at a unit
      inside their tenant
  - provenance: test
    source: >-
      services-platform:modules/security/tests/e2e/grant-checks.e2e.spec.js#is refused it above the
      wall, at the customer, naming the authority they do not hold there
  - provenance: test
    source: >-
      services-platform:modules/security/tests/e2e/grant-checks.e2e.spec.js#is refused it at another
      tenant of the same customer
  - provenance: test
    source: >-
      services-platform:modules/security/tests/e2e/grant-checks.e2e.spec.js#is refused it at
      platform scope, which is Rhythm staff authority
  - provenance: test
    source: >-
      services-platform:modules/security/tests/e2e/grant-checks.e2e.spec.js#is answered 404 for
      another customer’s role, as for a role that does not exist
  - provenance: test
    source: >-
      services-platform:modules/security/tests/e2e/grant-checks.e2e.spec.js#a reader who holds the
      role’s key but may not manage access
  - provenance: test
    source: >-
      services-platform:modules/security/tests/e2e/grant-checks.e2e.spec.js#is let through to the
      check, which refuses for the missing authority
  - provenance: test
    source: >-
      services-platform:modules/security/tests/e2e/grant-checks.e2e.spec.js#a customer
      administrator, on the customer form
  - provenance: test
    source: >-
      services-platform:modules/security/tests/e2e/grant-checks.e2e.spec.js#is allowed the role at a
      unit of one of the customer’s tenants
  - provenance: test
    source: >-
      services-platform:modules/security/tests/e2e/grant-checks.e2e.spec.js#is allowed it at the
      customer itself
  - provenance: test
    source: >-
      services-platform:modules/security/tests/e2e/grant-checks.e2e.spec.js#why there is a tenant
      form
  - provenance: test
    source: >-
      services-platform:modules/security/tests/e2e/grant-checks.e2e.spec.js#refuses the tenant
      administrator the customer form, which no tenant grant reaches
  - provenance: test
    source: 'services-platform:modules/security/tests/e2e/grant-checks.e2e.spec.js#what a check writes'
  - provenance: test
    source: >-
      services-platform:modules/security/tests/e2e/grant-checks.e2e.spec.js#writes no assignment and
      no audit event, however many checks were asked
dependency_evidence: >-
  The local request harness exercises the route dispatcher and the prepared database. The suite
  controls Cognito, the signing key at the declared seams; those collaborators remain outside its
  live proof.
evidence:
  - 'services-platform:modules/security/tests/e2e/grant-checks.e2e.spec.js'
  - >-
    Static review at the recorded source revision; executable results remain not-run and conformance
    remains not-verified.
binding_note: >-
  The file has no scenario binding established by this examination. Its executable checks remain
  registered without assigning them broader acceptance coverage.
examiner: codex
examined_at: '2026-10-23'
final_text: OpenAI
dependency_review:
  provenance: test
  source: 'services-platform:modules/security/tests/e2e/grant-checks.e2e.spec.js'
  explicit_no_doubles: false
  identified_double_boundaries:
    - Cognito
    - the signing key
---
# Grant checks request checks

## Verification Boundary

The file exercises public request handling through the local service harness. The assertion references identify the source checks for grant checks.

## What This Suite Proves

The file supplies executable engineering checks for the named subject. No complete acceptance scenario is inferred from the file’s existence.

## What It Does Not Prove

This examination does not run the suite. Passing behavior, deployed conformance and the behavior of substituted dependencies require separate execution evidence.

## Real Dependencies and Test Doubles

The local request harness exercises the route dispatcher and the prepared database. The suite controls Cognito, the signing key at the declared seams; those collaborators remain outside its live proof.

## Must Not Be Doubled

Keep route dispatch, signed-context verification and the exercised service decisions real. A test key can supply signatures, but replacing the authorization decision cannot prove request enforcement.