---
id: ADR-PFM-LLM-002
title: Record Before Admission and Reserve With One Conditional Update
product_area: platform
module: llm
revision: 1
status: proposed
design_intent: proposed
source_sha:
  services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1
  react-console: baf6dae382d6f41dce976c7f848667ccc37e076f
decision: >-
  Create the request before reserving its estimate and running slot through the conditional monthly update;
  treat the current reservation sizing policy as proposed.
constrains:
  - DOM-PFM-LLM-001
  - DOM-PFM-LLM-003
  - WF-PFM-LLM-001
  - STATE-PFM-LLM-001
  - SVC-PFM-LLM-llm
origin: >-
  The foundation design, section 4.4 Accounting Rules, in the work plan approved by Andrew 2026-10-10 and
  accepted 2026-10-12 (services-platform:docs/llm/llm-foundation-and-generate-query.md#4.4 Accounting Rules);
  the in-flight cap of eight by D-6
  (services-platform:docs/proposals/llm-observability/11-decisions.md#Decision record).
alternatives:
  - option: Reserve only a typical conversation cost
    why_not: >-
      It admits work before its full configured reservation is covered and can reveal overspend only after
      usage.
  - option: Check balance before a separate unconditional hold
    why_not: Competing readers can each accept capacity that only one request can consume.
  - option: Create bookkeeping after holding credits
    why_not: Interruption can leave a hold with no request record to inspect.
  - option: Add a daily spending budget
    why_not: The existing throttling decision avoids another budget period and its effect on legitimate batch work.
consequences:
  - The hold predicate serializes competing admissions under current capacity.
  - Reservation size can cause refusal before displayed usage is exhausted.
  - Holding credits and recording their amount remain separate transactions.
  - Allowance refusal takes precedence when both allowance and concurrency predicates fail.
supersedes: []
evidence:
  - >-
    services-platform at ad3f6a6: modules/llm/services/persistence/allowance-periods.ts (authorizeCredits);
    services/execution/run-operation.ts; services/metering/llm-credit-ledger.ts;
    tests/integration/lifecycle/llm-ledger-concurrency.integration.spec.js.
---

# Record Before Admission and Reserve With One Conditional Update

## Context

Concurrent staff and jobs can request model work against the same organization’s capacity.

## Decision

Create the request before reserving its estimate and running slot through the conditional monthly update; treat the current reservation sizing policy as proposed.

## Alternatives Considered

Reserve only a typical conversation cost: It admits work before its full configured reservation is covered and can reveal overspend only after usage.

Check balance before a separate unconditional hold: Competing readers can each accept capacity that only one request can consume.

Create bookkeeping after holding credits: Interruption can leave a hold with no request record to inspect.

Add a daily spending budget: The existing throttling decision avoids another budget period and its effect on legitimate batch work.

## Consequences

The hold predicate serializes competing admissions under current capacity. Reservation size can cause refusal before displayed usage is exhausted. Holding credits and recording their amount remain separate transactions. Allowance refusal takes precedence when both allowance and concurrency predicates fail.