Runtime decisions

A runtime decision is the answer your product asks for before it does work that may be costly, limited, or billable.

Lifecycle

1. Your app sends the subject, action or meter, quantity, and idempotency key.
2. Valqio resolves plan rules, customer terms, credits, quotas, reservations, and current usage.
3. Valqio returns allowed or denied with reason and evidence context.
4. Your app runs the product action only when the decision allows it.
5. Valqio records evidence so the outcome can be explained later.

Reserve, commit, release

For work that may fail after it starts, reserve before the action. Commit when the action succeeds. Release when the action fails or is cancelled.

This matters for expensive or asynchronous work:

• model generation
• report export
• media rendering
• marketplace API calls
• background jobs

Retries and idempotency

Every billable request should carry an idempotency key. If your app retries the same request, Valqio can return the same decision instead of double-counting usage.

Use a key that is stable for the product attempt, such as:

generate-report:req_123

Failure modes Valqio is designed around

• A request is retried after a timeout.
• Work starts but fails before completion.
• Two concurrent requests try to spend the same remaining balance.
• Billing sync is delayed.
• Support needs to explain why a customer was blocked.

Valqio manages the transaction lifecycle around usage: preflight, reserve, commit, release, and evidence.