Keep one account for a multi-request AI task

Purpose

Group related model requests into a task whose outcome and total cost staff can inspect.

How It Works

A consuming feature opens an execution around the work it wants to account for. The wrapper supplies a context that associates its model requests with that execution. Each request still passes through normal admission and settlement. Settlements add to the execution’s counters as they become final. A refusal remains associated with the task without becoming a settled request count. The wrapper closes the task according to whether its work returns or throws. Reusing an idempotency key retrieves the prior execution without repeating the work. Recovery later identifies abandoned tasks and reports counter drift.

Relationships

Run AI requests with consistent attribution and accounting supplies the prerequisite behavior for this outcome.

Show evidence (sources, provenance, origins, pinned commits)

The Formal Contract

The narrative above explains; the sections below are authoritative — the rules, scenarios and tests this document binds.

Outcomes: A task aggregates its request counts and charges.An idempotency key prevents a duplicate task from running.Failed tasks retain charges from completed requests.
Surfaces: apijob
Preconditions: The execution key exists in the catalog.
Postconditions: The execution retains its final outcome and request totals.

Controls

24 controls apply, from the corpus control catalogue.

TC-AI-006 TC-AI-007 TC-AVL-001 TC-AVL-005 TC-AZ-001 TC-AZ-002 TC-AZ-003 TC-AZ-004 TC-IAM-001 TC-IAM-002 TC-IAM-004 TC-IAM-005 TC-LOG-004 TC-LOG-005 TC-PI-001 TC-PI-002 TC-PI-003 TC-PI-005 TC-TEN-001 TC-TEN-002 TC-TEN-003 TC-VEN-001 TC-VEN-002 TC-VEN-003

Business Rules

9 rules, 7 to be proved before approval. A rule's product intent is derived from its origin: 0 confirmed by a product decision, the rest inheriting this capability's proposed.

Id	Rule	Kind	Enforced at	Provenance
`01`must prove Proposed	The execution starts running before its first request and closes completed or failed with its completion time and elapsed duration. proved by `ATS-PFM-LLM-003-01`, `ATS-PFM-LLM-003-08`, `TST-PFM-LLM-018`, `TST-PFM-LLM-045`	lifecycle	service, database	observed services-platform:modules/llm/services/execution/with-llm-execution.ts
`02`must prove Proposed	Only the exact context supplied by the execution wrapper associates a request with it; outside or derived contexts carry no execution association. proved by `ATS-PFM-LLM-003-02`, `TST-PFM-LLM-018`	invariant	service	observed services-platform:modules/llm/services/execution/execution-scope.ts
`03`must prove Proposed	Opening a nested execution is rejected and makes the enclosing execution fail. proved by `ATS-PFM-LLM-003-03`, `TST-PFM-LLM-018`	validation	service	observed services-platform:modules/llm/services/execution/with-llm-execution.ts
`04`must prove Proposed	An unknown execution key is rejected before creating a record, and duplicate keys, unknown applications or empty features invalidate publication. proved by `ATS-PFM-LLM-003-04`, `TST-PFM-LLM-018`, `TST-PFM-LLM-057`	validation	service	observed services-platform:modules/llm/catalog/llm-executions.ts
`05`must prove Proposed	Request settlement atomically adds one request and its credits and cents to the execution; estimated settlement adds no cents, released settlement adds no cost, refusals add no settlement count, and late settlements still contribute. proved by `ATS-PFM-LLM-001-12`, `ATS-PFM-LLM-003-05`, `ATS-PFM-LLM-003-09`, `ATS-PFM-LLM-003-11`, `TST-PFM-LLM-018`, `TST-PFM-LLM-032`	calculation	service, database	observed services-platform:modules/llm/services/persistence/invocations.ts
`06`must prove Proposed	Reusing an organization’s execution idempotency key returns the earlier running or closed execution as a replay without invoking the task again. proved by `ATS-PFM-LLM-003-06`, `ATS-PFM-LLM-003-10`, `TST-PFM-LLM-012`, `TST-PFM-LLM-018`	policy	service, database	observed services-platform:modules/llm/services/execution/with-llm-execution.ts
`07` Proposed	The execution retains its declared identity, application, feature, caller attribution and any subject record.	invariant	service	test services-platform:modules/llm/tests/integration/lifecycle/executions.integration.spec.js#records the declared key, the attribution and the subject
`08` Proposed	A settlement log identifies its enclosing execution when one exists and leaves that association absent otherwise.	policy	service	test services-platform:modules/llm/tests/integration/lifecycle/executions.integration.spec.js#carries the execution id on the call made inside the execution
`09`must prove Proposed	A task failure remains the caller’s error even if closing its execution also fails; that close failure is logged. After successful task work, a close failure is returned to the caller. proved by `ATS-PFM-LLM-003-07`	lifecycle	service	observed services-platform:modules/llm/services/execution/with-llm-execution.ts:withLlmExecution

Scenarios

Id	Given	When	Then	Provenance
`01`	A task performs three requests.	The task finishes successfully.	Its execution records their count and summed charges.	test services-platform:modules/llm/tests/integration/lifecycle/executions.integration.spec.js#charges the period exactly what the execution totalled
`02`	A task fails after two completed requests.	The failure closes the execution.	The failed task retains those request charges and its elapsed time.	test services-platform:modules/llm/tests/integration/lifecycle/executions.integration.spec.js#keeps the credits those two calls were charged

Planning

Implementation

Keep one account for a multi-request AI task ​

Purpose ​

How It Works ​

Relationships ​