ADR-0029: OpenClaw Operator Trust And Deferred Integration Boundaries
ADR-0029: OpenClaw Operator Trust And Deferred Integration Boundaries
Date: 2026-03-13 Status: Accepted Author: Architect Agent Supersedes: N/A
1. Context
Jorvis has already merged the bounded OpenClaw runtime upgrade to v2026.3.12
via PR #477. That lane intentionally upgraded the tracked runtime baseline
without adopting deeper OpenClaw control-plane behavior.
Current merged/runtime truth remains bounded:
- OpenClaw runtime image is
ghcr.io/openclaw/openclaw:2026.3.12 - current memory-search baseline remains
gemini-embedding-001 - no adoption of
sessions_yield - no adoption of pending-work queue primitives
- no multimodal memory-indexing expansion
- no bridge/internal/admin-copilot widening beyond the already merged bounded surfaces
OpenClaw v2026.3.12 also makes explicit trust and operator-policy questions
more visible:
- workspace plugins now require an explicit trust decision
- upstream session/pending-work features imply an execution-authority model
- any deeper bridge/admin-copilot integration would widen control-plane boundaries across Python bridge, NestJS internal services, and operator-facing surfaces
Jorvis does not currently have a formal architecture decision that defines:
- workspace plugin trust policy
- pending-work ownership and execution semantics
- bridge versus admin-copilot responsibility boundaries
- operator authority for proposal, approval, and execution
Without those prerequisites, a new deeper OpenClaw integration lane would be a policy decision disguised as an implementation slice.
2. Decision
We formally defer any new deeper OpenClaw integration slice at this time.
The merged v2026.3.12 baseline upgrade is runtime truth only. It is not
an implicit authorization for deeper Jorvis/OpenClaw integration work.
2.1 Deferred Until New Stage 0 + Fresh GO
The following are explicitly deferred:
sessions_yieldadoption- pending-work queue integration
- any workspace-plugin enablement model beyond operator caveat documentation
- memory/search integration changes driven by newer OpenClaw releases, including baseline model switches or multimodal indexing adoption
- admin-copilot / bridge integration slices justified only by the new OpenClaw baseline
2.2 Policy Prerequisites Required Before Reopening
Any future deeper-integration proposal must first define:
- Workspace plugin trust policy
- who may trust a plugin
- whether trust is per workspace, per operator, or per runtime
- whether trust is durable or session-scoped
- Pending-work ownership
- whether pending work is advisory only, operator-approved, or executable
- who owns creation, approval, cancellation, and replay semantics
- Bridge/admin-copilot boundary
- what remains bridge-owned
- what remains NestJS/admin-copilot-owned
- what data and authority may cross that boundary
- Operator authority model
- which actions are observe-only
- which actions are recommend-only
- which actions require explicit operator approval
- which actions are prohibited from automated execution
2.3 Re-entry Rule
If Jorvis later revisits deeper OpenClaw integration, the next artifact must be
a fresh Stage 0 spec anchored to current origin/main, with:
- a concrete problem statement
- one bounded slice only
- explicit file contract
- explicit policy assumptions
- explicit verification/evidence plan
- fresh GO issued on the exact review head
This ADR does not issue that GO.
3. Alternatives Considered
- Start
sessions_yieldnow. Rejected: it changes session continuity and operator-execution semantics before Jorvis has an authority model. - Start pending-work queue integration now. Rejected: queue ownership and execution approval are undefined.
- Treat the
v2026.3.12upgrade as implicit approval for broader OpenClaw work. Rejected: the merged upgrade lane explicitly excluded deep integration. - Bundle bridge/admin-copilot expansion into a future runtime patch. Rejected: this would collapse architecture and implementation decisions into one uncontrolled slice.
4. Consequences
Positive
- preserves the bounded OpenClaw
v2026.3.12upgrade as a stable runtime baseline - prevents control-plane widening without an explicit operator-policy model
- keeps bridge, admin-copilot, and runtime responsibilities separable
- makes future deeper-integration work depend on architecture-first scoping
Negative
- Jorvis does not immediately adopt newer upstream session/pending-work capabilities
- workspace-plugin/operator flows remain intentionally conservative
- any future deeper-integration lane now requires extra architecture prep before implementation