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 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.
• Same-repository Lobster evidence includes #9248, #9384, #9605, and independent follow-on #12276.
• 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.

Current review status (2026-09-17)

The latest revision:

• refreshes the RFC's substantive update date;
• records Lobster #12276 as independent reuse of the runtime-owned binding for bounded native Question observation and Answer/Skip brokerage;
• keeps operator.questions out of the browser and notes that the adoption remains behind a default-off flight; and
• does not claim that the full model is accepted, released, or enabled by default.

The remaining decision is maintainer acceptance of the bounded Control Model v1 and UI-artifact contract. Hosted policy, Board Model, and Config Model retain separate acceptance gates.

Sidecar specs

• 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

• 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 Control UI reference adoption and 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

Renderer paths

• Product clients own their allowlisted native component catalogs.
• Existing OpenClaw MCP Apps and Canvas remain sandboxed executable-UI paths.
• Current OpenClaw A2UI v0.8 support is Canvas-hosted evidence, not native-catalog proof.
• A2UI may become an optional renderer dialect without becoming a Control Model v1 requirement.
• Patch streaming and dynamic vocabulary negotiation remain future contracts requiring bounded semantics and cross-client evidence.

A runnable protocol-shape prototype covers exact dialect/catalog selection, composed A2UI messages, explicit MCP App fallback, structured fallback, and fail-closed version handling. It is not claimed as renderer conformance.

[clawsweeper]

🦞👀
ClawSweeper picked this up.

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

ClawSweeper review complete

ClawSweeper finished reviewing this revision. The review result is being finalized.

View the workflow run.

[clawsweeper]

Codex review: blocked before merge. Reviewed September 17, 2026, 12:06 PM ET / 16:06 UTC (Revision 30).

ClawSweeper review

What this changes

Adds a framework-neutral conversation-model proposal, artifact and hosted-policy specifications, adoption and ownership plans, and a runnable renderer-selection example.

Merge readiness

⛔ Blocked before merge - 3 items remain

Keep open for RFC acceptance. The previous date finding is fixed, the prototype proof remains applicable, and no blocking patch defect was found. Current main does not contain this proposal.

Priority: P3
Reviewed head: 33b3058804e89e89aaa748cbcb2129afb2934fb5
Owner decision: Required. See Decision needed.

Review scores

Measure	Result	What it means
Overall readiness	🐚 platinum hermit (4/6)	A coherent proposal with appropriately scoped executable proof and no remaining patch findings; acceptance is a separate process decision.
Proof confidence	🐚 platinum hermit (4/6)	Sufficient (terminal): The contributor’s direct Node transcript exercises the added prototype’s exact selection and fallback paths, including version rejection; GitHub comparison confirms that code is unchanged since the proof. This supports the demonstration, not production renderer or Gateway conformance.
Patch quality	🐚 platinum hermit (4/6)	No actionable review findings were identified.

Verification

Check	Result	Evidence
Real behavior	Verified	Sufficient (terminal): The contributor’s direct Node transcript exercises the added prototype’s exact selection and fallback paths, including version rejection; GitHub comparison confirms that code is unchanged since the proof. This supports the demonstration, not production renderer or Gateway conformance.
Evidence reviewed	8 items	Repository lifecycle requires acceptance: README requires a maintainer-discussion thread and acceptance before merging a new RFC; acceptance then requires an implementation issue and accepted frontmatter. The proposal still correctly declares draft status. Previous finding resolved: GitHub’s comparison against the previously reviewed head confirms last_updated changed to 2026-09-17 and adoption notes changed in three Markdown files; the prototype is unchanged. This resolves the retained date finding. Contributor supplied relevant execution proof: The September 9 comment supplies direct Node output for supported selection, explicit MCP fallback, structured fallback, and invalid-version rejection: #62 (comment). The fully read prototype implements those scenarios with only Node’s assertion module; its claim is protocol-shape demonstration, not renderer conformance.
Findings	None	None.
Security	None	None.

