Workspace governance
The workspace is the durable control boundary for approval, policy context, workflow authority, proof export, and delegated execution.
Why the workspace boundary matters
Enterprise buyers do not want agent controls that float at user-session level. They want a named operating boundary with owners, membership rules, approval posture, runtime policy, workflow authority, and export authority. In OSuite that boundary is the workspace.
What belongs to the workspace
- Approval tiers and escalation behavior
- Runtime connection policy
- Workflow-connected governance and delegated execution scope
- Export destinations for proof and compliance artifacts
- Plugin enablement and scope grants
- Identity trust posture that contributes to action review
- Evaluation posture and learning-loop ownership
- Named owners for governance, billing, and security operations
Why this is different from a project setting
A project setting is usually application-local. A workspace boundary is meant to survive runtime changes, model swaps, provider changes, partner integrations, and workflow refactors. The point is to keep governance durable while the execution substrate evolves.
Control flow
- An action enters through a runtime, SDK, relay, or observer import.
- OSuite normalizes the action into a stable envelope.
- The workspace provides approval policy, allowed lanes, plugin scopes, workflow context, evaluation posture, and export posture.
- PCAA closes the decision and preserves replay, proof, and accountability in workspace vocabulary.
What buyers should be able to ask
| Question | Expected answer |
|---|---|
| Who owns approvals for this environment? | Named workspace owners and approvers |
| Can plugins change final authority? | No. Plugins contribute signals but do not replace certificate closure |
| Can a user leave without collapsing evidence history? | Yes. Evidence stays attached to the workspace object |
| Can the same account hold different authority in different environments? | Yes. Authority is delegated per workspace |
| Can a runtime self-expand its permissions inside a workflow? | No. Delegated execution remains bounded by workspace policy and scope grants |
| Can workflow context survive provider or runtime changes? | Yes. The workspace remains the durable authority boundary even when execution substrates change |