Entitlements
Internal implementation of the tier/capability gate.
A central EntitlementService resolves a subscription tier to a real, additive feature set. The execution engine checks the advancedRuntimes entitlement before allowing a request classified as execution-class (file writes, commands, code edits) to proceed — checked in the main process, before the underlying action ever runs.
Software installation and PATH/environment-variable actions are not currently included in the execution-class gate — see Coding → Software Installation for the user-facing implication and Security → System Actions for the security framing.
Product disclosure
This reference page describes the current PawOS implementation surface for Entitlements. Internal details are disclosed for clarity but are not a promise that every internal type is a public API.
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
- 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.
Warning
PawOS can assist with planning, coding, automation, connectors, billing flows, and system operations, but the user remains responsible for reviewing plans, confirmations, diffs, command effects, connector side effects, billing actions, and final outputs before relying on them.