---
id: TST-PFM-OPS-064
title: Audit permissions
kind: unit
product_area: platform
module: operations
revision: 1
status: draft
source_sha:
  services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1
repository: services-platform
files:
  - modules/audit/tests/unit/aws/api/audit-permissions.spec.ts
implements:
  - ATS-PFM-OPS-009-01
environment: local
implementation_state: implemented
latest_result: not-run
latest_run_at: null
latest_run_ref: null
conformance: not-verified
estimated_minutes: 1
estimate_basis: Scheduling estimate only; no duration is measured during this documentation pass.
isolation: 'Process-local inputs, registries and test adapters.'
evidence:
  - >-
    services-platform:modules/audit/tests/unit/aws/api/audit-permissions.spec.ts at
    ad3f6a6582843008ed0f5a17b131878d15829af1: existing suite body, setup, assertions and cleanup.
binding_note: Bindings apply only to the listed specification scenarios.
assertion_sources:
  - >-
    services-platform:modules/audit/tests/unit/aws/api/audit-permissions.spec.ts#publishes exactly the
    three keys the four routes need
  - >-
    services-platform:modules/audit/tests/unit/aws/api/audit-permissions.spec.ts#publishes no update,
    delete or bulk key, because an event is never changed
  - >-
    services-platform:modules/audit/tests/unit/aws/api/audit-permissions.spec.ts#publishes no create key
    for audit-events, because an event is written only by the person it is about
  - >-
    services-platform:modules/audit/tests/unit/aws/api/audit-permissions.spec.ts#declares reporting one’s
    own view at the read tier, so every console role that reads anything carries it
  - >-
    services-platform:modules/audit/tests/unit/aws/api/audit-permissions.spec.ts#declares reading one’s
    own history at the read tier as well
  - >-
    services-platform:modules/audit/tests/unit/aws/api/audit-permissions.spec.ts#declares reading another
    user’s audit events at the admin tier, which is what keeps it out of Read Only
  - >-
    services-platform:modules/audit/tests/unit/aws/api/audit-permissions.spec.ts#marks reading another
    user’s audit events sensitive, so granting it is reviewed
  - >-
    services-platform:modules/audit/tests/unit/aws/api/audit-permissions.spec.ts#marks none of them
    staff-only, which would keep them out of every customer’s roles
---

# Audit permissions

## Verification Boundary

This suite exercises record activity through its declared function or structural boundary. Its implementation is present at the pinned source revision, and this register records no execution result.

## What This Suite Proves

The checks exercise audit permissions within the file’s declared setup and assertion boundary. The structured assertion anchors distinguish these checks from the surrounding feature flows. The scenario bindings name the attributed outcomes.

## What It Does Not Prove

Local execution does not establish deployed infrastructure, live commercial-provider configuration or authorization-cache completion. Registration and an implemented suite do not establish a passing result.

## Real Dependencies and Test Doubles

The production logic under assertion is real. Inputs, registries or source files supply the declared test data; no live service workflow runs.

## Must Not Be Doubled

The production function, registry or builder under assertion remains real.