How this fits together

The proposed Control Model sits above OpenClaw’s Gateway client, turning events and history into conversation snapshots and typed commands for independent interfaces. Hosts retain presentation ownership, while the Gateway retains authorization.

flowchart TD
  G[Gateway events and history] --> T[Gateway client]
  T --> M[Proposed Control Model]
  M --> C[Control UI]
  M --> H[Independent host]
  H --> R{Trusted renderer available}
  R --> N[Native presentation]
  R --> F[Structured or sandboxed fallback]

Loading

Decision needed

Question	Recommendation
Should optional Gateway Client model subpaths and UI artifacts become the accepted RFC scope while hosted policy, Board Model, and Config Model retain separate gates?	Accept the bounded first surface: Record acceptance of conversation state and UI artifacts while retaining separate publication, support, and sibling-contract decisions.

Why: The proposal supplies a coherent design and bounded demonstration, but only maintainers can accept the long-term public contract and ownership obligations.

Before merge

• Resolve merge risk (P1) - The permanent API ownership and support window remain undecided; adopting the RFC must not imply that its linked implementations are approved or released.
• Complete next step (P2) - Link the maintainer discussion and obtain an explicit scope decision; if accepted, add the implementation issue and accepted metadata before merge. Enable Allow edits from maintainers.
• Resolve maintainer decision - Resolve the maintainer decision shown above before merge.

Agent review details

Security

None.

Review metrics

Metric	Value	Why it matters
Proposal scope	8 Markdown files +2,716 lines; 1 standalone prototype +163 lines	The growth documents candidate contracts and their gates; it adds no deployed product implementation.

Merge-risk options

Maintainer options:

1. Decide the mitigation before merge
   Accept a bounded conversation-model and artifact contract only with explicit scope disposition, preserving independent acceptance and release gates for the sibling proposals.
2. Pause or close
   Do not merge this PR until maintainers decide whether the risk is worth taking.

Technical review

Best possible solution:

Accept a bounded conversation-model and artifact contract only with explicit scope disposition, preserving independent acceptance and release gates for the sibling proposals.

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

Not applicable: this PR proposes a new contract rather than reporting broken existing behavior; the prototype’s declared scenarios have contributor-supplied execution output.

Is this the best way to solve the issue?

Yes as a design-review direction: extracting shared conversation behavior while retaining host presentation and Gateway authorization is coherent; permanent API acceptance remains a maintainer choice.

AGENTS.md: not found in the target repository.

Codex review notes: model internal, reasoning medium; reviewed against 967d9aac7472.

Labels

Label justifications:

• P3: This is a design proposal awaiting acceptance, without an established urgent runtime defect.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🐚 platinum hermit and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (terminal): The contributor’s direct Node transcript exercises the added prototype’s exact selection and fallback paths, including version rejection; GitHub comparison confirms that code is unchanged since the proof. This supports the demonstration, not production renderer or Gateway conformance.
• proof: sufficient: Contributor real behavior proof is sufficient. The contributor’s direct Node transcript exercises the added prototype’s exact selection and fallback paths, including version rejection; GitHub comparison confirms that code is unchanged since the proof. This supports the demonstration, not production renderer or Gateway conformance.

Evidence

What I checked:

