Purpose
AI has no authority of its own. A conversational request is not permission to act — every action must run on behalf of a currently verified, identified person and case, not an assumption made once at setup time. The Role Assistant Runtime (Enterprise Runtime) is the architecture boundary that verifies that authority and turns an admitted business intent into safe, governed enterprise work for Role Assistants. This is step 4 of the section's define-once, verify-every-time pattern — see Architecture overview. The Decision Engine evaluates the current execution context and selects exactly one safe continuation: invoke one Runtime Function, wait, complete, or stop safely. This is a required first decision on every started task — not silent running with no next step.
Accepted Intent → Enterprise Task → Process Execution → Decision Engine → one Runtime Function or wait / complete / safe stop
No predefined workflow
The Runtime does not execute a fixed Intent → Reality → Knowledge → Evidence sequence. Order is determined from the current snapshot, Operational Trust, and available validated artifacts — not from a hardcoded pipeline.
The same Runtime Function may run more than once. Runtime Functions do not call each other directly; each returns a validated artifact into a new snapshot for the next Decision Engine evaluation.
Related work emerges from decisions, not from a plan. When admitted work touches related records — for example, updating a contract that also affects a linked account or a pending approval — the platform does not run a workflow the client sent, and it does not execute a stored step graph written down in advance. Each related record is reached through a successive governed decision made from the current business context: the Decision Engine evaluates the new snapshot the same way it evaluated the first one, one safe continuation at a time. No client-authored sequence and no cached multi-step plan ever runs unchecked.
Runtime loop
Work begins when intent admission — the platform check that accepts a business objective as legitimate work — completes. Admission creates an Enterprise Task (the tracked unit of that admitted work), carried through a Process Execution (the stateful carrier of the objective through Runtime decisions; see Process Execution Output for how it concludes). On each cycle:
- Intent / task context carries the business objective and role-scoped request.
- Decision Engine chooses the next safe action from current Reality, Knowledge, Evidence, available governed capabilities, and prior outputs.
- One Runtime Function may read Reality, derive Knowledge, read or store Evidence, execute a governed capability, or record a human interaction — never a private bypass around Operational Trust.
- Continuation continues, waits (Ask / Approval / missing context), completes, or stops safely.
When a Process Execution completes or stops safely, Process Execution Output records the validated business result. Conversation channels, temporary Review Workspace, Assistants, and Enterprise MCP present that result; they do not invent a second success story from chat memory. See Process Execution Output.
Human interaction boundary
A required human decision remains the human's decision — the Runtime cannot infer it, default it, or act on someone's behalf without it. Human interaction records a typed response (Ask value, evidence reference, decline, choice, or Approval).
- An Ask answer fuels the current execution; it is not certified Evidence by itself.
- An Approval accepts or rejects a proposed business change (including Evidence certification when that is the proposal). It does not invent Reality from chat, grant new permissions, or skip later trust checks.
The Decision Engine evaluates the recorded response with current Reality and trust controls before selecting the next step. See Human tasks, approvals, and Why.
Fail-closed operational trust
Operational Trust is fail-closed at the execution boundary. If required identity, role scope, protection, certification, policy, or capability conditions are unavailable or do not pass, the Runtime does not execute the requested action. It records a governed outcome that can be explained and reviewed instead of attempting a best-effort write.
The Capability gateway is the mandatory boundary for governed execution. The Runtime requests business capabilities through that gateway; it does not call underlying systems directly.
Freshness and safe stopping
Time-sensitive decisions are guarded by expiry and stale-state checks. A human task may remain readable after expiry, but the Runtime does not replay an old response into changed business context. When work cannot safely continue, it enters a visible wait or safe-stop outcome rather than silently progressing.
What does safe stop mean?
The Runtime preserves the current outcome and explanation when it cannot prove that continuing is safe. A later request can begin from fresh intent and current enterprise reality.
Architecture value
The Runtime separates user-facing conversation from the governed decisions that advance enterprise work. It makes human responses, Evidence, current Reality, and capability execution explicit boundaries so Role Assistant work remains explainable, reviewable, and safe under changing conditions.
Limits
Runtime Functions, available decision paths, and operational evidence vary by deployment. This architecture describes the governing boundary; it does not guarantee that every business objective has an available capability or can proceed without a human decision. Platform and first-party assistants must use the same Runtime path as customer Role Assistants — a private bypass means the Runtime is incomplete.