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:

  1. workspace plugin trust policy
  2. pending-work ownership and execution semantics
  3. bridge versus admin-copilot responsibility boundaries
  4. 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:

  1. sessions_yield adoption
  2. pending-work queue integration
  3. any workspace-plugin enablement model beyond operator caveat documentation
  4. memory/search integration changes driven by newer OpenClaw releases, including baseline model switches or multimodal indexing adoption
  5. 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:

  1. 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
  2. Pending-work ownership
    • whether pending work is advisory only, operator-approved, or executable
    • who owns creation, approval, cancellation, and replay semantics
  3. Bridge/admin-copilot boundary
    • what remains bridge-owned
    • what remains NestJS/admin-copilot-owned
    • what data and authority may cross that boundary
  4. 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_yield now. 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.12 upgrade 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.12 upgrade 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