Purpose
The Role Assistant Runtime (Enterprise Runtime) is the architecture boundary that turns an admitted business intent into safe, governed enterprise work for Role Assistants. It does not treat a conversational request as permission to act. Instead, the Decision Engine evaluates the current execution context and selects exactly one safe continuation: invoke one Runtime Function, wait, complete, or stop safely.
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.
Runtime loop
Work begins when intent admission accepts a business objective. Admission creates an Enterprise Task, carried through a Process Execution. 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, COM capability information, 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
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.