OpenClaw Operator Flow Boundary

Last Updated: 2026-03-22 Status: Active architecture reference

This document defines the bounded operator-trust and pending-work policy for OpenClaw inside Jorvis after ADR-0029.

Use this doc for:

workspace plugin trust policy
pending-work semantics
bridge vs admin-copilot authority boundaries
non-adopted operator surfaces

Do not use this doc as proof that deeper runtime integration is already active.

Current Policy Summary

Current repo-backed policy is intentionally narrow:

OpenClaw remains an assistant/copilot layer, not an operator authority
current admin behavior is advisory and plan_only, not executable
Jorvis does not adopt sessions_yield
Jorvis does not adopt a pending-work execution queue
Jorvis does not automate workspace plugin trust

This policy is the current boundary. Any later expansion must stay inside it unless a newer ADR and exact-head GO explicitly supersede it.

Operator Flow States

State	Current owner	Runtime status	Allowed output	Forbidden transition
Observe	bridge, admin-copilot, OpenClaw	Active	explain, summarize, classify, read-only context	may not create approvals or executable work
Recommend	bridge, admin-copilot, OpenClaw	Active	advisory findings, suggested fixes, smoke/checklist guidance	may not create durable pending work
Plan	admin-copilot / bridge	Active as `plan_only`	bounded steps, validation checks, rollback notes	may not approve or execute
Approve	human operator only	Not delegated	explicit human decision outside OpenClaw	may not be inferred from model output
Execute	approved human-run workflow only	Not delegated	bounded repo/runtime actions owned by human roles	may not be invoked from prompt or pending-work text

The important boundary is:

OpenClaw may observe, recommend, and plan
OpenClaw may not approve or execute

Workspace Plugin Trust Policy

OpenClaw 2026.3.12 requires an explicit trust decision for workspace plugins. Jorvis currently treats that trust boundary as manual and out-of-band:

no repo-managed default allowlist exists
no bridge/admin-copilot/runtime path may silently trust a plugin
no repo-managed durability contract exists for remembered trust
bridge/admin-copilot may describe trust requirements, but may not set them

This keeps Jorvis from accidentally taking ownership of upstream trust semantics before a separate policy decision exists.

Pending-Work Policy

Jorvis currently has no OpenClaw-owned pending-work queue.

Current meaning of "pending work" in this repo is intentionally limited:

advisory candidate work may appear in chat text, findings, or plan-only output
those suggestions are not durable queue records
they do not carry approval state
they do not carry replay, cancellation, or execution semantics

Human operators own promotion of any advisory work into an external issue, ticket, or manually run workflow.

This means the bridge and admin-copilot may produce recommendations and plan-only steps, but they do not create a runtime work queue on behalf of OpenClaw.

Bridge, Admin-Copilot, And Runtime Boundary

Open WebUI bridge

The bridge remains responsible for:

secret-exfiltration guard
role guard
typed capability resolution consumption
session key and memory-scope derivation
optional admin-context injection
proxying to the OpenClaw gateway

The bridge is not allowed to own:

workspace plugin trust decisions
pending-work creation/approval/cancellation semantics
execution approval

Admin-copilot

Admin-copilot remains responsible for:

read-only runtime snapshot
bounded recommendations
plan_only change guidance

Admin-copilot is not allowed to:

approve execution
create an executable work queue
act as a mutation gateway

OpenClaw runtime

The runtime remains responsible for:

model execution
the current memory-search lane
upstream runtime features that Jorvis has explicitly adopted

The runtime is not the canonical owner of Jorvis approval policy, governance, or operator authority.

Human operator roles

Human roles remain responsible for:

trusting workspace plugins, if they choose to do so
deciding whether a plan should be acted on
executing approved workflows
gate/release/merge authority under existing repo governance

Current Adoption Rule

The current adopted operator boundary is intentionally narrow:

bridge/admin-copilot may observe, recommend, and plan
bridge/admin-copilot may not approve or execute
no OpenClaw-owned pending-work queue exists
no workspace plugin trust rollout is owned by Jorvis

Any later implementation must remain additive and may not silently introduce:

no new execution path
no queue semantics
no plugin trust rollout

Anything broader requires separate approval and explicit boundary review.

Non-Adopted Surfaces

The following are outside the current adopted boundary:

sessions_yield
OpenClaw-owned pending-work queue execution semantics
workspace plugin trust rollout or remembered-trust durability
admin/operator mutation tooling
bridge/admin-copilot execution authority beyond the documented advisory and plan_only surfaces
memory-search lane changes or multimodal indexing policy, which belong in the model/data docs rather than this boundary file

docs/architecture/adr/ADR-0029-openclaw-operator-trust-and-deferred-integration-boundaries.md
docs/architecture/OPENCLAW_CONTROL_PLANE.md
docs/architecture/ROLE_AND_CAPABILITY_MATRIX.md
docs/operations/OPENCLAW_OPS_COPILOT.md
docs/security/OPENCLAW_SECURITY_MODEL.md