Completion & Charging

A run is only billed once it transitions through a server-side completion check — idempotent, so a duplicate completion signal can never charge twice.

• A failed, cancelled, retry-exhausted, or approval-denied run is never charged.
• A stale run (left in progress for more than 24 hours with no further activity) is automatically reconciled as abandoned, never billed, never left silently "in progress" forever.
• Completion is currently self-reported by the run itself — independent, connector-verified confirmation that a PR truly merged or a ticket truly closed is not yet part of this check.

Product disclosure

This disclosure is part of the PawOS documentation for Completion & Charging. It is written to make the product behavior understandable before a user relies on it, pays for it, connects an account, approves a plan, or authorizes a machine-affecting action.

What users see

• Autonomous Work appears as an unattended ticket-oriented run with investigation, plan, implementation, validation, completion, and charging state.
• Users should see eligibility, connector status, credit balance, ticket context, execution evidence, and final completion/charging result.
• When a connector cannot write back to the tracker, the user should see a structured report or supported PR/MR comment path rather than a claimed ticket update.

What PawOS does

• PawOS investigates the ticket and repository, creates isolated work where supported, applies changes through the same coding mechanisms, validates the result, and records evidence.
• Autonomous Work Credits are separate from Paw Compute and fund ticket completions only when completion criteria are satisfied.
• Billing logic is intended to be success-gated and protected against duplicate completion charges.

Permissions and boundaries

• Autonomous Work does not grant permission to install software, repair PATH, change system settings, or bypass user/organization confirmation gates.
• Connector capabilities differ by provider. Reading a ticket, commenting on a PR, creating a PR, and changing ticket status are separate capabilities.
• A run that is blocked, failed, or not verified should not be described as completed.

Evidence and records

• Completion should be supported by repository state, validation output, changed files, connector evidence where available, and billing/completion records.
• If independent connector verification is absent for a specific close/merge state, that limitation must remain disclosed.

Limitations and user responsibility

• Jira and Linear write-back from Autonomous Work is not implemented in the current docs.
• Automatic new PR/MR creation is not documented as implemented; supported connector actions should be described provider by provider.
• Eligible account, connector, repository, and credit conditions are required before an actual run can be validated.