Rhythm 2.0 Specifications

Appearance

ATS-PFM-LLM-013undefined

Markdown

ATS-PFM-LLM-013

undefined

Markdown
  • DocumentProposed

Planning

Proves capability
CAP-PFM-LLM-013

Design

Executed by
TST-PFM-LLM-007, TST-PFM-LLM-016, TST-PFM-LLM-021, TST-PFM-LLM-026, TST-PFM-LLM-036, TST-PFM-LLM-037, TST-PFM-LLM-053, TST-PFM-LLM-077, TST-PFM-LLM-079

KindAcceptance test setProduct areaPlatformModuleAI Requests, Usage and the Jazz AI TeammateRevision2

Read atservices-platform ad3f6a65react-console baf6dae3

undefined ​

Coverage ​

The scenarios identify the rules or journey assertions they are intended to prove. A test binding names existing evidence; an unbound proposal remains work to verify.

ScenarioTitleLevelProvenance
ATS-PFM-LLM-013-01Limit changes require management authorityapitest
ATS-PFM-LLM-013-02Full replacement clears omitted notesapitest
ATS-PFM-LLM-013-03Invalid limit values preserve all recordsapiproposed
ATS-PFM-LLM-013-04Changed saves need the inspected versionapitest
ATS-PFM-LLM-013-05Replaying stored values adds no historyapitest
ATS-PFM-LLM-013-06Allowance change affects the current period onlyapitest
ATS-PFM-LLM-013-07Widening audit distinguishes more capacityapitest
ATS-PFM-LLM-013-08Preview changes no saved stateapitest
ATS-PFM-LLM-013-09Global AI disablement outranks exemptionsapitest

The interaction register links concrete experiments with run ai requests with consistent attribution and accounting; publish ai operation definitions and historical prices; admit ai work against the organization’s monthly allowance; inspect an organization’s ai account and request history; provide temporary ai capacity and revoke it; show administrators their organization’s ai allowance. Each experiment checks the outcome at the shared boundary; an unbound experiment remains proposed.

Audit rollback, identical first-write races and full live-position transitions after configuration replacement need explicit proof. The console save remains disabled.

Coverage

  • Rule gap: FND-PFM-LLM-072
  • Transition gap: FND-PFM-LLM-072
  • Validation covered
  • Permission covered
  • Edge gap: FND-PFM-LLM-072
  • Failure covered
  • Boundary covered
  • Concurrency covered
  • Invariant covered
  • Interaction covered

Test Scenarios

18 scenarios proving CAP-PFM-LLM-013; 16 bound to an existing test.

