Main / Preload / Renderer
The three-process boundary and why it exists.
| Process | Owns |
|---|---|
| Main | Filesystem, process spawning, native OS integration, the execution engine, entitlement checks |
| Preload | A narrow, explicitly-typed bridge exposing only specific main-process capabilities to the renderer — never raw Node access |
| Renderer | UI, the 3D companion, conversation state — calls into main only through the preload bridge |
Note
This boundary is what makes the confirmation/entitlement gates real security checks rather than UI conventions — the renderer cannot bypass them because it has no direct filesystem or process-spawning access at all.
Product disclosure
This reference page describes the current PawOS implementation surface for Main / Preload / Renderer. 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 Main / Preload / Renderer. 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.
Related