Skip to main content
Gateway needs to explain which request it accepted, which provider attempts were permitted and what outcome was established. It does not need to turn that record into another copy of the user’s prompt or answer. The design calls this protected execution record O1. Its job is execution history and guarded transitions—not content replay or customer-payment authority.

​
The record follows one original call

A logical call links the authenticated request identity and fingerprint to its attempts. Each physical dispatch has a distinct attempt identity and order within that call. The history distinguishes registration, possible output exposure, attempt termination and the final logical outcome. These events answer different questions. An attempt registration records permitted intent; it does not prove a network request was received. An output marker records possible exposure; it does not prove that a reader saw or saved the text. The application keeps answer bytes separately when it needs them.

​
Why the database boundary matters

An execution log and a capacity counter can each look plausible while disagreeing after a crash. Gateway therefore couples the required O1 change and Native G4 capacity effect in the same admitted transaction. Registration and reservation agree together. Terminal and settlement transitions use their required grouping. The final call record and its notification obligation commit together. A convenience helper that commits capacity independently would break that protection. Provider network work happens outside the database transaction. The next permitted effect waits for confirmation of the relevant preceding boundary.

​
Six protected changes

The engineering design exposes six durable write boundaries. In reader terms, they register an attempt, mark possible output exposure, record an attempt’s terminal outcome, finalize the call, append an attributable correction and acknowledge a qualified settlement result. The first four are about the execution path. A correction adds evidence without silently rewriting the original history. A settlement acknowledgement records a result established by the financial owners; it does not perform the payment itself. A separate protected reader can help resolve a lost commit confirmation. Read permission is not an extra general-purpose mutation API or blanket permission to inspect private history.

​
Final does not mean that every fact is known

A call can have a fixed execution outcome while usage remains estimated, pending or unknown. Later qualified provider evidence can improve accounting through a linked correction. A normal accounting correction cannot overwrite the old execution outcome, reopen a finalized customer debit or create another charge. Any expressly authorized outcome supersession is a distinct, linked exception—not “the latest callback wins.”

​
Keep enough history to explain obligations

The selected contracts include a 90-day admission horizon for new provider usage or cost corrections and at least 180 days of duplicate-protection evidence, extended where unresolved obligations require it. These are scoped record rules, not a promise to keep answer content indefinitely. A record must not be purged while an unacknowledged notification, unsettled effect or other protected dependency still needs it. A legal purge ends the corresponding historical replay guarantee. Private native history supports exact confirmation under its access controls. A checksum identifies bytes; it does not establish who was authorized to write them or prove that a restored database is current. Read Usage, provider cost and customer payment and When a confirmation is lost to see how this record is used.