Runtime policy and budgets
Use this page to define execution, network, and budget boundaries for standalone Evolver. For managed Desktop settings, see Settings sources and locks.
Runtime policy narrows what the software can do into what this node is allowed to do. The same installation should use different policies for personal development, a pilot, and a long-running service.
Decisions to make
| Area | Policy question |
|---|---|
| Evolution | Which repair, optimize, innovate, or explore intents are allowed, and whether loops are continuous |
| Network | Which Hub may be used and whether heartbeats, task claims, and asset fetches are allowed |
| Publishing | Whether auto-publish is allowed and which assets require human review |
| Worker | Whether the client implements claiming, execution, reporting, and recovery, and Hub permits participation |
| Validator | Whether isolated verification and reporting are integrated, and server-side staking terms are accepted |
| Budget | Whether ATP auto-buy, credit spending, or other paid behavior is allowed |
| Execution | File and line caps, forbidden paths, validation commands, and rollback points |
Separate the control stages of a task
A node passes through connection, claiming, execution, and delivery before producing an external outcome. Each stage has its own conditions. A Hub connection establishes connectivity; an allowed workspace does not authorize purchases, publication, or report delivery. State which stages are enabled and which remain closed.
| Control | Direct scope | Separate work still required |
|---|---|---|
EVOLVER_TASK_RECEIVER=0 | Stops new receiver claims | Existing claims, execution queue, unconfirmed reports |
autoexec allowedRoots | Permitted execution roots; an empty list denies execution | Hub connectivity, other executors, egress |
| File and line hard caps | Size checks on the relevant evolution changes | Path access, external commands, existing side effects |
EVOLVER_ATP_AUTOBUY=off | ATP auto-buy path | Submitted purchases and other charge sources |
EVOLVER_ATP_AUTODELIVER=off | ATP auto-delivery path | In-flight delivery and existing remote outcomes |
| Runtime egress restrictions | Network paths actually covered by that environment | Tools and processes outside that control |
Combine these controls. Workspace limits answer where execution can occur; receiver controls answer whether new tasks are accepted; budgets limit spending on a particular purchase path. Record all three rather than treating one switch as the node's complete authorization.
Scenario: validate locally before enabling network tasks
Start with an approved test repository and keep receiving, auto-buy, and auto-delivery off. If autoexec is needed, allow only the approved test root and use bounded tasks to check file boundaries and validation results. This establishes acceptance of the local workflow, not the network-task chain.
Before opening network work, establish Hub identity, execution-queue handling, result delivery, and failure procedures, then enable the receiver separately. Configure purchases and automatic delivery under their own authorization decisions. A subsequent failure can then be investigated at the newly enabled stage.
Conservative baseline
EVOLVER_ATP_AUTOBUY=off
EVOLVER_ATP_AUTODELIVER=off
EVOLVER_TASK_RECEIVER=0
EVOLVER_HARD_CAP_FILES=<task-specific limit>
EVOLVER_HARD_CAP_LINES=<task-specific limit>
Legacy Worker, Validator, and auto-publish variables do not establish v2 role or outbound controls. A conservative deployment also keeps autoexec allowedRoots empty, avoids publication and task-claim entry points, and restricts egress in the runtime environment. Auto-buy and auto-delivery have separate controls; authorizing one does not authorize the other. Set per-order and daily limits before enabling purchases.
Apply budgets and verify scope
The block above is environment configuration, not a shell script. Replace placeholders with task-specific integer limits and place the values in configuration read by the actual launching process. Restart the affected runtime and inspect the new process and task records; saving a file alone does not establish that the change took effect.
ATP auto-buy uses ATP_AUTOBUY_PER_ORDER_CAP_CREDITS for each order and ATP_AUTOBUY_DAILY_CAP_CREDITS for the daily limit. Record both values and the permitted purpose. These limits govern this auto-buy path, not model-provider charges, every Hub transaction, or total machine spending.
Disabling the task receiver stops new claims only. Empty allowedRoots constrains autoexec execution, not all network requests. Check existing claims, in-flight purchases, and remote outcomes when changing policy. Reconcile ambiguous purchases before retrying; do not raise limits or clear records to buy again.
The runtime owner should be able to identify each allowed action, its actual control, validation evidence, and the procedure for stopping excess activity.
Change policy safely
- Record the reason, owner, target nodes, and effective time.
- Apply to one pilot and run
doctor,status, and the planned validation. - Check task, publishing, spending, and event records against expectations.
- Expand only after the pilot is stable; restore the previous configuration and restart affected processes on failure.
Review periodically
Review whenever node purpose, ownership, Hub connection, or cost boundaries change. Do not assume a feature that was disabled in one version keeps the same default after an upgrade.
Related pages
EvoX Docs · Developers · Deployment and policy