Operating a DVM

A deployed service needs more than a running process. Jobs must complete, payments must be recognized, and refunds must remain deliverable. Earnings and payouts answer different questions. Updates can change behavior while old jobs and customer balances still exist. Shutting down the process does not settle those obligations.

Health and job outcomes

Service status describes compute state. Logs, metrics, and events help explain what the service is doing. A healthy machine can still run a handler that fails every job or cannot reach its payment provider.

For an incident, retain the service, deployment, and job identifiers together with the time window. They let an agent distinguish a current failure from an earlier deployment's event. The installed skill routes diagnosis through its recovery procedure.

Earnings and payouts

Revenue reports describe what the service earned. Payout records describe transfers to the builder. Unused caller credit is an obligation and must not be counted as available earnings just because its original payment reached a wallet.

Cashu operations need a refund and payout worker. If refund state cannot be read, the worker holds the payout; unknown state is not zero liability. Lightning-funded credit can need the worker's separate spending connection to acquire refund ecash.

Stablecoin channels need their settlement and close handling to remain operational. One-payment stablecoin credit requires a manual refund process when enabled. Payments and payouts owns these distinctions; the command reference specifies inspection and repair operations.

Updates and ownership changes

An update must preserve the records and keys needed by existing jobs and customer balances. A code rollback changes the deployed revision; it does not necessarily undo a database migration, a payment, or a changed external credential.

A transfer changes the service's owner and can change its treasury configuration. Verify the resulting owner and any pending re-key before treating it as complete. Builder access describes the access boundary.

Use the skill's deployment procedure for a new revision and its operating procedure for a service change. When a response is lost, inspect the existing operation before starting another one.

Recovery

A failed command can describe a refusal, a completed operation whose response was lost, or an unresolved outcome. Repeating a payment or deployment without distinguishing those states can create a second charge or competing deployment.

Reconciliation checks existing evidence and repairs recorded state. A write-off accepts a loss; it is not another way to discover whether payment succeeded. Preserve the evidence and use the skill's recovery procedure to choose the supported operation.

Retirement

Pausing compute interrupts service availability. Destroying a service removes infrastructure. Neither operation proves that active jobs, prepaid credit, refunds, or payouts have been resolved.

Retirement needs an account of those obligations and a deliberate choice about retained databases, keys, and records. Keep the components needed to serve refunds available until those obligations are resolved. The installed skill has a separate retirement procedure so incident recovery does not accidentally become destructive cleanup.