Pulse: Real-Time Online Charging for AI Services

1.1. Motivation

Providers and resellers of mass-market AI services cannot today guarantee that an individual subscriber will not overspend, nor apply a hard per-subscriber budget. Pulse provides that guarantee the way telecom charging does: no chargeable work proceeds without a prior authorisation carrying a budget, and all consumption is reported back and settled against it.¶

1.2. Relationship to Diameter Credit-Control

Pulse is not a Diameter application, but deliberately reuses proven Diameter Credit-Control concepts from [RFC4006]: session-based credit control with granted quota (here: the grant), reporting of used units, and credit pooling — a single abstract unit pool with per-unit-type multipliers (Section 6.3), mirroring the Diameter G-S-U-Pool-Reference mechanism. [RFC8506], which obsoletes [RFC4006], is the current specification. The name reflects the protocol's own rhythm — supervision happens on a regular pulse of reports (heartbeat reports, reporting cadence, settlement cycles).¶

1.3. Scope

This memo specifies the charging plane only: the two operations, their semantics, timing, idempotency, errors, and security requirements. The management plane (tenant onboarding, plan authoring, subscriber provisioning, credential administration, reporting) is a separate surface and is out of scope here.¶

1.4. Version-1 scope and deferred items (named)

Version 1 targets bounded synchronous and streaming Actions operated against one logical charging domain per tenant; an Action MUST be operated against the domain that opened it, and HTTP redirection (3xx) is not used. Quiet periods inside an Action are covered by heartbeat reports (Section 7.1). The following are deliberately deferred, not accidentally missing — each is named so an implementer never mistakes silence for support:¶

• Batch / asynchronous work (a result returning hours later) has no contract in version 1.¶

• Cross-region failover semantics (retrying against a different charging domain).¶

