Run a shared-allowance accounting model
A dependency-free local example contrasts stale balance checks with reservation and shows why unknown outcomes keep capacity held.
This local program demonstrates why checking a balance and reserving it are different operations. It uses an in-memory model, no credentials and no network calls. It is an educational accounting example, not Anlyon's implementation or a distributed concurrency benchmark.
Run the example
Use Node.js 22 or newer. Download shared-allowance.mjs, save it locally, inspect it, and run:
node shared-allowance.mjs
The program uses built-in assertions and prints:
Stale checks admit 30 against a limit of 20.
Reservations admit 15; the second request is refused.
Unknown outcome keeps 15 held and 5 available.
Confirmed outcome consumes 15; availability remains 5.
The first scenario intentionally lets both callers read the same initial capacity before either spends it. Two requests of 15 each see a limit of 20 and both pass their independent checks. The resulting total is 30.
The second scenario reserves capacity as one indivisible local operation. The first request takes 15 and the second cannot reserve another 15. When the first result becomes unknown, its exposure stays held. Confirming it moves the quantity from held to consumed rather than replenishing the allowance.
What this does and does not establish
| Demonstrated | Outside this example |
|---|---|
| Stale observations can over-admit | Cross-process database coordination |
| Admission needs a reservation boundary | Provider API behavior |
| Uncertainty must retain exposure | Anlyon's live deployment behavior |
| Settlement changes accounting state | Period rollover and multiple limit scopes |
JavaScript's synchronous local reservation is not a production concurrency solution. A deployed service needs the equivalent invariant across workers, crashes and persistent state.
Connect the model to a real integration
Anlyon impact limits apply to governed routed actions within one environment and configured scope. To validate your deployment, use the two-agent refund test procedure and collect actual effect and provider records. Keep the local demonstration results separate from those integration results.
Read impact-limit configuration and unknown exposure. Cleanup is simply deleting the downloaded script; the example creates no accounts, provider operations or files.