Open product module
Credits and access
A visible, idempotent access unit that keeps expensive work bounded without turning the product into a wallet.
Why it exists
Credits connect a person’s access level to the cost of an AI action. The accounting boundary is separate from identity, billing, and abuse decisions.
Inputs and outputs
Inputs
- A resolved anonymous or user subject
- The action and integer cost
- The active entitlement and ledger state
Outputs
- A balance visible before expensive work
- An idempotent spend event
- A refund or deterministic empty state on failure
Visual flow
- Resolve identity after security checks
- Show the action cost
- Spend once with an idempotency key
- Execute the provider action
- Refund on a failed execution
Practical example
Situation
A user double-clicks “generate plan” while the provider is slow.
Result
The same request key reuses one spend; if the provider fails, the ledger returns the cost instead of silently losing access.
Limitations
- Credits are not money, a token, or a transferable asset.
- Paid balances require stronger storage guarantees than a low-stakes demo.
- Commercial amounts and plan promises come from owner-approved billing facts.
Open and closed boundary
Open here
The distinction between access, cost visibility, spend, and refund is public.
Kept private
Secrets, payment identifiers, fraud thresholds, and private ledger rows remain operationally private.