AI Requests, Usage and the Jazz AI Teammate

Purpose

This module brings together model requests, monthly capacity, usage inspection and AI control history. It also documents the Jazz AI console prototype. The specifications distinguish the shared Platform accounting path from prototype behavior that bypasses it.

Boundary

The module owns AI accounting and control records, operation definitions, reporting and diagnostic evidence. Query work, staff authority, notification transport, licensing and workspace lifecycle remain responsibilities of their owning modules. The charter metadata identifies those dependencies and the screens hosted elsewhere.

Features

Feature	Grouping
FEAT-PFM-LLM-01	Metered AI Requests
FEAT-PFM-LLM-02	AI Catalog and Pricing
FEAT-PFM-LLM-03	Monthly AI Allowance and Notices
FEAT-PFM-LLM-04	Rhythm HQ AI Usage Oversight
FEAT-PFM-LLM-05	Rhythm HQ AI Controls
FEAT-PFM-LLM-06	Organization AI Usage
FEAT-PFM-LLM-07	Jazz AI Conversations

Capabilities

Capability	Outcome	Product intent	Implementation evidence
CAP-PFM-LLM-001	Run AI requests with consistent attribution and accounting	proposed	observed
CAP-PFM-LLM-002	Bound AI conversations and handle recoverable failures	proposed	observed
CAP-PFM-LLM-003	Keep one account for a multi-request AI task	proposed	observed
CAP-PFM-LLM-004	Retain redacted AI evidence and remove it safely	proposed	observed
CAP-PFM-LLM-005	Publish AI operation definitions and historical prices	proposed	observed
CAP-PFM-LLM-006	Check AI behavior with scripted models and deliberate live runs	proposed	observed
CAP-PFM-LLM-007	Admit AI work against the organization’s monthly allowance	proposed	observed
CAP-PFM-LLM-008	Notify administrators at allowance thresholds	proposed	observed
CAP-PFM-LLM-009	Recover interrupted requests and identify accounting drift	proposed	observed
CAP-PFM-LLM-010	Monitor AI usage across organizations	proposed	observed
CAP-PFM-LLM-011	Inspect an organization’s AI account and request history	proposed	observed
CAP-PFM-LLM-012	Explain an AI refusal or unsuccessful conversation	proposed	observed
CAP-PFM-LLM-013	Set an organization’s AI access and recurring limits	proposed	partially-observed
CAP-PFM-LLM-014	Provide temporary AI capacity and revoke it	proposed	partially-observed
CAP-PFM-LLM-015	Correct an organization’s AI charges	proposed	partially-observed
CAP-PFM-LLM-016	Inspect captured AI content with a live access grant	proposed	partially-observed
CAP-PFM-LLM-017	Show administrators their organization’s AI allowance	proposed	partially-observed
CAP-PFM-LLM-018	Give people understandable AI refusal messages	proposed	observed
CAP-PFM-LLM-019	Use Jazz AI conversations and project folders	proposed	partially-observed
CAP-PFM-LLM-020	Refine queries and directory filters with Jazz AI	proposed	partially-observed

Journeys

Journey	Goal	Product intent	E2E policy
JNY-PFM-LLM-001	A staff member reaches the monthly AI allowance	proposed	required
JNY-PFM-LLM-002	Support investigates an AI refusal	proposed	required
JNY-PFM-LLM-003	A Rhythm administrator grants and withdraws temporary AI capacity	proposed	required
JNY-PFM-LLM-004	An administrator investigates an allowance warning	proposed	optional
JNY-PFM-LLM-005	A staff member refines a query and resumes its Jazz AI conversation	proposed	required

The examination report supplies the inventory mapping and outstanding proof obligations. Coverage means that an artifact addresses a source item; it does not mean that a complete customer journey has passed acceptance.

Test Hierarchy

Feature acceptance stays in planning, detailed capability proof lives in design and executable suites live in implementation. The testing tree names every artifact and its location. Results remain unexecuted, and the coverage findings preserve the missing experiments rather than claiming complete acceptance.