Concepts
Product actions
The billable or costly work your application asks Valqio to decide before it runs.
A product action is a product-native name for work your app wants to run.
Examples:
generateTextexportReportrenderVideosendInvoiceenrichLeadinviteSeat
Product actions keep application code readable. Instead of scattering raw meter and limit keys through your app, generated SDK clients can expose methods that match the work your product performs.
Product action shape
A good product action definition answers:
- What work is about to run?
- Which customer or workspace is responsible for it?
- What quantity should be evaluated or reserved?
- Which meter, credit, quota, reservation, or limit backs the decision?
- What context will support, finance, or analytics need later?
Action examples
| Product action | Backing control | Runtime behavior |
|---|---|---|
generateText | AI generation meter and monthly quota. | Enforce before model work starts. |
renderVideo | Credit reservation. | Reserve before rendering, then commit or release. |
exportReport | Plan feature and export quota. | Evaluate access, then enforce usage. |
inviteSeat | Seat limit. | Deny if the account is already at its seat cap. |
Operation types
Console maps each product action to an operation and backing resource.
| Operation | Backing resource | Use it when |
|---|---|---|
| Access check | Feature or parameter | The app needs to know whether the customer can use a feature or which configured value to apply. |
| Check and count usage | Usage control | The app should check allowance and count one completed unit in the same runtime call. |
| Reserve usage first | Usage control | The app needs to hold credits, quota, or allowance before expensive or asynchronous work starts. |
| Count completed usage | Usage control | The app should count only after it has confirmed successful work. |
| Check limit | Protective limit | The app needs a rate, token, or guardrail check before work starts. |
| Acquire limit | Protective limit | The app needs a temporary concurrency slot before work starts. |
| Release limit | Protective limit | The app needs to release a concurrency slot after work finishes. |
| Capture evidence event | None | The app needs an auditable event that does not itself decide whether work runs. |
App responsibility
Valqio decides whether the action should run. Your app still owns:
- collecting the user request
- choosing the subject
- passing the request ID and idempotency key
- running the product work after allow
- returning the product-specific denial message
- storing any local records your app needs
The clean boundary is simple: call Valqio before the billable action, then use the decision.