• Pre-grants / bulk authorisation for latency amortisation (Section 13.5 states version 1's posture).¶

• Multi-Action batch reporting / multiplexed transport (Section 13.5).¶

• An interoperable call-signature profile (Section 7.2 — the field is reserved).¶

• The unit-vocabulary catalogue contract (distribution of Action-Type unit definitions is a management-plane artefact; version 1 assumes out-of-band onboarding).¶

• Serving-system provenance (which model or system actually served an Action — a self-attested, evidence-only telemetry block on reports). No version-1 contract; its design belongs with the reference-model phase, alongside the evidence-grade question any self-attested provenance raises.¶

• A single owner's cap across several of its own operators — one company operating multiple tenants under a jurisdiction-mandated joint bound (the shape of, e.g., German gambling regulation). In version 1 a relation-scoped bound ranges within one tenant (Section 12.1); a cross-tenant bound has no contract.¶

3.1. Message flow

Gateway                                   Charging Server
   |                                             |
   |--- POST /ocs/ai/v1/authorizations --------->|   Authorise: may
   |<-- GRANT {grantId, grantedUnits,            |   this Action
   |           reportAt, expiresAt, unitWeights} |   proceed, and on
   |                                             |   what budget?
   |    (gateway serves AI calls, metering       |
   |     consumption against the granted pool)   |
   |                                             |
   |--- POST /ocs/ai/v1/grants/{id}/reports ---->|   Report: usage
   |<-- CONTINUE {next grant}   or               |   so far. Settle
   |    STOP {stopReason}       or               |   and re-grant,
   |    SETTLED                                  |   stop, or settle
   |                                             |   finally.
   |    ... repeat cycles until an ending ...    |

An Action opens with exactly one successful Authorise and ends exactly once (CLOSE, STOP, or LAPSE). Between opening and ending, the gateway reports at the server-stated thresholds and the server answers each report with the next directive.¶

3.2. The two-message contract

The protocol is deliberately two messages and no more:¶

1. Authorise — the client asks; the server answers GRANT or REFUSE. A refusal means no chargeable work may proceed; a grant means work up to the granted pool may proceed.¶

2. Report — the client reports cumulative consumption; the server settles and answers CONTINUE (with the next grant), STOP (a stop obligation: the client MUST cease serving the Action's traffic promptly), or SETTLED (final settlement acknowledged).¶

There is no server-initiated push channel in version 1. The stop obligation is delivered on the response to a report; grant lapse (expiresAt) bounds how long an unreported Action can run.¶

3.3. Flat-priced Actions

An Action whose type is flat-priced settles at open: the Authorise response carries decision: GRANT with settled: true and a grantId for correlation, and no reports are expected. A flat Action ends at authorisation — its ending is CLOSE, its endedAt is the response's serverTime, and its late window anchors there. Its envelope therefore carries actionLive: false with terminal generation 2 — which is correct and does not countermand the work: the settled GRANT itself is the complete authorisation for the flat Action's work (Section 2, Envelope). The opening settlement carries a receipt of settlementId alone (no units existed to accept). A Report addressed to its grantId never settles — an identity match replays; anything else receives the terminal directive, with unattributable: true if units were carried (Section 3.5). The report-borne controls (call limits, runtime, signatures, inflation) do not apply to flat Actions by construction — their controls are the authorisation-time checks (Section 6.2). All other price forms follow the report lifecycle.¶

3.4. Division of responsibility

• The client admits Calls; the server settles money. The client MUST NOT knowingly serve consumption beyond the granted pool (checking each next Call against the remaining pool, which it can compute from grantedUnits and unitWeights, is the expected mechanism) and MUST report when the reportAt threshold is crossed. The server clamps every settlement at the reported meter and at the Action's ceiling; overshoot exposure is bounded to one final report. The permitted tail: consumption whose serving began before the report was dispatched may complete under the old grant and is settled on the next cycle.¶

• The server's clock is authoritative for lapse boundaries and time-band selection. A client MUST NOT assume its own clock decides either.¶

• One in-flight Report per Action. The client MUST serialise its Reports: at most one Report (including its retries) is outstanding per Action at any time, and while a Report is outstanding the client MUST NOT admit new Calls — work already begun (the tail, first bullet above) completes. The server's convergence rules (Section 3.5) remain the safety net for the distributed-gateway case where two workers overlap despite this rule.¶

3.5. The Action state machine (normative)

This section is the authority for every exchange; the prose of Section 6 and Section 7 restates it and never overrides it.¶

The gates — evaluated before the table, in this order, each state-neutral (Section 13.1) and carrying no Action-state envelope: transport (wrong method → 405, wrong content type → 415) → authentication (401) → gateway ownership (403 — including a parentActionId owned by another gateway, Section 9) → rate limiting (429) → parse and validation (400 — Section 4.3, Section 4.4, Section 5) → identity resolution (404 — an unknown actionId or grantId, or a path grantId that does not belong to the body's Action). Only a request that passes every gate reaches the table.¶

Row evaluation: within a state, rows are evaluated in the listed order and the first matching row applies — the table is a function from (state, input) to one outcome.¶

States: NONE (the actionId is unclaimed) · LIVE(Gn) (open; one current grant, generation n) · ENDED(e) (ended as e ∈ {CLOSE, STOP, LAPSE}; recognised) · FORGOTTEN. A flat-priced Action passes through LIVE for zero time: a successful flat Authorise opens and ends it (ENDED(CLOSE)) in one transition. Generations: every stored outcome mints a generation (grantSeq/outcome generation, strictly +1) — cycles, the terminal transition, and late adjustments alike — so envelope ordering (Section 6.3) and receipt ordering (Section 7.3) are total, and terminal state is sticky (actionLive never returns to true).¶

In state NONE (a Report cannot reach NONE — the identity gate returns 404):¶

In state LIVE(Gn):¶

In state ENDED(e) (while recognised):¶

The terminal directive applies to every ENDED-state response except row 3's verbatim replays, and is a pure function of the ending: CLOSE → SETTLED · STOP → STOP with the original stopReason (and limitOwner where it applied) · LAPSE → STOP (LAPSED) — always with endedAt. The ENDED envelope: currentGrantSeq = the latest outcome generation; currentGrantId = the last issued grant's id (the address late reports use). A flat Action: generation 2 and the settled grant's id.¶

Arbitration: processing is serialised; the applicable rules are those of the state at processing time. The "final beats stop" precedence (Section 7.5) applies to conditions evaluated within one report's processing — never to transitions that already committed: a final report processed after an ending is late handling under the terminal directive.¶

Retention (uniform): the terminal outcome plus the last 4 non-terminal outcomes (cycles and late adjustments share the ring), each carrying its generation. A retry whose outcome has aged out takes its state's no-match row — safe by construction (Section 7.2's absorption), though its original settlementId is then no longer re-presentable (Section 7.6). Recognition (duplicate detection and the terminal directive) is unconditional until max(endedAt + 24 h, expiresAt + 1 h) — an unseen asynchronous stop can never outlive the window of the grant that hid it.¶

When recognition ends: ENDED → FORGOTTEN — the identity is discarded. Reports → 404, unattributable (Section 7.6); an Authorise on the id is evaluated fresh (this is the documented reopen residual of Section 6.5).¶

4.1. Endpoints

Requests and responses are application/json bodies, in the JSON format of [RFC8259], carried over HTTP [RFC9110] on TLS. TLS 1.2 [RFC5246] or later is REQUIRED (TLS 1.3 [RFC8446] RECOMMENDED; configuration per [RFC9325]); plaintext HTTP MUST be refused. A non-POST method on these paths → 405; a non-JSON content type → 415. These two paths are the only public charging surface.¶

4.2. Authentication

Every request MUST carry a per-gateway bearer API key (Authorization: Bearer …). Keys are issued per gateway, support dual-active rotation, and are revocable with effect within seconds. Mutual TLS is a deployment option. OAuth2 client-credentials is planned for a later protocol version and is not part of version 1.¶

4.3. Encoding rules and JSON types (normative)

Every field has exactly one JSON type; a value of the wrong type is malformed (MALFORMED_REQUEST / MALFORMED_REPORT):¶

• Decimal quantities — unit quantities, estimate values, grantedUnits, reportAt values, unitWeights, quantumUnits, minRate, and every other decimal — are JSON strings in canonical decimal rendering: plain notation, no exponent, no trailing zeros, no trailing decimal point, no leading zeros (a bare 0 integer part is the only zero prefix), no leading +, no -0, non-negative unless stated otherwise, scale ≤ 6. Exactly one spelling of every value is valid; any other spelling is malformed — there is no equivalence class of spellings anywhere in this protocol. (JSON numbers are IEEE-754 doubles and cannot carry scale-6 decimals faithfully; single-spelling strings also make canonicalization exact, Section 6.5.) Money never appears on this wire (Section 15.7).¶

• Identifiers (actionId, callId, grantId, currentGrantId, parentActionId, tenantRef, accountRef, actionType, scope, timeBandId, settlementId): JSON strings, ≤ 128 characters from [A-Za-z0-9._:-].¶

• Display labels (limitOwner): UTF-8 JSON strings, ≤ 64 characters of printable text — no control or bidirectional-control characters; clients render them as plain text, never as markup. Presentation text declared with the relation, not an identifier.¶

• Unit-type names (map keys in estimate, units, unitWeights, receipt maps): strings matching [a-z0-9_]{1,64}.¶

• Timestamps (expiresAt, serverTime, grantIssuedAt, endedAt, gatewayTime): JSON strings in the [RFC3339] profile YYYY-MM-DDThh:mm:ss.sssZ — uppercase T and Z, exactly three fractional digits, years 1970–9999, no leap seconds.¶

• Counts and versions (schemaVersion, maxSchemaVersion, grantSeq, currentGrantSeq, lawVersion, retryAfter, maxCallsPerAction, maxRuntimeSec, maxConcurrentActions, enforcementWindowSec): JSON integers ≥ 0 and < 2⁵³.¶

• Numeric domains (closed under the arithmetic): request quantities lie in [0, 10^9] and weights in [0, 10^6], scale ≤ 6; derived pooled quantities (grantedUnits, reportAt, quantumUnits, cyclePooledUnits, baselineCumulative/meterCumulative pooled values) have their own domain [0, 10¹⁷), scale ≤ 6 — closed under 16 unit types × 10⁹ × 10⁶. Response maps are bounded by the 16-unit-type limit; acceptedCalls by the 256-entry limit. The 10⁹ per-unit-per-Call cap is a hard operational bound: a gateway MUST terminate or segment work before any Call's cumulative value reaches it — it is not merely a parser limit.¶

• Flags (final, settled, retryable, rateReduced, adjustment, clamped, actionLive, unattributable, signaturesRequired): JSON booleans.¶

• Maps: JSON objects whose keys are unit-type names and whose values are decimal strings as above.¶

• Duplicate JSON keys anywhere in a body are malformed.¶

4.4. Limits (normative)

6.1. Request

6.2. Processing

The server resolves the subscriber, verifies tenancy (Section 15), selects the price entry for the declared Action Type from the subscriber's plan (pinning the plan version — the Action is rated under that law for its entire life), resolves the applicable time band if the type is banded (Section 10). It then verifies budget headroom (the opening reservation covers the estimated charge, any contractual minimum, and rounding), verifies the shared bounds (any sponsor cap and the applicable capacity pool, Section 12), applies the trust limits (Section 15.4), and answers.¶

6.3. Response — GRANT

Grant invariants (normative): every issued grant satisfies grantedUnits > 0, 0 < reportAt ≤ grantedUnits, quantumUnits > 0 where present, expiresAt > grantIssuedAt, and reachability: reportAt MUST be attainable within the Action's cumulative caps under the grant's weights. A response violating them is a server defect; the client treats it as a 5xx-equivalent and retries the identical request.¶

6.4. Response — REFUSE

refusalReason registry (version 1):¶

Every refusal additionally carries:¶

Version-1 grades: NO_CAPACITY and PREEMPTED are BOUNDED; SERVICE_BARRED and DRAINING are ATTESTED; every other reason is PROVEN.¶

A refusal is a complete outcome: no budget is held, nothing is charged, and the client MUST NOT serve the work. A refusal retains no identity: no Action opens, the actionId remains unclaimed, and any later Authorise carrying it — identical or different — is evaluated fresh. DUPLICATE_ACTION applies only against Actions that actually opened. Concurrent identical Authorises are serialised per subscriber; if one opens the Action, the other lands on live-Action replay (Section 6.5).¶

6.5. Idempotency, request identity, and identifier scopes

Request identity is SHA-256 over the JSON Canonicalization Scheme (JCS) [RFC8785] canonicalization of the strict-parsed request body (duplicate or unknown members are rejected before hashing, Section 5); for Reports, the path grantId is appended to the canonical bytes before hashing. Because every decimal travels as a canonical string (Section 4.3), JCS needs no number-rendering caveats. Two requests with equal canonical form are the same request. Test vectors accompany the conformance suite.¶

Identifier scopes: actionId is unique within its (tenant, account) pair — two tenants can never collide; callId is unique within its Action; grantId is server-issued, opaque, and unique within the charging domain. Server recognition retention is the late window (Section 7.6).¶

Authorise always answers in the Authorise shape — a replay re-presents facts, it never returns a stored Report body:¶

• Retry of a live Action (same actionId, matching identity) → decision: GRANT re-presenting the current standing grant (current grantSeq and parameters) plus its cycle-baseline receipt (acceptedCumulative at the settlement that issued it), so a restarted gateway recovers both the address and the remaining pool — with a fresh envelope.¶

• Retry of an ended Action within the late window (matching identity) → an Authorise-shaped terminal acknowledgement: decision: GRANT, settled where applicable, the ending, endedAt, and the final receipt; a flat-priced Action's retry re-receives GRANT/settled: true, never a refusal.¶

• Same actionId as an opened Action, different identity → 200 REFUSE / DUPLICATE_ACTION (a charging refusal like any other — identity conflicts are not HTTP errors).¶

• An actionId that opened an Action is never legally reusable, including after the Action ends. Beyond the late window the server no longer guarantees replay; a client MUST NOT rely on replay after it.¶

Clients MUST serialise a retry as the identical logical request: JCS removes JSON key-order differences, and nothing else — there is no equivalence class of spellings (Section 4.3 admits exactly one spelling of every value; any other is malformed before identity is ever computed). Any byte difference that survives canonicalization is a different request.¶

7.1. Request

7.2. Cumulative semantics (normative)

Each calls[] entry is {callId, units, startedAt?, signature?} where units is a map of unit type → cumulative total for that Call since the Call began — not a delta; values are canonical decimal strings (Section 4.3). calls[] is a keyed patch, not a snapshot: only Calls with changed totals need appear; an omitted callId reads as unchanged; a callId never seen before initialises all its declared units at zero baseline; two entries with the same callId in one request are malformed. The calls-per-Action limit counts distinct callIds over the Action's life. Unit keys MUST be among those declared by the pinned Action Type (undeclared keys are malformed); declared keys absent from an entry read as unchanged. signature is reserved in version 1: an opaque string, recorded verbatim. Its verification profile is bilateral and out of band, and SIGNATURES_REQUIRED (Section 7.4) applies only where such a profile is agreed. startedAt (version 1.1, Section 5) is OPTIONAL evidence: the instant the Call began at the serving system (timestamp, Section 4.3). Like gatewayTime it is recorded and never enforced against (Section 15.6), and it can never re-price anything — the Action's time band is pinned at open (Section 10), so no client-reported timestamp changes a charge. Its value is that the moment consumption occurred, not merely the moment it was reported, survives into the audit record. It SHOULD carry the same value on every entry for a given callId; the server retains it under the audit retention rules (Section 15.7).¶

Monotonicity and out-of-order delivery: a reported value lower than the server's stored high-water for that Call and unit is absorbed: the meter is the per-value maximum, so a stale, reordered, or replayed report charges zero and is never an error — this is what makes the arithmetic immune to retries, duplicates, and delivery order. (Within one request there is no shrinking case to define: duplicate callId entries are malformed outright.)¶

Cumulative reporting is what makes the protocol retry-safe: a replayed report or replayed call entry moves the cumulative meter by zero and therefore charges zero. The server settles each cycle as the increment of the rated cumulative consumption under the pinned law — never rating the same consumption twice, for any price form.¶

Pool arithmetic (normative — one cumulative pipeline, cadence-independent): everything is computed on Action-cumulative quantities, and every charge or threshold is a delta of cumulatives — never a rounded delta. Per unit type u: cumulativePooled_u = HALF_UP₆(weight_u × cumulativeTotal_u); the Action's pooled total is the exact sum over unit types. For quantised forms, blocks apply to that cumulative pooled total — blocksCharged = ceil(cumulativePooled / quantumUnits) — and each cycle charges the newly completed blocks (the cumulative-rated rule). reportAt and pool exhaustion compare raw (unquantised) pooled-total deltas against the cycle baseline. Because rounding and quantisation are applied only to cumulative values, report segmentation provably cannot change any charge.¶

7.3. Response

This distributed-worker convergence flow is illustrative; it does not relax the one-in-flight requirement of Section 3.4. The CURRENT branch shown is the no-ending-condition branch of Section 3.5 LIVE row 6:¶

Gateway worker A   Charging Server      Gateway worker B
    |                     |                     |
    |--- Report on G1 --->|                     |
    |<-- CONTINUE G2 -----|                     |
    |                     |<-- stale non-final -|
    |                     |    G1; no retained- |
    |                     |    id match         |
    |                     | max-merge meter;    |
    |                     | evaluate ending     |
    |                     | conditions          |
    |                     |--- CURRENT G2 + --->|
    |                     |    baseline +       |
    |                     |    post-merge meter |
    |                     |    no settlement,   |
    |                     |    no mint          |
    |                     |                     | B resynchronizes

Cycle baseline (normative): grantedUnits and reportAt are cycle-scoped, and the baseline is a meter state, not an instant: a cycle's consumption is the weighted pooled delta (Section 7.2 arithmetic) between the accepted meter at the settlement that issued the grant — the acceptedCumulative of that response; zero for the first grant — and the current meter. Both sides can compute it exactly: the client from its last receipt, the server from its stored meter. Report values remain Action-cumulative (Section 7.2). Tail consumption lands in whichever cycle's report first carries it — the cumulative arithmetic makes double-counting impossible.¶

Settlement receipt: every settling response (CONTINUE, STOP, SETTLED) carries settlementId (stable per settlement; a replay returns the same id), acceptedCumulative (the server's post-merge Action totals — a complete map over the declared unit types), acceptedCalls (an array of {callId, units} entries — the per-call accepted cumulative values for exactly the Calls present in this request, ≤ 256 entries), and cyclePooledUnits (the raw pooled delta settled this cycle, pre-quantisation), plus where applicable clamped: true (limited by the meter or a ceiling) and adjustment: true (a late settlement). A client holding several receipts trusts the one from the highest-generation outcome. Receipts are denominated in units only — no balance, price, or currency ever crosses this wire.¶

Response replay and convergence: governed entirely by the state machine (Section 3.5) — the server serialises all of one Action's operations; only a fresh Report on the current grant runs a cycle and mints; identity-matched retries replay their stored outcome under a fresh envelope; non-matching reports converge (a final: true close is always honoured against the current state; non-final ones max-merge and answer CURRENT); retention is the terminal outcome plus the last 4 non-terminal outcomes — an aged retry converges safely, though its original settlementId is then no longer re-presentable (Section 7.6). A lost CONTINUE is therefore always recoverable: retry the identical request (replay), or report against currentGrantId from any response's envelope. acceptedCalls appears on Report responses only.¶

The lost-response path below illustrates the request identity and replay rules of Section 6.5 and this section. R includes the Report body and its path grantId; S is the stable settlement receipt. The retry remains the same logical Report for Section 3.4:¶

Gateway                          Charging Server
   |                                    |
   |--- Report R against current Gn --->|
   |                                    | merge, settle, and
   |                                    | atomically store
   |                                    | CONTINUE G(n+1) + S
   |<-- CONTINUE G(n+1) + receipt S --X |  response lost
   |                                    |
   |--- identical retry of R ---------->|
   |                                    | retained identity
   |                                    | matches
   |<-- stored CONTINUE + receipt S ----|  body replay; fresh
   |                                    |  envelope; no
   |                                    |  settlement, no mint

7.4. stopReason registry (version 1)

Precedence (normative): final: true beats every server stop condition → SETTLED (Section 7.5), draining included. For a non-final report on which several stop conditions hold at once, the reported stopReason is the first that applies in this order: ADMIN_FORCED · DRAINING · PARENT_STOPPED · LAPSED · CEILING_REACHED · EXPOSURE_CAP · NO_HEADROOM · CALL_LIMIT · MAX_RUNTIME · INFLATION · SIGNATURES_REQUIRED · NO_CAPACITY — and the stored terminal outcome records that same reason, so replays agree.¶

7.5. Lapse boundary (normative)

With now being the server clock at processing:¶

• now < expiresAt → normal processing; CONTINUE is possible.¶

• expiresAt ≤ now < expiresAt + 5 s → the report is accepted as the closing report: consumption is settled and the directive is SETTLED when final: true, else STOP (LAPSED) — never CONTINUE.¶

• now ≥ expiresAt + 5 s → the Action is ended as LAPSE (if it wasn't already — the transition instant is the same either way, Section 3.5) and the report is processed as a late report (Section 7.6).¶

The following diagram illustrates those branches; Section 3.5 and the rules above remain authoritative, including the stored-outcome replay exception:¶

Gateway                      Charging Server (`now`)
   |                                    |
   |--- Report ------------------------>|
   |                                    +-- now < expiresAt
   |                                    |   normal processing;
   |                                    |   CONTINUE is possible
   |                                    |
   |                                    +-- expiresAt <= now
   |                                    |   < expiresAt + 5 s
   |                                    |   final=true: SETTLED
   |                                    |   final=false:
   |                                    |   STOP (LAPSED)
   |                                    |
   |                                    `-- now >= expiresAt + 5 s
   |                                        ENDED(LAPSE), with
   |                                        endedAt=expiresAt+5 s;
   |<-- response under selected branch --    late handling
   |                                        (section 7.6)

Precedence: on a final: true report, the client's close wins over any concurrent server stop condition — the response is SETTLED (the stop obligation is moot once the client has ended the Action). A late report can never revive a grant. A client that wants to continue past expiresAt MUST have reported before it.¶

The LAPSE instant (normative): an Action that ends as LAPSE has endedAt = expiresAt + 5 s — by definition, whether the ending is physically performed by a timer, a sweep, or the first post-grace report. Both sides can compute the late window's anchor from the grant alone. CLOSE and STOP endings record their processing instant as endedAt.¶

7.6. Late reports and the late window

While recognised — until max(endedAt + 24 h, expiresAt + 1 h) (Section 3.5; endedAt is carried on every terminal response) — the server:¶

• MUST retain recognition: replay of stored responses to recognised retries (matching request identity) and duplicate-actionId detection are unconditional for the full window — this guarantee does not degrade.¶

• Settles genuinely new consumption reported late: the cumulative meters are merged upward, and the increment of rated consumption — floored at zero, clamped by the remaining ceiling — is charged under the Action's pinned law and returned with the ending's terminal directive (Section 3.5), adjustment: true, and a receipt (Section 7.3). Contractual minimums are never applied a second time. Repeated late reports charge each unit at most once. Late-settlement capability (unlike recognition) is best-effort under extreme retention pressure — an exceptional, server-metered condition; a late report the server recognises but can no longer settle is answered with the stored terminal outcome plus unattributable: true and no new settlementId — the response says plainly that the new units were not settled (they are recorded unattributable). A non-matching terminal report whose merge adds zero receives the terminal outcome with the current receipt and no adjustment flag.¶

Beyond the late window, reports against unknown identities receive 404 and the traffic is recorded as unattributable — recorded, never charged.¶

7.7. Reporting cadence requirements

A client MUST report when the cycle's pooled consumption delta reaches reportAt (comparator: ≥), and SHOULD report promptly on its own initiative when an Action ends client-side (with final: true). Batching beyond reportAt increases the client's overshoot exposure, which the protocol bounds to one final report but does not eliminate.¶

On receiving STOP, the client MUST stop admitting new Calls immediately, SHOULD cancel cancellable in-flight work, and MUST flush the final meter — dispatching the first flush report within 30 seconds (a hard per-event deadline, distinct from the statistical promptness profile of Section 12.4); when more than 256 Calls changed, the flush spans serialised 256-call chunks continued back-to-back. The flush obligation fires once per ending: a STOP directive received in response to the flush itself, a replay, or a late response does not re-trigger it. Uncancellable work may complete, and its consumption reports late (Section 7.6).¶

8.1. Protocol constants and configurables

This table is a descriptive index to the defining prose, not a second source of rules. Where a value is a recommendation or a configured value, the table says so; where two statements are not fully harmonised, it preserves both without choosing between them. "Deployment-configurable" includes plan-, catalogue-, integration-, client-, and server-policy values.¶

Fixed in protocol.¶

Deployment-configurable.¶

No row defines an Action boundary: the protocol does not define what constitutes one Action — the actionId is asserted by the application originating the work (Section 6.1). No row exposes a monetary amount (Section 15.7).¶

12.1. Sponsor caps

A sponsoring party (typically a reseller funding an AI benefit) MAY declare an aggregate spend bound across a population of subscribers. It is enforced at authorisation and at each cycle like any other headroom check. Its refusals and stops are attributed: EXPOSURE_CAP always carries limitOwner, and a client MUST surface the distinction to the end user — from a single account's viewpoint the sponsor's cap and the user's own limit are otherwise indistinguishable, and telling a user their own money ran out when the sponsor's did is untrue.¶

The cap's accounting basis is exposure — credits committed to open grants plus credits settled, per sponsor relation; an open grant is spend the sponsor is already standing behind, so a cap that counted settled spend alone could be overshot by in-flight work. The bound is declared per period: the accounting window (a calendar month, a rolling interval) is part of the sponsor's declaration, not a protocol constant, and is disclosed to the sponsor and its members out of band — the wire carries only the refusals and stops the cap produces. Exact period-boundary mechanics (the reset instant, the treatment of exposure spanning the boundary) are deployment-profile in version 1, pending the same trace validation as Section 12.2 to Section 12.4.¶

12.2. Capacity pools

A tenant MAY declare provisioned serving capacity — a rate — that named Action Types draw on. Admission then answers two questions: may this be paid for, and can it be served. A grant is a rate authorisation: its rate is grantedUnits over the interval from grantIssuedAt to expiresAt — so capacity enforcement changes grant sizing, not the message set. When a pool cannot admit at or above the declared minimum rate, authorisation refuses NO_CAPACITY — always retryable with retryAfter — graded BOUNDED, because capacity keeps no ledger. Capacity refusals say something about the service's provisioned room, never about the customer's money; clients MUST NOT render them as balance problems.¶

Enforcement is server-side and window-aware: when sizing each grant, the server accounts the Action's consumed rate over the enforcement window (enforcementWindowSec > 0, disclosed in limits) — so reporting early and cycling fast confers no rate advantage (the window remembers, and smaller grants follow). The client has no pacing obligation; pacing to the grant rate is optional smoothness, not conformance. Shared bounds are linearizable: admissions against a capacity pool — and against a sponsor cap (Section 12.1) — are evaluated as if serially against the aggregate; two concurrent admissions can never both observe and consume the same remaining headroom. (Provisional: the window's exact algorithm and reproducibility are completed by the capacity conformance traces — see Status.)¶

12.3. Degradation before refusal (fair usage)

Under capacity pressure the server degrades before it refuses: a grant (opening or continuation) MAY be reduced — always by lowering grantedUnits, never by shortening the validity window (a shorter window with the same units would raise the implied rate) — and never below the declared minimum rate. Such a response carries rateReduced: true and reduceCause: "CAPACITY"; the client can compute the allowed rate exactly from grantedUnits, grantIssuedAt, and expiresAt. Three guarantees travel with it:¶

• The price never changes with the rate. A slowdown is never a surcharge.¶

• The cause is always capacity. Commercial throttling has no code path in this protocol — a margin decision is a tariff term to be declared in the plan, never an operational throttle.¶

• It is disclosed. The reduction is flagged on the wire and recorded per party, so "what was reduced, when, and why" is answerable per customer, not only per pool.¶

Degradation lands at exchange boundaries only — there is no push channel — which is one reason validity windows are short. Below the minimum rate the server answers honestly instead: STOP (NO_CAPACITY) at a report boundary, refusal at authorisation.¶

12.4. Report promptness

Rate enforcement is defeated by stale reports: a gateway batching every thirty seconds defeats a per-second pool while passing every other check. Promptness — measured as the elapsed time from a unit of consumption occurring to dispatch of the report that first carries it, evaluated at the 95th percentile — is a tested dimension of an integration's profile (alongside authorise-before-serving and stop obedience): a bound the conformance suite measures, never a documentation claim. The bound is agreed per integration at onboarding; the version-1 default profile bound is 30 s at p95 (provisional — subject to ratification with the rate-enforcement window design; integrations should treat the mechanism as fixed and the number as negotiable). Threshold-triggered reports (Section 7.7) and the closing report are due immediately regardless of the profile bound.¶

13.1. HTTP status mapping

Charging refusals are not HTTP errors: a REFUSE or STOP arrives as 200 — including DUPLICATE_ACTION (an identity conflict is a charging refusal, not an HTTP error). Clients MUST NOT treat 200 as permission without inspecting the body.¶

Error envelope: every non-200 response carries a JSON body {errorCode, message, serverTime, maxSchemaVersion, retryable?, retryAfter?} — errorCode from Section 13.2 for the 400 family or a status-mirroring code otherwise (UNAUTHORIZED, FORBIDDEN, NOT_FOUND, METHOD_NOT_ALLOWED, UNSUPPORTED_MEDIA, RATE_LIMITED, UNAVAILABLE, INTERNAL); schemaVersion is echoed when it was parseable (Section 5). Error envelopes carry no Action-state fields (Section 2, Envelope).¶

Atomicity (normative): request processing is all-or-nothing. Full validation precedes any state mutation, and every non-200 response is state-neutral — nothing merged, counted, or settled. Settlement and the stored exchange outcome persist atomically; a crash between processing and durable storage means the request was not processed, and the identical retry is safe.¶

13.2. errorCode registry (400 family, version 1)

13.3. Client retry guidance

Idempotency (Section 6.5, Section 7.2) makes retries safe: on timeout or 5xx, the client SHOULD retry the identical request with bounded, jittered exponential backoff (RECOMMENDED: initial 1 s, factor 2, full jitter, cap 30 s). The serialisation unit of Section 3.4 is the logical Report: identical retries are the same unit, and overlapping identical attempts (a retry racing its timed-out original) are permitted — replay makes them harmless. The admission freeze ends on a charging outcome (any 200); state-neutral errors (4xx/429/503) leave it in place while retries continue, until an outcome arrives or the grant expires. The client MUST NOT mint a fresh actionId to retry an Action whose authorisation outcome is unknown — that risks double authorisation; retry the original request instead, or abandon the actionId permanently. Retrying a Report remains useful up to the late window; retrying an Authorise past the point the work would still be served is pointless — abandon it; if the work is re-attempted later, that is a new Action.¶

13.4. Charging-plane unavailability — the client state machine

When the server is slow or unreachable, the existing mechanisms compose into a complete, bounded posture; a conforming gateway follows it:¶

1. Mid-Action: per Section 3.4's single-writer rule, once the report is dispatched no new Calls are admitted until a response arrives — retrying included. Work already begun (the tail) completes within the remaining pool of the last received grant; consumption from uncancellable streams is reported when connectivity returns (late, if need be — the late window exists for this).¶

2. At pool exhaustion with no response: stop admitting new Calls. Serving beyond the pool is non-conformant regardless of the outage.¶

3. At expiresAt with no successful report: the gateway MUST stop serving the Action — validity is the hard bound, and the server will settle at the reported meter via the lapse ending. Consumption reported late still settles while late-settlement capability holds (Section 7.6). Its exceptional degradation is the one bounded exception, and it is flagged unattributable, never silent.¶

4. New Actions: when Authorise is unreachable, a conforming gateway does not serve — fail-closed is the only conformance posture this protocol defines. (Informative: a tenant may contractually accept unauthorized serving during outages; such traffic is outside this protocol — never authorised, never reported, never settled here — and is accounted between the parties as declared loss. Pulse neither forbids the business arrangement nor provides a wire path for it.)¶

5. Recovery: retry identical requests (Section 6.5/Section 7.3 replay makes every lost response recoverable), or report against the envelope's currentGrantId; reconcile via receipts (settlementId, acceptedCumulative, acceptedCalls).¶

This post-grace, late-settleable example illustrates the end-to-end posture. The gateway's local hard bounds remain the received grant's remaining pool and expiresAt; new Authorises fail closed during the outage. Other recovery branches remain as specified above.¶

Gateway                          Charging Server
   |                                    |
   |  outage begins; a grant is live    |
   |  serve only within remaining pool  |
   |--- Report R at reportAt --------X  |  unreachable
   |  no new Calls; the tail finishes   |
   |--- identical retries of R ------X  |
   |  at expiresAt: stop serving        |
   |                                    |
   |  connectivity recovers at          |
   |  now >= expiresAt + 5 s            |
   |--- identical retry of R ---------->|
   |                                    |  LAPSE and late
   |                                    |  handling
   |<-- STOP (LAPSED) + receipt --------|
   |                                    |
   |--- final-meter flush ------------->|  within 30 s of
   |    (tail included)                 |  STOP
   |<-- STOP (LAPSED) + receipt --------|

The exposure of the outage posture is: the remaining granted pool, plus the consumption of Calls already in flight when the outage began — each such Call bounded by the call-level caps (Section 4.4 magnitudes; limits.maxRuntimeSec) and settling late. Uncancellable in-flight work is the one component the pool does not cap; the protocol bounds it per Call and prices it under the pinned law, never silently.¶

13.5. Operational expectations (informative)

Authorise and Report sit on the serving hot path; the server is designed to answer from hot state and the RECOMMENDED client deadline is 2 s per attempt. For latency-critical cheap actions, the flat price form (Section 3.3) is the minimal-overhead shape (one exchange, no lifecycle). Control-plane request rate scales with Actions × cycles; the server controls the cycle rate via reportAt/grantedUnits sizing, and HTTP/2 connection reuse is assumed. Pre-grants, bulk authorisation, and multi-Action batch reporting are deferred, named (Section 1.4).¶

15.1. Transport and credentials

TLS 1.2+ is REQUIRED (1.3 RECOMMENDED; [RFC9325] configuration). API keys are secrets: gateways MUST store them in a secrets facility, MUST NOT place them in URLs, and MUST redact them from logs and traces; the server never echoes a key and audits by credential id only. Dual-active rotation rolls keys without downtime. Compromise of a key is bounded by revocation (effective within seconds), tenant binding, gateway ownership, and the per-credential rate limit. Revocation and outstanding grants: a revoked credential's requests fail 401 from the revocation instant; Actions its gateway opened continue only to their grants' lapse, ending and settling at their reported meters — the residual exposure is the remaining validities. Because ownership is gateway-level, a replacement credential of the same gateway MAY report and close them; nothing strands.¶

15.2. Tenant binding

Every request is authorised as: credential enabled → tenantRef within the credential's bound set (else 403) → subscriber belongs to that tenant (else NO_LAW). A credential can never operate on another tenant's subscribers.¶

15.3. Gateway ownership of Actions

Every Action records the opening credential's gateway. Reports and Authorise-replays are accepted only from credentials of that gateway (else 403) — a sibling gateway of the same tenant cannot operate another gateway's Actions, and a child Action MUST be opened by the parent's owning gateway (Section 9; checked before any charging evaluation). Identifiers are correlators, not secrets; authority derives from credential + binding + ownership, so sequential or guessable ids confer no authority. Acknowledged residual: the 403-vs-404 distinction lets an authenticated gateway of the same tenant probe whether an identifier exists — existence only, never content or authority; accepted and documented.¶

15.4. Abuse limits

Always enforced per subscriber: a concurrent-Actions cap and a calls-per-Action limit. Optionally (per deployment/plan): velocity limits, consumption-inflation wires, maximum runtime, and required call signatures. These stop Actions; only operator action bars a subscriber.¶

15.5. API-level protection

A per-credential request rate limit (token bucket; 429 on excess) protects the platform independently of charging-level velocity. Every request is audit-recorded by credential id; the key itself never appears in records.¶

15.6. Clock authority and posture

Band selection and lapse are computed exclusively from the server clock (Section 3.4), removing client-asserted-time gaming. The gateway MAY report its own clock (gatewayTime) and per-call start instants (startedAt, Section 7.2); both are recorded as evidence and never enforced against — a wrong clock is a fact about the gateway's estate, not a verdict about the customer whose call it carries. Persistent skew beyond tolerance is a trust signal on the integration's profile, never a refusal.¶

15.7. Trust model and privacy

The gateway is a trusted metering point. Its reports are attestations of consumption, not proofs: the protocol bounds what a dishonest or compromised gateway can cost (grants, ceilings, caps, tenant binding, gateway ownership, revocation, rate limits) but cannot verify token counts it did not observe. The residual — systematic under- or mis-reporting — is addressed outside the request path: integration grading by the conformance suite, and slow-clock observation of the executor. Stated plainly so no one mistakes the boundary: a tenant's spend guarantee holds against its subscribers; the operator's protection against a dishonest metering point is detection and contract, not cryptography, in version 1.¶

Every version-1 decision is automated. No human participates in the request path — for a grant, a refusal, or a stop. A refusal says so on the wire (automatedDecision, Section 6.4) and MAY carry a tenant-configured human-review channel (reviewContact), so a subscriber facing an adverse automated decision has a route to a person; the notice travels with the decision it describes rather than living only in documentation.¶

No money crosses outward. Grants and receipts are denominated in work units only; a gateway never learns a balance, a price, or a currency. This is deliberate — a commercial and privacy boundary, not an omission.¶

Privacy. accountRef SHOULD be a pseudonymous, tenant-scoped identifier (never a raw MSISDN, e-mail, or name); the server treats it as an opaque key. limitOwner is a presentation-safe display label declared by the sponsor with its relation — never a legal identity the tenant did not choose to show. gatewayTime, startedAt, and per-request audit records are retained under the operator's retention policy; the protocol itself mandates retention only for the late window. Refusal metadata deliberately reveals coarse state (which kind of limit bound); tenants choosing per-subscriber secrecy beyond that boundary configure presentation, not the wire.¶

18.1. Normative References

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC3339]

Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <https://www.rfc-editor.org/rfc/rfc3339>.

[RFC5246]

Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/rfc/rfc5246>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8259]

Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/rfc/rfc8259>.

[RFC8446]

Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/rfc/rfc8446>.

[RFC8610]

Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, <https://www.rfc-editor.org/rfc/rfc8610>.

[RFC8785]

Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, <https://www.rfc-editor.org/rfc/rfc8785>.

[RFC9110]

Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, <https://www.rfc-editor.org/rfc/rfc9110>.

[RFC9325]

Sheffer, Y., Saint-Andre, P., and T. Fossati, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November 2022, <https://www.rfc-editor.org/rfc/rfc9325>.

18.2. Informative References

[RFC4006]

Hakala, H., Mattila, L., Koskinen, J., Stura, M., and J. Loughney, "Diameter Credit-Control Application", RFC 4006, DOI 10.17487/RFC4006, August 2005, <https://www.rfc-editor.org/rfc/rfc4006>.

[RFC7942]

Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, <https://www.rfc-editor.org/rfc/rfc7942>.

[RFC8126]

Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/rfc/rfc8126>.

[RFC8506]

Bertz, L., Ed., Dolson, D., Ed., and Y. Lifshitz, Ed., "Diameter Credit-Control Application", RFC 8506, DOI 10.17487/RFC8506, March 2019, <https://www.rfc-editor.org/rfc/rfc8506>.

A.1. Authorise → grant

POST /ocs/ai/v1/authorizations
{
  "schemaVersion": 1,
  "actionId": "app-7f3e:conv-2091:task-4",
  "tenantRef": "4102",
  "accountRef": "subscriber-889201",
  "actionType": "chat.frontier",
  "estimate": { "tokens_in": "12000", "tokens_out": "4000" }
}

200
{
  "schemaVersion": 1, "maxSchemaVersion": 1,
  "decision": "GRANT",
  "grantId": "g-000117", "grantSeq": 1,
  "grantedUnits": "50000",
  "reportAt": "40000",
  "expiresAt": "2026-09-01T10:15:00.000Z",
  "unitWeights": { "tokens_in": "1", "tokens_out": "4" },
  "timeBandId": "offpeak"
}

A.2. Report → continue

POST /ocs/ai/v1/grants/g-000117/reports
{
  "schemaVersion": 1,
  "actionId": "app-7f3e:conv-2091:task-4",
  "tenantRef": "4102", "accountRef": "subscriber-889201",
  "final": false,
  "calls": [
    { "callId": "c1",
      "units": { "tokens_in": "9100", "tokens_out": "7800" } }
  ]
}

200
{
  "schemaVersion": 1, "maxSchemaVersion": 1,
  "directive": "CONTINUE",
  "grantId": "g-000118", "grantSeq": 2,
  "grantedUnits": "50000",
  "reportAt": "40000",
  "expiresAt": "2026-09-01T10:30:00.000Z",
  "unitWeights": { "tokens_in": "1", "tokens_out": "4" },
  "timeBandId": "offpeak"
}

A.3. Final report → settled

POST /ocs/ai/v1/grants/g-000118/reports
{
  "schemaVersion": 1,
  "actionId": "app-7f3e:conv-2091:task-4",
  "tenantRef": "4102", "accountRef": "subscriber-889201",
  "final": true,
  "calls": [ { "callId": "c1",
               "units": { "tokens_in": "9100",
                          "tokens_out": "9950" } } ]
}

200
{ "schemaVersion": 1, "maxSchemaVersion": 1,
  "directive": "SETTLED",
  "endedAt": "2026-09-01T10:19:42.114Z" }

A.4. Stop obligation

200
{ "schemaVersion": 1, "maxSchemaVersion": 1,
  "directive": "STOP", "stopReason": "CEILING_REACHED",
  "endedAt": "2026-09-01T10:12:03.551Z" }

A.5. Authorise → refuse metadata

The two abbreviated outcomes below show the distinct conditional metadata rules of Section 6.4: retryAfter accompanies a retryable refusal, while the sponsor's party-scoped bound carries limitOwner. Both carry the automated-decision notice; the second additionally shows a tenant-configured human-review channel. This is a version-1.1 exchange (schemaVersion: 2, Section 5) — the disclosure fields belong to schema version 2; the other examples show version-1.0 exchanges. They are alternatives for separate Authorise attempts, not two responses to one request.¶

POST /ocs/ai/v1/authorizations
{
  "schemaVersion": 2,
  "actionId": "app-7f3e:capacity-check",
  "tenantRef": "4102",
  "accountRef": "subscriber-889201",
  "actionType": "chat.frontier"
}

200 (capacity refusal)
{
  "schemaVersion": 2, "maxSchemaVersion": 2,
  "decision": "REFUSE", "refusalReason": "NO_CAPACITY",
  "retryable": true, "retryAfter": 5, "grade": "BOUNDED",
  "automatedDecision": true
}

200 (sponsor-cap refusal)
{
  "schemaVersion": 2, "maxSchemaVersion": 2,
  "decision": "REFUSE", "refusalReason": "EXPOSURE_CAP",
  "retryable": false, "grade": "PROVEN",
  "limitOwner": "Example AI Benefit Sponsor",
  "automatedDecision": true,
  "reviewContact": "support.example-tenant.com/spend-review"
}

A.6. Stale report → CURRENT

This exchange happens between A.2 and A.3, while the Action is still LIVE — after A.3's close, the same stale body would instead draw the terminal directive (Section 3.5, ENDED rows). This non-final body differs from the retained report for g-000117, so it is not an identity replay. Both values are below the stored high-water after A.2; the max-merge adds zero, no ending condition holds, and the standing grant is re-presented (Section 3.5, Section 7.3). The map rendering follows Section 7.3's weighted-difference description; Appendix B, schema note 5, records the conflicting domain wording and keeps this representation provisional.¶

POST /ocs/ai/v1/grants/g-000117/reports
{
  "schemaVersion": 1,
  "actionId": "app-7f3e:conv-2091:task-4",
  "tenantRef": "4102", "accountRef": "subscriber-889201",
  "final": false,
  "calls": [
    { "callId": "c1",
      "units": { "tokens_in": "9000", "tokens_out": "7700" } }
  ]
}

200
{
  "schemaVersion": 1, "maxSchemaVersion": 1,
  "directive": "CURRENT",
  "grantId": "g-000118", "grantSeq": 2,
  "grantedUnits": "50000", "reportAt": "40000",
  "expiresAt": "2026-09-01T10:30:00.000Z",
  "unitWeights": { "tokens_in": "1", "tokens_out": "4" },
  "timeBandId": "offpeak",
  "baselineCumulative": { "tokens_in": "9100",
    "tokens_out": "7800" },
  "meterCumulative": { "tokens_in": "9100", "tokens_out": "7800" }
}

A.7. Error envelope

Here an Authorise estimate uses a JSON number instead of the canonical decimal string required by Section 4.3, so the request fails state-neutrally with the Section 13.1 envelope.¶

POST /ocs/ai/v1/authorizations
{
  "schemaVersion": 1,
  "actionId": "app-7f3e:conv-2091:task-bad",
  "tenantRef": "4102",
  "accountRef": "subscriber-889201",
  "actionType": "chat.frontier",
  "estimate": { "tokens_in": 12000 }
}

400
{
  "schemaVersion": 1,
  "errorCode": "MALFORMED_REQUEST",
  "message": "estimate values must be canonical decimal strings",
  "serverTime": "2026-09-01T10:20:11.006Z",
  "maxSchemaVersion": 1
}

B.1. Schema notes — ambiguities found

1. Section 6.5 requires a live Authorise replay to include the standing grant's "cycle-baseline receipt", but explicitly identifies only acceptedCumulative. Section 7.3 defines the remaining receipt fields for settling Report responses, while the first grant has no preceding settlement. The schema therefore makes the baseline receipt optional and makes its other members optional.¶

2. An Authorise terminal acknowledgement explicitly contains decision, ending, endedAt, and the final receipt, with settled "where applicable". It does not say whether grantId and grantSeq are repeated, or enumerate the applicability of settled. The schema makes the last-grant reference and settled optional.¶

3. The initial flat-GRANT state-machine row names settled and endedAt, while an ended-Action Authorise replay names ending. It is not explicit whether the initial flat response also carries ending: "CLOSE"; the schema makes it optional.¶

4. The shared-envelope definition requires Action-state fields on every 200 that identifies an opened Action and excludes them on refusals of unopened Actions. It is unclear whether REFUSE / DUPLICATE_ACTION counts as identifying the already-opened Action. The unopened REFUSE shape excludes the envelope; only the duplicate-Action branch optionally permits the complete envelope.¶

5. Sections 3.5 and 7.3 describe baselineCumulative and meterCumulative as meter states whose difference is weighted. Section 4.3 groups their "pooled values" with derived quantities in [0, 10^17). The examples provisionally use per-unit maps because the weighted-difference operation needs them; current-meter-fields permits either a map/map or pooled-scalar/pooled-scalar representation because the exact JSON shape and value domain require adjudication.¶

6. A zero-merge terminal response carries the "current receipt", but Section 7.3 defines acceptedCalls relative to the Calls present in the request that caused a settlement. It is unclear what acceptedCalls contains for a non-settling zero-merge request, so it is optional in terminal-current-receipt.¶

7. For recognised new consumption that can no longer be settled, Section 3.5 says there is no settlementId, while Section 7.6 says there is no new settlementId and also refers to the stored terminal outcome. It is unclear whether an old current receipt remains present; the unattributable terminal shapes therefore permit it optionally.¶

8. A Report to a flat Action receives SETTLED and never settles. The prose does not say whether the response re-presents the flat opening receipt's settlementId; the flat Report shape therefore makes it optional.¶

9. retryAfter is required when an Authorise refusal has retryable: true, but its presence is not expressly forbidden or defined when retryable: false. The false variants therefore model it as optional. The error envelope separately leaves retryable and retryAfter independently optional and does not couple them to an HTTP status.¶

10. The JSON type, length, and character domain of error-envelope message are not stated in Section 4.3 or Section 13.1. The provisional schema uses any; if a JSON string is intended, an authoritative field rule is needed before regeneration.¶

11. Section 7.3 does not state whether each acceptedCalls[].units map is complete over the declared unit types or contains only the keys relevant to that Call or request. The schema permits any within-limit unit map.¶

12. The exact trigger for clamped: true is not fully mechanical: Section 7.3 says "limited by the meter or a ceiling", although every settlement is bounded by the meter. The schema preserves the stated optional presence and does not infer a trigger.¶

13. minRate is a pooled-units-per-second decimal, but Section 4.3 does not unambiguously assign it the request, weight, or derived-pooled upper domain. The schema enforces only the canonical decimal representation pending regeneration.¶

14. The 256 KB request limit does not say whether KB is decimal or binary, so CDDL cannot express an exact byte .size bound without choosing a meaning.¶

15. Section 7.7 requires a Report that flushes the final meter after STOP, but does not state the value of that Report's required final field. The request schema accepts either Boolean, and the outage diagram does not choose one.¶

16. Section 6.4 requires limitOwner for a party-scoped bound but does not enumerate every refusal reason that can be party-scoped. Section 12.1 makes it unconditionally present for EXPOSURE_CAP. The schema requires it there, permits it on the bound-like refusal shapes, and excludes it from conditions that the prose does not describe as bounds.¶

C.1. Authorise and opening grant

The Action Type declares two unit types with distinct weights and a pooled quantum of 10:¶

The gateway opens the Action with both types in its estimate:¶

POST /ocs/ai/v1/authorizations
{
  "schemaVersion": 1,
  "actionId": "arith-action-1",
  "tenantRef": "4102",
  "accountRef": "subscriber-arith",
  "actionType": "chat.quantised",
  "estimate": { "tokens_in": "18", "tokens_out": "10.1" }
}

The full opening GRANT is:¶

200
{
  "schemaVersion": 1,
  "maxSchemaVersion": 1,
  "decision": "GRANT",
  "grantId": "g-arith-1",
  "grantSeq": 1,
  "grantIssuedAt": "2026-09-01T10:00:00.000Z",
  "grantedUnits": "20",
  "reportAt": "15",
  "expiresAt": "2026-09-01T10:05:00.000Z",
  "unitWeights": { "tokens_in": "0.333333", "tokens_out": "2.5" },
  "quantumUnits": "10",
  "serverTime": "2026-09-01T10:00:00.000Z",
  "actionLive": true,
  "currentGrantSeq": 1,
  "currentGrantId": "g-arith-1",
  "unattributable": false,
  "lawVersion": 1,
  "limits": {
    "maxCallsPerAction": 10,
    "maxRuntimeSec": 600,
    "maxConcurrentActions": 4
  }
}

The first cycle baseline is the zero meter (Section 7.3): M0 = {tokens_in: 0, tokens_out: 0}. Applying Section 7.2 gives pooled total P0 = 0 and block count B0 = ceil(P0 / 10) = ceil(0 / 10) = 0.¶

For each accepted meter Mk, the calculations below use the Section 7.2 formulas:¶

P_u(k) = HALF_UP_6(weight_u * cumulativeTotal_u(k))
P(k)   = exact sum of P_u(k) over unit types
D(k)   = P(k) - P(cycle baseline)     ; raw cycle pool consumption
B(k)   = ceil(P(k) / quantumUnits)
DB(k)  = B(k) - B(previous settlement) ; newly charged block delta

D(k), not DB(k) * quantumUnits, is compared with reportAt and the grant pool (Section 7.2). cyclePooledUnits carries that raw pre-quantisation delta (Section 7.3).¶

C.2. Cycle 1 — threshold crossing, settlement, and re-grant

At 2026-09-01T10:01:00.000Z, the gateway reports one Call cumulatively against G1:¶

{
  "schemaVersion": 1,
  "actionId": "arith-action-1",
  "tenantRef": "4102",
  "accountRef": "subscriber-arith",
  "calls": [
    { "callId": "c1",
      "units": { "tokens_in": "10", "tokens_out": "4.666669" } }
  ],
  "final": false
}

The cumulative products and exact sum are:¶

P_in(1)  = HALF_UP_6(0.333333 * 10)
         = HALF_UP_6(3.333330) = 3.33333                (section 7.2)
P_out(1) = HALF_UP_6(2.5 * 4.666669)
         = HALF_UP_6(11.6666725) = 11.666673            (section 7.2)
P(1)     = 3.33333 + 11.666673 = 15.000003             (section 7.2)
D(1)     = P(1) - P0 = 15.000003 - 0 = 15.000003       (section 7.2)

Thus D(1) = 15.000003 >= reportAt 15 and D(1) <= grantedUnits 20. The crossing runs a settling cycle and produces CONTINUE with G2. Quantised rating is cumulative:¶

B(1)  = ceil(15.000003 / 10) = 2                        (section 7.2)
DB(1) = B(1) - B0 = 2 - 0 = 2 newly charged blocks     (section 7.2)

Those two blocks represent 20 pooled units in the quantised rating. No such derived block field is added to the wire. The receipt members in the top-level response are exactly:¶

{
  "settlementId": "s-arith-1",
  "acceptedCumulative": { "tokens_in": "10",
    "tokens_out": "4.666669" },
  "acceptedCalls": [
    { "callId": "c1",
      "units": { "tokens_in": "10", "tokens_out": "4.666669" } }
  ],
  "cyclePooledUnits": "15.000003"
}

Neither clamped nor adjustment is present. CONTINUE mints G2 with grantId: "g-arith-2", grantSeq: 2, grantIssuedAt: "2026-09-01T10:01:00.000Z", grantedUnits: "12", reportAt: "9", and expiresAt: "2026-09-01T10:06:00.000Z"; its pinned weights, quantum, law, and limits are unchanged. Its fresh envelope has actionLive: true, currentGrantSeq: 2, currentGrantId: "g-arith-2", and unattributable: false. The cycle baseline moves to M1 = {tokens_in: 10, tokens_out: 4.666669}, whose pooled value is P(1) (Section 7.3).¶

C.3. Stale, out-of-order report — zero merge and CURRENT

At 2026-09-01T10:01:10.000Z, a stale worker sends a different non-final request against superseded G1 with c1 = {tokens_in: 9, tokens_out: 4.5}. It is not the retained Cycle 1 identity. Per Section 7.2, the max-merge is:¶

max({10, 4.666669}, {9, 4.5}) = {10, 4.666669}; meter increase = 0

No ending condition holds. Under Section 3.5 LIVE row 6 and Section 7.3, the response is CURRENT. The full standing G2 grant is re-presented; the selected convergence fields are below. As in A.6, the per-unit map rendering is provisional under Appendix B, schema note 5.¶

{
  "directive": "CURRENT",
  "grantId": "g-arith-2",
  "grantSeq": 2,
  "baselineCumulative": { "tokens_in": "10",
    "tokens_out": "4.666669" },
  "meterCumulative": { "tokens_in": "10", "tokens_out": "4.666669" },
  "actionLive": true,
  "currentGrantSeq": 2,
  "currentGrantId": "g-arith-2",
  "unattributable": false
}

There is no settlement, receipt, charge, or mint; the current generation remains 2.¶

C.4. Cycle 2 — the baseline moves again

At 2026-09-01T10:02:00.000Z, the gateway reports against G2 with the cumulative meter M2 = {tokens_in: 15, tokens_out: 7.8}:¶

P_in(2)  = HALF_UP_6(0.333333 * 15) = 4.999995          (section 7.2)
P_out(2) = HALF_UP_6(2.5 * 7.8) = 19.5                 (section 7.2)
P(2)     = 4.999995 + 19.5 = 24.499995                 (section 7.2)
D(2)     = P(2) - P(1)
         = 24.499995 - 15.000003 = 9.499992             (section 7.2)

D(2) = 9.499992 >= reportAt 9 and D(2) <= grantedUnits 12, so this is another settlement and re-grant. The cumulative block calculation is:¶

B(2)  = ceil(24.499995 / 10) = 3                        (section 7.2)
DB(2) = B(2) - B(1) = 3 - 2 = 1 newly charged block    (section 7.2)

The exact top-level receipt members are:¶

{
  "settlementId": "s-arith-2",
  "acceptedCumulative": { "tokens_in": "15", "tokens_out": "7.8" },
  "acceptedCalls": [
    { "callId": "c1",
      "units": { "tokens_in": "15", "tokens_out": "7.8" } }
  ],
  "cyclePooledUnits": "9.499992"
}

Again, clamped and adjustment are absent. CONTINUE mints G3 with grantId: "g-arith-3", grantSeq: 3, grantIssuedAt: "2026-09-01T10:02:00.000Z", grantedUnits: "10", reportAt: "8", and expiresAt: "2026-09-01T10:07:00.000Z". Its envelope carries current generation 3 and current id g-arith-3. The new baseline is M2 = {tokens_in: 15, tokens_out: 7.8} with pooled value P(2) (Section 7.3).¶

C.5. Final report — CLOSE and terminal settlement

At 2026-09-01T10:02:30.000Z, the gateway sends final: true against G3 with cumulative meter M3 = {tokens_in: 18, tokens_out: 10.1}. The close is allowed before reportAt; it settles the full remaining meter delta (Section 3.5, Section 7.3):¶

P_in(3)  = HALF_UP_6(0.333333 * 18) = 5.999994          (section 7.2)
P_out(3) = HALF_UP_6(2.5 * 10.1) = 25.25               (section 7.2)
P(3)     = 5.999994 + 25.25 = 31.249994                (section 7.2)
D(3)     = P(3) - P(2)
         = 31.249994 - 24.499995 = 6.749999             (section 7.2)
B(3)     = ceil(31.249994 / 10) = 4                     (section 7.2)
DB(3)    = B(3) - B(2) = 4 - 3 = 1 newly charged block (section 7.2)

D(3) = 6.749999 <= grantedUnits 10. The exact terminal receipt members are:¶

{
  "settlementId": "s-arith-3",
  "acceptedCumulative": { "tokens_in": "18", "tokens_out": "10.1" },
  "acceptedCalls": [
    { "callId": "c1",
      "units": { "tokens_in": "18", "tokens_out": "10.1" } }
  ],
  "cyclePooledUnits": "6.749999"
}

Neither optional flag is present. The response directive is SETTLED; the Action's ending is CLOSE and endedAt is 2026-09-01T10:02:30.000Z. The closing outcome mints generation 4 without minting a serving grant. The terminal envelope is therefore actionLive: false, currentGrantSeq: 4, currentGrantId: "g-arith-3", and unattributable: false (Section 3.5).¶

As a final check, the raw receipt deltas sum without cadence loss:¶

15.000003 + 9.499992 + 6.749999 = 31.249994 = P(3) - P0

The charged block deltas also telescope:¶

2 + 1 + 1 = 4 = ceil(31.249994 / 10)

The stale report contributes zero to both checks. This is the cadence-independence property of the cumulative pipeline in Section 7.2.¶

D.1. The framework's terms

The sponsor-cap concept, by its framework name: what EXPOSURE_CAP enforces is the framework's Solvency Rule at a second scope — "a bound on exposure ranges over a relation, not over any one Balance." Where the engine enforces open grants ≤ the Balance, it also enforces commitments across the relation ≤ the exposure bound; Section 12.1 states the same basis (committed + settled, per relation) explicitly.¶

Two cross-vocabulary notes: the framework's fourth velocity level, RELATION_VELOCITY (Actions started and credits charged per minute, counted across a declared relation), is this document's GROUP_VELOCITY — the same object, counted as the framework defines it, in both Actions started and credits charged. And the framework closes its refusal vocabulary (fourteen reasons) but enumerates no closed set of stop reasons — its reference engine's stop codes are the nearest list; this document closes both registries per version (Section 5, Section 7.4, Section 13.2) — a protocol decision, not a divergence.¶

D.2. Additional implementation and telecom terms

False friends — same word, different meaning:¶

• Profile. Three meanings collide. In the charging stack, the subscription profile is the subscriber's stored charging state. In the framework, a Profile is the Metering Point's tested integration record — a test result, not stored state. In this specification, profile appears only as deployment profile — a named set of deployment choices (Section 12, Section 13.5). None of the three is any of the others.¶

• Expiry (resolved at draft-04). In the framework, Expiry is a date after which a Balance's unreserved credits are written off — money is destroyed, and reserved credits are spared until their Actions settle; the implementation's counter expiry is the same event. Through draft-03 this document named the ending of a lapsed grant EXPIRY, and the two were false friends. From draft-04 that ending is LAPSE and its stop reason LAPSED (the expiresAt field keeps its name): a lapse settles at the reported meter (Section 7.5) and writes nothing off; an Expiry is a balance event with no wire term. The word expiry is no longer used for the lapse anywhere in this document.¶

• Envelope. Here, the Envelope is the always-fresh part of a response (Section 2). In the framework, an envelope is a money partition — the authorisation floor. Neither is the other.¶

• Minimum. The framework's Minimum is a price form: a per-Action floor on the Charge. Its counterpart here is the contractual minimum reserved at open (Section 6.2) and never applied a second time (Section 7.6) — no wire field. limits (Section 6.3) are the disclosed protective bounds, and limits.minRate (Section 12.2) is a capacity rate: three objects, one word apart.¶

• Facility. In the framework, a Facility is a regulatory regime that contains Tenants. In the implementation, a facility is a node of the operator's tenancy tree below the tenant (the root facility is the tenant). Neither reaches the wire; tenantRef is the Tenant.¶

One field, two uses — signature. On this wire, signature is a reserved, opaque per-call attestation (Section 7.2), enforced only where a bilateral profile is agreed (SIGNATURES_REQUIRED, Section 7.4). The framework's reference engine uses a per-call signature as a fingerprint for repeat detection (its Inflation wire), and the implementation does the same server-side with the value it receives. Same field, two purposes — recorded here so the wire contract and the server-side use are never conflated.¶