Billing Architecture

Paw Compute (subscription usage) and Autonomous Work Credits (a dollar wallet funding ticket completions) are deliberately separate systems — a credit purchase can never be read by the ticket-billing code path, and vice versa.

Autonomous Work completion billing runs through an idempotent, server-side RPC — a duplicate completion signal can never charge twice, and a stale run is automatically reconciled as abandoned rather than left billing indefinitely.

Product disclosure

This disclosure is part of the PawOS documentation for Billing Architecture. 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

• Reference docs are intended for engineers and administrators who need to understand process boundaries, IPC, runtime action types, evidence records, entitlements, billing isolation, connector architecture, and current API/SDK status.
• Users should expect architectural disclosure, not marketing copy.
• Reference pages should identify which contracts are public, internal, implemented, partial, or reserved extension points.

What PawOS does

• PawOS is an Electron application with main, preload, and renderer responsibilities separated by typed bridges and IPC.
• Runtime actions use shared request/result types, with main-process plugins performing the actual side effects.
• Evidence, billing, connector, and entitlement systems are intended to be separable so one subsystem cannot silently stand in for another.

Permissions and boundaries

• Internal TypeScript types are not automatically public API guarantees.
• A documented extension point is not the same as a shipped external SDK or supported third-party plugin API.
• Architecture docs should not imply a provider, connector, payment path, or runtime exists unless it is actually wired.

Evidence and records

• Reference claims should be traceable to implemented modules, tests, build outputs, or explicit limitation statements.
• For compliance-style use, Work Records and connector/billing records matter more than natural-language claims.

Limitations and user responsibility

• Public API and SDK surfaces remain limited unless a page explicitly documents a supported external contract.
• Architecture may evolve; changelog and release notes should identify user-visible behavior changes, not only implementation details.