Models and persistence
Confirm content and charges after a disconnect
Display, history, gateway usage and the ledger are four different facts. Query them against the original request to establish what was saved, whether the result was delivered and whether a charge was posted.
Separate four questions before investigating
A response has several completion points: text reaches the browser, content enters history, the gateway saves final usage and the application posts a charge. They share a request relationship but are separate operations. A disconnect can occur between any of them. The last visible line cannot establish the remaining outcomes.
Read Chat’s committed history to determine what can be opened again, YaoDel’s original-request result to establish the saved counters, and Yaoledge’s authorization and ledger to check charges. Keep the original conversation, turn and gateway-request association, and distinguish a successful read, an absent result and a failed query.
| Observed fact | Record to read | What it establishes |
|---|---|---|
| Screen output | The browser’s provisional deltas | What appeared locally at that moment |
| Saved history | Committed references and turn status | The readable prefix and its ending status |
| Gateway usage | Original request result and notification state | Saved counters and delivery progress |
| Posted charge | Original grant, final result and usage ledger | Actual settlement and charge allocation |
Start with the definite prefix in history
Consider an illustrative sequence: the page has displayed A, B, C and D, while checkpoints have published only through C. After a disconnect, reopening establishes A through C as readable. D having appeared does not establish that it was saved. The letters indicate content order, not a measured response or performance dataset.
Chat writes content to private object storage and then publishes ordered references for the original conversation and turn. Only references committed in the current history participate in reading, export and subsequent input. An explicit Stop attempts to save the retained tail within the original budget; browser disconnection does not add that save. Reopening neither resumes the provider stream nor repeats the original inference.
Inspect the terminal result actually saved by the gateway
YaoDel accepts the four usage counters together from a complete matching provider terminal. The terminal event can reach the client while result submission proceeds independently. A result may also be saved after client output fails. Receiving a terminal therefore does not replace a persistence query, and missing output does not prove missing persistence.
The query needs the original application ID and gateway request ID. Chat retains the latter when it receives the corresponding response header. Its own turn ID is not an upstream idempotency key, and the two identities cannot be substituted. If the gateway ID was never obtained, preserve the missing association rather than inventing an identity and executing again.
| Observation | Meaning | Unsupported conclusion |
|---|---|---|
| Saved ERROR with four zeros | The gateway retained an explicit error candidate | The provider performed no work |
| Successful read, missing result | This read found no matching retained result | The original call was never sent |
| Failed read | The required observation is unavailable | It is equivalent to missing or zero |
| Delivery expired | Application processing was not confirmed in time | The application cannot have posted a charge |
Confirm money against the original authorization
At authorization, Yaoledge saves the account, model, target and rates. It does not pre-debit the charge or reserve a spending ceiling. A matching final result is priced using those original rates and allocated against the account state at settlement. Browser connectivity plays no part in that decision.
If accounting commits but its acknowledgement is lost, YaoDel can redeliver the same result. The application reads the closed original request and acknowledges without another posting. Redelivery and another inference attempt have different effects: the latter creates a new execution opportunity and cannot repair an unconfirmed notification.
An original-inference inquiry distinguishes an admitted request with no final posting from a closed one, retaining its rates, outcome and amounts. The admitted state describes local accounting, not a model that is necessarily still running. A complete matching zero-usage result may close without a debit. A missing notification cannot be replaced with an invented zero result.
Follow a bounded inquiry path
For “the answer stopped, but the charge changed,” first identify the original conversation and turn, then its retained gateway-request association. History establishes saved content, the original YaoDel result establishes gateway observations, and the Yaoledge record establishes settlement. Each step can remain unavailable without another inference to manufacture evidence.
When a read succeeds, continue under the same original request. When it fails, preserve that failure and the age of the last known observation. Notification state explains delivery progress without changing the saved result or deciding what the application ledger posted.
Confirm content in the original conversation
Read committed history and the original turn state, preserving the definite prefix.
Confirm the original request result
Use the gateway identity actually obtained, separating saved result from notification state.
Confirm charges against the original grant
Compare retained rates, final usage and posting; browser disconnection establishes no zero-charge result.
Redelivery handles the same saved result
The receiver uses durable original-request deduplication for one business effect.
Another inference is not result recovery
A new model call creates another execution opportunity and cannot resolve the original uncertainty.
Design each check to exclude a specific wrong conclusion
Useful verification goes beyond seeing an error on screen. It creates distinguishable event ordering and compares the outcome with independent expectations. The following scenarios are requirements identified by the design, not a report of completed measurements.
Observations retain the original conversation, turn and gateway binding. A failed query remains unconfirmed; a retained older reading keeps its observation time. Next actions follow the original record and current authority. A log, timeout or absent event alone supplies no permission to execute again.
Disconnect after display and before publication
Show D before its checkpoint commits. Reopen and compare the A–C prefix, while checking that no second provider call occurs.
Delay persistence confirmation after terminal output
Allow the complete terminal to close the client stream. Confirm that submission continues with the same candidate and output does not wait for its acknowledgement.
Drop the acknowledgement after accounting
Redeliver the original terminal result. Compare one charge and one daily-summary increment for the original request.
Distinguish zero, missing and unavailable
Supply these observations separately and ensure the interface and operator result do not collapse them into zero cost.