Governed work execution

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.

Stating a business objective is itself the action that starts governed work, and that start reaches the same first decision every later step reaches: execute, wait, complete, or stop safely. There is no additional state where work is simply "running" in the background with nothing pending for a person or the platform to act on — silent execution with no next step is not a valid outcome here.

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)

Operators read a business-readable result. Technical identifiers stay in a restricted trace — they are not the operator record of what happened.

In Assistants, worker:read lets an operator list tasks, but it does not reveal another person's bound Result. A cross-principal Result or execution-detail inspection also requires audit:read or worker-runtime-trace:read; without either permission, the operator sees access denied rather than an invented partial Result. This narrow operator view does not transfer task ownership or relax the owner-only Result boundary in Work and external AI tools.

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

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. See Human tasks, approvals, and Why for the full Ask, choice, and Approval distinctions.

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 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.
• Result presentation and execution-detail depth can differ by tenant and task. Restricted trace access is for investigation, not a substitute for the validated business result.

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.