Governed work execution means every business action a Role Assistant assists with passes through verified identity, Business Role, dimensions, policy, approvals, governed capabilities, and Evidence — before and after execution.
Enterprise Runtime may execute, wait, complete, or stop safely. Safe stop is a valid governed outcome when context, authority, or verified information is insufficient.
Why it matters
Uncontrolled execution — direct API access, silent permission expansion, or unaudited model actions — creates enterprise risk. Governed execution makes AI-assisted work accountable by design.
Operators experience this as allow, deny, wait, or safe stop on capability requests with explainable reasons. Integrators enable it by publishing Business Entity capabilities; architects define certification policy. Catalog membership (what can appear on a Role Assistant) is separate from runtime allow — see How Role Assistants get capabilities.
How it works
This is the trust path, not a fixed workflow. Each next step is evaluated from current governed context:
Verify person + Business Role
→ Resolve permitted business context
→ Retrieve permitted knowledge
→ Apply rules and Evidence requirements
→ Request a governed capability
→ Human approval when required
→ Preserve the actual result (including deny or safe stop)
Each step is verifiable: who acted, which role applied, which capability ran, whether approval was required, and what outcome was recorded. Existing applications remain authoritative for their transactions.
Authorised request → ALLOW → verified business result → Evidence
Unauthorised request → DENY → SAFE STOP → Evidence
Needs a person → WAIT → Ask or Approval in ChatGPT, Copilot, or Teams
What governance includes
| Control | Purpose |
|---|---|
| Identity + Business Role | Who is acting and which work may be requested |
| Dimensions / protection | Which records are in scope |
| Certification state | Whether integration is AI-ready for this capability |
| Policy / approval | Whether execution may proceed now |
| Evidence capture | Proof for audit and learning |
Role Assistants may recommend, prepare, and request; Operational Trust and Enterprise Runtime decide whether execution proceeds.
Human authority and explanation
When work needs a person, an Ask records information, evidence, a decline, or an allowed choice. An Approval records an approve-or-reject decision about a proposal. Neither response certifies enterprise reality or chooses the next step; the platform evaluates current context and controls before continuing.
Simple decisions can stay in conversation. The Review Workspace in Work is used when a decision needs structured comparison or richer review, then returns the person to the conversation. Why? explains an allow, deny, wait, or safe-stop outcome in readable business language. See Human tasks, approvals, and Why and Business value from work steps.
Limits
- Denied, waiting, or safely stopped outcomes are normal when policy, certification, or approval rules block continuation — operators escalate through governance, not by bypassing the platform.
- This page describes runtime behavior; capability design and upload are covered under Build → Business Entities.
Operator scenarios
Allowed execution — Role, certification, and policy align; outcome recorded in Evidence Fabrix.
Denied execution — Escalate to governance if policy seems wrong; to integrators if certification is stale or capability missing.
Pending approval — Expected path for high-risk capabilities; not a platform error.
Safe stop — Insufficient context or authority to continue; preserved as a validated result, not as success.
See Operator overview.