RFC 0029: clarify Control Model capability and additive scope

[giodl73-repo]

Updates RFC 0029 so the upstream review ask is explicit and bounded:

• Control Model v1 and UI artifacts are the first native-product surface.
• Hosted Control UI policy is now included as a related sibling sidecar with its own acceptance gate.
• Board Model, Config Model, Managed Configuration, and Policy lockdown remain additive sibling contracts with separate gates, not hidden Control Model v1 scope.
• Same-repository Lobster evidence is reflected: #9248 merged carry, #9384 merged SessionView adoption, and #9605 native-table follow-up.
• Capability advertisement is advisory/private and does not install renderers or authorize operations.
• The a2ui/uiDetails appendix includes a concrete mapping example and keeps actions non-executable.

Sidecar specs now linked from the RFC:

• Control Model v1: rfcs/0029/control-model-v1-spec.md
• UI artifact v1: rfcs/0029/ui-artifact-v1-spec.md
• Hosted Control UI policy v1: rfcs/0029/hosted-control-ui-policy-v1-spec.md

Implementation drafts linked from the RFC:

• CM1 foundation: RFC 0029 CM1: add Control Model session foundation openclaw#127670
• CM2 conversations/commands: RFC 0029 CM2: add Control Model conversations openclaw#127671
• CM3 UI artifacts: RFC 0029 CM3: add renderer-neutral UI artifacts openclaw#127672
• CM4 conformance/package/perf/compat/security hardening: RFC 0029 CM4: harden Control Model conformance and security openclaw#127674
• CM5 Control UI command/interaction/artifact adoption: RFC 0029 CM5: adopt Control Model in Control UI commands and artifacts openclaw#127675

Hosted policy siblings linked from the RFC:

• Umbrella issue: Host-controlled Control UI surface for embedded and managed deployments openclaw#115423
• Host Control UI policy draft: Add host Control UI policy openclaw#115408
• Hosted Gateway policy enforcement draft: Add hosted Gateway policy enforcement openclaw#116013
• Fork-only settings constraint evidence: feat(policy): expose settings constraints contract giodl73-repo/openclaw#196 through test(policy): add settings constraints examples giodl73-repo/openclaw#202

Scope guard: the hosted-policy sidecar is related and belongs in the one-shot RFC family, but it is not a Control Model v1 dependency. Each sidecar has an independent conformance and acceptance gate.

Validation: git diff --check in C:\src\openclaw-rfcs-control-model.

[clawsweeper]

🦞👀
ClawSweeper picked this up.

Pull request received. I will update this pull request when review starts.

[clawsweeper]

Codex review: needs real behavior proof before merge. Reviewed August 24, 2026, 3:10 PM ET / 19:10 UTC.

ClawSweeper review

What this changes

The PR adds RFC 0029 and seven Markdown sidecars proposing a framework-neutral Control Model, renderer-neutral UI artifacts, and separately gated hosted-policy guidance.

Merge readiness

⚠️ Ready for maintainer review - 5 items remain

Keep open: this is still an active RFC proposal, but it remains blocked on the repository-required maintainer-discussion record for its new package/API direction.

Priority: P3
Reviewed head: 7a8f437ce152c0f13860e43b04afbf56e50928ef
Owner decision: Required. See Decision needed.

Review scores

Measure	Result	What it means
Overall readiness	🦐 gold shrimp (3/6)	The draft is coherent, but cannot be merged until its required maintainer discussion is linked.
Proof confidence	🌊 off-meta tidepool	Not applicable: All eight changed files are Markdown RFC documents, so runtime behavior proof is not applicable.
Patch quality	🦐 gold shrimp (3/6)	1 actionable review finding remain.

Verification

Check	Result	Evidence
Real behavior	Not applicable	Not applicable: All eight changed files are Markdown RFC documents, so runtime behavior proof is not applicable.
Evidence reviewed	4 items	Required RFC lifecycle step: The repository requires every new RFC to have a maintainer-discussion thread; the RFC remains a draft with no implementation issue, consistent with that lifecycle. Missing discussion link: No maintainer-discussion or Discord thread link appears in the RFC or any submitted sidecar. Prior blocker remains unresolved: The previous completed review requested the maintainer-discussion link; the current checkout is still at the same reviewed head, so the finding remains applicable rather than newly raised.
Findings	1 actionable finding	[P2] Link the required maintainer discussion
Security	None	None.

