---
id: TST-PFM-SEC-085
title: Access document database and service checks
kind: integration
product_area: platform
module: security
revision: 2
status: draft
source_sha:
  services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1
repository: services-platform
files:
  - modules/security/tests/integration/services/access/access-document.integration.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: 3
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/integration/services/access/access-document.integration.spec.js#security
      capability: getAccessDocument
  - provenance: test
    source: >-
      services-platform:modules/security/tests/integration/services/access/access-document.integration.spec.js#a
      customer-scope grant of a built-in role
  - provenance: test
    source: >-
      services-platform:modules/security/tests/integration/services/access/access-document.integration.spec.js#answers
      the caller, the grant with its role name and validity, and every key the role allows, and
      nothing else
  - provenance: test
    source: >-
      services-platform:modules/security/tests/integration/services/access/access-document.integration.spec.js#names
      the tenant it was asked about, and answers the same keys there, a customer grant reaching
      every tenant
  - provenance: test
    source: >-
      services-platform:modules/security/tests/integration/services/access/access-document.integration.spec.js#leaves
      a grant out of the document once it is revoked, answering no keys at all
  - provenance: test
    source: >-
      services-platform:modules/security/tests/integration/services/access/access-document.integration.spec.js#grants
      that are listed but not in force
  - provenance: test
    source: >-
      services-platform:modules/security/tests/integration/services/access/access-document.integration.spec.js#lists
      all three newest first, each with its own validity, its own status and none of them in force
  - provenance: test
    source: >-
      services-platform:modules/security/tests/integration/services/access/access-document.integration.spec.js#carries
      no role name at all for the grant holding its own rules rather than a role
  - provenance: test
    source: >-
      services-platform:modules/security/tests/integration/services/access/access-document.integration.spec.js#asks
      about the whole catalog and allows none of it, which is how 'I have the role but it does
      nothing' reads
  - provenance: test
    source: >-
      services-platform:modules/security/tests/integration/services/access/access-document.integration.spec.js#a
      tenant-scope grant of rules of its own
  - provenance: test
    source: >-
      services-platform:modules/security/tests/integration/services/access/access-document.integration.spec.js#allows
      the key at the tenant it was granted for, and every catalog key the pattern covers
  - provenance: test
    source: >-
      services-platform:modules/security/tests/integration/services/access/access-document.integration.spec.js#lists
      the very same grant in force at the other tenant and allows nothing there
  - provenance: test
    source: >-
      services-platform:modules/security/tests/integration/services/access/access-document.integration.spec.js#a
      portal member of one tenant
  - provenance: test
    source: >-
      services-platform:modules/security/tests/integration/services/access/access-document.integration.spec.js#answers
      the member's own tenant on the document beside the tenant it was asked about
  - provenance: test
    source: >-
      services-platform:modules/security/tests/integration/services/access/access-document.integration.spec.js#the
      slice the route is served with
  - provenance: test
    source: >-
      services-platform:modules/security/tests/integration/services/access/access-document.integration.spec.js#carries
      the derived grant, and the written one stripped of its rules (premise)
  - provenance: test
    source: >-
      services-platform:modules/security/tests/integration/services/access/access-document.integration.spec.js#answers
      the keys the role really carries, which the slice it was served with could not have named
  - provenance: test
    source: >-
      services-platform:modules/security/tests/integration/services/access/access-document.integration.spec.js#leaves
      the route's own self-read key out of the keys it asks about, it being no ability anybody
      granted
  - provenance: test
    source: >-
      services-platform:modules/security/tests/integration/services/access/access-document.integration.spec.js#still
      lists the grant an administrator wrote, which is read from the database rather than the slice
  - provenance: test
    source: >-
      services-platform:modules/security/tests/integration/services/access/access-document.integration.spec.js#a
      customer administrator, beside the security context
  - provenance: test
    source: >-
      services-platform:modules/security/tests/integration/services/access/access-document.integration.spec.js#allows
      the keys the Administrator role carries, where before phase 16 it allowed nothing at all
  - provenance: test
    source: >-
      services-platform:modules/security/tests/integration/services/access/access-document.integration.spec.js#allows
      exactly what the security context allows the same caller in the same tenant
  - provenance: test
    source: >-
      services-platform:modules/security/tests/integration/services/access/access-document.integration.spec.js#asks
      about the whole catalog, so what it allows is a subset of what it asked about
  - provenance: test
    source: >-
      services-platform:modules/security/tests/integration/services/access/access-document.integration.spec.js#a
      read-only user whose grant denies one of its own keys
  - provenance: test
    source: >-
      services-platform:modules/security/tests/integration/services/access/access-document.integration.spec.js#honours
      the deny, leaving out the one read key the role carries and keeping the rest
  - provenance: test
    source: >-
      services-platform:modules/security/tests/integration/services/access/access-document.integration.spec.js#allows
      no write of the catalog, the role carrying none
  - provenance: test
    source: >-
      services-platform:modules/security/tests/integration/services/access/access-document.integration.spec.js#a
      caller holding nothing
  - provenance: test
    source: >-
      services-platform:modules/security/tests/integration/services/access/access-document.integration.spec.js#answers
      the caller rather than refusing them: no grant, no key allowed, and the catalog asked about
dependency_evidence: >-
  The prepared PostgreSQL database supplies the persisted fixtures and constraints exercised here.
  The file declares no substituted collaborators.
evidence:
  - >-
    services-platform:modules/security/tests/integration/services/access/access-document.integration.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/integration/services/access/access-document.integration.spec.js
  explicit_no_doubles: true
  identified_double_boundaries: []
---
# Access document database and service checks

## Verification Boundary

The file exercises database or service behavior through the local integration harness. The assertion references identify the source checks for access document.

## 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 prepared PostgreSQL database supplies the persisted fixtures and constraints exercised here. The file declares no substituted collaborators.

## Must Not Be Doubled

Keep the queried database, applicable constraints and transaction boundaries real. Provider substitutes cannot establish delivery, cloud execution or cross-service recovery.