Entitlements

An entitlement is a real, backend-enforced capability gate — checked by the main process before an action runs, not a UI-only restriction a client could bypass.

The tier ladder is additive: Go → Pro → Pro Max → Team → Enterprise. The single most consequential gate is advancedRuntimes — it separates read-only planning/analysis (available on every tier, including free) from real execution (writing files, running commands, editing code), which requires Pro or higher.

Product disclosure

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

• Concepts appear in the product as workspaces, tasks, task cards, plan review cards, confirmation prompts, Work Records, usage meters, and connector status.
• Users interact with concepts through normal requests rather than through an abstract configuration console.
• The same vocabulary appears in documentation, billing, security, and troubleshooting so a user can trace what happened after a task finishes.

What PawOS does

• A workspace scopes file and command work; a task groups one user request; a plan proposes future work; an action performs one concrete operation; evidence records what actually happened.
• The renderer displays task state, while the main process owns execution and security-sensitive checks.
• Execution records are assembled from real action request/result data rather than a free-form after-the-fact summary alone.

Permissions and boundaries

• Concept names are not permissions. Calling something a workspace, plan, or task does not remove confirmation gates.
• PawOS can reason about a requested outcome, but the model does not directly mutate the user machine; deterministic action handlers do.
• Entitlement gates and confirmation gates are separate protections and may both apply to the same request.

Evidence and records

• Evidence should identify the command, file, connector, validation step, screenshot, or result that supports a claim.
• A Work Record can honestly show partial success, skipped validation, a rejected plan, a failed command, or a blocked permission request.

Limitations and user responsibility

• Not every runtime emits the same richness of structured evidence yet; generic timelines remain the fallback where specialized evidence is not implemented.
• Plan state after approval depends on the existing conversation and execution handoff and should not be interpreted as a full lifecycle engine unless step transitions are recorded.