How this fits together

The proposed Control Model would sit above OpenClaw’s Gateway client transport and provide state, commands, and UI artifacts to Control UI and other host products. The RFC defines that proposed contract and its release, ownership, and compatibility gates before implementation adoption.

flowchart LR
A[Gateway transport] --> B[Proposed Control Model]
B --> C[Control UI]
B --> D[Other product hosts]
B --> E[Commands and UI artifacts]
F[Hosted policy sidecar] --> D
E --> G[Gateway authorization]

Loading

Decision needed

Question	Recommendation
Should OpenClaw adopt the proposed Control Model and UI-artifact contract family as an RFC direction after maintainer discussion?	Sponsor and scope the RFC: Record the required discussion and use it to decide the initial API boundary, ownership, and compatibility window.

Why: The PR proposes new public package subpaths and long-lived behavioral contracts; the repository requires maintainer discussion before a draft RFC can progress.

Before merge

• Add real behavior proof - Not applicable: All eight changed files are Markdown RFC documents, so runtime behavior proof is not applicable.
• Link the required maintainer discussion (P2) - The RFC lifecycle requires a maintainer-discussion thread, but neither the RFC nor its sidecars links one. Add that discussion URL before merge so approvers can assess the proposed public contract.
• Resolve merge risk (P1) - Merging a 2,658-line RFC family without its required maintainer-discussion record would create an unreviewed compatibility and ownership commitment around the proposed Gateway Client subpaths.
• Complete next step (P2) - The missing record needs contributor and RFC-approver participation; automation cannot invent or sponsor the required discussion.

Findings

• [P2] Link the required maintainer discussion — rfcs/0029-openclaw-control-model.md:9

Agent review details

Security

None.

Review metrics

Metric	Value	Why it matters
RFC material	8 Markdown files, 2,658 added lines	The proposal creates a broad contract family, making the mandated design-discussion record important before merge.

Merge-risk options

Maintainer options:

1. Link the required discussion (recommended)
   Add the maintainer-discussion URL to the RFC before merge so the proposed public contract has a review record.
2. Pause the RFC
   Keep the proposal out of main until an RFC approver sponsors the product and compatibility direction.

Technical review

Best possible solution:

Create and link the required maintainer-discussion thread, then have RFC approvers decide the acceptable first API boundary, owners, and compatibility commitments.

Do we have a high-confidence way to reproduce the issue?

Not applicable: this PR proposes a product contract rather than reporting a reproducible defect.

Is this the best way to solve the issue?

No: the RFC has a coherent draft boundary, but it must first satisfy the repository’s required maintainer-discussion step before its API direction can be accepted.

Full review comments:

• [P2] Link the required maintainer discussion — rfcs/0029-openclaw-control-model.md:9
  The RFC lifecycle requires a maintainer-discussion thread, but neither the RFC nor its sidecars links one. Add that discussion URL before merge so approvers can assess the proposed public contract.
  Confidence: 0.99

Overall correctness: patch is incorrect
Overall confidence: 0.99

AGENTS.md: not found in the target repository.

Codex review notes: model internal, reasoning high; reviewed against af708f0ddb6f.

Labels

Label justifications:

• P3: This is a forward-looking documentation proposal rather than a confirmed current-user regression.
• merge-risk: 🚨 compatibility: The RFC proposes new Gateway Client package subpaths and behavioral contracts that could become long-lived public commitments.
• rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🌊 off-meta tidepool and patch quality is 🦐 gold shrimp.
• status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Not applicable: All eight changed files are Markdown RFC documents, so runtime behavior proof is not applicable.

Evidence

What I checked:

• Required RFC lifecycle step: The repository requires every new RFC to have a maintainer-discussion thread; the RFC remains a draft with no implementation issue, consistent with that lifecycle. (README.md:83, 7a8f437ce152)
• Missing discussion link: No maintainer-discussion or Discord thread link appears in the RFC or any submitted sidecar. (rfcs/0029-openclaw-control-model.md:9, 7a8f437ce152)
• Prior blocker remains unresolved: The previous completed review requested the maintainer-discussion link; the current checkout is still at the same reviewed head, so the finding remains applicable rather than newly raised. (rfcs/0029-openclaw-control-model.md:9, 7a8f437ce152)
• Current-main ownership history: RFC history identifies the original template and sidecar-layout contributors as the closest repository-process owners. (rfcs/0000-template.md:1, f4fdf38f4717)

