Evidence

Evidence is the governing principle behind Work Records: a step is only ever reported as passed, verified, or completed if a real, independently-checked result says so.

• A build is only "passed" once a real output artifact is confirmed to exist — not merely because the build command exited 0.
• A software install is only "verified" once a fresh-shell version check actually finds the tool — not because the installer exited without error.
• A step PawOS could not check is reported as skipped with a real reason, never silently assumed to have passed.

Product disclosure

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