The narrative above explains; the sections below are authoritative — the rules, scenarios and tests this document binds.
| # | Surface | Action | Capability | Expected | Provenance |
|---|---|---|---|---|---|
| 1 | /console/{tenantId}/queries/new | Submit an AI request with allowance available. | CAP-PFM-LLM-001 | The scripted request is charged and remains below the warning threshold. | test services-platform:modules/llm/tests/e2e/allowance-warning.e2e.spec.js#says nothing while the first call leaves the organization under 80 % |
| 2 | /console/{tenantId}/queries/new | Make another request that crosses the warning threshold. | CAP-PFM-LLM-008 | Both administrators receive a warning with usage and reset information. | test services-platform:modules/llm/tests/e2e/allowance-warning.e2e.spec.js#tells each of the two administrators once when the second call passes 80 % |
| 3 | /console/{tenantId}/queries/new | Make a request that crosses the full allowance. | CAP-PFM-LLM-007 | The admitted request finishes and is charged; administrators receive the pause notice. | test services-platform:modules/llm/tests/e2e/allowance-warning.e2e.spec.js#tells both again, once, when the third call passes 100 % |
| 4 | /console/{tenantId}/queries/new | Try another AI request. | CAP-PFM-LLM-018 | Admission stops before provider dispatch and returns the allowance explanation. | test services-platform:modules/llm/tests/e2e/allowance-warning.e2e.spec.js#refuses the next call, because the allowance is used |
| 5 | /hq/aiUsage/requests/{tenantId}/{invocationId} | Ask Rhythm support to inspect the refusal. | CAP-PFM-LLM-011 | The request directory provides the refusal reason and the admission figures. | documented services-platform:docs/milestones/plans/PLAT-M1-plan.md#9. Acceptance scenarios |
| Path | From step | Condition | Path taken | Outcome | Provenance |
|---|---|---|---|---|---|
| alternate | 4 | Support grants temporary capacity. | A request within the grant window can pass admission. | The person resumes using AI before the monthly reset. | test services-platform:modules/llm/tests/integration/services/overrides/allowance-overrides.integration.spec.js#lets the ledger admit a call the base alone would refuse |
| failure | 2 | The workspace has no administrator. | The notice is marked complete without recipients. | The organization receives no warning. | test services-platform:modules/llm/tests/integration/services/notices/threshold-notice.integration.spec.js#stamps the crossing notified with zero recipients |
| failure | 4 | The next request needs more capacity than remains. | Admission refuses it even though the usage summary is still warned. | The distinction between remaining credits and affordable requests needs a product decision. | documented services-platform:docs/milestones/plans/PLAT-M1-plan.md#D1. When is an organization's allowance "used up"? |
| Id | Statement | Provenance |
|---|---|---|
01 | In the tested sequence, administrators receive warning and pause notices while other staff receive neither. | test services-platform:modules/llm/tests/e2e/allowance-warning.e2e.spec.js#never tells a person who is not an administrator |
02 | The request made after capacity runs out is refused with no charge. | test services-platform:modules/llm/tests/e2e/allowance-warning.e2e.spec.js#refuses the next call, because the allowance is used |
03 | The proposed support walkthrough includes locating the refusal and its reason. | documented services-platform:docs/milestones/plans/PLAT-M1-plan.md#9. Acceptance scenarios |
End-to-end policy: required: A complete browser walkthrough must connect the query screen, delivered mail and support inspection. The available scripted test does not prove that whole path.