Work Records

A Work Record is the real, structured trace of one request — what commands ran, which files changed, what was verified, and why it stopped if it stopped early.

It’s derived from an internal ExecutionRecord, which accumulates real evidence as actions run: command text, exit codes, real stdout/stderr, file operations, and structured validation results (typecheck/build/test/lint). Sections with no real evidence render an honest empty state — never a fabricated summary.

Product disclosure

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