Likely related people:

• kevinlin-openai: Introduced the repository RFC template that establishes the lifecycle and discussion requirement. (role: RFC template introducer; confidence: medium; commits: f4fdf38f4717; files: rfcs/0000-template.md, README.md)
• Dallin Romney: Added the RFC sidecar layout pattern used by this proposal. (role: sidecar-layout contributor; confidence: medium; commits: 3aa7d727383f; files: rfcs/0000-template.md, README.md)

Rank-up moves

Optional improvements that raise the rating; they are not merge blockers.

• Link the maintainer-discussion thread that records review of the proposed API and ownership boundary.

Rating scale

Score	Internal tier	Crab rank	Meaning
6/6	S	🦀 challenger crab	Exceptional readiness
5/6	A	🦞 diamond lobster	Very strong readiness
4/6	B	🐚 platinum hermit	Good normal PR; ordinary maintainer review
3/6	C	🦐 gold shrimp	Useful, but confidence is limited
2/6	D	🦪 silver shellfish	Proof or implementation needs work
1/6	F	🧂 unranked krab	Not merge-ready
N/A	NA	🌊 off-meta tidepool	Rating does not apply

Overall follows the weaker of proof and patch quality.
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

Workflow

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

History

Review history (17 earlier review cycles; latest 8 shown)

• reviewed 2026-08-23T09:56:29.426Z sha bca94c8 :: needs real behavior proof before merge. :: [P2] Describe the RFC as the submitted draft | [P2] Remove the false unsubmitted claim from the spec | [P2] Align the UI-artifact sidecar's submission status
• reviewed 2026-08-23T13:11:30.830Z sha bca94c8 :: needs real behavior proof before merge. :: [P2] Describe the RFC as the submitted draft | [P2] Remove the false unsubmitted claim from the spec | [P2] Align the UI-artifact sidecar's submission status | [P2] Remove the contradictory no-upstream-PR statement
• reviewed 2026-08-23T13:22:40.012Z sha 939dc20 :: needs real behavior proof before merge. :: [P2] Link the required maintainer discussion
• reviewed 2026-08-23T20:05:37.155Z sha 939dc20 :: needs real behavior proof before merge. :: [P2] Link the required maintainer discussion
• reviewed 2026-08-23T20:28:55.130Z sha 6a7d949 :: needs real behavior proof before merge. :: [P2] Link the required maintainer discussion
• reviewed 2026-08-23T21:42:35.114Z sha 6a7d949 :: needs real behavior proof before merge. :: [P2] Link the required maintainer discussion
• reviewed 2026-08-23T22:26:48.133Z sha 7a8f437 :: needs real behavior proof before merge. :: [P2] Link the required maintainer discussion
• reviewed 2026-08-23T23:45:37.396Z sha 7a8f437 :: needs real behavior proof before merge. :: [P2] Link the required maintainer discussion

[giodl73-repo]

@clawsweeper re-review

Addressed the submission-status findings at 939dc20:

• rfcs/0029-openclaw-control-model.md now identifies RFC 0029 as the submitted draft and keeps acceptance/release/product adoption unclaimed.
• rfcs/0029/control-model-v1-spec.md and rfcs/0029/ui-artifact-v1-spec.md now identify the sidecars as submitted draft sidecars, unaccepted/unreleased upstream.
• rfcs/0029/implementation-plan.md no longer says no upstream branch or PR was opened; it points to CM1-CM5 as upstream draft review surfaces and keeps OC6/OC7/BM2/CFG1/CFG2 proposal-gated.

Validation:

• git diff --check
• rg -n -i "does not request RFC intake|open an upstream pull request|has not been submitted|No upstream branch or PR was opened|fork-only preview" rfcs/0029-openclaw-control-model.md rfcs/0029 returned no matches.

[clawsweeper]

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event exact_review_queue).
Result: when the review finishes, ClawSweeper will create the durable review comment if needed or update the existing comment in place.

Re-review progress:

• State: Complete
• Detail: The durable review result and its route handoff completed.
• Run: https://github.com/openclaw/clawsweeper/actions/runs/32642208748
• Updated: 2026-08-23T13:23:54.473Z