01 Limit changes require management authoritypermissionapinegativetest
Proves
BR-CAP-PFM-LLM-013-01
Preconditions
Read-only staff, a customer administrator and a manager have sessions.
Steps
Attempt limit preview and write as each.
Expected
Only the manager can proceed; denied callers write nothing.
Data
Authorized and unauthorized fixtures for the scenario, with controlled request and usage records.
Bound to
Source
services-platform:modules/llm/tests/e2e/llm-limits.e2e.spec.js#is refused the write
02 Full replacement clears omitted notesruleapitest
Proves
BR-CAP-PFM-LLM-013-02
Preconditions
Stored limits include a note.
Steps
Replace limits with that note omitted.
Expected
The note clears and the changed configuration advances a version.
Data
Fixtures representing stored limits include a note.
Bound to
Source
services-platform:modules/llm/tests/integration/services/limits/tenant-limits.integration.spec.js#leaves the notes cleared, since a replacement states them
03 Invalid limit values preserve all recordsvalidationapinegativeproposed
Proves
BR-CAP-PFM-LLM-013-03
Preconditions
An organization has saved limits.
Steps
Submit excessive allowance, unknown operation and blank reason examples.
Expected
Each invalid field is reported and limits, period and audit remain unchanged.
Data
Fixtures representing an organization has saved limits.
Source
services-platform:modules/llm/services/limits/tenant-limits.ts:validateTenantLimitsInput
04 Changed saves need the inspected versionvalidationapinegativetest
Proves
BR-CAP-PFM-LLM-013-04 INV-DOM-PFM-LLM-003-09
Preconditions
Stored limits have version one.
Steps
Attempt a changed save with no version and an older version.
Expected
Missing-version and stale-version errors preserve existing state.
Data
Fixtures representing stored limits have version one.
Bound to
Source
services-platform:modules/llm/tests/e2e/llm-limits.e2e.spec.js#refuses a write with no If-Match with 400 naming the header
05 Replaying stored values adds no historyinvariantapitest
Proves
BR-CAP-PFM-LLM-013-05
Preconditions
A valid limits replacement has committed.
Steps
Submit the same values again.
Expected
The response says unchanged and adds neither audit nor period mutation.
Data
Fixtures representing a valid limits replacement has committed.
Bound to
Source
services-platform:modules/llm/tests/e2e/llm-limits.e2e.spec.js#answers a replay of the write that committed with 200 and no second audit row
06 Allowance change affects the current period onlytransitionapitest
Proves
BR-CAP-PFM-LLM-013-06 INV-DOM-PFM-LLM-003-10
Preconditions
Current usage includes spend and holds alongside a prior month.
Steps
Increase the recurring allowance.
Expected
The current base changes while prior allowance, spend and reservations remain intact.
Data
Fixtures representing current usage includes spend and holds alongside a prior month.
Bound to
Source
services-platform:modules/llm/tests/integration/services/limits/tenant-limits.integration.spec.js#moves this month’s allowance to the new figure
07 Widening audit distinguishes more capacityruleapitest
Proves
BR-CAP-PFM-LLM-013-07
Preconditions
Changes raise and reduce allowance and toggle AI and operations.
Steps
Apply each change with a reason.
Expected
Before and after values are retained, and only increased allowance or re-enabled access is marked widening.
Data
Fixtures representing changes raise and reduce allowance and toggle AI and operations.
Bound to
Source
services-platform:modules/llm/tests/integration/services/limits/tenant-limits.integration.spec.js#keeps the row before and the row after in the audit row
08 Preview changes no saved stateboundaryapitest
Proves
BR-CAP-PFM-LLM-013-08
Preconditions
The current period has usage.
Steps
Preview a reduced allowance.
Expected
The projected position is returned without configuration or audit writes.
Data
Fixtures representing the current period has usage.
Bound to
Source
services-platform:modules/llm/tests/e2e/llm-limits.e2e.spec.js#previews the limits against this month without writing or auditing
09 Global AI disablement outranks exemptionsruleapinegativetest
Proves
BR-CAP-PFM-LLM-013-09
Preconditions
Global AI and individual operation restrictions combine with an active exemption.
Steps
Evaluate operation access under each configuration.
Expected
Exemption permits a disabled operation only while the global AI switch remains on.
Data
Fixtures representing global AI and individual operation restrictions combine with an active exemption.
Bound to
Source
services-platform:modules/llm/tests/integration/services/limits/tenant-limits.integration.spec.js#refuses it when AI is off, whatever exemption is in force
10 Exemption cannot bypass global disablementinteractionapinegativetest
Proves
BR-CAP-PFM-LLM-013-09 BR-CAP-PFM-LLM-014-02
Preconditions
An operation is disabled and a temporary exemption exists.
Steps
Check admission with global AI enabled, then disable global AI and check again.
Expected
The exemption bypasses only the operation switch; global disablement refuses without holding capacity.
Data
An isolated workspace with the records, clock instants and caller authority stated in the preconditions.
Bound to
Source
services-platform:modules/llm/tests/integration/services/limits/tenant-limits.integration.spec.js#allows it again while an operation exemption is in force,services-platform:modules/llm/tests/integration/services/limits/tenant-limits.integration.spec.js#refuses it when AI is off, whatever exemption is in force
11 Customer availability follows recurring switchesinteractionapiproposed
Proves
BR-CAP-PFM-LLM-013-09 BR-CAP-PFM-LLM-017-04
Preconditions
A feature has one declared operation and current usage.
Steps
Read availability, disable its operation, then disable global AI and read each state.
Expected
Customer restriction wording follows the current switches without exposing management configuration or model details.
Data
An isolated workspace with the records, clock instants and caller authority stated in the preconditions.
Source
services-platform:modules/llm/tests/integration/services/limits/tenant-limits.integration.spec.js#refuses it when AI is off, whatever exemption is in force,services-platform:modules/llm/services/usage/organization-usage.ts
12 Persisted limits reject a zero running capvalidationapinegativetest
Proves
BR-CAP-PFM-LLM-013-03
Preconditions
The suite owns isolated fixtures representing the valid control and the contrasting case described by its steps.
Steps
Insert a cap of one, then attempt zero for the same configuration shape.
Expected
One is accepted and zero is refused.
Data
Suite-owned fixtures, with a fixed clock where dates or grant windows matter.
Bound to
Source
services-platform:modules/llm/tests/integration/db/llm-tenant-limits.table.integration.spec.js#refuses an in-flight cap of zero, which would refuse every call
13 An exemption restores only operation accessinteractionapitest
Proves
BR-CAP-PFM-LLM-013-09
Preconditions
The suite owns isolated fixtures representing the valid control and the contrasting case described by its steps.
Steps
Attempt a scripted operation while it is disabled, grant an operation exemption and attempt again.
Expected
The first request refuses with no provider call; the exemption permits the later scripted request.
Data
Suite-owned fixtures, with a fixed clock where dates or grant windows matter.
Bound to
Source
services-platform:modules/llm/tests/integration/lifecycle/tenant-limits.integration.spec.js#runs the call once the exemption is in force
14 Competing limit replacements choose one writerconcurrencyapitest
Proves
BR-CAP-PFM-LLM-013-04
Preconditions
The suite owns isolated fixtures representing the valid control and the contrasting case described by its steps.
Steps
Race changed replacements from the same inspected version.
Expected
One replacement commits and the other receives the changed-record refusal.
Data
Suite-owned fixtures, with a fixed clock where dates or grant windows matter.
Bound to
Source
services-platform:modules/llm/tests/integration/services/persistence/limits.integration.spec.js#lets one win
15 Limit inspection retains the next write versionruleapitest
Proves
BR-CAP-PFM-LLM-013-02
Preconditions
The suite owns isolated fixtures representing the valid control and the contrasting case described by its steps.
Steps
Read persisted limits after a known write.
Expected
The returned version matches the saved configuration and supports a later conditional replacement.
Data
Suite-owned fixtures, with a fixed clock where dates or grant windows matter.
Bound to
Source
services-platform:modules/llm/tests/integration/services/persistence/limits.queries.integration.spec.js#answers the version the next writer must send
16 Limit writes require an inspected versionvalidationunitnegativetest
Proves
BR-CAP-PFM-LLM-013-04
Preconditions
The suite owns isolated fixtures representing the valid control and the contrasting case described by its steps.
Steps
Map a changed write without its version precondition and compare a valid versioned write.
Expected
The missing version is refused before the save.
Data
Suite-owned fixtures, with a fixed clock where dates or grant windows matter.
Bound to
Source
services-platform:modules/llm/tests/unit/aws/api/llm-usage-limits-api.spec.ts#is required, since a write with no claim would let a stale screen overwrite a change
17 Limit validation rejects undeclared operationsvalidationunitnegativetest
Proves
BR-CAP-PFM-LLM-013-03
Preconditions
The suite owns isolated fixtures representing the valid control and the contrasting case described by its steps.
Steps
Validate disabled-operation names against the declared catalog.
Expected
Undeclared names are refused before a configuration replacement.
Data
Suite-owned fixtures, with a fixed clock where dates or grant windows matter.
Bound to
Source
services-platform:modules/llm/tests/unit/services/tenant-limits.spec.ts#refuses an operation key the catalog does not declare, naming it
18 Disabled-operation failure maps to a conflictfailureunitnegativetest
Proves
BR-CAP-PFM-LLM-013-09
Preconditions
The operation-disabled error is constructed by the production refusal type.
Steps
Map the error through the shared response shaper.
Expected
The response is a conflict carrying the disabled-operation code; this experiment does not evaluate exemptions.
Data
A production disabled-operation error and a literal period snapshot.
Bound to
Source
services-platform:modules/llm/tests/unit/services/llm-operation-disabled.spec.ts#answers 409, because it holds until staff switch it back on and is neither a limit nor a failure

The Markdown files under specs/ in rhythmsoftware/rhythm-v2-docs are the canonical source of truth. This reader is a generated, read-only projection of them.

Rhythm Software