• Repository lifecycle requires acceptance: README requires a maintainer-discussion thread and acceptance before merging a new RFC; acceptance then requires an implementation issue and accepted frontmatter. The proposal still correctly declares draft status. (README.md:83, 967d9aac7472)
• Previous finding resolved: GitHub’s comparison against the previously reviewed head confirms last_updated changed to 2026-09-17 and adoption notes changed in three Markdown files; the prototype is unchanged. This resolves the retained date finding. (rfcs/0029-openclaw-control-model.md:6, 33b3058804e8)
• Contributor supplied relevant execution proof: The September 9 comment supplies direct Node output for supported selection, explicit MCP fallback, structured fallback, and invalid-version rejection: RFC 0029: clarify Control Model capability and additive scope #62 (comment). The fully read prototype implements those scenarios with only Node’s assertion module; its claim is protocol-shape demonstration, not renderer conformance. (rfcs/0029/prototypes/a2ui-artifact-envelope.mjs:117, 33b3058804e8)
• Acceptance remains explicitly outstanding: The September 17 contributor comment confirms that maintainer discussion and acceptance remain open. The proposal separates Control Model acceptance from hosted policy, Board Model, Config Model, and publication ownership; all ownership acceptance records remain pending. (rfcs/0029/owner-acceptance-record.md:26, 33b3058804e8)
• Required contributor setting: The repository PR template requires Allow edits from maintainers. The live pull endpoint returned maintainer_can_modify=false and confirmed the pinned head and base. (.github/pull_request_template.md:21, 33b3058804e8)
• No established replacement on default branch: The pinned main tree has no RFC 0029 files. Searching the remaining RFCs found no Control Model, model-subpath, renderer-neutral, or session-snapshot match. A bounded all-state pull listing found no replacement Control Model proposal. No same-repository merged fixing PR or shipped implementation was established. (967d9aac7472)

Likely related people:

• unknown: The claimed source-line change could not be verified from bounded local history. (role: source history unknown; confidence: low)

Rank-up moves

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

• Link the required maintainer discussion and record its scope disposition.
• Enable Allow edits from maintainers as required by the repository PR template.

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 (29 earlier review cycles; latest 8 shown)

• reviewed 2026-08-28T17:32:59.269Z sha daab871 :: needs real behavior proof before merge. :: [P2] Link the required maintainer discussion
• reviewed 2026-08-28T17:44:36.650Z sha daab871 :: needs real behavior proof before merge. :: [P2] Link the required maintainer discussion | [P3] Refresh the RFC update date
• reviewed 2026-08-30T18:55:43.525Z sha daab871 :: needs real behavior proof before merge. :: [P2] Link the required maintainer discussion | [P3] Refresh the RFC update date
• reviewed 2026-09-02T14:11:07.726Z sha daab871 :: needs real behavior proof before merge. :: [P2] Link the required maintainer discussion | [P3] Refresh the RFC update date
• reviewed 2026-09-03T17:01:54.030Z sha daab871 :: needs real behavior proof before merge. :: [P2] Link the required maintainer discussion | [P3] Refresh the RFC update date
• reviewed 2026-09-03T20:01:54.469Z sha daab871 :: needs real behavior proof before merge. :: [P2] Link the required maintainer discussion | [P3] Refresh the RFC update date
• reviewed 2026-09-05T16:00:18.848Z sha daab871 :: needs real behavior proof before merge. :: [P3] Refresh the RFC update date
• reviewed 2026-09-09T05:29:59.965Z sha cd60778 :: blocked before merge. :: [P3] Refresh the RFC update date

[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

[giodl73-repo]

Refreshed patch-equivalently onto current main at $head. Direct Node execution of the changed prototype now provides the requested after-change evidence:

PASS supported A2UI v0.8 composition selected
PASS unsupported dialect used explicit MCP App fallback
PASS unsupported catalog/data version used structured fallback
PASS invalid A2UI version failed closed to structured fallback

Command: node rfcs/0029/prototypes/a2ui-artifact-envelope.mjs. git diff --check also passes. This demonstrates the example's selection, fallback, and version rejection; it does not claim renderer conformance or RFC acceptance. The required maintainer-discussion link remains the explicit process follow-up.

@clawsweeper re-review

[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.

[giodl73-repo]

Updated the RFC at 33b3058 with current independent adoption evidence:

• refreshed last_updated;
• added merged Lobster PR #12276 as independent reuse of the runtime-owned Control Model binding;
• preserved the browser authority boundary and default-off rollout qualification.

The required maintainer discussion and acceptance decision remain open.

@clawsweeper re-review

[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.